Scrum Methods:  Planning for Value

Posted on June 4, 2016
by Doug Klugh

Steve Jobs was obsessed with providing the best user experience to his customers.  Because, above all else, that is what they valued most.  He was the grand master at delivering value to his customers.  Not necessarily in terms of dollars, but in terms of what they wanted.  And while technology helped get him there, his focus was always on exceeding the expectations of the user.

For over 15 years, Agile has been touting better delivery of software products over Waterfall methods.  Better delivery typically includes decreased time to market, greater adoption of changing requirements, increased quality, and happier customers.  The integration of various Agile practices helps to achieve these benefits.  While some practices are fairly easy to employ, others tend to be more of a challenge.  Planning around functionality, instead of activities, is one practice with which many teams struggle.

The Best Measure of Progress Is Working Software

Agile is about delivering value to the customer.  By delivering small slices of functionality often, the customer is able to provide feedback to facilitate frequent course corrections in product development, while it is still relatively cheap and easy to do so.  Like driving a car, it is much better to make a lot of micro course corrections (to keep from driving off the road) than to make just one or two dramatic adjustments.  That feedback loop is an essential component of an empirical process (including any Agile process) to decrease time to market, accommodate changing requirements, increase quality, and satisfy customers.  But to achieve this value, the development team must be focused on delivering value (working software) to the customer and not on creating artifacts for themselves.

Results-Driven Development

Tony Robbins will tell you…  In order to achieve your personal goals, you should not focus on what you need to do, you should focus on the outcome.  Don’t mistake activity for accomplishment.  You are not succeeding by completing tasks, you are succeeding by delivering working software.  Completing tasks will help get you there, and they need to get done, but they should not be your focus.  That is why user stories are written from the perspective of the user.  Because delivering working software is the outcome we want.  Without working software, nothing else matters.

Never the less, this is a very common problem among Agile teams.  They tend to plan around tasks they need to complete instead of functionality they need to deliver.  So what’s wrong with planning around development tasks?  By themselves, they don’t deliver value to the customer.  While your team may develop the most elegant code ever written, your customer will not care.  They care about the working software you promised to deliver.  Is it full of bugs?  How easy is it to use?  How well does it perform?  Tell them you coded the entire SPA in Angular 2 and watch their eyes roll over like a hungry shark attacking a baby seal.  They don’t care!  So the question is…  Are you developing this software for your customers or for yourselves?  And I’m not saying it’s not an accomplishment to code your SPA in Angular 2.  What I’m saying is, if your software does not satisfy your customers, it doesn’t matter how elegant or modern your code is.  So stop focusing so much on the tasks and focus on delivering satisfaction to your customers.  Give them what they want.

Anti-Patterns

This is one reason while we write user stories in the format…  As a <user role>, I want to <function> so that <benefit>, unless <exception>.  This helps the team to focus on delivering value to the customer.  But Agile teams commonly fall into the habit of writing stories from their perspective; for what they need/want to accomplish as a team (or as individuals).  If a user story starts out “As a Team Member” or “As a Developer”, then it’s not a story; it’s a task.  Our goal is not to complete tasks (or to do things), it is to deliver working software.  Never get in the habit of planning around tasks.  By themselves, they do not deliver value to the customer, and customers rarely care about what tasks have been completed.

Another anti-pattern is when teams feel as though they need to break stories up between disciplines (in a waterfall fashion) to be able to complete a “story” within a sprint.  Remember that the entire story (feature) must be small enough to complete within a sprint.  If it’s not small enough, don’t start splitting your cards up horizontally by different stages of development (such as analysis, design, implementation, or testing); take thinner, Vertical Slices of that feature.  For example, if you can’t develop the functionality of an entire screen within a sprint, develop just one function, such as a button.  Horizontal slicing does not provide value to the customer and only helps to revert your team back to waterfall practices.  Vertical slicing of features takes practice, especially for teams doing procedural programming, such as COBOL or FORTRAN.  But it can be done; it just takes some coaching and a little practice.

Technical Excellence

While it is important to focus on working software, we do not want to neglect technical excellence.  And we need to understand what we mean by technical excellence, what the outcome is, and why it is so important.  Building software that is easily extensible, easily maintainable, and easily testable is not our goal, but it is an objective that will help us to quickly and consistently meet customer needs through working software.  While we intend to achieve technical excellence, we must not get distracting in thinking that developing an elegant architecture is our goal.  Development plans should not focus on artifacts or development tasks, but must focus on the delivery of valuable features to the customers.  After all, that is why we’re developing software in the first place.

“Continuous attention to technical excellence and good design enhances agility.”1  True agility can only be achieved if you have well engineered code that is easily extensible, maintainable, and testable (see Agility with OCP), along with well defined and well executed development operations.  Employing continuous integration (CI) will go a long way in being able to develop valuable features, from inception to deployment, within a sprint (see Building Success with CI).  Testing early and often through Test-Driven Development (TDD) will also help to ensure a high-level of quality.  Overlaying these and other XP practices will help to promote technical excellence.

Conclusion

Steve once said “Our goal is to make the best devices in the world, not to be the biggest.”2  His goal was not to build the greatest company (although that was probably a byproduct); his focus was always on building the greatest products.  And for us to succeed at delivering great products and services, we must be more like Jobs.  Luckily for us, Agile comes with that built in.  We just need to apply it.