Agile Nutshell Newsletter #13


Competing with Unicorns



Buy now

Hello all – long time no see! It has been several years since my last update. But that’s only because I have been hard at work on a book that I have wanted to write for over six years – Competing with Unicorns. And I am proud to say it is finally out.

This book is the conversation I have wanted to have with many of you, since leaving Spotify. It contains all the tips, tricks, management strategies, and cultural norms that enable companies like Spotify to out execute the competition. And this book contains a summary of how they do it.

Here is a summary of what the book covers.

Chapter 1: What’s Different About Startups

Spotify, Google, Amazon, and Facebook were once all startups. What they try very hard to do as they scale is keep that small startup culture. This goes way beyond free lunches and foosball tables. It gets to the heart of how they work and where they focus. In a nutshell they are constantly trying to out learn the competition.

Chapter 2: Give Purpose with Missions

Big tech Unicorns don’t give their teams projects. Instead they give them something much more powerful – missions. Mission let teams operate autonomously, create their own work, and think for themselves.

Chapter 3: Empower Though Squads

Instead of continuously forming and reforming teams, Unicorns keep teams together longer. These longer running teams they call Squads. And self empowered Squads leave traditional Agile teams in the dust.

Chapter 4: Scale with Tribes

The way Unicorns get big initiatives done isn’t by breaking down teams into silos, and never letting them speak with one another. They create small autonomous companies right inside the organization. These they call Tribes, and it’s these Tribes full of self-empowered trusted Squads that do amazing things.

Chapter 5: Align with Bets

Unicorns swarm problems in ways traditional companies could, but for organizational reasons can’t. By creating company wide bet lists, and sharing that throughout the company, everyone knows what they should be working on, and what the companies highest priority items are.

Chapter 6: Working At a Tech Lead Company

Unicorns trust their people way more than most. On rare occasions this can cause problems. But the upside in terms of speed and innovation is so huge, that they are willing to accept a few bad apples, in an effort to enable everyone else to be happier and go faster.

Chapter 7: Invest in Productivity

Unicorns make investment in infrastructure and services that enable their teams to learn and go faster. The speed of iteration is incredible. And anything that gets in the way is fixed or removed.

Chapter 8: Learning with Data

Unicorns leverage data in ways other companies are only learning now. This gives them a big advantage strategically in finding opportunities, but also in product delivery as they better discover what their customers really want.

Chapter 9: Reinforce Through Culture

Culture is so important to Unicorns, that they dedicate a good chunk of time to supporting it. Too important to leave to chance, they support and foster it countless big and small ways.

Who is this book for?

This book is for leaders, people who are in the trenches, and are responsible for setting up teams doing software project delivery.

I would really love every high-level executive out there to read it, because they are often the ones with the power to make these kinds of changes happen.

But experience has taught me however that change seldom comes from the top. Instead it is often led from the bottom. For that reason this book was really written for the people doing the work in the trenches. And this book shows them how to do it.

My hope is that more companies start working this way. It’s a heck-of-a-lot more fun. It delivers outstanding results. And it makes you want to come into work.

Anyways. Enjoy. If you are like me you are working from home. I look forward to getting back out there, and seeing you all again soon.

Till next, Jonathan Rasmusson

Calgary, Alberta, Canada

Where can I buy the book?


Pragmatic Programmers (cheaper for you / better for me)



The Way of the Web Tester

Leave a comment

Screen Shot 2016-09-15 at 5.45.37 AM.png

Hello everyone. A book I have been working on diligently for the last two years has finally hit the shelves. It’s called The Way of the Web Tester and it’s a book for anyone who wants to learn how to write automated tests for the web.

What’s in this book?

The book starts out by explaining what the three kinds of tests are that we typically see in web projects, along with some rules of them and guidance on where and when to use each.

We they spend a full two chapters at each level of something called the testing pyramid seeing how to add UI tests to legacy systems, how one can test web services, along with some rules of thumb around unit testing. That’s Part I.

