Category: Software Development

[This is part two of this blog series.  Part One contains an explanation of User Value Trees. You will probably need to read that to make sense of this post.]

We saw in part one that User Value Trees (UVTs) are a way to map the domain of a user’s tasks, goals and motivations.  UVTs provide a way to connect User Stories to higher level goals and to group user stories into the flows of work that are necessary to achieve those goals.  In this and the following posts I outline some potential applications for a User Value Tree based on my experience putting them into action. We start with User Value Tree as card wall. 

User Value Tree as Card Wall

In part one of this blog post I noted that the (kanban) card walls that have become universal in agile software development are not maps.  The card wall is a workflow tool designed to enable teams to visualise and track the completion of tasks.

This leads to a number of problems that I will explain in more detail in a future post.  Among these is a lack of strategic visibility available to team members.  As the vast majority of software projects revolve around delivering functionality to end users, it makes sense to track progress aganst the delivery of that functionality.  This was the original thinking behind the advent of the User Story.  The problem with the traditional card wall is that it focuses on the workflow of the team right now.  Who is doing what?   What is the status of the stories? What is the priority of upcoming work?  Cards arrive onto the wall and disappear off the wall.  The focus is always the current iteration.  This makes it very easy to lose sight of the bigger picture.  Almost all agile software development projects struggle with this challenge.

I wondered what would happen if we used a User Value Tree instead of the usual kanban card wall to track the team’s work.  Would this change the focus from the low level implementation details of the project back to the user value being delievered?

Because User Value Trees include User Stories, this turned out to be quite a straightforward adaptation.  We attach avatars, status stickers and mark stories as Done in the same way we would on a normal card wall.  This is what it looks like (zoom in for greater clarity):-

This is the same UVT presented in part one of this blog post.  We turn it into a card wall by annotating the user stories with the usual markings.  The avatars indicate who is working on which stories.  The green ticks indicate stories that are done.  The red stickers indicate stories that are blocked.  Because the User Value Tree contains all the stories we currently know for the project, it also functions as a backlog of work.

We can do everything on this wall that we can do on the normal card wall.  However, this wall contains important information that is not captured on traditional walls:-

• We currently have a dev pair working on the “Export a Plan/Forecast” story.  We see that when it is done, we have delivered the complete work flow which will enable the Account Manager to create a forecast of labour and costs.
• As the “Send to potential client” card is already done, once the create forecast work is complete the higher level goal of negotiating terms of service is also done.  The Account Manager should be able to use the system for that purpose shortly.
• There are no User Stories below the “Manage labour expectations” and “Manage scope” tasks.  Have we been unable to do the analysis on this work?  Why not?  This is a risk.
• A large part of the Liaise with Client work is blocked. This is a risk.
• We know from the structure of the UVT that delivering the “Measure discrepancy between expected and actual cost” card is of value in liaising with clients.  This task can be completed independently of managing labour and scope.  We know that delivering that functionality on its own will be useful to the Account Manager.
• When the “Export a Plan/Forecast” card is done we don’t have any more user stories ready to go.  We should start to discuss what to do with the dev pair when that happens.

Note that all this information is represented visually.  As the team gathers around the wall for standup each morning, the UVT tells us the status of the project.  We still see the work that is in progress.  We also see how much work has been completed.  The status of individual stories is placed within the context of the whole body of work.  We get the status of the whole project. 

There are some other important properties of this kind of card wall:-

• There is an implied theme of work built-in.  Currently we have have two user stories in play.  These correspond to the larger themes of “Negotiate Terms of Service” and “Liaise with Client”. On scrum teams, this should be a visual representation of the current iteration’s theme.  On non-scrum teams, this solves the persistent problem of losing focus on the goal of the current work.
• There are natural release points built-in.  Once the Export story is done, we should be able to release all the Negotiate Terms of Service functionality.  This is relevant for teams not doing continuous deployment.
• For teams that want to break down user stories into tasks and put them on the wall (even though I think that’s a bad idea) they are easily placed below the user stories.
• We represent workflow by the avatar/status marker that is on the card.  A card with a BA’s avatar is “in analysis”.  If a dev pair’s avatar is there, the card is “in dev”. If a tester, it is “in test”.  The green tick is “done”.
• Larger teams will almost certainly be working across multiple User Value Trees (one UVT for each user).  Thus, the User Value Tree concept scales quite easily.  If the teams are working on the same User Value Tree, it is easy to visualise how the work of the teams contributes to the larger delivery plan.

