[Music]
anyways the anyways the gist of this
entire uh presentation is pretty
simple can agile actually be done in
operations a lot of us uh in various
organizations we have uh Senior
Management SE Suite coming down and
saying we need to change our uh Pro uh
programs to follow agile methodologies
mainly because For Better or Worse they
they may read K one the Southern's books
um scrum how to do twice the work in
half the time which is quite literally a
terrible title for the average uh worker
there because
it doesn't necessarily mean there will
anybody can achieve
that but coming from the basis there
outside of the
general agile
Manifesto what is it in the first place
there's 12 uh princip 12 guiding
principles regarding agile in this case
um uh it's basically the highest
priorities satisfy the customer through
early and continuous delivery of Val
software in this case you you you do
smaller production runs in order to to
achieve this um welcome changing
requirements even later in development
the idea is you with these smaller
production runs you're more able to
accept change in the actual program
deliver working software frequently for
a couple weeks or months uh of time with
a precedence for short time scills we
probably we see this most commonly with
scrum we've got spreads going from one
week two weeks four weeks on average for
they are being
done business people and developers must
work together daily throughout the
project simple uh it's not uh in this
case it's management and the employees
the analysts and so there have to Simply
put work together for this it's not uh a
separ it's not that they in and that's
it there is input from that there has to
be continuous input from management to
uh the team and vice versa to from the
team to management for
this the face-to-face
conversation right now it's a little bit
iffy due to work from home and so on for
that there but it does work ideally you
can uh it could be set up as team chats
and similar for scrum we have the uh uh
the morning meetings where we all meet
up and see where we're at for this the
key takeaway is more than anything is
keeping a line of conversation and
communication going for
this working software is a primary
measure of progress basically you ship
products that work uh the idea is you
don't have to it doesn't you don't have
to ship the entire product or that or
you ship parts of it as long as they
work so in this case sub diving the work
the project work into something smaller
always
helps uh Pro agile processes promote
sustainable development uh sponsors uh
the sponsors developers and users should
be able to maintain uh concert Pace
indefinitely basically don't overwork
yourself you're not you've got 40 hours
of week of work you should not be doing
ex work outside of that it's too much
you're going to be burning out the
entire idea between behind agile is not
really to do twice like it says twice
the work and half the time it's to
increase it's to gradually increase the
performance of a team without
necessarily having to increase overtime
expenditures for uh for that and even
just general stress on the team for this
it's in reality it's trying to optimize
uh the process of what you're
doing and here uh Simplicity the art of
maximizing the amount of work not done
is
essential uh in your projects you're
you're going to be looking saying you
how much actually needs to be done what
do we need to implement for this this is
the part where you actually start
cutting down the size and scope of a
project so uh not as a whole but in
sections you implement part of it good
make sure it's running you start
implementing the second part as a
continuation for that uh you make sure
that the parts that the sections you're
doing go up to a whole product or whole
solution in a m in a certain am of time
it doesn't matter uh the interest is not
to burn out and making sure that you're
not doing too much stuff all at the same
time you're configuring a Sim and also
ingesting new alarm new sources of logs
and generating new alarms at the same
time yeah you're going to be overworked
you're going to be flooded with alerts
they have no idea how to resolve that's
uh against the idea of Simplicity in
this case and you're going to be
firefighting more than actually doing
the work to implement the Sim best
architectures requirements and Designs
emerge from self-organization of teams
in this case talk to people on the
ground if you're a manager or uh leading
a teams ask them what do you think of
the tools can or what can what are we
doing wrong in our
processes talk to them get them get
their opinions on what can be improved
because they are the people who are
primarily solving these uh questions and
everything uh that's being done your job
if you're in management is to listen to
them and see if the ideas they provide
have any value and you can push to upper
management to get approval for that at
regular intervals the team reflects on
how to to become more effective and
tunes adjust this Behavior accordingly
same thing what I was going on before
set up times to listen to that you're
doing a Sprint to every two sprints
three Sprints or whatever you want for
that just as long as it's regular hold a
team meeting and say Hey you know let's
see what we're doing wrong what can we
improve on uh for this overall the
process I'm not talking about just a
scrum or the general uh or uh project
for that but on every single process a
company is well not a company but an
organization do is doing in security
operations the origins of agile agile is
old surprisingly old it technically
originates from around the 1990s but the
foundations are go back to the 1980s and
1970s primarily through the theory of
constraints by gold Rat for this any
system is limited from achieving more of
its goals by a smaller number of con by
small number of constraints and by
focusing to identify and restructure the
organization around them we limit their
impact we're we're going to have people
who are overworked who have who have
tons of tasks being sent to them they're
a constraint we might have to be working
with other teams and waiting for them to
complete the task that we assigned to
them those are constraints and also
dependencies for
that we have to work around those
concepts for this basically identify the
constraints the Bott necks this how how
to exploit them exploiting them in
Project manag means can we use them to
can we use keep them as is and use them
to improve our work or do we see about
finding way to get rid of them or
anything um subordinate everything to
the above decision how are you going to
deal with the constraints that's the
final decision on improving the process
for that Elevate the systems constraints
make sure that those constraints are if
you can't get rid of them or you have to
work around them uh make sure those uh
constraints are always worked around and
identified in projects or tasks that are
going to be done making sure that either
the person or the team is not overloaded
because of that of that one constraint
after the constraint breaks which is
it's eliminated you go back to Step One
simply because there's going to be other
constraints underneath it some things
other stuff will come out there don't
just go with a nura say oh yeah uh it's
all this thing is fixed and we can go on
as is it's new things will be popping up
find find the stuff find what's next
underneath that and work around
that
the
uh the theory of con rats also Advocates
keeping the inventory product inventory
of products low in this case it's
manufacturing you can't make new
inventory when you can't sell it that's
going to it's going to be sitting around
you're going to be paying to keep it in
the shop Warehouse or anything there at
the same time your in work inventory has
to be also kept Low by small batches
you're you're if you're not selling the
stuff that you're making immediately
you're going to fill up in inventory
with half-made products in this case
what is in uh what is inventory what is
the product in our case incidents and
tickets uh work is transforming one
thing into another we uh we transform
tickets
incidents and tasks from things that
need to be done to be done with by doing
work that's simply put this is the
actual product that we do we work on
it's tickets that's all our inventory
for that the time to process an element
of inventory is key to finding where the
bottle next appear slas kpis there you
go inventory is anything that requires
labor to create or modify and like I
said uh ticket it's tickets incidents uh
tasks from teams other other people that
uh matter in this case that we have to
work
on continue on with the origins of agile
the toy way
first aspect continuous
Improvement it's a CH it's you have the
first Cas is challenging long-term
vision for company or program this is a
little bit uh weird for most of us it's
uh it's not the idea of saying oh we
want to be the best uh cyber security
team out there yeah that's unattainable
that's generic or that there you need an
actual specific uh goal that you want to
reach which maybe you it's impossible
but it creates a specific uh path to
actually achieve it say in Security in
in security operations here the goal is
with uh to respond to any new ioc that's
published online to create uh uh to
create detection rules block uh block uh
ways to block it and secure our systems
within an hour of publication that
everything is done that we have thees in
every AV in in our we have alerts in our
Sim we have automations implemented to
actually identify it delete it or handle
it there everything's done within an
hour after it's been
published it's an idealistic vision for
that there and most likely nobody's
going to actually obtain it but it is a
realistic goal that uh your team can
push
for uh Kaizen we've heard of this a lot
of time continuous Improvement for
thisat go to source to find the facts
and make correct the correct decisions
you have a problem go if you in this
case there's a a person that's taking
too much time on for his work or he has
too many tasks being assigned to them go
to them talk with them find out how you
can help them out for this if it's
another team that's slowing you down go
talk with the management there see
what's the problem work with
them respect for
people respect respect for others and
take responsibility to do our best uh to
build Mutual trust in a
team one of the biggest issues I
see teams is saying if we try to build
trust we also try to assign blame to if
something fails oh you you didn't find
this you let this uh fishing ticket uh
go through yeah everybody makes mistakes
you might be overloaded with the number
of tickets there so you get you have
ticket fatigue there happens find
the reason why if it's human error okay
maybe you can automated it there uh for
that if it's too many tickets ticket
fatigue see how you can fix that those
are uh that's uh the respect that for
teamwork in this case sorry respect for
others in a team teamwork stimulate
personal and professional growth share
opportunities of development and
maximize individual team individual and
team
performance training give opportunities
for uh people to learn uh Mentor them uh
give them find training Solutions or
potentially have them work with other
teams to see what they're doing for that
always uh provide growth opportunities
for that because the more the uh your
team knows the wider their breath of
experiences the potentially they
potentially can help out on improvements
uh better the right process create a
process that can bring problems to the
service this is key most of us are
throwing have projects going on we're
throwing things left and right pasta
wall to see what sticks and hopefully
things don't break that's literally
working without a
process you have to create a process to
identify where things are going wrong
use a poll system to avoid
overproduction so you have tickets here
the qu it's a question now are you guys
is your team being forced to do assign
50 tickets each day every person without
any consideration for the amount of work
that they can do or that or are they
pulling the tickets themselves in this
case the amount of work that's being
done so on there should be controlled by
the you by the employee the user the
analyst there but it needs to be a level
of trust that they know that they're
actually doing the work for this level
out the workload don't overwork uh
workers same
thing build a culture where it's okay to
stop a process in order to fix it when
problems are identified you find
something that's broken for that you
stop all analysis on tickets that were
generate for that completely find out
what really happened and then go back on
analyzing
them if you keep on going saying oh yeah
it's broken we'll get to it you won't
get to
it
standard standardize tasks and processes
same thing when you know the process of
what you're do how you're supposed to be
doing things especially playbooks for
example those help out a lot use visual
control so no problems are hidden in
this case visual control is actually
looking at the problem in this
case you can consider this playbooks you
can have playbooks in various sources in
a Word document or anything there but if
your playbooks are running as stories as
actual processes in your ticketing
system yeah the user has to keep an eye
on actual and on doing every actual step
to do
this um use already tested
technology don't don't uh simply put
don't reinvent the wheel sometimes it's
cheaper to actually pay for something
for that and get it in produ get in
production running everything there and
people trained up it'll be faster than
trying to rebuild the entire
thing and paying money for developers to
actually try to duplicate
functionality add value to organization
grow grow leaders who understand the
work live the philosophy and
teach help people make sure your uh
managers follow uh follow the basics
here for respect and uh identifying
these uh these uh these uh features of
agile for this develop people and teams
who follow the company's philosophy
create uh you have a company culture
there make sure it's good and make sure
that uh the team follows it there
respect partners and suppliers by in uh
challenging and helping them improve
you've got you see your products that
you're buying from another company have
bugs they're half finished or that there
yeah just don't go yelling at them
saying hey you know your your stuff is
crap it's not finished it's not done say
hey you can you can really improve your
product if you start if you put this
feature in that it help us us a lot and
pro potentially allow of your customers
to improve your product and potentially
sell better sell it for that work with
them not just blame
them continuously solve root problems
drives organization
learning when you find a problem or
incident there you do the postm learn
from that simply this the entire
organization has to be Orient itself
around that any problems any issues you
have to learn from them either as
analysts managers or heck even the SE
Suite it's basic in in the end it's
basically project management with up to
a point without the project managers
every plan fails when confronted With
the Enemy the further you plan out work
the more of a chance unexpected work or
circumstances will wreck your
schedule as you know Gant Arts don't
last uh uh a week usually waterfall
works when plans don't change for this
increasing flexibility means breaking it
work up into smaller and more manageable
chunks iterate based on chunk size work
with team leads management
here the the chunk size is key you have
to know how much you're going how much
is needs to be done and I these
methodologies you've got all the usual
letter jumble scrum cam ban
scrumban in general for this scrum you
you keep lower number of team members
three to nine mainly because
communication is a lot easier
everybody's on the same page cam ban
scrumban people are more independent in
what they're doing for this um team
roles scrum members assign different
roles and
responsibilities uh caman you've got
generalist people are picking up work as
it comes scrum ban everybody's doing
whatever they can for this work cycle
scrum you've got Sprints that last from
anything from 1 to four weeks uh cam ban
could use workflow uh
scrumban uh two we iterations with
continuity the uh you got you
have tasks which spill over to next week
for that there it's not that the taxs
are not done but they might just take a
little bit more time overall for this
there's no penalty in that case rules
scrum is strict regarding the rules you
can't add a new work once sprinted
started for that cam ban relaxed
flexible throw stuff on the backlog
people will pick it up and uh work on it
scrumban it's a little bit in the middle
for that there you've got the iterations
for that IDE you shouldn't be adding too
much work in the middle for that but
it's flexible to allow uh new stuff to
be
added task assign assignment there are
separately tasks are assigned by to team
members um uh cand team members choose
the work based off what's needed first
and scrum band in general team members
choose whatever they want to do based
off of uh their teams or projects for
that
limits it's everything is based all
around the current Sprint in scrum you
can't add new stuff in you can't really
take off anything for that there limits
here in caman it's a work in progress
you don't overload yourself or your
staff everybody's doing a certain amount
of work make sure that they're work
always working on something and that's
it scrum band limits are placed on work
in progress you've got same thing with
the caman you don't over overload your
team on uh on the tasks that are there
even though there might be a two we
limit to actually complete
them your usual scrum meetings Sprints
one to four weeks then Sprint planning
first dayve of Sprint product owner
scrum Master scrum team which means
product owner your manager scrum Master
uh the guy who's stuck with the job and
the scrum team everybody else in the
team potentially an
hour B depending on team size and the
only objective is set the spr goal what
what tasks are you going to be doing in
these uh next two weeks or so on daily
scrums as name goes daily you've got the
scrum master and the scrum team the
product owner or product manager is not
included on these meetings there they're
supposed to be informable lasting no
more than 15 minutes and the main
questions we have what did you do
yesterday what are you doing today do
you have any blockers or issues that are
coming across that need help Sprint
review it's done at the end of a Sprint
scrum team scrum owner scrum Master
everybody for that it can last two to
four hours in this case for development
you you do a demo of of the work
done also user stories confirm and
decide on incomplete ones do we close
the incomplete ones and issue new t uh
new tasks or new user stories for that
or do we get rid of them and we take a
look at the backlog uh what we uh what
can we push back into backlog or if
there's anything new that's been added
spr
retrospective this one's also between
the the View and planning meeting the
entire idea is everybody's in this but
it's at this point it just looks at uh
the process you know what went wrong
that we failed to do all our all our
tests why uh how can we improve on this
what was done well also backlog
refinement every other week depends on
uh the duration of the Sprint same thing
everybody included no defined ation in
this case here it's just prioritized
backlog items what's in the backlog do
we are we still doing these things do we
still need them uh a line in this case
backlogs to kpis there are is are the
tests are we doing really needed for our
work for this that we planned out or has
have things change also and appropriate
sizing of backlog items is the amount of
work that the size of the items in the
backlog can you do them in in a day or
less
or are they take going to take you five
or six days that's the question can you
do them in a Sprint verify they the
items that are listed in the backlog can
actually be done for that and eventually
adding more detail to work uh to worklog
uh backlog what is actually the task
that's supposed to be done instead of
just writing a single title for
that ad isn't simply a methodology for
that so stay away from cargo cult agile
uh an organization wants to implement
agile can't just order the use of scrum
or Canan across the board every
operations team will have different
organizational and business requirements
for this it's a two-way street the
methodologies can can be implemented
partially or in a hybrid manner but
institutional organization must also
change to give project managers product
owners team leads more initiative to
initiate and Lead changes for this so
you have to give more power to people
below you as as much
as having people up top saying that they
want to do the organization to be
agile scrum can also help grow your
team it's not necessar but can help in
Team Evolution you've got the usual
stages of team development forming and
storming more structured work
environment is beneficial norming as
people get used to working together and
their tools the structure can be eased
as need needed performing less outright
structures needed as team members know
what they're supposed to do and are
active in choosing tasks to complete
they're self-managing at that point
adjourning or changes in structure other
than closing teams people will come and
go so it might be useful to reimplement
some of the more structured elements in
scrum and so on there to identify issues
with Team organization and to be used as
corrective measures if things are
starting to
go
off regarding team
performance actually putting to Agile to
work devops the culmination of agile in
the development World in
development the accumulation of agile
can be said to be devops devops has the
same principles as agile while not
necessarily following the strict
methodologies it defines objectives
regarding the types of work and the
technique used to achieve them it
expects good knowledge of what team
members are doing and and creating
implementing tools uh that can well and
creating imple create Implement tools
that can uh Implement changes
frequently uh the biggest talk on devops
the past couple years is the famous one
I
believe 10 uh 10 changes a day U I don't
remember the actual full title for that
but it's uh from the flicker team from
around 2008 the idea is that they were
pushing out more than 10 changes every
day to their code base on their
website frequently and the question is
how many changes how many changes are
you pushing out in your organization I'm
not talking about development but
actually changes in uh in platforms or
so on there how often are you doing that
there how in one day how many
things are being done like that that's a
question and the basis for that we see
is the software development life
cycle types of work and priorities the
four types of work this is from G Jean
Kim's Phoenix project in devops handbook
business projects generally highest
priority bu business initiatives most of
development work internal IT projects
highest priority uh infrastructure and
it
operations updates and changes normal
priority often generated from the two
types uh previous types of work and
unplanned work or recovery work which
should be limited as much as possible
incidence gen and problems generated by
other work here's the kicker incid
should be limited or eliminated so that
basically means that
we that by UPS uh we're out of a
job but here we go it doesn't
necessarily mean that it just means
prioritizing certain types of
work systems thinking and flow of
work uh work goes from one direction to
uh in Only One Direction never flows
backward based off
of what's in organization if something
goes back to the same person to be fixed
or something like that then there's a
problem for that you identify why flow
back and fix the process amplify
feedback loops learn from current
process and find
improvements uh Implement improvements
into the process see what can be
improved can you work faster better add
in automations for that this is the feed
initial feedback loop experimentation
try multiple ways of improving uh
processes and work
can you automate these things in
different ways can you use different
Tools in your that you have in your
organization to do the automations or do
the same task there which one is better
this is most commonly known in
development it's AMD testing for the uh
which
is which I would say Facebook is famous
for devops foundations of security Dev
SEC
Ops uh from the priorities there's a
difference between Enterprise and mssp
work in Enterprise environments
Enterprise and team projects uh take
priority for that maintenance and
operation work uh tests for other teams
installation of software Etc is lower
priority incidents take Engineers away
from improvements that should be and
should be limited 80% of uh the project
op is op project Ops work 20% incident
work how how do we get there automate
incidents and uh operations to meet kpis
and team
slas for an mssp it's a different
story maintenance operations work can be
handled separately from the team
compared to security monitoring instance
are the main work done in this case the
it's the opposite uh for this 80% inst
work 20% identifying improvements based
on based on the agreements with other
organizations apply automation and
process improvements to me kpis and
slas if you can do automations for that
great it'll depend but may depend on uh
your contract with the with another
organization starting to change to Agile
people process tools change has to come
from both the top Ser management
management and within the teams
themselves identify all the processes
that your team is involved with that is
task
uh receive from other teams incidents
that you do and how to resolve them
common operations work for that it's
your day it's your day-to-day work that
you usually find out there Sor is your
friend never too early to start you're
building up a new security operations
program hey great for you the uh once
you set up the S sim the second thing is
set up the sore environment for that you
literally have to start from the from
that
early playbooks in word SharePoint one
note or Wiki they're fine but they don't
force analysts to actually foul through
with them for this use use playbooks
that generated through your ticketing
system like the security operations
module in service now Force analysts to
follow the workflow ensuring
repeatability and it also creates the
foundations for autom inst response
process when you're when you already
have the Playbook that everybody has to
follow it there that's the Bas Basics
you can add in automations into each
step sequentially as you need them and
as you
can constraints in bottleneck time is
literally money it operations uh doesn't
have uh often doesn't have money Bott
necks regarding infrastructure that is
you know commands tasks taking too much
time on a computer but there's one Bott
neck that's Universal manom hours of
work don't expect 8 hours of fully
productive work from a person lose two
hours for lunch breaks and meetings
consider the first two hour and last
hour as half productivity people are
still waking up coming in from the uh
from traveling or they're getting ready
to go home and think about what they
need to do at home for
this for this four hours so in this case
it's four hours of fully productive work
2 hours at 50% productivity and two
hours of zero
productivity find also find the people
who are always being called out to put
out fires or take the more most work on
them get them to delegate their Tas
those tasks so that they are not
overloaded from process to pipeline
identify the work process find
improvements rinse to repeat know your
team's work knowing your team's work
process is foundational you Lally have
to know what's go what work is done and
how it's done interactive playbooks are
a first step to standardize work
identify dependencies where other teams
are needed to actually do work and
constraints
either you know one of your co-workers
needs to do the job or and they're
overloaded Implement improvements
automate parts of the playbooks uh talk
to other teams request that other teams
Auto automate some of their work that's
related to your work that way not only
do you save time for your own team to
meet
slas you do the same you help the other
team do the same thing you get the low
you find the lowest uh branches and uh
lowest fruit and pick them if incident
response to alerts has been fully
automated create new alerts based on the
frequency of the automated ones to find
discrepancies to normal daily flow for
this new Services products Technologies
are implemented regularly so you start
this thing all over
again the software development life
cycle
here it's not
it
sorry the software developer life cycle
which would be the Sim development life
cycle in this
case plan follows the same line of the
software developed life cycle planning
identify I that you want to create alert
for research the ioc's and Analysis
design I identify the availability of
log sources to see if the I es will
would be visible implementation write
the initial query alert for the Sim
ideally in a code repository version
tracking testing integration test the
query the SIM for existing indicators
from the log archive if it's successful
that you found something push the query
into SIM as a new alert rule if you
didn't find anything push it into SIM
and set up so that the alerts any alerts
generated go straight to you for this
and that time assign and after all this
assign a purple team member to write
test articles on on a dedicated machine
to confirm that the alert will actually
fire create a custom script that will
set off that alert on a known machine
that you're using for this testing for
this you know the alert fires great you
know that you can detect it at that
point if you just write alert and you
don't do any testing of it sure you
wrote a new alert but but it has no
meaning if it doesn't if you can't test
it if it works maintenance run regular
drills making sure that all the known
alerts are able to be detonated at will
by the team to make sure everything
works correctly your usual fire drills
you've got a server that has all the
purple team stuff set to launch to run
through every script uh every quarter
see SE see and the logs did all the
alerts fire off of that there if
something didn't fire well you've got a
problem it's either the logic in in the
detonation soft software didn't work or
it's the alert logic that failed there
you've got something to fix and
interesting enough this uh using the
software develop life cycle is actually
one of the
design is one of the scenarios described
by Microsoft for automating sental
integration
okay yeah here's the full
there ticket metrics the sub art proving
the teams work number of tickets Clos is
is a disingenous metrics it takes into
consider uh it doesn't take into
consideration the difficulty or the
result true positive or false positive
false positive automatically assigning
tickets to users randomly is good but
you can't use the count how many tickets
they closed as a measure to for employee
performance you don't know how hard the
tickets are you're going to be you're
one employee can get tons of difficult
tickets and they're going to do three
tickets in a week while another couple
employees get 10 or 20 tickets they're
easy and they finish them out without
any problems so your metrics are uh
broken either way uh pick and pull
tickets at discretion also doesn't work
as employees with experience can
identify the easy tickets and hoard them
so you know you find the easy ones hey
yeah these are usually always false
positives check yeah false positive
false positive false positive easily
you've got 20 tickets there you've met
your quota and that's it and everybody
else is scrabbling and you're saying I
did it why can't
you how about classifying tickets based
on a priority level critical medium high
low and assigning point value to them
for that it can help it can help but the
frequency of curs of these tickets and
the results true true or false positives
still aren't considered critical tickets
aren't going to be coming in Daily or
that there if they are you've got you've
got other problems to deal with for that
but you can users can still game them um
but scrum has one interesting feature
called planning poker you sign a weight
for a task based on the amount of amount
or difficulty of work to complete it
assigning a separate weight to True
posit to True positive incidents and
false positive incid can normalize the
amount of work done between team members
so you have a different Val weight
waiting for if the incident is a false
positive when it's closed or is if it's
a true positive because the amount of
work
varies planning poker Sting from scrum
to make metrics work it's actually
simple it's usually done during backlog
refinement values are decide how much
work a task takes and never how much
time it would we're terrible at esing
time for
this that's why I'm looking to see how
much I time I have on my talk
but we're more visually oriented we can
see if something's big small a lot or
little for that and that tends to be
more accurate cing poker uses generally
a modified Fibonacci Sequence uh to
estimate work zero It's Already Done 1 2
3 5 8 13
20 40 100 for that based on difficulty
levels the main reason for this is it's
a little bit easier to estimate size or
that there by having wider space Val
values the the thing is though when you
do this you literally don't take into
consider consideration any slas or kpis
when you're deciding this you just see
how much work it actually takes but here
one thing that I didn't add on this but
you actually uh the work that when you
look at the work for tickets or some
there you only consider the work your
team does any dependencies of work that
needs to be done by another team you
totally ignore that because it's it
doesn't matter because you can't control
that and the only work that matters to
you is the work that your team does I'll
get back get to that in a second why but
the key is here the law of averages in
the end comes to our rescue regarding
metrics averages and standard deviations
standard deviation you get you get the
you sum every value subtract you get the
sum of every value subtracted by the
average average squared divid by the
number of values minus one and the
square root of that it's
basic it's basic statistics Force to
remember here but it's useful to know
the standard deviation shows
where where different tasks start taking
too much time or too little
time out of bounds tickets when response
times exceed standard deviation you can
say one standard deviation two standard
deviations you decide how much you want
for that
there when they take more time
dependencies can there's stuff that you
can
identify why dependencies can be blame
to blame team members are waiting for
other teams to complete Associated work
yeah so you know your ticket is open but
you're still waiting for the other team
to get back to you with the completing
their own uh a sub ticket for this or a
child ticket there you know you can't
control that your ticket is still open
and you're still working on it or
potentially it's a the employee might
need additional training or it's a new
team member it needs to improve they're
still getting their ropes to learn you
see that their T their completion of the
tickets take more time than everybody
else's for that these are easy EAS
should be easy relatively easy filters
you can apply in jira or service service
now when you're looking at tickets and
metrics for that and or potentially
there's a problem with the tool that the
team uses for that something's broken
simply these uh t uh these can be the
first targets to quickly improve sla's
results by aration so the ones that
exceed that automate them find the ones
that see that you can bring them uh
bring the entire uh time to to close the
tickets uh down it will help you meet
your slas that way the ones that most
that follow most out of that they're the
the they're the lowest fruit to take on
but what about when tickets take less
time NE
negative um uh standard deviation well
one good thing employee found a way to
automate it there they're actually
arming their work and doing it for that
and they just are shy or haven't told
them or are just cheesing the system to
make saying to keep their workload low
while keeping their tickets high this
way you can see hey
they made something good what do you do
congratulate them and see about
standardizing the pro the procedure for
that they they saved your team money for
that you can go up to your upper
management the SE Suite there say hey
this guy knows what they're doing there
uh they're implenting improvements that
save us time and money or the
opposite employee has been closing
tickets without actually doing the
work so you
that's a question are do they need
retraining or should you start
monitoring their work
closer or firing
them track the average
averages this is where the law of
averages comes to play the average time
it takes the
job with a certain estimation of effort
playing poker value even when not linked
to kpis or can provide valuable
information on a team as a team invol
evolves forming storing norming
performing the average time it takes to
work should drop month to month this
includes performance improvements done
with automations and improvements done
in conjunction with other teams for
this this shows your improvement over
the month as the process goes time saved
money saved doing more tickets and less
time and improved efficiency means
management can offer a measure of money
saved over time to senior leaders at an
organization we're we're cost we're cost
centers for any company for that we
could say that we saved this much of
money by automating our processes by
doing and being able to do more work hey
that's good news for them we we don't
get our budget cut there we can say hey
if we get we might be able to do this
even more if we get these other
tools changes to teams also can raise
the averages see how fast they start
dropping again can IND see how fast they
drop again can indicate how well the
team is working together you've got new
people coming in and people coming and
going there uh
the new people come in times will
increase see how fast the times start
dropping
again so going from this here there's
some a number of useful books I found
the three main ones the goal a process
of ongoing Improvement by gold Rat um
Jean Kim's book The Phoenix project is
basically based around that Toyota C by
Mike rthur covering the the Toyota
methodology and the devops handbook by
Jean Kim another book that's useful in
my opinion said security can be also
considered a creative
Enterprise we're all makers in one way
or another we mess around with stuff and
we have to find weird sometimes
solutions
to non-standard
problems I really suggest the book
creativity Inc overcoming unseen forces
that stand in the way of true
inspiration by Ed cell it's basically
the Pixar story and how they ran Pixar
from the start to roughly after the
Disney buyout and if you've read the go
to devops handbook you're going to be
hearing a lot of that stuff in the Pixar
book for that just mention on how it's
being used in a creative Enterprise for
that they're making movies they're
making art they're actually using a lot
of these techniques from
agile agile methodologies agile
methodologies other stuff to
actually do their
work Sears so you know work wants to say
see what what you can do there are scrum
useful if you're the scrum Master just
to say that you are do you have that
qualification personally I would go I
would suggest getting the professional
scrum Master C rather than the surfi
scrum Master csm1 uh there's been a a
wide divide between that and the create
the creators of scrum actually left the
organization that created the certifi
scrum Master exam and created their own
organization competing for that there
it's a big it's a long story look it up
for that it's actually an interesting
read for that regarding agile anything
from uh the project management Institute
like it or not they've uh they've done a
good job overall on that there and if
you don't have the work history it to be
a
PMP comp a project pler it's cheap it's
available you don't need any work
history as a project leader there and it
gives you a really good idea of what is
uh project managed
overall and with that thank you I'll be
uploading this to uh with the slightly
edited sides for uh typos everything
here on my SlideShare for this and
thanks for attending the talk and hope
hopefully provided some value to
everybody any questions or anything go
ahead yeah there's there's the PMI ACP
the certification also
there
h no but you uh but in part uh you can
there's some other certific potential
certifications for that there but the
comp one if you're if depending on what
your organization
does it's a cost- effective one it gives
you the basics for that there they're
cheaper exams from the PMI from the
project management Institute uh the PMI
ACP there's one just below that below
the PMP which is I think $200 $400 you
don't need the as many years of
experience in project management there
and it counts as training for the PMP
for that there so there is uh there's a
growth way to grow into the PMP for that
there so there's less of that the
talking about the ca stuff it's a good
base starting point for that if you've
never done a project management there
going head into the actual hard hard
stuff there
you're you're going to have some
difficulty in understanding the the
project plus comes in for a much gentler
slope and it goes into the newer
versions go into agile more uh uh more
in depth and I would say it's very good
value for the money especially if you're
not trying to be a project manager per
se but working as in security operations
or a general manager it just has to know
what the heck they're supposed to be
doing at this point when the company
says we're going agile
one more
question uh one
[Music]
second noticed a
lot a little late here was talking about
um ways to assign tickets to people um
you have
people can be good but that ends up with
a lot of you have people getting not
with and then you know the freely taking
from the CU where said to like you know
some team members can end uping things
that are
easy um do
you thoughts on that like what where to
find a balance there um we do like
some
well you know for balance uh technically
like I said if you give a value a
certain value for tickets at incidents
for that there uh with the planning
poker you can uh set up so that the uh
you can give the tickets randomly there
but make sure that the sum of those
values that everybody gets in a day or
so on there is roughly the same so some
might get higher PRI High higher
difficulty tickets some might get lower
difficulty there but the work that's
being done done should roughly be the
same between everybody for that the
entire idea is you're not going to be
you don't want people to race to do who
knows how many tickets keep it level the
randomized random random assignments are
good but let's say if you keep track of
how much work or off of those project
planning numbers uh are is left to that
there you can potentially uh even out
the spread a little bit for difficulty
between
users any other questions or anything
here yeah we
got devop devops built off
of well I would say more than anything
containers built off of devop for that
there it involved you've got virtual
images
there you with Cloud you start off
with virtual machines generally the
cloud Network everything there and
that's it then find out well if you make
things the T the workload like in agile
you're making the workload smaller so
you're not doing huge bits of work there
but what if you do the same thing with
the individual parts of applications
there or servers there so you're not
running massive virtual servers on AWS
there you're just running the you start
running multiple but the cheapest
servers out there but you with the
cheapest servers out there also they're
they can be activated whatever you want
you could shut them down wherever you
want there so you could scale them scale
them out for that you can increase or
you can increase the power how much they
need there and at that point once you're
doing the SC the automated scaling of
that there you've got kubernetes for
that there orchestration of that so
literally the concepts from agile helped
push the general basics of uh virtual
Machines of the the cloud to something
that's actually functional uh as what we
know as Docker kues where individual
parts are smaller more unique and
contained for that there and it just
it's a outgrowth of the basic concepts
and agile into development into actual
uh infrastructure
okay that all all right once again thank
you very much for coming to the talk
here and I'll have the slides on
SlideShare I'll link it out for uh where
uh hopefully today or tomorrow morning
thank you very
[Applause]
much