Screen Shot 2016-09-15 at 6.25.50 AM.png

In Part II we build on the concepts outlined in the testing pyramid, but shift our focus to those skills specifically geared towards writing good tests.

First we look at some of the basics of programming, and show how by learning a few simple principles and practices we can dramatically increase the readability and maintainability of our automated tests.

We then look at some practices around test organization, and see how by simply grouping and organizing our tests in certain ways can make maintaining our tests so much easier.

And in the chapter on effective mocking, we look at some of the perils that come with this style of unit testing, and see how we can use mocks effectively while staying out of the swamp of mocking.

And we conclude with a section on the art of writing tests first. And see how beginning with the end in mind not only helps you test your systems, it can actually help you iterate on your design.

Who is this book for?

Screen Shot 2016-09-15 at 6.52.26 AM.png

If you are a tester who’s always wanted to get into test automation, this is the perfect book for taking that first step into a larger world.

If you are a developer, and you’d like to learn how to make your code even more robust, this book will show you how to move fast without breaking stuff.

And if you are team lead, looking better ways to get your testers and developers together, his is the Rosetta Stone you’ve been looking for.

Once your team has a common framework, language and understanding around automated testing, they will be able to better coordinate they’ll their efforts and write the best automated tests for your project.

So wait no further. Crush bugs. Move fast. And have fun. I hope you enjoy The Way of the Web Tester.

On sale now at all reputable book stores.


The Agile Mindset


Agile has been around for over a decade, a lot of people are doing it, and that’s great.

But I see a lot of organizations struggling. Not so much with the tools and practices. But mostly in the mind – the head.

Here are a list of thoughts and attitudes companies need to get if they are going to truly adopt Agile as a means of delivery.

The plan is going to change

Plan the work, work the plan. That’s the mantra traditional project management has been teaching PMs for years. Except that it doesn’t work. Companies that expect software projects to be straight lines. But they look a lot more like this:


and it’s this unwillingness to change the plan that kills them – Agile or not.

Everyones has a plan until they get punched in the face. – Mike Tyson

Software projects are a bit like getting in the ring with Mike Tyson. They punch you in the face. And if you can’t take a hit, or are so tightly boxed in a corner that you have no room to maneuver, you are going to get knocked out.

Adaptive planning enables Agile teams to roll with the punches, take advantage of opportunities when things don’t go their way, and avoid much of the drama and dysfunction traditionally seen on projects that refuse to adapt.

So get used to changing the plan.

You don’t have all the requirements

Accept it. You don’t.

You might think you’ve got them all. You may read books telling you to gather them all before you start. But you can’t. Why? Because like Kent Beck once said:

The act of delivering software, changes the requirements.

Which means no matter how hard you try, you’re not going to have them all before you start. And the ones you do have are going to change. Just accept it and plan accordingly.

There is no change control board

This concept is so foreign to Agile delivery I almost cringe in bringing it up.

On an Agile project the only person who decides whether a feature gets implemented is the customer. They don’t need to seek anyones permission or approval. It’s their money. They can spend however they like.

Agile sides with the customer. If the customer wants a change, they can have it. Agilists believe this leads to better decisions, better products, and puts the responsibility for deciding how to spend the money where it belongs – in the hands of the customer, not the PM.

The cost of change isn’t high

Traditional thinking is that the cost of change on projects is high. That’s why this picture is still printed and promoted in modern project management bodies of knowledge.


This used to be true in software. But not anymore.

With the advent of the personal computer, just-in-time compilers, and phones with more processing power than older mainframes, we can make changes to software at extremely low cost.

We’ve also gotten a lot smarter. We have software engineering practices today that allow us to make changes with confidence at speed. That changes the game.

Instead of fearing and resisting change, you are now free to embrace it. And use it to your customers advantage.

There are no predefined titles or roles

Roles blur on Agile projects.

I know you have narrow, clearly defined, titles, roles, and responsibilities. Agile teams don’t care about any of that. What they do care about is doing a good job and removing anything that gets in the way.