Using the User Value tree as a card wall is quite a shift in mindset.  Gone is the card wall which focuses only on the current iteration of work.  Gone are the columns which track the status of cards.  These are replaced by focusing on the larger meaning of the work – value delivered to the user.   We conduct standup each morning in front of the entire functional scope of the project structured as a User Value Tree.

We still track the status of cards and who is working on what.   But we do so while placing the card in the context of value delivered to the user.  We can see how the current stories that are being worked on contribute to the larger system. We visualse both the work that has been completed and how much is left to go.   And every morning at standup we are reminded who the user is and what their goals are. 

I believe this shift of focus is a very beneficial one.  Modern software development teams are too preoccupied with their own internal workflow and not on the value delivered to the user.  Kanban card walls reinforce this mindset. 

The User Value Tree brings the team’s focus back towards situational awareness of the whole project.  This should improve the ability of teams to think strategically and steer projects towards delivering value to the user. 

Mapping is all about situational awareness and understanding the context of a complex system whether an organisation, a line of business or a technical system. Without good situational awareness then it’s extremely difficult to identify where to attack and hence strategic why (since ‘why’ is a relative statement – why here over there). It’s even difficult to know how to manage something – Simon Wardley

On the technical side of software development we have many useful maps that we use to understand our work.  Among these are architecture diagrams, object diagrams and domain models.  But what about the maps we use on the business side?  The maps which should help to us to ensure we are building the right product?

At a recent conference, a common theme touched on by many different speakers was to focus on The Why of the product.  What user needs are being addressed? What problems are we solving for the user?  It struck me that many people are working on projects where they do not know The Why.  They feel that they don’t have a situational awareness of what the product is.  Given that the main purpose of a good map is to faciliate situational awareness, I wondered whether the maps we are using are deficient.

Our primary “map” these days is the card wall.  Card walls are everywhere.  There are card walls for each delivery team, cards walls of card walls (SAFe), card walls in HR departments, card walls in kitchens and garages etc etc.  Card walls are fine for short term tracking of tasks to be completed.  They work well to faciliate communication within teams around work that is underway.  But cards walls do not give an overview of our work.

Original agile teams used to tear up cards as soon as they were done.  Nowadays we normally leave them in the Done column until the end of the iteration.  Then they are removed never to be seen again.

For upcoming work we organise the card backlog in terms of priorities for delivery.  A backlog is just an ordered list of cards.  You can’t look at a backlog and see connections between cards or to the overall context of the work.  You can’t look at a backlog and get a meaningful understanding of how much work is left. 

Card walls don’t provide (and are not designed to provide) a map of what has been delivered or what will be delivered.  The card wall’s focus is on what is happening now.  It does not represent the work we have done or the work that is coming up in a meaningful manner.

The closet thing I’ve seen to a usable map is the User Story Map developed by Jeff Patton.  This categorises storoes into abstract functions (eg. ordering, paying, invoicing). It also demarcates releases which helps to provide the temporal context for cards.  However, the User Story Map is ultimately just an ordered list of cards. There is no easy way to navigate through a User Story Map.  You have to read the cards and draw the connections yourself.

In this post I want to outline a new kind of map that addresses some of these shortcomings.  I call it a User Value Tree.

Constructing a User Value Tree

What we need from a map is situational awareness.  Some properties of a good map include:-

• The ability to see the whole terrain
• The ability to see individual elements within the terrain
• The ability to group like elements
• Representing connections between elements and groups of elements
• The ability to represent change in the terrain over time (where relevant)
• The ability to easily visualise alternative paths through the terrain or alternative states of the terrain

