Category Archives: Lean

Agile, BDD/ATDD, Business Analysis, Lean

It starts with a story…

May 20, 2014 AntonyMarcano 5 Comments

If agility to you means maximising the opportunity of realising value early & often while rapidly adapting and responding to market feedback then user stories, applied effectively, can facilitate that. However, one common misunderstanding of user stories seems to hinder teams from achieving the benefits they hope for…

A user story is a “short descriptions of functionality–told from the perspective of a user–that are valuable to either a user of the software or the customer of the software”[1]. You may first encounter stories in this form:

As a microblogger,
I want to find out as soon as others mention me,
So that I can choose to respond while topics are current.

One common misunderstanding of user stories might result in the above example looking more like this…

As a microblogger,
I want a notifications screen showing my mentions,
So that I can find out as soon as others interact with me.

The problem here is thinking of user stories in terms of what the user will have, rather than what they’ll be able to do. This can cause avoidable dependencies that limit your flexibility, reduce your speed to market and limit your ability to change direction based on market feedback.

These dependencies can be dramatically reduced if our user stories steer the conversation towards what the user will be able to do. Let’s explore why…

What the user will have (features)…
Let’s imagine we envision a house (which will be made of lego in this exercise). What stories would you write for your lego house? Here are some of the typical stories people write:

As a cook,
I want a kitchen,
so that I can prepare food.
As a parent,
I want a master bedroom,
so that I can sleep comfortably with my partner.
As a car-owner,
I want a garage,
so that I can park my car off the street.

Have a think about what’s involved in delivering these stories with a lego house, building our final vision of the kitchen, the bedroom, the garage. If our vision is to have the master bedroom on the top floor, then we can’t have a place to sleep until we’ve built the ground floor. To build our garage ‘iteratively’ we will focus on building the walls first, then put the roof on. Essentially, the architecture drives the order of implementation, not what is of greatest value to us.

The problem here is that these stories are encouraging us to fixate on specific solutions to each problem. Ideally, we want the story to be about what the user will be able to do (i.e. sleep comfortably together), not what they’ll have (a bedroom).

In these examples, as is often the case, the problem we’re trying to solve is there, just in the ‘so that’ part. Getting everyone to share in an understanding of the problem(s) we want solved helps us prioritise based on business value…

What the user will be able to do (capabilities)…
Now, imagine if we had stories like this:

As a cook,
I want to prepare hot food for the family,
so that we can safely enjoy various fresh foods.
As a parent,
I want to sleep comfortably with my partner,
so that we can keep each other warm.
As a car-owner,
I want to park somewhere safe,
so that I can keep my insurance premiums low.

Have a think about the different ways we could initially solve these problems (from camping cookers, a mattress on the floor and a driveway to park the car). We can meet all of these needs rapidly without having to achieve the final vision but make it possible to layer on more and more refinement to each one evolving to the solution and enabling us to discover the solution we really need.

when what we want is “a thing” then what we are describing is not a user story – it is a feature.

Features (“I want a…”) vs. Capabilities (“I want to…”)

Relatively recently, while running my user stories course (with Lego) to delegates at a well known company, one delegate pointed out a difference between the ‘template’ for the two story styles above. They observed that in the case of stories that are really “Features” the format tended to be “I want a…” whereas for stories that were “Capabilities” the format tended to be “I want to…”. Some found ways around this by saying “I want to have a…”.

Interestingly, the original ‘Conextra Template‘ indeed followed “I want to…” and all of Mike Cohn’s examples in his book “User Stories Applied” are indeed capabilities (although sometimes in his explanations he does refer to stories as describing a feature, his examples are generally capabilities).

In short, when what we want is “a thing” then what we are describing is not a user story – it is a feature.

(This short section was added on: 22nd May 2015)

Flexibility & Adaptability…

Each of these stories may be broken down even further. Let’s look at the garage and all the needs a garage might meet