So don’t get discouraged when your developers want to test, your testers what to be involved upfront in the analysis, and your Project Managers what to contribute and program. You are going to have happier people, most engaged teams, if you don’t limit them with a formal title or narrowly defined role.


You are going to fail

There’s a price to pay for all this progressive, initiative, risk taking way of working. You are going to periodically fail. It happens.

You can’t build innovative software or create great products without periodically going over the edge. Good companies will forgive you. The bad ones won’t. The good news is you get to choose which you would rather work for.

They are not requirements

Let’s think about this word. Requirement. It rings of something completely necessary. Something we absolutely must have.

So if we can deliver 80% of the business value from 20% of the requirements, what are the the other 80%? They’re not requirements. We didn’t need them.

Drop the word requirements from your software project vocabulary. It’s the wrong word. Instead use features, and treat them as things your software project may or may not have. Not requirements.

They are estimates

You know what an estimate is right? It’s a guess.

Guess how long it would take you to roll ones with a pair of dice. How long would it take you to find a missing card in a deck of cards.

Guess. Try it out. And then compare your actuals to your estimates. Think you are going to be within 10%. Care to make a wager on that?

The way we size software projects isn’t all that different. We estimate, or guess.

Except instead of treating these estimates as guesses, we treat them as commitments (and that’s where we get into trouble).

Agile estimates aren’t commitments. They are best guesses based on limited knowledge.

We turn them into commitments the only way we know how. By building something, seeing how long that takes, and then extrapolating that for the rest of the project (it’s not rocket science, but it works).

Working software is the definition of success

For a lot of companies getting projects in on time and on budget is the overriding definition of success. And Agile would agree that projects have to work within their means.

But rather put so much attention on the plan (which by itself does nothing) Agile takes that time and energy and puts it back in the one thing that does add value – the software itself.

That may sound obvious, but we deliver a lot of projects that are on time, and on budget, but deliver no value. It’s gotta stop.

Chaos is the norm

In 2004 Doug Decarlo wrote an article I really liked contrasting the different mindsets between the traditional and extreme (Agile) project manager.

Newtonian – Stability is the norm Quantum – Chaos is the norm
The world is linear and predictable Uncertainty reigns
It is controllable Expect surprises
We can minimize change We should welcome change
Add rigor to the process to increase the feeling of security Relax controls to increase the feeling of security
Deliver on the planned result Deliver to the desired result
Use the plan to drive results Use results to drive the plan
Aim, air, fire Fire, then redirect the bullet
Keep tight control on the process Keep the process loose
Manage to the baseline Manage to what’s possible
Get it right the first time Get it right the last time

I think this hits it bang on. You either believe everything can be planned, controlled, and thought of ahead of time, or you don’t.

Agilists think Quantum. And their practices, management and expectation setting techniques reflect that.

Three simple truths

Once you accept these three simple truths, leading agile projects becomes a lot easier.

You don’t stress as much about schedules (we know we’re already late!) You stop trying to own problems that are outside your sphere of control. And you just accept that there is always going to be more to do than time and money allow.

You stop taking things personally.

And software is personal. You put a lot of yourself into a software project, and it’s easy to take feedback, criticism, and things like schedule pressure personally.

But accepting these simple truths frees you from all that. It allows you to see that which is clearly, and to not try and change something that can’t be changed.

OK. That’s it for now. I plan on referring back to this article in the future, but I wanted to get some stuff out there on paper, so when when helping companies get better at software delivery, I can direct them here for a conversation starter, and then get to work.

OK – let’s talk.

The book that changed the game


I miss XP. It hit me hard how much when I read Uncle Bobs Ode to Kent’s White Book.


Man those were good times. We were going to change the world. It was us against them. It was the tyranny of the traditional against the brash, naivety of the new. And It was the programmers who finally stood up and said “Enough!”.