To know that we are building the right product we need to understand the needs of potential users.  We want to know the motivations of the users and what tasks they are trying to accomplish.  We want to know that the system is useful.

Traditionally we have User Stories to represent the individual tasks or goals of the user eg. I want to pay for my shopping cart; I want to organise shipping etc.  What has been lacking is a way to meaningfully group individual user stories and relate them higher level users needs and values (although User Story Maps do this to some extent).  That is where the User Value Tree comes into play. 

Let’s walk through the construction of a User Value Tree. 

We begin at the top with the user’s role and a high level description of what their overall values or goals are.  In this case, we have an Account Manager at a consultancy.  Their role is to keep clients happy by ensuring that the product is built and delivered to the client in a timely fashion.  Note that you could enter more detailed, user persona-style data in this place. [Note: zoom in or open the image to view it properly]

[Note: zoom in or open the image to view it properly]

Next we describe the high level, abstract tasks that the Account Manager carries out in their role.  Account Managers work on a project-by-project basis even if the client is the same. 

The first step is to get an initial project scope which is a high level description of the job.  This involves ascertaining if there is a basic fit between what the customer wants and what the consultancy can provide. Do we have the right technical skills to build the product?  Do we have enough manpower?  Can we meet the timeframe? etc. 

If this step goes well, we move on to negotiate terms of service.  This is a more detailed breakdown of the work.  Which consultants will be involved.  What they cost.  How long they will work on the project etc. 

The next step is the signing of formal Statements of Work, contracts, non disclosure agreements and the like.  Following that the project gets underway and the AM’s role is to stay in contact with the client to ensure they are happy with progress.

We can see that the User Value Tree has parent and child nodes.  The parent nodes represent the value that is delivered when the child nodes are fulfilled.  In the case of the AM at the consultancy, the customer is only happy when the product is only delivered.  In order to deliver the product, we have to carry out the four child nodes.  The child nodes therefore represent an entire flow of work.  The horizontal grouping of nodes represents this relationship between the tasks.  We capture it by having the child nodes connect upwards to a single horizontal line which then links back to the parent.  This means that the tasks below are in an ordered relation.  They must be carried out in a fixed order.

If you start at a child node and ask the question “why is this task important?” you simply navigate up to the parent node to find the answer.  Why do we conduct initial product scope?  Because it is part of delivering a product to our client.  We can’t deliver a product without first knowing what the product idea is.  Similarly, we sign contracts and statement of work because they are legal requirements that must be in place beore work starts. 

This ability to capture the parent-child and sibling relationships between tasks is a key feature of the User Value Tree.

To continue constructing the UVT, we take each node and ask the question “what child tasks are needed to complete this task”?  In this example, we focus on only two nodes. 

“Negotiate terms of service” requires creating a detailed forecast of labour and costs and then communicating it to the potential client. 

“Liaising with the client throughout the project” involves managing expectations around budget, labour and scope.  This is because projects start with the forecast of labour and costs but things happen are not in the forecast eg. sick leave, resignations, unexpected events.  There is a constant process of ensuring expectations are updated to meet reality.

Note the difference in how the child nodes of the “Liaise” task are connected to their parent.  In this case, there is no horiztonal connection between the children.  What this means is that there is no necessary relationship between these tasks in the real world.  You do not have to manage budget expectations before managing labour expectations.  You can manage scope without worrying about time and money.  We represent this by drawing a single line from each child back to the parent.  This is different from the parent-child relationship at the top level where each child was horizontally connected to each other before joining back to the parent.

This ability to represent whether tasks are necessarily connected or not becomes useful when prioritising work and thinking about releases of the software.

