Literature regarding Scrum + KanBan + IT Operations = Agile IT Operations

[Felipe Perez]

Hello guys!

 

My name is Felipe and I'm sending this e-mail because I need you help! I hope you can help me! :)

 

I started to plan my final course assignment and I will write about how to use the best of Scrum and Kanban to manage IT Operations tasks. The problem is that I didn't fount any kind of literature to support this idea... This subject is very new...

 

I already worked at a company where thse two methodologies were and still being used to manage IT Operations tasks and I know how they can help a lot!! But I need a literature to support it. Initialy I will start explain about Scrum and Kanban just to put who is reading in the same page... then I plan to write about how to use the best from both... this last one will be supported by Mattias Skarin book regarding it... finally... I need to explain how to use it in IT Operations... that's the difficult part... no literature to support it... and I need it to support.

 

So... Do you know literatures about it?

 

Many thanks!!

 

Regards,

Felipe

[Ray Chudzinski]

Felipe,

I recommend 'Lean from the Trenches' by Henrik Kniberg. It is a practical book in that it follows a particular use case but it covers the motivation in each decision.  It was made required reading for my team as has some smart content.

Best of Luck!

ray

p.s. I am in no way affiliated with the author nor the publisher.

--
You received this message because you are subscribed to the Google Groups "Agile System Administration" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-system-admini...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Vladimir Lazarenko]

Hi there,

I agree with you - there's no texbook recipe to adopting Agile methods to operations. In our operations department each sub-team does sort of adjusted Kanban, keeping boards either digital or analogue on the walls :)

Aside of that I did find an interesting piece of literature on the subject. It's not really related to Operations, but describes conversion of any company from waterfall-like models to agility. 

Book is called "Succeeding with Agile", author Mike Cohn, Addison Wesley publishing. I found it a very interesting read. It discusses problems that agile adopters meet, acceptance of new ways of working and how to transition successfully. It illustrates both success stories and failure scenarios. Basically it's just a good source of information.

Here's a link: http://www.succeedingwithagile.com/table-of-contents

(I'm also neither related to the author nor to the publishing house, so it's an unbiased opinion).

Book targeted at development teams, but basic principles are applicable to anything. I personally think that any kind of agile process introduced into any team should not be for the sake of the "let's do it this way". People need to feel that it helps them work faster, keep overview, improve quality; then your acceptance level will be high. As soon as "administration" around the process becomes a burden - process will go down the drain.

"I need to spend 3 minutes fixing an issue and I need to spend 10 filling out stupid ticket in JIRA". <- Wrong. Some things do need a paper trail, some can go live like that. In my opinion agility itself should be agile - i.e. adapt the process. Do hold retro's first few times, ask feedback from the team - what they think went well, what helped them, what was an obstacle more than the help. Ask them how they want to adjust that process. Don't push it down their throats.

My 2ct :)

Regards,

Vladimir

[Aaron Nichols]

On Tue, Jul 16, 2013 at 10:59 AM, Vladimir Lazarenko <favo...@gmail.com> wrote:

"I need to spend 3 minutes fixing an issue and I need to spend 10 filling out stupid ticket in JIRA". <- Wrong. Some things do need a paper trail, some can go live like that. In my opinion agility itself should be agile - i.e. adapt the process. Do hold retro's first few times, ask feedback from the team - what they think went well, what helped them, what was an obstacle more than the help. Ask them how they want to adjust that process. Don't push it down their throats.

I concur on the retrospectives, I think they belong at the beginning - not the end. I actually started with retrospectives before changing anything else and got folks used to that process. It's a fantastic tool not only for getting feedback, but also for establishing a sense that there's a mechanism for change so any decision you make is only as permanent as the team allows it to be. Once folks understand that you will regularly talk about problems and take action on them they'll be more willing (usually) to try new things. Introducing retrospectives is also a fairly non-threatening step - they're fun if facilitated right and they don't change the way you work immediately. 

Tools, process, and other aspects of Agile tend to be very tailored to each organization - though they follow common themes. The retro however, is the feedback loop that helps you tune things to your needs. 

Also - reading the agile manifesto often brings me back to reality. So many things are simplified by just facilitating interactions with folks vs. trying to find a tool/process to avoid that interaction. Everyone screams that they hate meetings, but most folks hate bad meetings that waste their time - meetings happen all day informally and are usually the easiest path to consensus. 

Aaron

--
Twitter: @anichols

Blog: http://www.opsbs.com

Pro: http://www.linkedin.com/in/anichols

[Ernest Mueller]

Well, it's not book quality, but I've moved several ops organizations to agile and/or devops mode. I have some things written on it and am working on some more, perhaps it'll help. http://theagileadmin.com/tag/scrum4ops/

[Vladimir Lazarenko]

Honestly, in my opinion scrum doesn't work for Ops, unless you ditch sprints. 

Ops are mainly very much more dependent on external factors out of their control, like hardware vendors, 3rd parties, etc.

Things like "relaxed", or adjusted kanban worked bit better in my situations.

[Anthony Goddard]

We currently have 2 week sprints, but we only plan <~50% of the available time, and the rest is devoted to small things that come up during the sprint (mostly small requests from other staff, of which there are lots). The idea originally was that as we gave people more self service tools, that <~50% will decrease, but my biggest issue is that if we have a system go down that takes a few days to get right again, then we don't factor that into the sprint and it drops velocity. I guess over time velocity will show your estimates including the odd day+  unexpected outage, but you have to be careful not to incentivize good velocity over stable systems.