And man did XP make waves.
Test first? Ridiculous.
Recipes cards for requirements? You gotta be kidding.
Simplest thing that could possibly work? Grow up.

It’s unfortunate that people don’t talk about XP like we used to. But it’s practices are alive and well practiced everyday by thousands around the world.

Let’s take a look at why this book has so influential, the impact it’s had on our industry, and why we still aren’t all using it today.


XP tipped testing on it’s head.
No longer an after thought, left till the end, XP made testing the center of the universe on software projects
You didn’t write code until you had a failing test on XP projects
You didn’t check code in until all the tests ran
The tests needed to be continuously passing – 100%
You weren’t done, until all of your customers tests passed
Customers wrote tests. Developers wrote tests. Everyone tested on an XP project.


XP challenged a lot of what we traditional thought was good (upfront) design.
Taking more of an options approach, XP recommended not adding complexity until you absolutely needed it (YAGNI).


This was XP’s way of pushing back against the over engineering going on in the late 90s. XP taught us to design continuously (not once) while introducing us to the importance of language, and the power of a good metaphor.

Requirements & Analysis

The story card was XPs greatest innovation.
Instead of trying to get everything written down and get everything right upfront, XP said jot the idea down on one of your mom’s recipe cards, and have a conversation later with your customer if it ever comes up.
You wouldn’t believe the howls of protest.
How this could possibly work!
Where’s the tracability?
Where are the requirements?
How are you going to fit all those requirements on that one little index card?


1000s of books had been written on how to manage and plan software projects. XP pretty much blew them all up.
XP trivialized what it took to plan software project.
It punted on the whole ‘plan the work, work the plan’ thing by telling the truth (we don’t know exactly when we are going to be done), and rejecting static plans. Instead it said, we are going build something, see how long that takes, and then feed that back into the plan. Then we’ll tell you how are date is looking. No wishful thinking or management by miracle here.

XP was the first to suggest that when you have too much to do, and not enough time, you should do less. Rocket science. I know.


You can see where all this is going.
XP disrupted just about every traditional role on the software project.
It showed how dysfunctional things in our industry really were.
And not everyone appreciated that.
XP’s problem was it’s lack of inclusiveness.
It was great if you were a programmer or a customer.
But it was terrible if you did anything else.
It threatened testers (developers were now writing the tests)
It threatened analysts (developers were now talking directly to customers)
And it especially threatened project managers (small groups of professionals don’t require much in the way of management).

For these reasons many attacked XP and the Agile movement. And that might have been it if it wasn’t for the emergence and soft sell of Scrum.

Scrum to the rescue

For all of XP’s divisiveness, Scrum was the exact opposite.
Scrum was for everyone.
Small, self organizing teams made up of multi-disciplinary people delivering software every 30 days. Sounds great.
Traditional testers could test
Analysts could analyze.
Everyone had a spot at the table and was a large part why so many flocked to it.

PM’s were perhaps the most happy. Not only where the back in change. They finally had a means to ‘control’ these Agile projects, while simultaneously gaining a new title themselves – Scrum Master.

This was of course maddening to XPers and felt like a huge step backwards. Not only did Scrum not bring anything new or innovative to the party (from the XPers point-of-view). It completely left the most important parts out – the software!

But despite all these things, Scrum was hugely successful in one area where XP failed. Scrum was Agile’s beach head in enterprises and organizations.

Scrum made it safe for people to talk Agile. I am also extremely grateful to Scrum for promoting the concept of the self organizing team – no titles or roles on projects.

Ripples for years to come

Some to the largest organizations in the world are applying XP at a mass scale. XP had a huge affect on how Google tests software. And, not sure if anyone has noticed, Kent spends a lot of time these days at Facebook. I don’t know what the arrangement is, but that place reeks of XP. And for anyone who wants to see world class engineering and problem solving on a global scale check out how Facebook releases software or how they do development and deployment (hint – there is no QA department).

