Improving your chances of successfully rolling out Agile by being better prepared at the start

Over the course of the last month plus, I've been very frustrated by how things have gone within my new team - that has been newly made Agile - in a company that's just gone Agile (as of January 6th, a rolling rollout across seven or so teams). Working through this, I see several books in the making - because there is so much information that people need about how to really make this work and I'm not sure if there's enough literature out there to cover it. Yeah, sure, you can hire a coach to help your company make the transition, but it's really expensive, and how do you know you're going to get the right person for the job?

So ... our training, across the department, pretty much consisted of some two days that made us "Scrum Masters." Now, this is about the most useless training I've ever had for the money, and you aren't actually properly trained to be a "scrum master" (as in "the person who runs interference for a scrum team") and you're sure as hell not a master of Scrum practice just because you've spent two days learning about how to properly scope the amount of work you can do in a sprint. Worse yet, people come out of it thinking they know how to do Agile when in fact they only know how to do the tiniest bit of Agile. Scrum Master training is basically aimed at developers. It ignores the needs for requirements gathering, documentation, testing, and releasing a product - and if that's where you are involved in the software lifecycle, you will come out of the training thinking there is no role for you in the new world. But this is Not So.

So, if you're looking to switch your company to Agile, what can you do to most ensure success? I expect there is a lot more to say about this that I will in just this post, but what I would like to encourage people to do is learn how to build a product backlog. The moment when the team comes together for the first sprint estimation meeting is a month or two too late to be starting this work. The product owners need to learn how to start expressing what they need in a way that can help a team make good estimates, rather than just producing a list of tasks that all require further investigation, and someone needs to make sure the results of this research are somewhere that the team can access, so that (for example) the QA folks can work on developing extensive acceptance criteria during their down time in the sprint rather than waiting until the actual point where the work for a sprint is being chosen to decide what the verification points are going to be. (These meetings move fast, and its difficult to spend the time you need to develop these tests fully when it's holding up moving on to the next item for estimation.)

I think this is where we've critically failed. We didn't have enough in the backlog to start with, which meant we didn't have enough work to prioritize the first day (and we ran out of time rathe than running out of work to do), we didn't spend time during the sprint working to further flesh out our backlog, and ultimately our team probably operated at 60% of what our capacity should have been for the sprint. We didn't know where to go to get work and we didn't have the work prioritized so we could just "grab the next card." Result: a very frustrating first sprint, and, I'm sorry to say, a second sprint that is about to start without a sufficient definition of the work we are going to be doing.

Next up I expect I'll be talking about how to create user stories.