Finally we get to the last level of the UVT.  This level represents the User Stories we need to build our system (you could think of the higher level taks as Epics).  The child nodes of the “Create  forecast of labour and costs” are Create a Project, Create a Forecast and Export a Forecast.  As the child nodes are connected to each other horizontally, we know that they are in a dependent relationship.  In order to create a forecast, we must first create a project.  In order to export we must first have a project and a forecast.  We also know that all three of these tasks must be carried out before we have delivered the higher level value of creating a forecast of labour and costs.

For liaising with the client, the system only provides functionality around budget expectations.  It measures the discrepancy between expected and actual costs.

At this point we have the full User Value Tree for this project.  The Parent-Child relationship at each level allows us to easily navigate through the tree.  You can go to any user story and ask the question “why is this important?”  The answer is already there in the parent node. 

Why is it important to create a project?  Because you need it to forecast labour and costs. 

Why is it important to forecast labour and costs? Because it’s part of negotiating terms of service with the client. 

Why do you need to negotiate terms of service?  Because you need to give a price estimate and agree on how work will be carried out.

Thus, the User Value tree gives us a clear and detailed situational awareness of the user’s goals and tasks.

The User Value Tree as a map

We can see that the UVT fulfills the properties of a good map:-

• It provides an overview of the whole terrain.  In this case, the tasks and needs of the Account Manager.
• It places individual elements in the terrain i.e. the tasks.
• It groups the tasks meaningfully showing which tasks are connected, which tasks need to precede others, which groups of tasks add up to higher level goals.
• It allows us to visualise different pathways or alternative ways to do things.  For example, what if we removed an entire branch or work, could we change the order of branches of work, what if we did not provide certain tasks or branches of work in the software, could these be handled manually?

For any given task, the UVT allows you to place it in its context – the parent goals it contributes to, the child tasks needed for its fulfilment, the tasks that precede it and those that follow it.

The fractal structure of the UVT also allows you to drill down to as much resolution as you would like.  In the example above, we stop at the level of the User Story as this most relevant for us in software develoment.  But there is no restriction on going to higher resolution and including lower level tasks.  How do you create a project?  You click on the Create button, you enter the name, you click save etc etc.

Conclusion

The User Value Tree is a map that gives us situational awareness of the user’s values, needs and actions.  More importantly for software development, it gives us a way to place User Stories in their proper context: the value to the user.  This enables us to see the relations between stories and how stories fit into the large picture of what we are delivering.

In Part 2 of this blog post, I will give an account of the UVT in action.  We will see how the UVT can be used as a tool for discovering and specifying requirements, organising and track the daily work of the team (instead of the traditional card wall), planning releases, mapping test coverage and as a schematic version of a user persona.

I’ve done many different jobs in my life.  I’ve done work on a farm (where I grew up), semi-skilled work in manufacturing, bartending, legal secretary, call centre operator, hotel receptionist, linguist, software tester and iteration manager.  One of the less enjoyable jobs I’ve had was working in a factory which made cardboard boxes.  I took it to make some quick cash one summer.  I was mostly working on the production line but occasionally would get rotated on to internal transport where you got to drive an electric trolley around. That part was quite fun.

There is nothing much to like about working on a production line.  The people who work on them are under no illusions about it.  But it is an honest job and somebody has to do it (until the robots take over anyway).

Years after that summer of stacking boxes, I got my first job in IT.  IT might as well be on a completely different planet from production line work.  It is high status, high tech, intellectually demanding and creative work with a high degree of personal autonomy that is conducted in temperature controlled environments.  On each of these dimensions it is diametrically opposed to the production line which requires minimal intellect, no creativity and, most challengingly, no personal autonomy.  On the production line, you are a cog in the machine. Plain and simple.  If the machine stops because of you, somebody comes over to find out why.  Time is money.

Beacuse of this extreme juxtaposition of the two industries, I was very surprised when kanban came onto the IT scene. A methodology taken from production lines designed to optimise inventory management.  How could that be relevant to the way we work in IT?  In IT we build complex systems.  The challenges we face in building those complex systems don’t bear much resemblance to what I remembered about working on the production line.  The use of kanban seemed to me a category error. 