But love it or hate it, it’s hard to deny how much this book has affected our industry. Apparently it’s now recommending reading for management gurus. While on the other hand I know many in our industry would be quite happy to see it quietly die.

XP matters. This book matters, and many of us wouldn’t be where we are today if it weren’t for Kent and Ward. That book took courage to write. Let us hope we can show the same courage and continue talking about it in the future.

For more information checkout:
My recommended reading list (XP Books near the top)
The original IEEE Paper
Good ol Wikipedia

The Automated Tester


Write. Code. Automate.

In the last couple of years I’ve seen a huge spike in demand for people who can write, code, and automate their own acceptance tests. I call these folks
automated testers. Not only do these people automate their own tests, they also do their own analysis and enjoy talking with customers.

In this talk I would like to explore the role of the automated tester, show how it is different than traditional Quality Assurance (QA), and share a few ideas on how to get there.

Software is eating the world

In his seminal article, Software Is Eating the world, Mark Andreesen makes a strong case for how software is taking over huge swathes of the modern economy and eating the world. Amazon. Apple. Google. Twitter. All these companies are building highly defensible, highly profitable businesses, with software at the heart of what they do.

This is great for the disruptors, but painful for the incumbents.

  • Amazon killed Barnes and Noble.
  • Netflix ended BlockBuster.
  • And AirBnb and Uber are redefining the meaning of hotel and taxi.

And it’s not just companies that are getting disrupted. It’s people.

With the rise of Agile, and the popularity of running projects with a more entrepreneurial startup spirit, traditional software development roles are being challenged. None more so than traditional QA.

Everyone is a tester

Today everyone is a tester.

  • Analysts test.
  • Developers test.
  • Designers test.
  • Customers tests.

Everyone tests. Quality is no longer the sole domain or responsibility of a single group or entity. It’s a team responsibility. And that’s a big change for the traditional tester. Everyone is in their house.


This wouldn’t be a big deal if testers could show up on a project, be given a well written spec, and then be left alone to create comprehensive test plans to be executed every time someone changed the software. But those days are gone.

That role doesn’t exist anymore.

So if analysts are testing. And developers are testing. What’s traditional QA doing?

Leveling Up

I see two options. Traditional QA can dig in, defend their turf, and fight for the mantle of sole custodians of quality (in other words try to keep the status quo). Or they can branch out and get into analysis and development they way BAs and dev’s have gotten into testing.


To do this, the trick is to stop viewing analysis, development as testing as siloed roles. These are things that need to be done. Who does them doesn’t really matter.

I know many testers who are wonderful analysts. They bring an attention to detail and outside the box way of thinking that’s invaluable in flushing out requirements and necessary for doing thorough analysis.

I also know testers who are great at automating their own test cases. I don’t mean simple click and record playback bloat ware. I mean actually getting into code, using open source frameworks like Watir, Selenium, Cucumber, and RSpec.

By expanding their skills and getting into these other areas testers can quickly become doubly valuable on projects. Not only can do their own analysis and write great acceptance tests. They can code them up, verify things work, and reduce their reliance on developers for automation.

Shorter queues. Fewer handoffs. Less waste. More value.

Don’t let yourself be limited by yesterday’s job definitions.

Enter The Automated Tester


This is where the automated tester comes in. These are testing experts with a passion for business and a thirst for automation.

They like knowing the business because it helps them write better test cases. And the more they automate, the more time they have for edges cases and exploratory testing.

They also like technology because a good understanding of the tech gives them insight the limits and capabilities of their testing frameworks.

The experienced ones know they can’t (and shouldn’t) automate everything. Every test has a cost and they think carefully about what to automated. They also work closely with developers to to see what unit tests the developers have written and make sure they aren’t duplicating effort.

And of course they still love exploratory testing. Automation is fine. But it’s not perfect. To truly be effective you still can’t beat the intuition and creativity that comes from firing up the browser, clicking through the app, and looking for ways to bust things along the way.

Getting there

