Your User Stores are suffering from a crooked ‘Spine’ at the bottom

One problem it seems every “agile” implementation has today is a crooked spine.? No, I don’t mean calling out the slick salespeople who sell bloated help desk software that’s been “agile washed” to sell licenses everywhere.? I am talking about the actual spine model that the agile manifesto and, with further definition, XP was structured around.? In case you’re not familiar, it looks like this:

Many of you will be familiar with the Agile Manifesto and its 4 values and 12 principles. The values support the principles. The principles can always be tracked back to the values they represent. XP takes this further and is prescriptive in Practices that are supported by various Principles. Likewise, you can see how frameworks like Scrum and SaFE have specific sets of Practices as well. The full details can be found at https://spinemodel.info/, but the basic summary goes as follows, quoted from the documentation page as you consider all of Agile & XP as being systems - which, of course, they very much are:

“Once you've started to understand the reasons the system exists in the first place and the reasons you want to be a part of the system (Needs), you can decide start to consider what to optimise for (Values). As you have some idea of what you are optimising for you can begin to know what ecological levers are going to get you there (Principles). Once you have that, then it starts to follow how you are going to do it (Practices). And, once you have done that, decide if any mechanisation would improve efficiency (Tools)...”

So what does this mean for Needs and Tools in the context of agile?? We make some assumptions in this model about what our Needs are - to the point where, if these philosophies of Values & Principles weren’t meeting our Needs, we’d have abandoned the Values, Principles, Practices, and probably Tools. However, I believe we have absolutely suffered by allowing everyone and anyone to indiscriminately tell the people doing the work what tools to use!

Project Management Tools - The wrong tools for Agile Teams

The early days of agile practices, we were lucky.? SO LUCKY!? Everyone used index cards in physical spaces for stories and tasks.? Backlogs were tracked in Excel.? Does this sound terrible to you?? If so, why??

Developers needed to track stories and development tasks in person, face to face, as we worked on delivering functionality.? It worked great.? We would run our own experiments on the board - change WIP limit, add some new notation for who’s pairing with who.? Blocked card? Just “tack” it at an angle.? Someone making changes to task cards?? Those were marked in screaming red marker with “NEW!” This was a reasonable, fine grained view of immediate work that has been completed, and work that is still in process. Our XP “Customers” (the traditional XP role name) or Product Owners needed to discuss and track stories at high levels.? Excel spreadsheets were a bit cumbersome, but worked for this. A spreadsheet gave a reasonable, high level view of work to be done AND the basics of work that is in process.

So what went wrong, you ask?? Simple: nobody asked the most important question about tools, which is always the very first question you should ask when you pick up a tool to accomplish some goal - “Is this the right tool for the job?”? And that’s where the software industry as a whole shoehorned the wrong solution into what looked like the right problem.?

It’s not a f*cking ticket, it’s a damn User Story!

Out there, in the world of software development is a monster.? This monster is imposed on development teams to observe and track their work by people who do not DO the work.? Ask anyone who delivers ‘hands on keyboard’ if they like it. Go ahead. I dare you to find someone that would put THAT company sticker on their laptop without irony. It’s project management software, or workflow software simply “agile washed” so that it looks like what teams need. The biggest problem?