As a car-owner,
I want to park my car off the street,
so that I can reduce my insurance premiums
As a car-owner,
I want to shelter my car from the rain,
so that I don’t have to wash it as often.
As a car-owner,
I want to hide my car from onlookers,
so that opportunists don’t think of stealing or vandalising it.
As a car-owner,
I want to hinder thieves from driving my car away,
so that I get the lowest insurance premiums.
As a car-owner,
I want to securely store my tools near the car,
so that it’s easier to do basic maintenance.
…and so on.

Now think of the different ways we could meet those needs with our lego house?

Most of these stories are largely independent of each other and can be delivered in almost any order. This allows us to prioritise the stories based on value rather than the architecture of the final vision.

We’ll realise our first piece of value very quickly and continuously gain more and more value until eventually we’ll have a whole garage (if that’s what we really need). If this was something that makes us money, it would mean we’d be generating revenue sooner. Revenue would grow continuously as we continuously grow our product.

It also means we can change direction at any time, for example if we were to start getting feedback taking the garage more in the direction of a workshop with space for a car rather than just a simple garage.

In the real world
I recently helped a client interview people who had from three to five years “experience” with user stories. During the interview I pulled out some index cards and pens. I described a simple product (which was surprisingly similar to early incarnations of Twitter) and invited them to help us write some user stories for our backlog.

What each of them wrote was, essentially, a functional specification, split like use-cases into several cards, except using the above “As a… I want… So that…” template. They explained each story in terms of the screens in the user-journey such as Registration, Login, View Profile, Follow Other Users, Post a Status Update, View Status-Updates and so on. The real issue here isn’t in the name of the story, it’s in what the stories represented in their minds…

I asked them to help us prioritise them based on value. “Registration is most valuable because without it we can’t do anything else”–one interviewee explained. This means that it would not be possible to obtain any feedback about the main value proposition of the product until a number of user stories are complete. Each candidate explained the stories as dependent steps in a journey that, essentially, had to be built in the same sequence as the journey [4].

The main value proposition is sharing updates with people and seeing what others are saying. A simple screen-name (like in a chat room) will do initially. Registration and login are largely about hindering others from pretending to be me. Could there be simpler ways of achieving this at first?

Like I said, I’m not suggesting that any of the story titles that each candidate came up with are invalid, just that they thought of them in terms of the expected solution (what the user will have), not understanding the real problem (what valuable thing the user will be able to do).

In Closing…
With tractable mediums like lego or code (with the right engineering practices around it), we are able to evolve our product to meet each user-need in turn. This is facilitated by thinking of our user stories in terms of the outcome (e.g. shelter from the rain) rather than one possible output (e.g. a roof and four pillars). Ultimately, this way of thinking is one of the key upstream enablers to realising value early & often and brings more opportunity to rapidly adapt to feedback by dramatically reducing dependencies.
——————————-
Experience this for yourself: If you would like me to run this as a hands-on workshop with your team(s), let me know. We’ll explore how user stories work in practice, not only by writing the stories, but understanding the conversation and means of confirmation [3] that complete the practice of user-stories. I can also wrap this in a simulation of Scrum and/or Kanban so that teams can experience how user stories work in practice. I make it accessible to all team members using lego as a metaphor for software, demonstrating the principles described above. We then explore how to apply this to your products, writing some stories or reviewing and refining your existing stories to take what we learn into the real world.

Acknowledgements:
The Lego House exercise that I run has been created by combining my experience with a number of other exercises, including the “XP Lego Game” and Rachel Davies‘ Household Stories exercise.

Footnotes:

[1] “Advantages of User Stories for Requirements” by Mike Cohn (See also his book, “User Stories Applied”)
[2] Typical user story format: http://guide.agilealliance.org/guide/rolefeature.html
[3] There is a lot more to user stories than this three line statement. The simplest explanation is that this is just the ‘Card’ in the three C’s of User Stories: http://guide.agilealliance.org/guide/threecs.html
[4] A key characteristic of user stories is there are few dependencies, if any, between them and each is valuable. This is explained by the mnemonic INVEST: http://guide.agilealliance.org/guide/invest.html

Agile, Business, Lean, People, Project Management, Software Development

Slow is Smooth–Smooth is Fast