Now if all this sounds easy – I assure you it isn’t. This is a tough, demanding role. You’ve got know the business. You’ve got to have a passion for automation and technology. And you have to enjoy continuously learning and retraining yourself.

But it’s a huge opportunity. It’s an invaluable role and one I think we are going to start seeing a lot more demand for in the near future.

Here are some ideas on how to get there.

1. Build apps.

You don’t have to be a developer. The goal is to get just deep enough to understand at a high-level how things work.

If you are testing web apps, you should know how HTML/CSS and JavaScript work. If you are building iPhone applications, you should have XCode and be really familiar with the emulator.

Did you know, that if you build a simple app holding a table with some numbers from a database, you’ve basically replicated 99% of the business applications being built today!

Building simple apps and understanding the technology is going to give you insight. Insight into how these testing frameworks works, their limitations, and where they need to be abandoned.

2. Master one testing automation framework.

There are a lot of automated tested frameworks to choose from. Don’t sweat it. Just pick one. Learn it really well. Then move onto another.

They all work pretty much the same, and once you’ve got one figured out they all work pretty much the same.

If you are testing the web, start with Selenium. Then try Watir, RSpec, Cucumber, or whatever else your team likes. If you are on the iPhone try Frank. The framework doesn’t really matter. Just pick one and go.

3. Hug a developer.

A good developer can be your best friend. The good ones are already doing what you getting into and the best will be more than happy to show you how it all works. They can set you up, help get you going, and even augment the frameworks you are using by making them easier to use.

Study what they do. Learn how they set things up. And soon you will be able to do it on your own.

4. Automate everything.

I know I just said the good tester don’t automate everything before their eyes, but in the beginning you should try, just to get the practice and see what’s possible.

You are going to write a lot of bad tests when you first start out. Don’t worry about it – we all do. Just automated everything you can, and you’ll soon start to get a feel for which tests add value, which ones don’t, and where to draw that line.

5. Fear nothing.

It’s going to be scary when you start (I am talking to you traditional QA testers). You are going to be leaving a space of traditional, comfort, strength, and responsibility, and entering something completely foreign and new. I’ll let you in on a little secret. It’s like this for everybody.

Developers go through this every time they learn a new language. BA’s go through it when learning a new business domain. And PMs go through it when they drop the Gantt chart in favor of the burndown.

You have nothing to fear. Everyone is going through it. Just be humble. Ask for help when you need it. And you will fit right in.

One challenge


One challenge of becoming an automated tester is people are going to look at you a little bit funny. Companies don’t like things that don’t fall neatly into slots, and you are going to be an anomaly.

You are going to go to conferences, explain what you do to people and they are going ask:

So are you a analyst, tester, or developer?

Conferences, papers, titles, pay scales, expectations, and bodies of knowledge are not going to be ready for you. Nobody is expecting you to work like this. We’ve got 50 years of history working against us. But it’s like that for the pioneers.

All I can say is hang in there. Do whatever feels right. Start slow. Start fast. Look for the opportunity and seize it when it comes.

In the meantime practice, be prepared, and keep taking on more responsibility. Once you demonstrate the value this role brings (through action – not words) project managers will soon be getting into fist fights for your services, and you’ll have the freedom to contribute however you wish.

Remember the goal isn’t to test or even build great software. It’s to build something wonderful for our customers. And you are just doing whatever it takes to make that happen.


There’s a new role for testers out there. One that blends the art of traditional testing, with analysis, development, and automation.

If you have a passion for testing, are curious about technology, and are looking for more ways to contribute to your project, consider becoming an automated tester. It’s an exciting role, one that every Agile project needs, and one I hope we see a lot more people entering in the near future.

Create the Movie Poster First

Leave a comment

Instead of creating the script and video first, like I normally do when creating a new video, this time I started with the title screen and short description.


iteration mechanics


Iteration mechanics are how Agile teams get things done on projects. In this episode I show you how they work, what three activities are essential, and how to make sure you and your team are setup for success before they begin.

