My Stories Are Bigger Than Your Story
Big Stories...
I've always found it a challenge when new teams are adopting scrum but have simply renamed their list of requirements as a product backlog. Scrum provides a nice facade which shows a steady progress of churning through these requirements, but it makes it extremely difficult to measure the tangible business value. This is particularly the case where we have a scrumbut model, especially when done doesn't include production/release.
The progression from a list of requirements to user stories with acceptance criteria is usually the first step I recommend, but this is fraught with danger. Requirements typically have inherent dependencies that don't translate well into stories and requirements are also usually solutions to problems rather than the problems themselves. It is only by uncovering the underlying problems that we can start forgetting about the "requirements" and start providing tangible business value by solving business problems.
The first stab at cutting user stories usually results in very large stories with very vague, subjective acceptance criteria, if indeed there are any acceptance criteria. As teams work on these large stories, the tasks they produce are also probably too big and vague and simply sit forever in the in progress column. This is usually due to blindly trusting and following the scrum process. At this stage I usually challenge teams to stop tracking tasks and instead focus on delivering the stories. This is extremely uncomfortable at first since teams will be struggling to deliver big stories. However, it only takes a sprint or two before the team start focussing on the stories and feel relieved that they don't get bogged down in 3 or 4 hour planning meetings to produce extremely detailed task breakdowns. The tasks are still extremely important to capture and update, but this is more of a real-time activity and no-one gets penalised for adding new tasks, or removing tasks that are not needed any more...
This hybrid scrum/lean model provides much greater opportunity to start introducing new technical practises (e.g. test first, automated acceptance testing, etc) since stories are broken down at the last responsible moment and some stories are natural candidates (comfortable technologies, clearly defined, etc) for trying new things.
The next challenge I usually face is getting stories to a size that is acceptable for the team and the PO. Applying the INVEST model works quite well here as does parking open questions through agreeing to raise future stories as required to limit the scope of the story in question to something that is estimatable. At this point stories can become quite small (which is great IMHO) with perhaps only 1 or 2 acceptance criteria. This for me is the sweet spot. It means the story will probably fit in the 2 hr to 2 day window, it is well understood, it is easy to estimate, it is easy to test and a host of other great things... However, it will also probably invalidate any existing (but also highly dubious) velocity metrics since the team will need to rebaseline...
Scrum
I've witnessed scrum applied extremely well, when supported with some additional technical practises and good story discovery/acceptance criteria/backlog management, but more often than not in my experience scrum is applied as the smoke and mirrors over the requirements list to demonstrate progress and it's only when you hit the last sprint you realise that you can't integrate/release/deliver despite having completed 90% of the requirements before entering the sprint with only a couple of requirements to go (e.g. Oracle Auditing and Secure Messaging)...
Limitations of “Grow Your Own” Agile
"Grow Your Own"
Over the course of my career I have worked at several organisations and have always tried to improve the internal processes using agile techniques and principles. Despite being a valued employee (I hope) at each of the companies I have worked at, the amount of success I achieved in agile adoption always reached some internal limits. It was only when I joined emergn that I was able to rationalise this.
It is inevitable that as an employee of a company you will have something to do as part of your day job. This will always be your primary concern and there will inevitably be certain processes you must follow in order to perform your function. Changing this process from the inside will usually involve challenging the process (rocking the boat) using rational arguments and demonstrable alternatives. This is certainly achievable, but does take rather a long time to introduce even simple improvements. Organistations, particularly large organisations are not content with local optimisation and nearly always want to ensure that any benefits from a single improvement become the standard for the organisation as a whole. This usually means that the number of interested parties is artificially (and politically) quite significant and therefore the amount of resistance to change is high.
As an external coach the mandate is entirely different.
First and foremost, your primary function is to instigate change.
This will mean the amount of resistance is significantly less.
Secondly, you will not be tied to existing processes.
This means you can implement changes and improvements much faster.
Thirdly, as an outsider you are automatically assumed to be an expert.
This will mean that you will not need to engage in the same level of rational argument or discussion as an internal employee.
Lastly, as an outsider you bring some diversity and objectivity to the environment.
You will not be unconciously constrained by any existing processes or internal preconceptions about the art of the possible.
As an external coach now, I am actually extremely surprised with just how much compromise I had been willing to unconciously accept as an employee. Every small improvement I would have liked to make became a battle and unfortunately I lost many of these battles not through a lack of rational argument but through a lack of energy or time to continue to fight. When push came to shove I had to get on with my day job and ensure I lived to fight another day. Reflecting now, I'm not surprised that the more successful some of the improvements were the bigger the political entourage became and the more difficult it became to make the next improvement. Battles had to be chosen carefully not necessarily for the potential benefit but often based on the people who had expressed an interest.
I'm aware (and quite proud) of the changes I've made in each of the organisations that I've worked at but am left reflecting whether the effort was worth it. I think the barriers to continual improvement are probably a major factor when I decided whether I wished to remain at a given company and I can now see that effecting change from the inside is simply not effective. It will take at least twice as long to be at most half as effective as an external coach.
Avoiding Inertia
Michael Hill has produced a lovely essay about how TDD and Pair Programming ensure that the internal quality of your code doesn't cost you in future productivity. It is often difficult to grasp the benefits of TDD and Pair Programming due to the inevitable short term perceived hit in productivity. It is extremely important to recognise that the short term hit is however producing the desired side effect of highly maintainable code as a natural byproduct of producing high quality, well tested, simple code.
http://anarchycreek.com/2009/05/26/how-tdd-and-pairing-increase-production/
More Reasons to Pair
Pairing is perhaps the hardest sell of the agile practises, so it is extremely refreshing to see yet more compelling evidence, courtesy of Mark Needham, of how pairing is extremely effective, in this case in the context of a large-scale refactoring (although I wonder just how the business assigned value to this activity).
http://www.markhneedham.com/blog/2009/05/26/pair-programming-refactoring/
I would concur that refactoring is much more effective while pairing and it is often while refactoring that patterns emerge which makes up for the lack of upfront design, so having more than one brain looking for patterns will ultimately lead to better code...
Pair Programming from the Trenches
On a recent gig for exoftware I introduced pair-programming to a (very) small team and over the course of the engagement we held regular retrospectives specifically about how the pair programming was going. This was very much an exploratory exercise for a substantial company and the findings were extremely encouraging. To really benefit from pairing does require some major organisational and cultural changes and this is very early days, but fingers crossed...
Of course, when pair programming is done well, with a group of experienced developers the benefits are enormous, and if you're wondering what pair programming really means, then the following article from Rod Hilton sums it up extremely well...
http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/
This not only provides an insight into the life of someone doing pair programming, but also hints to the true benefits of pair programming, which is always a tough sell...