It’s true that IT work can be modelled as a series of interrelated activities and represented by cards on a wall.  So can all other work.  That is why you now see kanban boards in HR departments and home kitchens and men’s sheds.  

Because there is some truth in the analogy, you can’t say that it’s “wrong” to apply kanban to IT.  But you can say that it’s invalid. 

A useful way to demonstrate a category error is to examine the assumptions underlying the analogy.  This is easy enough to do in this case because the claims that are made about kanban are well known.  They are broadly as follows:-

• Reduce waste
• Improve worker utilisation
• Increase flow
• Maximise value
• Improve communication

Let’s examine each of these in turn:-

Reduce Waste

On the production line, time is money. Save time, save money.  

IT, on the other hand, involves creative work. In creative work you cannot know in advance how long something will take. Sometimes you get lucky and find a solution quickly. Sometimes not.  There’s also feedback loops of various kinds.  What seems the right solution in the short term turns out to be the wrong solution long term.  New information often comes to light that changes your original assumptions.  What seemed like a perfectly good idea before is not such a good idea any more.  There’s often no way to know in advance what will turn out to be “waste”.  You can’t reduce waste if you can’t identify it.

Improve Worker Utilisation

Solving complex problems is not a linear exercise.  It requires creativity.  Creativity is correlated with procrostination, trial and error and sometimes “doing nothing”.  The subconscious mind is often the driver of creative thinking and it needs the conscious mind to shut up while it does its thing.  This is why the solutions to complex problems often pop into your head while you were doing someting else. The classic example is Archimedes having a bath.  How to structure our work to recognise and encourage the role of creativity is a whole other debate.  One thing’s for sure, keeping people busy (aka worker utilisation) is not conducive to creative thinking.

Increase Flow

Kanban was originally concerned with the flow of widgets around a factory.  When we talk about flow in IT, it’s the feeling of getting real traction on a problem and delivering the solution efficiently.   This kind of flow entails both having the solution to the user’s needs and having the right overall technical framework to deliver it.  This usually only happens later in a project when things have settled down after the early uncertainty exploring the problem space.  Flow is not something you could or should have all the time throughout an IT project.  Sometimes it’s better to be trying things out to see what works.  Sometimes you take a wrong turn and have to back track.  And sometimes you never get into the flow even though you do grind out a suitable outcome.  That’s the way it is with creative work.

Maximise Value

Value on a production line is simple thing.  The widget you are manufacturing has been around for a long time.  There is an established market and consumer base.  The bugs have been mostly ironed out.  The price is stable.  People know what your widget does and what it’s worth.  That’s as true of a cardboard box as it is of a new car.

In IT, many projects deliver no value at all because they are highly speculative.  The business model is not established. The user base hasn’t been found.  You still don’t really know what the product is.  It’s also possible to deliver negative value.  A product so poorly built that the users would rather not use it (but they have to because somebody at work signed a contract).  And there are some products in IT that, even though a lot of people value them, don’t make money. 

Defining and measuring (and maximsing) value is very hard to do in IT work. That uncertainty is as much on the business side as on the technical.  

Improve Communication

On one of the projects I have worked on that used kanban, the product manager asked if we could “set a theme for the week” of work.  The reason for this was because it wasn’t possible to look at the board and see a unified goal in the work being done.  New cards came and went.  Priorities seemed to change from one day to the next.  The product owner didn’t feel like they had an adequate grasp on when groups of features would be available.  Rather than improving communication in that case, kanban had reduced it.

 

I was fortunate that my first job in IT was in a company that was striving to do XP software development.  What surprised and impressed me the most was the focus on intelligence, creativity and learning.  There was the underlying assumption that, in the end, doing things right worked out quicker than doing things fast. 

The “business” of IT has traditionally had a different set of priorities.  There is the desire for more certainty, predictability and consistency.  The production line is still the gold standard for this.  I think that is why the introduction of kanban has been driven by the business of IT and not by the engineers.

