Wednesday, November 08, 2017

Careful with that brain, Igor!


So - you have invested in transforming to an agile development process. Your teams have honed their processes until it runs like clockwork, and are resilient to changing needs. Software is being produced cleanly and efficiently with minimal fuss.

But there is still something missing. The software simply doesn’t do what you expect. The customers don’t like it, and won’t use it. It has annoying quirks and foibles that put people off. It simply isn’t right. What’s going on?

Congratulations! You have discovered the Achilles Heel of all software development. It has to have an undamaged brain. A well disciplined agile team will deliver whatever its business brain asks of it. The team is only as good as its inputs and subsequent feedback on its deliveries.



Or to put it another way, so-called ‘agile’, and all other software delivery processes for that matter, rely on sound business thinking. Make Abby Normal your customer/Product Owner, and you will be in serious trouble.

At its heart, agility is about delivering a product iteratively, delivering a small slice of value for validation, and getting feedback whether it is right, allowing corrective action as needed as lessons are learned. This means that for software delivery to succeed, business - however you define it; customer/product owner/whatever - must engage fully. This includes providing a definitive product vision to the team, prioritising what needs to be delivered next, and making decisions based on the results of each iteration. Throwing away work is perfectly valid, and can be beneficial. Break this feedback control loop and it will not work, no matter how good the team is.

By treating projects as a series of small, iterative gambles, the business becomes far more likely to succeed in delivering what it intends. The business, as well as the team providing the raw development talent, needs to be agile in its thinking. If it’s not, then you run the risk of putting an abnormal brain into a seven and a half foot long, fifty four inch wide gorilla....

Don’t be an Igor.

Monday, May 08, 2017

Of Goals, Backlogs and Sprints


Jean-Fran├žois Millet (II) 014
As an experienced developer/coach, once in a while you get asked a truly fantastic question by a client who has actually done her homework, and you're absolutely stumped by it. I love it when this happens since it is a fantastic opportunity to not only learn, but also to teach the client how to solve similar questions themselves next time.

This particular team had been attempting to implement Scrum for some time, with a degree of success. But one thing was bugging them in particular. How to control stories in-sprint. The advice they had been given (and the way I understand Scrum to work) was that sprints are immutable. During the plannig game, the team sets the sprint backlog, populating it with the subset of backlog stories that the team believe they can fit into the timebox. That's it - only a major event causes that to change, in which case the sprint is terminated, replanned and restarted.

So when the Scrum Master asked about the 2016 edition of the Scrum Guide, and why it seemed to contradict that view, I was somewhat surprised. Here it is, in black and white:
As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real -time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Woah! Wut? What madness is this? The Scrum Manual contradicting Scrum as I understood it for years? Having battled with seemingly random, moving requirements during my early professional years I can relate to why processes such as Scrum limit the amount of churn. But this paragraph seems to encourage it.

What to do? What could I do to help? I did what any sane person would do in a situation like this, and asked some People Who Know - other coaches in my network and got three different answers back. Hmmm…obviously some room for interpretation here.

So, having scratched my head for a while, it turns out I had missed some nuances. Here's a fourth point of view, hopefully pulling in the salient points from the other three.... The documentation is not giving out an inconsistent message at all. But it is subtle, and open to (bad) interpretation if you don’t pay attention.

Looking at the wording above in isolation was the problem. Reading it in context, a previous paragraph says,
The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
(my emphasis)

So what is being added to/dropped from the sprint by the team mid-sprint is the work needed to achieve the functionality. So it is the functionality (defined in User Stories) that is fixed ("At the end of the sprint, the software wil do x, y and z that it didn't do last week"). Tasks (build a database, define a service etc etc) to get there can vary - which is unsurprising.

I believe one reason I missed this subtlety was because I generally recommend teams do not split stories ("functionality") into tasks since in my experience it encourages not finishing - all the easy things get done, but the software still doesn't work! Also I have found it encourages micro-management, and the use of the severely damaging "Predicted time/Actual time" fields in reporting tools like Jira. Sometimes splitting things out is useful, but usually less so. Most teams don’t miss this micro-planning step, and are very succesful without it.

I think this explains the whole mutable in-sprint work backlog pretty well. Now, what about the Sprint Goal mentioned in the title? It is another much abused Scrum artefact. Most (all?) teams I have worked with have had trouble with it, and in some cases just shoehorned it in retrospectively after selecting what to put into the sprint "because Scrum says so" (<sigh>). Looking deeper into how Scrum sees the Sprint Backlog also clarifies the purpose of the Goal.

The Scrum Manual doesn't have any explicit definition of the Sprint Goal that I can see - but the Goal appears to be there to focus the team on the answer the important question "What is the most important thing this software product needs to do next?" . And this is what links it to Features/Stories.

The Sprint Goal helps define what Stories to play next, what Features to implement next.
This means defining the Sprint Goal needs to come before defining the sprint backlog, not at the end as a retrofitted afterthought. Indeed, this is exactly what the manual says:
Sprint Planning, Topic One: What can be done this Sprint?
...
The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal
So the only logical order for the Planning Game has to be:
  1. Define the Sprint Goal (the Product Owner should already know this, or have a pretty good idea of what it should be)
  2. Pick the Sprint Backlog stories that will satisfy the Goal
  3. (Optionally!) break the stories into tasks (“work needed”)
I hope that clears up some confusion out there.