IT Services as Agile?

[Steve Smith]

I work at a Fortune 500 company and our new CIO wants to transition us to Agile.  For my department of about 250 people I am responsible for determining how to do this.

For our software teams, it's easy.  I will just create Scrum teams.  I have done this before and I think it's relatively straightforward.  

My question is around IT services teams and whether we should run them as Agile or not.  I think these teams operate more like a factory with various assembly lines and orders coming in fairly randomly all day long.  When I think of it this way, I think of the book called the Phoenix Project and how they kept referring to IT as a factory model where you had to think about work in progress, theory of constraints and minimizing cycle time.

Or more simplistically, imagine that we have a fast food restaurant where we have 3 people making burgers, 2 people making fries and 2 people in charge of drinks and 2 cashiers taking orders.  Each customer that comes in might order one or more meals that include burgers, fries and drinks.  Other people might come in and only order 1 or 2 drinks.  Someone else might come in and only order fries.  This is similar to our IT environment except instead of burgers, fries and drinks we have servers, databases and network requests to fulfill.  Some application teams need a lot of all 3 for their big projects while we also get plenty of requests for just a single network change or a single database change.  

The restaurant analogy isn't perfect since those orders are all fulfilled using repeatable processes.  Some of our requests are simple and repeatable (and we send those to offshore) but most are at least a little complicated and require some discussion and collaboration to determine the best solution.  

Given this context, for these IT Service teams I have three questions:

1) Do you think we should attempt to run these as Agile teams?  Or would we be better off running them as Lean?

2) If we run them as Agile do you think that Kanban is the best approach to use?

3)  Do you think we should group them by technology or by requesting department?  

 

a) We could continue to group all of the database people together, all of the network people together and all of the server people together as we do today.  But this way we have silos and none of these teams work together.

b)  We could form new teams that each have, for example, 2 database people, 2 network people and 2 server people with the idea that Team A would handle all requests from Line of Business A and Team B would handle all requests from Line of Business Department B.  The good part about this is that they could start to understand their customers (since they'd be working with the same requestors all the time) and they could work together on projects instead of in silos.  The bad part is that they can't rally together too much since database people don't know how to do network tasks and network people don't know how to administer servers.  We could attempt to cross-train them, but that's a big learning curve.  

Any thoughts you have on this would be most appreciated.   

 

- Steve

[Alan Dayley]

Some practical questions, Steve. I like the thinking.

For clarity, Agile is defined by the Agile Manifesto. It is a set of value statements and 12 principles. If the teams and your company are seeking those values and following the principles, the are "[running] as Agile." Scrum, Extreme Programming and other frameworks are practical structures that attempt to support the following of the principles. ANY way of working can be said to be Agile if the principles are supported.

1)

Should you "run them as Agile"? Yes. The Agile Manifesto principles are difficult to argue against. Follow them, no matter what process you invent. Also, Lean is not exclusive to Agile ideas. Nor is Agile contrary to Lean ideas. Follow the Agile principles while following Lean ideas, sounds great to me.

2)

Kanban is not Agile. And it is not, not Agile. Kanban is agnostic to the underlying process. Kanban can be used in Waterfall or whatever process you have. It is an improvement framework that can layer over any framework, like Scrum, or even some phase gated, big-up-front-planning monster.

Based on your description, it seems like a Kanban layer, tracking flow and exposing things to improve.

3)

I would say that option 3b) is more like cross-functional Agile teams that can get requests completely done on their own. So, maybe do that under a Kanban flow for each team, following Agile principles.

Option 3a could also be a good starting point. Overlay Kanban on the flow that includes all of the specialized teams, start using Kanban principles to learn and improve together. You might eventually end up in something like the cross-functional teams of option 3a. Kanban will help you emerge what you need.

Other ideas:

A)  Look into a new but highly interesting framework called FAST Agile. http://www.fast-agile.com/method  From what you described, your group could be a few tribes that figure out process and getting the work done all together.

B) How about presenting to the250 people the idea of Agile ways of working as a CIO initiative and asking them what they want to do to meet that initiative? 

Alan

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Dan Rawsthorne]

I see no mention in your discussion of IT work about prioritization. Who is deciding how much care to give to each IT request? Who is deciding what is best for the Organization, and company as a whole? It is important to remember "People over Process" -- Processes don't make decisions, people do. Who are those people? Who is comparing the IT requests and determining which ones actually count and which ones don't? Who is deciding which ones need to be done carefully, and which ones can be 'whipped out'? Who is pushing back on the requesters for IT services, assuring that what they are asking for is actually what they need? If you don't have such people, and they're not aligned in some way, then you're not being agile.

Additionally, stop thinking about the process, and start thinking about the work. In the triad of People/Product/Process, Process is the 3rd most important thing -- and the other two are tied for first based on context.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
   Exploring Scrum: the Fundamentals
   Exploring Scrum: Patterns that Make Scrum Work
Download our free eBook, Scrum 101: a Pocket Guide

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

Virus-free. www.avg.com