August 21, 2013 AntonyMarcano Leave a comment

A few years ago, to explain what goes wrong for many organisations that “go agile”, I wrote an article called “Putting the Kart before the Horse” [1].

Go-karting is where most of the current Formula One racing drivers first learned the basics of race-craft. Antony Marcano, a former kart racer himself, recounts a father-and-son racing experience that helps him explain what goes wrong for many organizations that adopt Scrum as their first attempt to “go agile.”

In this article I explained how novice drivers try to go as fast as possible rather than trying to master the racing line:

At the open practice session my son and I attended, novice drivers seemed to approach their first lap as if it really were as easy as experienced drivers make it look. They floored the throttle and flew down the straight only to crash—painfully and expensively—into the barrier at the first hairpin turn.

I went on to liken this to how many teams adopt agile…

Organizations starting their transition to agile methods with Scrum are much like the novice drivers trying to go fullthrottle before learning how to take the corners. Before being able to truly bend and change their software with speed and ease, they fly into short iterations and frequent incremental product delivery—crashing painfully into the barrier of hard-to-change software.

It was my son’s first experience in a go-kart. We started by driving slowly with him following me to learn the racing line. We gradually went faster and faster. Soon, we were the quickest drivers on the track.

Since then, he has gone on to advance further and further in his racing. Back then, we were in slow, 35mph go karts. This year he started racing for a team in race-tuned karts (see photo). The driver-coach in the team watched him driving on his first few attempts in his new high-performance machine (70+ mph, super-car acceleration). While he was reasonably quick, he wasn’t smooth.

Photo of Damani Marcano driving his 2013 Mach1 Kart for MLC Motorsport — Damani Marcano driving his 2013 Mach1 Kart for MLC Motorsport

His coach told him “slow down”. His coach said “whatever speed you can do while still driving on the ideal racing line is the speed you should be going”. My son went out again. Initially slower than he was before, his speed progressively built… we watched his lap-times improve dramatically.

Yet again, we relearned this lesson: slow is smooth–smooth is fast.

For some reason, I see teams who are novices in agile development make the same mistake, however, not always feeling like they have a choice. Kanban might make it easier to start from where you are and gradually improve but it’s ok if you’ve decided to start with Scrum. When starting with Scrum, start slow, focus on doing fewer things well first then progressively improve. On a course I gave recently, one of the attendees said “but how do you get management and marketing to back-off enough to allow us to slow down?”

My answer: avoid going faster than you can. But if you feel compelled to go faster, make it a business decision. Help them understand that there is a risk that whatever time you save now will cost you more in the future. Help them understand all the effort you’ll spend repairing the damage that going too fast will cause. Pretty soon you’ll be spending so much time fixing problems and struggling to adapt hard-to-change code that there will be little capacity left to add new features. Essentially, incurring a “Technical Debt” .

As a general rule, I always try to start something new, slow and steady. I only go as fast as I know I can while predictably and sustainably delivering. I’m mindful of business pressures but experience has shown me that by focusing on “making things right” we can deliver smoothly, build trust and progressively become faster.

—————–

[1] You can read the original article here: Putting the Kart before the Horse? – published in Better Software Magazine, 2009

My son’s story is continued here: http://damanimarcano.com

Is updated here: https://www.facebook.com/DKMRacing

And here: https://twitter.com/DKMRacing

And here (updated 03-02-2014)…

UPDATE [11-12-2013]: Damani Marcano finished his first ever season 3rd in the Hoddesdon Kart Club Championship Junior Rotax Formula at Rye House, the track that started Lewis Hamilton’s career. This achievement is significant since, as a novice license holder, Damani had to spend the first half of the season starting every heat from the back of the grid. Find out what happens next season by following his story on Twitter and/or Facebook. Who knows, by adding to his ‘likes’ / ‘followers’ you may become a part of his story by helping him become more attractive to a potential sponsor.

Agile, Lean

Making the right things vs. Making things right

August 17, 2013 AntonyMarcano Leave a comment

Recently, David Anderson wrote of how he disagrees with the idea of focusing more on ‘doing the right thing’ than ‘doing things right’.

