List/Grid Monthly Archives: October 2009
Switching stories mid sprint
Introduction
I blogged about this some time ago and then posted the blog on various agile forums to judge peoples responses.
Most of the responses were well reasoned, however, one of the responses I received shocked me somewhat and so I feel that it’s worth blogging about this particular situation once more.
The response I received was “You’re not serious you’re going to ignore the PO” and “You can’t be a slave to the process”
In all fairness, there are many situations under which the need to switch stories arise. And the specifics were not really provided. For example:
How long are the sprints?
How far into the current sprint are you?
Are there stories that have yet to start that is of similar size that you can switch it out with?
Is this a critical issue that needs to be fixed ASAP as customers are complaining and may negatively impact revenues?
Those are some of the questions that need to be asked when making that decision.
In response to being a slave to the process…
Well you’re either a slave to the process or the team is a slave to any chicken in the company who shouts the loudest. Lets go back to basics and why the Sprint is there in the first place. It’s designed to provide stability for the team to get stuff done. Hopefully you’re doing short sprints so it’s not a lot of time before the team pops it’s head up again and asks for more direction.
If the team listens to whatever the next flavor of the month is, then we’re back to square one where there’s just chaos and nothing gets done. Seriously, smart people figured out why we need to do it this way. There is strong evidence to support that this makes a difference, a really positive difference. So lets not willy nilly and go changing plans whenever someone in the organization feels like there’s something more important to do.
Moreover, in this situation, I think it’s important the team asks some serious questions as to why suddenly there’s a story that’s so super urgent that it calls for a change in plan. Lets say you’re doing 2 weeks sprints and lets say you’re midway. This means in reality that 5 days ago, nothing was more important (top priority items get selected to go into the sprint). Why all of sudden is their a need to change direction so soon after. Additionally can’t it wait another 5 days?
Now I am sure there are times where such a situation arises and that’s fine. I would never be so hard-line to suggest that the team doesn’t collaborate over this and decide what are the best options. And in such a case, it’s important that the team does this.
But lets be very careful how we deal with this. Because once you do this once, it’s a slippery slope after that.
So what would I do. As already mentioned above, I would sit down with the team. Have the PO explain the dilemma. Thereafter, it’s up to the team to decide if there is an easy swap out that doesn’t impact the Sprint goals and productivity. Ultimately if it is possible, I am sure most teams would do it any ways. Level heads should prevail.
State of Agile
Introduction
Seems like there’s lots going on in the agile world right now. Lots of talk about Lean and it’s impact on Agile. Lots of attacks going on at the CSM certification. Kanban is all over the news these days. And just last week, I read about a new Agile methodology called Stride.
So how do we make sense of this all?
My opinion is that there is value in each of the methodologies (for the purposes of this blog I’ll refer to them all as methodologies even though some of you might not think of them as such). It’s real important to read about them all so that you are armed with enough knowledge to know what’s out there. I see this as a toolset from which you can choose for your specific situation.
In order to illustrate ….
Scrum is a methodology and process that provides the mechanisms for teams to learn and adapt. Scrum however doesn’t say much about the meaning of DONE and how to accomplish that. That’s where XP comes in. XP has great practices around engineering discipline. It teaches us all about craftsmanship and producing quality work. I personally cannot see anyone practicing Scrum without at least some elements of the XP toolset. Be it pair programming, TDD, ruthless refactoring, emergent architectures etc.
Lean on the other hand is way more philosophical, but they have great teachings. For example, recognizing that work-in-progress is a liability is huge. If you start to think like this, you’re going to minimize work-in-progress and as a result you will improve overall cycle time. With Lean, people come first. What effect does this have on your organization? Well happy teams make happy customers, better quality software, improved work culture.
And Kanban? Well Kanban helps teams with flow (i.e. cycle time, throughput etc) and almost eliminates the need for traditional sprints which I won’t get into here (subject for another discussion). So many teams are using kanban boards for controlling the workflow of tasks or stories, or both.
Scrum has also been said to have problems with scalability and cross site development shops. Well Stride in it’s infancy (not even sure you can call it an accepted methodology yet) has adapted Scrum to provide capabilities for better handling these sort of situations.
So what do you do?
Well in my opinion Scrum provides the best overall process or mechanism to manage agile project. It’s a good base to start with and I would definitely start with Scrum. But you can’t go it alone with Scrum. You have to pick and pack from other methodologies till you get what works for you.
I think Agile is evolving and most likely wont stop. And why should it. I want us to get better at it. And there’s so many smart people thinking about how to make software development better. I can’t wait to see what it will be like in 5 years from now.
Poka Yoke, error handling for your process
Software engineering is still a very human endeavor. Its a complex process that requires our ability to create non-standard solutions for non-standard problems. But with this ability to creatively solve problems comes a tendency to introduce defects, o…
