Think Backwards to Split Stories

Splitting stories through vertical slicing is something you’ve probably heard and are practicing.  Now you’re probably thinking “I’ve done that before, this is simple.”  If that were the case, many of the agile consultants would be out of the job.  It’s harder than you think to have the discipline to slice features up.  It’s also tough to be disciplined and make sure that ever iteration has multiple features in the iteration. 

Often times iterations become boxes of features – when planning the sprint the question asked is “what can you deliver in 2 weeks” as opposed to “what can you grow in 2 weeks”.  Creating two week feature boxes is encouraged by a lot of authors that talk about release themes – people misunderstand that to mean that sprints should be themed.  When push comes to shove the sprint is extended to meet the completion of the theme.  Sound familiar? 

Thinking in terms of a pull system rather than ‘pushing’ work into a sprint will go a long way.  I’ve had students that said their software is extremely complex and nothing can be produced for weeks on end.  Consider this – do you compile and check out what the code is doing only after the end of weeks – I hope not.

A 2 week sprint is 2 weeks of time, not an estimate of what the team thinks can be completed in 2 weeks which is then extended to accommodate the estimated features.  You’ve got to think backwards, that will help quite a bit.

End of the line for a coach

I’ve been a consultant for quite a number of years, in both technical and managerial roles.  One thing I’ve noticed about being a business coach – the end of the engagement is very different technical engagements. 

When you’re a developer and the end of the engagement comes, it’s usually because some huge project is finishing up.  There’s a celebration and a sense of finality.  There’s usually a concrete deliverable and the project is moving into a new phase of routine operational maintenance.  It’s over and, hurray, you’ve done it.

When you’re a coach the end of the engagement is quite different.  The client no longer relies on you for understanding or your expertise.  It’s down right sad.  You begin to be less and less important until they come to you and say that they don’t need you any more.  Hopefully they end with a retainer for a certain period.  You don’t go out in a blaze of glory but tend to trickle out.  So sad.

I must say though, knowing that the client doesn’t need me any more is actually satisfying, despite knowing that I won’t be working with the teams any more.  Human nature makes it difficult to look at the positive in such a situation – the end of an era – but if you’re even in this situation, just consider where they were when you started.  They’re probably better off.

Agile Contract Models

Using the agile software development process in conjunction with client contracting is challenging due to the emergent nature of the detailed plan and product. Traditional contracts, used to bid or scope an agile development effort can subvert project execution and causes both parties miss the potential benefits of agile development since a full understanding of the client needs is assumed in a contract. 

Fortunately others have come before us who have tried different contracting models.

Some of the typical models of contracts are listed in the following table:

Contract Name	Description
Capped T&M	Use time and material  but cap the cost based on effort or scope.  Sets up a conflict with the customer as this model assumes all scope is known.
Fixed Bid	Price and scope is fixed.  Quality is the only variable – which is not good.  Assumes all scope is known.
Target Cost	Mutually target a cost, if final product cost is less, split the savings.  If final product cost exceeds target, share the extra cost.  Can be a tough sell and setting the target cost is a challenge.
Target ROI	Estimate work for effort and value to determine each piece’s ROI.  When the summation of effort and value for a sprint reaches a certain ROI, enter a ‘work wrap up’ sprint and end the project.
Contract by story point	Work is broken down into small stories and estimated by story points.  Fixed bid work is based on number of story points.  As the project progresses, scope is fixed but stories can be exchanged as long as they are not currently in a sprint.
Money for Nothing Changes For Free	This is a combination of target ROI and contract by story point.  The work is targeted toward a certain ROI and stories of the same size can be exchanged as long as they haven’t started yet.
Contract by Sprint	Each sprint is a mini project.  Could be contract by several sprints. Client can cancel after any given sprint.

* A good blog on agile contracts from another scrum.org coach:

http://scrumology.com/an-overview-of-agile-contracts/

The best contracts for agile use a variable scope and shared risk approach.  Of those, Target ROI, Contract by Story Point, and Money for Nothing Changes for Free are the most popular and effective.  Here’s a description of each.

Target ROI

Target ROI works when customers want fixed price estimates for the entire contract up front but the work has not been fully .  The Agile contract allows termination of the contract when the value of features drops below a certain ROI criteria.  It can be effective for delivering high value to the customer for a reasonable price and building trust.  The ROI value can be based on revenue or using other techniques. 