Creating the poster first did a couple of things:

  1. It got me thinking about you the customer.
  2. I had to think about what you might find iteresting
  3. I had to think about why you would want to watch

I am not a great marketer. But this hack of Steven Covey’s begin with the end in mind helps me get into the customers head and think a little bit more about what’s in this for them.

Here is the video. You can see the others here.

Show Notes

iteration mechanics

iteration mechanics

iteration mechanics

iteration mechanics

iteration mechanics

iteration mechanics

iteration mechanics

iteration mechanics

iteration mechanics

iteration mechanics

iteration mechanics

iteration mechanics

iteration mechanics

New Agile Planning Video


Just released a new Agile In a Nutshell Planning video. You can see it and the other Agile In a Nutshell videos (like user stories and estimation) here.

Here are some slides from the deck.

Agile Planning

agile planning

agile planning master story list, velocity, iterations

agile planning

what kills most software projects

agile planning step 1

agile planning step 2

agile planning step 3

agile planning step 4

velocity will vary

agile planning pick some dates

deliver by date

deliver by feature set

Self-Inflicted Scope Creep


Self-inflicted scope creep happens when a team increases the scope of their project without their customers actually asking for anything new. It’s painful to watch because it can mess up your plan, create fear and anxiety, and undermine the trust you’ve worked hard to gain with your client.

In this article I’ll show what self-inflicted scope creep looks like, and what you can do to stop it from happening on your project.

The Incomplete Story

When a team takes a story to work on during an iteration, the intent is that they’ll finish it. That’s why we like our stories to be small (something that can be done in a couple of days).

Sometimes, however, a story is bigger or more complex than we think. And despite our best efforts, we aren’t able to finish it during an iteration.

Not finishing a story once in a while isn’t a big deal. It happens. Where things can go awry is how we handle it.

One team I coached (that was of course under a lot of pressure) got into the habit of taking unfinished stories and splitting them into new stories at the end of an iteration.

They would break the old story (5 points) and break it into two parts. One part they would claim as done (say 3 points). The other part they would say was not done (say 4 points).

So now they have two stories (7 points) instead of one (5 points).

On its own, this isn’t that big a deal. What’s 2 points?

But if you keep doing this long enough something strange starts to happen. The team noticed that their burn down chart started to look something like this:

This is what I call self-inflicted scope creep. It’s not real scope creep, as there is no new work. But it’s malicious because it creates confusion in planning and leads to uncomfortable conversations with your client.

Agile planning works when stories are sized relative to one another. The fact that as humans we are pretty good at sizing things relative to each other is powerful. So long as we size things relatively and track how fast we are going, we’re in good shape.

But if we keep taking stories and slowly increasing their individual sizes over time it messes things up. When our stories stop being sized relative to one another we lose the ability to predict when we are going to be done.

Let’s now take a look at how we should handle unfinished stories, and how to treat new ones we discover along the way.

Don’t Count It Till It’s Done

New stories are easy. If you discover a new story, simply write it down and move on. Esimate it and prioritize it like the others but don’t sweat it. We knew we’d discover new stories along the way so it’s no big deal.

Unfinished stories, however, are different.

The first rule of thumb is to simply carry the unfinished story over. Agile is pretty binary about stories being done—either it’s done or it’s not. There is no 90% done.

So it’s usually simplest to just leave the estimate the same and carry it over to the next iteration (and for every story that’s a few points over there are always a few under so it all comes out in the wash).

If your story is a lot bigger than you originally thought, just re-size it relative to the others.

If your story truly is epic, you can also split it. But this should be the exception rather than the rule. We are trying to get working software out the door after all, and if you find yourself continuously splitting stories, they may be a little bit big to begin with.

But usually the best thing you can do is simply carry it over. It keeps things simple, accurately reflects how long things are taking, and it’s telling you something. If it’s taking this long to do this story it’s probably going to take that long to do others similarly sized—which is what we want.

The Flip Side

Now not all scope creep is bad. In fact it can be very good—nowhere more so than if you are in a startup.