Before using sprints, we just had a simple kanban board, which I actually prefer, but then the issue becomes communicating with the customer/stakeholders that their task won't necessarily be completed on a date. That leaves you free to fix the database backup that went offline and became priority #1, and let stakeholders know their new feature will be delayed a little bit. With the kanban board, the backlog was prioritized, so barring emergencies, if your task was at the top, it would be complete first (or it would be the first to move to "waiting" if it required a hardware vendor etc..) and you'd just provide the stakeholders with task delivery estimates during the standup.

@Ernest, I'd love to hear your opinion on how you've dealt with the above. I should also add the caveat that the kanban-only solution was when it was just a few devs and I, the 2 week sprint was when we added another ops member and a few more devs.

[icar...@thoughtworks.com]

Hi Felipe,

Here's a comprehensive case study on one particular Kanban implementation within an IT Operations team at a large dotcom: http://itopskanban.wordpress.com

Thanks,

Ian.

[Zac Stevens]

Hiya,

On Mon, Jul 22, 2013 at 2:01 PM, Anthony Goddard <ant...@anthonygoddard.com> wrote:

We currently have 2 week sprints, but we only plan <~50% of the available time, and the rest is devoted to small things that come up during the sprint (mostly small requests from other staff, of which there are lots). The idea originally was that as we gave people more self service tools, that <~50% will decrease, but my biggest issue is that if we have a system go down that takes a few days to get right again, then we don't factor that into the sprint and it drops velocity. I guess over time velocity will show your estimates including the odd day+  unexpected outage, but you have to be careful not to incentivize good velocity over stable systems.

When you talk about incentivising good velocity, what do you have in mind?  It's usually good advice not to incentivise it at all (consider Goodhart's Law).

Before using sprints, we just had a simple kanban board, which I actually prefer, but then the issue becomes communicating with the customer/stakeholders that their task won't necessarily be completed on a date. That leaves you free to fix the database backup that went offline and became priority #1, and let stakeholders know their new feature will be delayed a little bit. With the kanban board, the backlog was prioritised, so barring emergencies, if your task was at the top, it would be complete first (or it would be the first to move to "waiting" if it required a hardware vendor etc..) and you'd just provide the stakeholders with task delivery estimates during the standup.

The Kanban Method's advice for dealing with this is to have different classes of service.

For example, most of your requests might be in a "standard" class of service.  After observing the flow of work, you might notice that 80% of requests are completed within two weeks.  In some environments, that might be an acceptable SLA - in others, (particularly low-trust environments), you might define it as 95% of requests completed in 4 weeks (or whatever the data suggests is appropriate).

Sometimes customers need greater certainty than either of those SLAs - eg, there will be a penalty if a request is not completed by a particular date.  Adding a second class of service for these "fixed delivery date" requests can help.  And you could have another class of service for urgent issues like the database problem that needs to be top priority.

Of course, that's just the canned advice - the important thing is discovering what works in your situation!  Have you found that the sprint commitment gives customers/stakeholders the predictability they were lacking with the kanban approach?  

Thankyou for sharing your experience,

Zac

[agoddard]

Hey, wow... this is a late reply! better late than never!

Since posting, we've actually switched to a continuous kanban system with no sprints, tickets are added to the backlog and then ops works on them and the product owner releases the completed tickets when they review them, though I think I can still answer the questions below. With respect to incentivizing, I suppose I should have said "inadvertent incentivizing", but your point is absolutely correct. We used to start iteration planning meetings with "oh nice, we did 100%" or sometimes "oh wow, we finished everything and then added tasks" and I suppose this naturally became something to aim for, but perhaps that was just in place of better, higher level metrics, like (just guessing here) uptime, bugs, accuracy defined in some way etc.. If aiming for velocity in an of itself is it's allowed to occur naturally, then I guess that's a failure of better metrics.

Classes of service makes a lot of sense I think, now that we've gone back to kanban, we have an "expedite" lane in our kanban board, it's big and red and at the top. This is obviously only used for things that are very urgent, but we could easily add more lanes if the need arose.

And now for the inevitable question about why the switch back... our team got a little smaller and we wanted to experiment with being a little more reactive over short periods. One of the problems we had with doing the 2 week sprint was having external stakeholders who didn't understand the system, so we'd be asked to do something and it would finally make it into an iteration 6 weeks later for various reasons, and even if those reasons were legitimate (which they often were!) the stakeholder wouldn't really understand why they kept hearing "it didn't make it into this iteration". At the time we were trying to build up some internal business and so we didn't want to put people off. Secondly, we found that in some cases it was a bit hard to avoid the product owners only reacting to very recent events in the planning meetings, rather than taking a wider view of things, so we ended up quite reactive and not able to spend time on bigger long-running projects designed to reduce our workload (like monitoring improvements etc). Switching to kanban has meant I've been able to throw a little bit of time at projects like that as I go and keep them almost in WIP (if that makes sense? they jump in and out of WIP a little, then they stay in WIP for a push when there is time).. that seems to keep things current and it avoids issues where we just remain aware of a problem for months but the fix is so big that it never gets scheduled, then the problem just becomes "that problem" that's accepted and doesn't go away. For whatever reason, having the freedom to juggle tasks around a little more than we could in the 2 week iterations means these problems have actually have time thrown at them and been resolved.

To answer your last question, I think on short term basis the answer would have been yes. When we scheduled work for the next 2 weeks, that work generally got done on time and so the stakeholders had predictability, but in our case that was at the expense of long running projects (paying off technical debt), and at the other end of the spectrum, very short term agility. Obviously both of those could be fixed with some redefining of "quick fixes" and a more critical look at the backlog during sprint meetings, with a focus on breaking down big technical debt projects into small chunks that could fit happily in an iteration. 

Hope that also helps, sorry again for the super late reply!