This tension between the business and the engineers might simply be a perennial feature of IT.  It might be that the best we can do is to separate the priorities of the business and the engineering teams in the way prescribed by Scrum.  I’d much rather see an attempt at making the business agile.  Having everybody aligned around an understanding that the work we do is fundamentally complex and creative.  That the search for the business model requires just as much creativity as the search for the technical solution. But kanban is not a step in that direction.

Once upon a time I did a six month contract working on a new web development project at a large corporate.  There were about 25 people on the newly formed team – a very large team by modern standards.  As with any other “agile” team, we would walk the card wall each morning at standup.  There would be around 20 cards in the Doing column at any one time which caused standup to run for longer than was comfortable for either our feet or our attention spans.

It took just under 6 months to get to the first release of the software.  During that period the wall was always completely covered with cards. By the time we made it to production, hundreds of cards had moved across the wall.  

What did our team of 25 people deliver in that first release?  

A login screen with four hyperlinks.  That’s it.  Six months of work and hundreds of cards amounted to a user being able to sign up, login, and click one of four hyperlinks.  

If you were to capture the functionality we delivered on that project on traditional agile User Stories, you would need only three cards.  Card 1 – I want to sign up.  Card 2 – I want to log in.  Card 3 – I want to click on a hyperlink.  If you really wanted to pad it out you could have a separate User Story for each hyperlink.  

I like to imagine what it would have looked like for 25 people to stand around a card wall with just those three User Stories on it.  I like to imagine the CEO popping by for standup one morning and being presented with a wall which demonstrated the actual value that project was delivering.  I like to imagine the CEO mentally calculating the salary of the 25 people who were building a login screen which showed hyperlinks.  Instead, we had hundreds of cards on our wall and on each card was a Task.

Task cards have been a bugbear of mine for some time now and not just on obviously dysfunctional projects like the one I have described.   There are several reasons for this:- 

1. Clarity

As the above story demonstrates, task cards add noise to a wall.  There are always going to be many more task cards than user stories.  If you put each task on a card and each task card on the wall they will dominate the space, especially in the Done column.   Task cards make it more difficult to see what value has been delivered to the user.

2. Focus

Part of the original motivation of User Stories was to foreground the needs of the users.  The old waterfall documentation was full of technical jargon making it very hard to know what the real underlying needs were.  User Stories were a way to redress that.  Task cards reintroduce technical jargon to the card wall.  They bring the focus back to technical tasks, something the original agilists were trying to avoid. 

3.  Feature Factories

The desire for task cards seems to be closely correlated with the Feature Factory mindset.  Seeing lots of (task) cards go across a wall is a natural fit with a way of thinking which prioritises output over outcomes.  It is hard enough to focus on outcomes as it is.  By filling up the card wall and the team’s attention with tasks, we make it even harder.  We promote a culture of getting cards across the wall.

4. Visibility 

The primary reason given for task cards is that we want visibility of what other team members are doing.  This is a worthwhile goal.  However, we already have a forum for that.  It’s called standup.  Given that tasks are fleeting in nature, briefly discussing them at standup seems to be about the right amount of attention to give them.  Use standups to discuss tasks for the day and the card wall to represent when those tasks add up to real value delivered.  

5. Relevance

Modern agile teams often have several non-technical people who are also stakeholders in the card wall.  Task cards are not relevant to these people.  User Stories are.  Filling up the wall with task cards makes the wall less relevant for non-technical team members.

Task cards are not responsible for the ills in modern software development.  They are a symptom of those ills.  What most agile teams need these days is less focus on the technical aspects of delivery and more on verifying the business value of the software.  On a team that is co-located and has high levels of trust, visibility into the minutiae of development is not required.  And on teams which have good flow, the flow is of value to the users and not task cards to the Done column. 

P.S. Although I believe that task cards on a wall are not a good way to manage the work of an agile team, I am firmly in favour of tracking tasks as a way for individuals to manage their work.  I use task lists all the time to manage both my work and personal life and I highly recommend them. The Checklist Manifesto is a great read on that subject.