…we’ve heard a number of leaders in the Agile community promoting the idea that you should focus on doing the right thing – discovering what customers really want and need – rather than focusing on building and deploying working software

David disagrees because…

“doing things right” creates the circumstances to enable deferred commitment. Deferred commitment enables better predictability and faster delivery and a virtuous cycle ensues. Deferred commitment forces hard selection decisions and creates a focus on how selection is done. Combined with the limited WIP of a kanban system, deferred commitment raises awareness of the scarce resource of engineering capability. This is turn focuses attention on how to best utilize that scarce resource by “doing the right thing.”

There is another reason why focusing on “doing things right” is a good idea. One of the very principles behind many agile/lean approaches is iteration, allowing us to make the wrong thing so we can see it is wrong and more rapidly figure out how to make it right. The ability to do that quickly in an easy to evolve product is a significant aspect of agile approaches. “Doing things right”, as David points out, is the path to making this rapid evolution viable.

One way this is relevant is when we give the customer what they say they want so that they can then see what they really need. The ability to iterate quickly and predictably, as David clarifies, builds trust and leads to getting the right thing faster.

So, I entirely agree with David, however, I would phrase it in a slightly different way. To me, there is a distinction between “doing things” and “making things”.

David is talking more about what I would describe as “making the right things” vs. “making things right”. I think of “doing” as a layer below this. Where “making things” is more what we do and “doing things” is more how we do it.

doing the right things -> doing things right -> making things right -> making the right things

For example, using TDD might be “doing the right thing” but maybe the practitioner isn’t very experienced in it and is not using many of the techniques that give them the most benefit for the effort they put in. While they might be effective, by “doing the right thing” (TDD in this case), they are not as efficient at it because they’re not yet “doing TDD right”.

So, if you ever hear me talk of “doing the right things” before “doing things right” then it’s because of this distinction in my mind between “doing” and “making”.

Start with “making things right” and you’ll get better at “making the right things”.

To improve at “making things right”…

Start with “doing the right things” and you’ll get better at “doing things right“.

—————————

Footnote :

Barry Boehm is the first thinker who I saw use the phrase…”Building the right thing” vs. “Building things right” in his 1981 book Software Engineering Economics. I use the term “making” because it’s a more general term that has fewer implications on “how” we create a product. This is partly because developing software products with agility doesn’t feel like “building” to me.

Agile, BDD/ATDD, Business Analysis, Lean, Software Development, Software Testing

Software Pottery

August 15, 2013 AntonyMarcano Leave a comment

“Building software” is a phrase I hear used time and again. Indeed, many do still think of software development as akin to construction. Modern (agile) software development doesn’t feel like that to me. There was a time, like the construction architect, when we had to increment and iterate on paper and in models. The cost of computing was too high to do such iteration inside the machine. The cost difference between making a small change in our understanding and reflecting that in the actual product was too great. The cost of change meant that we had to treat the creation of software like constructing buildings or bridges. But those times are, or should be, in the past.

To me, modern (agile) software development feels more like pottery. But, instead of ‘throwing clay’ we throw our consciousness, in the form of electrons flowing over silicon, onto a spinning wheel of user-story implementation cycles.

Picture of a pot being created and evolved on a pottery wheel. — Source: http://www.flickr.com/photos/kellinahandbasket/2183799236

We evolve our understanding of what our customer wants with each conversation. We reflect that understanding by evolving the product’s shape as we touch the outer surface with each new automated acceptance test (or example scenario). We evolve its structure as we touch the inner surface with each new unit test (or unit specification). We keep it supple as we moisten it with each refactoring. Our customer looks on, gives us feedback and we start the next revolution of the software development wheel. Never letting the product dry and harden; keeping it flexible, malleable, soft(ware).

There is nothing that feels like construction here. I never feel like I’m “building” something. Much more like I’m evolving my understanding, evolving the product, evolving my understanding again and so on.

For these reasons l am not comfortable with referring to this process as “building”. I’m also not comfortable calling it “throwing” (as in pottery).

