How do I Agile?

 

Nine years ago, when I signed up for the CSM class, I went into it thinking, "I'm going to learn how to do Scrum, at work."     I was partially correct, and I wasn't alone.  As mentioned in my last post, I don't have figures for how many people take a Scrum (or other flavor of Agile) class, expecting to know how to make it work at their company afterward, but the more people I talk to about this, the more people I find who experienced the same thing; Scrum certification classes focus on using Scrum, not on how to get the rest of your company to use Scrum.  Admittedly, it is a small group.

If you search the web for how to become Agile, you will get a lot of different results.  Some people say being Agile is more about your state of mind than your skills.  Others attempt to point out that it's not really agile to strictly adhere to one project management/development approach.  A lot of online information about becoming Agile isn't that different from the CSM and CSPO training classes, in that they focus on steps to use a framework or methodology, as opposed to how to successfully transition your company to using Agile processes, which is where the pain point really lies.  It can be discouraging to want to do something that can be a game changer if you are the only willing to do it.  It's hard enough when you have support for the change.

Don't get me wrong, I'm not saying these are useless resources.  Some are very good.  A couple that I found, this week, that I like are:

• The Scrum Kickoff Planner
• The Scrum Checklist

But, it seems like if you want to learn how to transition your company to using a flavor of Agile, you have to hire a consultant/company to take you through the process. This is not necessarily a bad thing, but it could be difficult to convince company leadership and get approval for the budget.  Perhaps one of the biggest reasons that it is difficult to find meaningful information on transitioning a company to Agile, freely available, is that there is no one-size-fits-all approach to doing so.  I'll withhold cynical comments about it being a source of income for some companies.

Some sources say, "Just get started."  In a sense, they are right.  If you spend your time worried that you won't be able to do it, you'll be right.  So, how do you get started?  I wish there was a simple answer.  If all your company does is develop one piece of software for retail sale, making the transition to Agile is less complicated than it might be for a company that has multiple product lines, and multiple sales channels, in multiple global markets, with separate, yet connected, back end systems that all need regular development and upgrades.

In the spirit of "just get started," are you able to run an experiment?  Can you pick a team, get them trained, and run an Agile project for one of your products?  If you're successful, you potentially have champions for taking this to other groups in the company.  I'm not saying that this is the best approach, but it's one way to demonstrate value, if you succeed.  I've said it before; transitioning to Agile is organizational change.  It's risky.  It's bumpy.  It's hard.  If you want to succeed, key ingredients are either adding value that others value (not just you), or solving a problem that is causing others significant pain. 

You could start top down - convince the executives that Agile is the right way to go and then drive it out to the organization - but I still recommend starting small.  A big bang approach might work, but it could also magnify a single issue that is experienced by multiple teams.  You need to make sure that all affected understand that it is a learning process, not an instant fix.

You also need to make sure that everyone understands their part.  There may only be a few roles in Scrum, but you can't run a business with just a Scrum team.  At least, not a large business.  There are other people who may not play a direct role in a Sprint, but they are affected by processes and outcomes and may have a voice in whether or not you continue to use your particular flavor of Agile.

Considering all of the above factors, this is probably why companies use a third party to help with the transition.  Even using a consultant is not a guarantee of success, but not because Agile doesn't work.  Many companies have demonstrated that Agile works for them.  The trainer for my CSM class related a story about a company he was working with.  There were certain changes that he told them they needed to make in order to use Scrum effectively.  They refused to make the changes.  After considerable discussion, the decision was made to terminate the transition. 

This speaks to why I feel that more could be done to educate companies, not just individuals, on what it takes to be successful using a flavor of Agile.  If the company leadership is not committed to making changes to how their company functions (or dysfunctions) and follow agile practices, the transition will eventually fail.  Chances are, when this happens, the failure will be blamed on Agile, not on the inability of the company to change.  The right mindset is an important part of making the transition.

I like the approach Mountain Goat Software takes to determining when to use Agile.  It's not a question of whether or not your company can use Agile (although this is a good place to start), it's which projects are suited for Agile.  A company doesn't have to adopt the same agile processes across the entire organization.  It may make sense for a company to have some dedicated Agile teams while the rest of the company uses other approaches.

I wish I could give a simple, definitive response to "How to transition to [pick a flavor of Agile]", and not just because of potential financial implications.  It's not simple, but it's worth finding out if your company can benefit from making the transition.  It's worth taking a class and getting hands-on practice using it - reading about it can only do so much.  It's worth starting the conversations around what Agile is and how your company can benefit from Agile principles, if not from Agile practices.  You have to start somewhere; start with the conversation. Build interest.  Discuss the problems you are trying to solve.  Even if you don't adopt a flavor of Agile, having these kinds of conversations could lead to making changes that are needed to help your company be more successful.