Those stores are User Stories! Not tickets! They were originally just cards on a board.? But those cards represented promises.? Promises for conversations (see https://www.agilealliance.org/glossary/three-cs/ ). The entire point of user stories in agile is to spark those conversations. Those conversations embody the agile Value of “individual interactions over processes and tools”, and the user stories once written on those cards double down their value with the Principles of “business people and developers must work together daily throughout the project” and “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” (even if ‘face to face’ is on a Zoom call with cameras off).?

User stories are a bridge point between two vital levels of software feature visibility: the vision/feature/road map level of the product, and the detailed and down to the metal level of ‘work in process’. But putting them in the same software system for the needs of two different communities is wrong. It was never the intent.? Ultimately, it serves neither well.

Okay, wise guy.? So what should we be doing instead?

The solution is simple, only has three steps, and can have cost savings as well:???

1. Leave teams to pick their own physical or virtual cork boards, thumb tacks, index cards & stickies. Let teams organize, visualize, and track User Story elements and activity as it works for them.
2. Leave anyone who doesn’t do “hands on keyboard” delivery (XP customer, Product Owner, Project Manager, Scrummaster, Manager) to use whatever software they want to manage those initial User Stories. Recognize that typically at least 75%+ of these are NOT even currently ‘in process’!
3. Consider reviving the original XP tracker role. Make one team member responsible for reporting story progress to management at least once per day, rotating this responsibility every iteration.?

Bonus: Want to save money?? Give up all the developers license cost to that PM system, or just use one floating license if available for each tracker per team.

But wait! I can hear you say.? “Doesn’t this mean a duplication of information?! Doesn’t this violate the concept of there being only one source of truth?!”? And to this I say, “No.”?

It’s the same as it ever was for the team. The team's board is their source of truth.? All the low-level details of story progress are here, focused on the visualization and organization of work currently being done. Without the noise of future issues. Where the team’s truth should be. To be used and improved as they see fit.? To deliver better software faster.

It’s the same as it ever was for management.? The project management software is the manager's source of truth.? All the high level concerns and strategies can be hashed out here, without the noise of current activity.? Where the managers’ truth should be.? To be used and improved as they see fit. To sharpen and improve the product vision and direction.

What’s old is new again.? And yes - this works just fine.

In my last full time development role about a year ago, we largely adopted this model.? Our working board, although virtual, incorporated something that myself and some former colleagues did on physical boards (and the occasional office window!) in an early evolution of FaST (see https://www.fastagile.io/ ) called Discovery Trees (see https://www.industriallogic.com/blog/discovery-trees/ ).? Our customer wanted to use that all too common piece of project management software that couldn’t handle Discovery Trees.? And that was just fine.? The “ticket id” was put on the top level story element of our virtual Discovery Tree “forest”.? At least once a day we updated what was ‘in process’, ‘ready for review’ (there was a manual QA step - mobile devices involved), and ‘done’.

The result was everyone not only got what they wanted, they got what they needed.? Help desk ticket tracking software used for project management that could not support Discovery Trees was not forced on the delivery team. Evolving, high context technical work mechanisms were not forced on the managers and stakeholders. They only wanted the big picture anyway, not to stumble around what at first glance might be mistaken for a “software murder board”.

It’s time for a divorce.? The separation of bloated PM tools from delivery team creativity.

Delivery teams: Ask.? Or, simply ask for forgiveness;) If you’re a team of ‘hands on keyboard’ people suffering with restrictive tools you’d never use in the first place, try a simple sticky board or cork board with cards (either in person or virtual) to run your iterations. Experiment with different notations & representations of how you’re handling the work you are responsible for.? Be sure and include that pesky ‘ticket id’ to track back when things get ‘in process’, ‘ready for review’, or even ‘done’ as well as significant stat changes (e.g. the size blew up).? For a typical team, it doesn’t take too long to update the PM tool once a day to reflect what’s going on.??

Product Owners et. all: Focus on the big picture and tracking your stories.? Let the teams get the ball over the line while you figure out the next play.? Need to update or refine something? TALK TO THE TEAM! Remember again: those virtual cards were never intended to be changed without a discussion (see again https://www.agilealliance.org/glossary/three-cs/ ). Keep the team honest by making sure they’re updating what’s relevant.? In return, you should be honest about the visibility of what’s coming up.

Postscript

There’s a lot of people out there today saying “agile is dead”.? I don’t believe that.? But it certainly has had its value, intent, and full capabilities buried in order to allow misguided and greedy actors to collect some fat paydays from schemes that have done more harm than good over the past two decades.? Be it certificate mills turning roles into job titles, or bloated help desk software hindering communication and organization of technical work, it’s time to leave “bad old agile” behind.? I think that’s best done by getting back to basics, and we can start with fixing our ‘spine’.