I am very comfortable calling it “development”. I use the word “develop” in terms of its literal meaning:

“to bring into being or activity; generate; evolve.”
–dictionary.com

From the first thought of a new idea, through each conversation along the way, to each revolution of the software development wheel, I develop products.

I don’t “build”.

I create. I make. I shape. I evolve.

—————————
Footnote: I’m not aware of anyone drawing this analogy before. If you have heard or read someone explain it in this way before now, please let me know.

Agile, Lean, Project Management, Software Development, Software Testing

This is not a manifesto: Valuing Throughput over Utilisation

February 11, 2012 AntonyMarcano 2 Comments

In a previous article, This is not a manifesto, I expressed the values I hold as a software development team member. Today, I’m going to talk about the first of these values.

Before I do, I’d like to say what I mean by “software development team”. I mean a cross-discipline team with the combined skills to deliver a software product – product owner, user experience, business analysts, programmers, testers, dev-ops, etc.

A common problem

Many teams I encounter will, at least in the beginning, have team-members who specialise in a single role. Each team-member will rarely, if ever, step outside their job description [1]. This can cause a problem.

Many teams find themselves in a situation where some team members have little to do on the current stories. At this point, the team has some choices, they can focus the under-utilised people on:

Future user-stories, working on tasks most relevant to their job title
Another team, working on tasks most relevant to their job title (e.g. ‘matrix management’)
Current stories, taking on tasks that will take the story to completion sooner, even if it’s more relevant to someone else’s job title
Things that will make the more utilised people get through their work faster, today and in the future.

More often than not, I find teams taking option 1. I think that people choose this option because it feels like it should increase the throughput of the team – i.e. the amount of new features they can add to the product. In fact, it has the opposite effect.

Little’s law

Let’s consider a team that is working in time-boxes or ‘sprints’ (à la Scrum) and measures it’s throughput with ‘velocity’ (story-points per-sprint). Points are accrued as each user-story is completed – i.e. coded, tested and product-owner validated.

In this particular team, it is able to complete an average of 10 points per sprint. Let’s say this is due to a bottleneck in the process. This bottleneck might limit the amount of testing that can be completed during the sprint. This is illustrated in fig.1 where each ball is a story point.

Shows a system through which a series of balls are being processed. Each ball represents one story point. It also shows that there is spare capacity in the team.

Shows a system through which a series of balls are being processed. Each ball represents one story point. It also shows that the spare capacity in the team has been used up, even though it does nothing to increase throughput.

Little’s law [2] tells us that the amount of time it takes to complete an item of work (cycle-time) is:

Work in Progress (WIP)
Throughput

Which we can read as:

story points in progress
velocity

In this simplified example, WIP is 10 points and throughput is 10 points per sprint. The average cycle time of a story is therefore 10/10 = 1 sprint. Notice, however, there’s all that spare capacity.

Let’s say this spare capacity is developers. So, the team starts taking on more user-stories from the backlog – increasing the number of story points in progress to 20 points (fig.2).

Because the bottleneck remains, velocity remains the same – 10 points per sprint. The amount of flexibility that the team has, however, is now reduced because the average time required to get a story to completion has increased from 1 sprint to 20/10 = 2 sprints [3].

Often this will take the form of testers working a sprint behind the developers. Worse still, over 10 sprints, the team still only completes 100 story points (as they would have before) but is left with a lot of unfinished work. This ‘inventory’ of unfinished work carries overheads which can, ultimately, reduce the velocity of the team.

The impact of filling capacity in this way has yet another effect.

Latency effect

As the developers get through more stories, a queue of stories that are “ready for testing” will build up. Testers working through these will, at least, have questions for the developer(s) or even find some defects. The developer, having moved on from that story, is now deep into the code and context of another story. When the tester has questions, or finds defects, relating to a story that the developer had worked on, say a week ago, then the developer has to reload their understanding of this old code and context in order to answer any questions or fix any defects. This context-switching carries significant overheads [4].

The end result is that the effort required to complete a story increases due to the repeated context switching, therefore reducing velocity.

