How to introduce agile methods?

[Martin Marcher]

Hello everyone,

lurking thru the archives I see quite some specific tool questions. Mine isn't one of those so feel free to ignore me if this question is OT here :)

I'm looking for ways to get started with agile methods. Currently there's Kanban on my mind. This is for a couple of reasons:

1. A lot of _positive_ information in operations teams is out there on the web. This (hopefully) makes it easier to accept

2. We (kind of) tried Scrum, it was decided on us, and got burned heavily. Actually we didn't do _any_ the things that make scrum work. We had to adapt to the the iterations of all the teams for which we do stuff, I'm pretty sure most of you can imagine that this time was...unpleasent at least. 

3. I know Kanban from my old company :)

I'm not completely and totally sold as Kanban as the solution if there's something else to try tell me (Mind you: I'll probably call it Kanban anyway when talking to other people in my company) :)

Let me describe the situation:

I'm a team lead (and! sysadmin) for 11 people and we are working in a typical siloed enterprise environment. We have DBA teams, core teams, various teams for specific products and such. On the bright side: When talking personally to developers, product owner or project managers the relationship is usually quite good. The part that's not so bright is that very often we get tasks or requests thru channels that quite questionable (I'm working on that :).

Eleven people is very much on the large side but the really really good part is that we got everything. People that like to design processes, write code, like to talk, just do, firefight, design and a mix of all of those in any combination. In my opinion we have a huge potential, but we are struggling to be transparent to others because of the side channels which require tasks to get done and because we didn't have any clear direction in the last 1.5-2 years (or so). I'm pretty sure it's the standard setup for a siloed team :)

Personally I joined the team as a sysadmin 2.5. years ago as a sysadmin and operations manager (at our company: the guy that goes to all the meetings, gets screamed at, de-escalates and generally talks to ... demanding customers -- that's OK it's a part I actually enjoy). I've been thinking about Kanban for a while now, even before I got assigned team lead and now I'm facing the problem that I _could_ simply force everyone to try it. It's not the way it would work and I know how much I'd have hated to have to adapt my workflow.

So I'm facing 2 major problems:

* How do I sell it to the team?

Do you have any resources, hints, tips on how to sell it so that the acceptance is high. I know it won't work without getting everyone (or almost everyone) to actually want to try it? I'm not actually looking for textbook resources, rather than real world tips (DOs, DONTs)

* How do I sell it to the stakeholders?

My gut feeling tells me that the current situation (low throughput, somebody who can obviously be blamed) is actually something that people want. They, of course, don't actually want all the trouble that comes up but they know how to blame and that is what they don't want to loose.

I'm aware there isn't a standard recipe to follow here but I'd be grateful for any advice, also I don't want you do all the work I'm not a native speaker so I might have phrased that way but not ment it that way.

thanks,

Martin

[Aaron Nichols]

Hey Martin,

I sorta melded your post and the other post about Agile documentation and responded to the other thread, sorry about that - but I think my response is equally (maybe more) applicable to you. In addition, a few things to think about :

I'm looking for ways to get started with agile methods. Currently there's Kanban on my mind. This is for a couple of reasons:

1. A lot of _positive_ information in operations teams is out there on the web. This (hopefully) makes it easier to accept

2. We (kind of) tried Scrum, it was decided on us, and got burned heavily. Actually we didn't do _any_ the things that make scrum work. We had to adapt to the the iterations of all the teams for which we do stuff, I'm pretty sure most of you can imagine that this time was...unpleasent at least. 

3. I know Kanban from my old company :)

Are any of these reasons things that others in the company care about? The fact that Scrum was tried and didn't work suggests folks weren't on board and/or the right facilitation didn't exist. Why didn't you do the things that make Scrum work? Did folks know about those things and willfully choose not to do them?

 

I'm not completely and totally sold as Kanban as the solution if there's something else to try tell me (Mind you: I'll probably call it Kanban anyway when talking to other people in my company) :)

This is highly dependent on your organization. I've had the best luck with Kanban for more interrupt driven work as Ops tends to be but that doesn't mean other approaches can't work. I think it's important that whatever you use allows you to follow a flow very similar to the dev organization - you should be able to fold their work into yours and vice versa. 

 

* How do I sell it to the team?

It's a lot of work to come in and propose a complete re-work of existing processes and get everyone to change, it's exceptionally disruptive. Find ways you can shift behavior in small bits, in particular where you can do more to expose constraints, and help others see that change is required. Again, this comes back to things like retro's and making it clear that if things do not work you'll try something else. Some small changes can have a dramatic impact toward allowing you to try something new - pick those things that'll help build confidence and show value, not necessarily the hard things that are more conceptually ideal. 

Also, if you are in a company that likes to place blame - get comfortable with taking the blame & trying to refocus on solutions. Give others credit when things go well and take the blame when they don't. Every time someone says something doesn't work is an opportunity to get ideas about other things to try. 

 

* How do I sell it to the stakeholders?

The same way you sell it to teams. You have to find opportunities to try to change things and expose how things have improved. 

This isn't possible in all organizations in my experience - while I think many organizations want to become more efficient, build better software, and have happier teams, they don't have a leadership team that's willing to let go of control enough to allow the team to properly embrace an Agile process. In those environments it seems like Agile is often just an impediment. At least for me, in an Ops role, I haven't yet had the ability to turn the ship in those cases. 

Hope that helps. 

Aaron

Twitter: @anichols

Blog: http://www.opsbs.com

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

[Chris]

The thing to keep in mind that Kanbans are just ultimately a visual aid used in an attempt to identify bottlenecks in your work in progress. The downside of that is there's no official process to follow like Scrum. 

So, here's my $0.02.

Start by trying to map your work flow and categories of work on a board with sticky notes. Here's a good example of not being to strict with your Kanban design - http://scottmuc.com/going-post-kanban-with-a-shark-tank/. 

Do a daily stand-up with your team to manage the process of moving the cards along and identifying issues preventing stickies from progressing. Keep an eye out for the items that hurt your team. Do certain categories of work stay on the board longer. Do one or two people get a bulk of the work? Is it 80% firefighting and 20% engineering? Find a pain point and work as a team to reduce the pain. Then find the next one. Some bottlenecks you cannot fix, but identifying them allows you to provide ETAs and set expectations. A great Kanban practice I've heard of is having anyone who wants to escalate an issue in priority has to talk to and get approval from every task owner currently in the backlog/queue. Everyone thinks their issue is top priority, so let everyone figure out which issue is really the most important to the business.

This is starting to get cliche around the 'tubes, but go buy a bunch of copies to The Phoenix Project and make everyone that reports to you and who you directly report to read it. 

[Daniel Cukier]

You should read the book by Mary Linn Manns and Linda Rising: "Fearless Change"

If you want o shot abstract of the book, take a look at my master thesis presentation. It is a story about convincing people to use Agile Methods in a company:

http://vimeo.com/6094673

Regards

Daniel 

--
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.
 
 

--

Daniel Cukier

Software Artist

+55 11 99991-3913