Contract by Story Point

Contract by story point works can well when the client wants a fixed bid based on work that isn’t very solidly defined or is emergent.  The estimates determined based on high level story points and, as work is broken down, stories of the same size can be substituted as long as they are not within a sprint.  This technique works well when the client doesn’t know what they want or there is a large risk of discovery.  It can be risky though for both parties considering team velocity comes into play when billing the project.  Also story points can become a sticking point in client-provider relationships when the provider re-estimates detailed stories.

Money for nothing, changes for free

“Money for nothing, changes for free” can be though of as combination of Target ROI, Contract by Story Points, and Target Cost.  The following elements of each are combined:

·      Contract by Story Points - the estimates determined based on high level story points and, as work is broken down, stories of the same size can be substituted as long as they are not within a sprint. 

·      Target ROI - Delivery is based on a target ROI, and project payment is based on a mutual price

·      Target Cost - Mutually determine target a cost for a certain ROI, if the ROI is reached and the final product cost is less, split the savings.  If ROI is reached and the final product cost exceeds target, share the extra cost. 

This is a complicated contract but the risk is shared, the delivered product is malleable, and success is based on what really matters – value. If the business value is not realized on a particular cost target, then there should be a fall-back to time & material.

 “Money for nothing, changes for free” contract turns the advantages of the agile development processes into a competitive advantage by prioritizing and delivering business value incrementally and allowing change when something is learned.

SAFe and Agile

Incase you don't know SAFe stands for Scaled Agile Framework.  It's a framework for scaling agile through an organization and it's controversial - why later.  Think of 20 teams working on multiple backlogs and multiple year projects.  The funding - the planning - the organization - the roles all of these things are where SAFe is meant to play.

I attended a 4 day course for SAFe certified consultants a while back and wanted to share my thoughts.  First of all, SAFe could very well be a RUP-like tool with the same negative results.  The 4 day training gives the student the ability (if passing a test) to roll out SAFe at an organization as a consultant including training and process consulting – hogwash.  

Some students could implement SAFe in a large organization. Despite experience in agile at the enterprise level, I personally feel uncomfortable in such a role without seeing SAFe in the works.  Mistakes could lead to organizational level disaster. On the other hand, having appropriate guidance on enterprise adoption can be very helpful in the right hands.

SAFe does talk about emergence, self organization, and a lot of the leadership dynamics, but in the context of company maximized profit and a push-top down mentality. Decisions made at higher organizational levels can be painful in the wrong hands when the decisions are not based on a thorough understanding of emergence.

It also breaks a lot of the ground rules of scrum through HIP sprints, multiple levels of product owner, multiple levels of scrum masters, and potentially long planning horizons.

The big questions I have about the process revolve around it’s overall focus on large, large projects.  Why do you need 50 teams on a project?  Why not make a lot of small projects?  Why plan out for a couple of years?  Can you decouple work so that dependencies among teams isn’t so much of an issue?  How do you tailor SAFe? 

These are all questions that weren’t answered in the class and, frankly, I don’t know the answers either.

Ultimately SAFe has merit as a starting point, but should be applied with caution – it can easily be implemented as a push style of management without having an understanding of agile itself.  Remember values over mechanics.  Agile in general could get an ugly name through SAFe or any other process being implemented through certified neophytes.

Agile Adoption Maturity Levels

I recently had a thought that I'd like to share with others regarding agile thinking.  

I believe that agile maturity can be thought of in three levels:

1) Level 1 is where agile is thought of as a way to allow change through adaption and inspection.

2) Level 2 sees agile as proactive in it's ability to change:  it not only allows change, but proactively positions the organization to expect and anticipate changes, in part by actively deferring constraining commitments.

3) The most mature agile organizations must seek out change, not just passively await it.  The example is organizations that foster change through techniques such as hack-a-thons or innovation days.

I've come to see these levels by watching multiple companies introduce Scrum and the supporting agile mindset without seeing product innovation.  They simply wander to the same general destination as they always have, minimizing risk and reducing waste, the only innovation being in the minor details. That’s a pity, but often the best you can hope for until the organization matures.

These levels are not meant to relate to Shu-Ha-Ri nor the Dreyfus model of skill acquisition.  It’s just way of progressing a company to higher levels of empirical processes based on their attitudes of change.  It works for me.

Have you experienced the same?