So, not only does filling the capacity with more work fail to increase throughput, it adds costly context-switching overheads – ultimately slowing everything down.

This phenomenon is not unique to teams using fixed-length time-boxes, such as sprints. Strictly following Kanban avoids this problem, but what I’ve seen is some teams creating a ‘ready for testing’ queue – so that developers can start work on the next story. This has the same latency effect and turns a process designed for continuous flow into a batch and queue process. But, I digress.

What to do with the spare capacity?

The simple answer is to look at the whole approach and determine what is slowing things down. In the example above, I’d be wondering what’s slowing the testing down. Many of the things that hinder testing can be addressed by changing how we do things ‘upstream’.

Are lots of defects being found, causing the testers to spend more time investigating and reproducing them? Can we get the testers involved earlier? Can any predictable tests be defined up front so that developers can make sure the code passes them before it even gets to the testers (e.g. Behaviour Driven Development)?

Are the testers manually regression testing every sprint? Could the developers help by automating more of that? Are the testers having to perform repetitive tasks to get to the part of the user-journey they’re actually testing? Can that be automated by the developers?

Is there anything else that is impacting them? Test data set-up and maintenance, product owner availability to answer questions? Anything else?

Addressing any of these issues is likely to speed up the testing process and increase throughput of the entire team as a result. One solution is to put these types of tasks onto the product backlog. This is fine but if we assign point values to them it can give a skewed view of velocity. Or rather, velocity is no longer a measure of throughput. You won’t be able to see if these types of tasks are actually improving things unless you are also measuring what proportion of the points are delivering new product capabilities.

The only good reason I can think of for story-pointing these throughput-enhancing tasks is if your focus is utilisation – i.e. maximising the number of story-points in progress. Personally, I care more about measuring and improving throughput. By doing so, we get the right utilisation for free and a faster, more capable team.

Up next: Valuing Effectiveness over Efficiency.

Footnotes:

[1] “Lessons Learned in Close Quarters Battle” Illustrates how stepping outside our job descriptions can move the team through each story more quickly by using special-forces room-clearing as an analogy.

[2] Little’s law (PDF) – the section “Evolution of Little’s Law in Operations Management” that references Hopp and Spearman’s observation about throughput (TH), work-in-progress (WIP) and cycle-time (CT) – i.e. TH=CT/WIP. And therefore we can say CT = WIP/TH.

[3] Little’s law also illustrates that if we reduce the work in progress to one quarter, then the cycle time for each story reduces to one quarter of a sprint. We’ll still get through 10 points per sprint, but stories will be completed more as a continuous stream throughout the sprint rather than all at the end.

[4] “The Multi-Tasking Myth” by Jeff Atwood, talks about multi-tasking across projects and pulls together several resources to illustrate the impact of multitasking at various levels. This applies when multi-tasking across stories.

Acknowledgements:

I’d like to say a special thank you to my fellow RiverGliders – Andy Palmer and James Martin – for the feedback that helped me refine this article.

Agile, Lean, People

This is not a manifesto

February 4, 2012 AntonyMarcano 4 Comments

Recently, I had cause to ponder the values I hold as a member of a software development team. Values that, alongside other values I hold, drive my choices and behaviours. They sit behind the things I do and how I do them. They underly my thinking when considering how we can improve as a team and as an individual contributing to that team – for example, during retrospectives. This is not a manifesto of what I will value. This is an articulation of the things I do value.

In what I do and how I seek to improve as a team member, I have found that I value:

Throughput over Utilisation
Effectiveness over Efficiency
Advancement over Speed
Quality over Quantity

While there is value in the items on the right, I care about the items on the left more.

Note, that I say I ‘care’ about the items on the left more. I actually do care. I know that I care about these things more because it actually annoys me if I’m being asked to focus on the items on the right (probably because I know that they will be at the expense of the items on the left). I also know because I actually have a positive feeling when I am being asked for the items on the left (probably because I know that, over time, we’ll get the items on the right for free).

So, what do I mean by these ‘buzzwords’. Stick around and I’ll tell you in a series of upcoming blogposts. Some of these apply in ways that go beyond the obvious.