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.
Friday 13 March 2009
Thursday 5 March 2009
The Eternal Questions of the Spotless Scrum
Much as people question, "Why does bread fall butter side down?" and "Why is something always in the last place you look for it?" I find that Agile has its own eternal questions. The one that is the most problematic is, "Why is it that it's so hard to get business owners to commit enough time to get the work done?"
Thinking about it, there are two things that probably ought to change. The first is in properly training the business owners about the change in their responsibilities. This should be part of the agile ramp-up in an organization (and was a step we skipped), and should include information like how to work the product backlog and how to develop user stories.
The second thing is more difficult to manage and has to do with freeing up their time. It's one thing for the development organization to say they're going Agile; it's another thing for a business owner, who, says, has responsibility for managing a team of (let's imagine) customer service agents, can suddenly make all of his other work go away and sit around "being available" for the team that needs his input rather than being there for the team he actually needs to manage. This is a much more difficult thing to work around, though colocation helps (not that I think a Dev team really wants to sit in a call center), but also anticipating this by reducing other duties a business owner might have is a possibility.
How has your company handled this?
Similarly, I'm curious about initial velocity calculation, for when you're trying to figure out hw much work you can get done in your first sprint. We had no estimations of the number of actual hours our team could work during a week, so we just made it up based on what we felt comfortable saying yes to - and wound up being 25% under our actual capacity based on when we've run out of work. Ideas on how to manage this?
Thinking about it, there are two things that probably ought to change. The first is in properly training the business owners about the change in their responsibilities. This should be part of the agile ramp-up in an organization (and was a step we skipped), and should include information like how to work the product backlog and how to develop user stories.
The second thing is more difficult to manage and has to do with freeing up their time. It's one thing for the development organization to say they're going Agile; it's another thing for a business owner, who, says, has responsibility for managing a team of (let's imagine) customer service agents, can suddenly make all of his other work go away and sit around "being available" for the team that needs his input rather than being there for the team he actually needs to manage. This is a much more difficult thing to work around, though colocation helps (not that I think a Dev team really wants to sit in a call center), but also anticipating this by reducing other duties a business owner might have is a possibility.
How has your company handled this?
Similarly, I'm curious about initial velocity calculation, for when you're trying to figure out hw much work you can get done in your first sprint. We had no estimations of the number of actual hours our team could work during a week, so we just made it up based on what we felt comfortable saying yes to - and wound up being 25% under our actual capacity based on when we've run out of work. Ideas on how to manage this?
Subscribe to:
Posts (Atom)