Sometimes you build the wrong thing. It’s not what your customer wants and to continue down the original path you set out is crazy. The startup community recently started calling this a “pivot,” and it happens all the time. (Did you know Flickr started out as an online game? People didn’t really like the game but they discovered that their players sure liked sharing photos.)

This doesn’t happen as much with corporate project work but it still happens. Your customers are going to change their minds, and you are going to have ideas for how they could improve their product. It’s your duty to share that with them (new scope be damned) and quite frankly most enterprises could use a dose of startup, so do share your new ideas.

So as my friend Andy Hunt says, context matters, and yes some self-inflicted scope creep can be good. But the kind I am focusing on here is related to messing up your planning and estimates, and a simple reminder for how to handled unfinished stories at the end of an iteration (don’t count them).

Keep It Simple

Agile planning isn’t rocket science. At the end of the day how you manage expectations on your project is totally up to you. Everyone has their own style, and it’s more art than science. So if you feel compelled to create a new story to manage expectations in a certain way, it’s not a big deal.

The point of this article was just to make you aware of a trap that new teams (and old) sometimes fall into.

If you are new to agile, my advice is to start simple and do it by the book—simply carry unfinished stories over to the next iteration and call them done when they’re done.

If you’ve been doing agile for a while, have built some rapport with your customer, and have earned their trust, you’ll have a lot more leeway in how you track and report progress. Eventually, you won’t need estimates at all and they will just trust you to get the work done.

Speaking at Agile 2011

Leave a comment

agile 2011

I’ll be giving two talks this year at Agile 2011 in Salt Lake City Aug 8-12.

Agile In a Nutshell
The surprising science behind agile leadership

Agile in a nutshell is an intro for people who have heard the hype and are looking for a clear simple explanation of what agile is and how it works. Perfect for those looking to make the transition from traditional waterfall.

The surprising science behind agile leadership explains how self directed teams work, the science behind why so many choose to work this way, and the impact it’s going to have on you and your organization.

And if you are going, I would love meet. Here are a few sessions I plan on attending:

Coaching Success: Getting People to Take Responsibility & Demonstrate Ownership: Christopher Avery, Ashley Johnson

What do CIO’s *really* think of agile?: Edward Yourdon

Critical Success Factors for Acceptance Test Driven Dev’t: Jennitta Andrea

Design Thinking: Mary Poppendieck

How to design stuff that matters fast: Eewei Chen

Hope to see you there!

The rise of the generalist


People love labels. As soon as you meet someone they instantly want to classify you. Web designer? Gen-Y? Level 50 Shaman? Shffft – you’re labeled.

Same thing happens on software projects. Whenever we form teams we naturally want to know the role each of us is going to play: Developer? Analyst? Tester? PM? Bam – you’re labeled.

Labels are fine, but they can stop you from thinking. ‘It’s not my job’ to worry about how the application works, or that there’s a bug with the print screen. QA or someone else on the team will pick that up.

When you think you are defined by a role or a title you are.

But we all know the most valuable members on our teams are usually those who can where multiple hats.

It’s the developer who has a passion for testing.
The tester who can code.
The analyst who thinks about design.
And the designer who has a passion for the business.

As agile gets more mainstream, I think we are going to see more and more of this style of work.

The rise of the generalist.

Where no single team member is limited by a role or title. Multiple people simultaneously where multiple hats. Much like a startup.

Dan Pink sums it up best in Drive: The Surprising Truth Behind what motivates us.

If we are truly going to empower our people, and let them do whatever it takes, then we better get out of their way and support them in playing whatever role(s) they need to play.

So don’t let a title or role stop you from serving your customer. Use whatever innate skill and ability you’ve got.

And if this subject of how agile teams work is of interest to you, come see me speak at Agile 2011 in Salt Lake city where I will be presenting a talk titled The Surprising Science Behind Agile Leadership and what really motivates us.

Older Entries

%d bloggers like this: