Ready-to-Sprint!

Introduction

In the past we treated Stories mostly like a rough idea with more details to follow as needed. Scrum states that you do not waste time on unnecessary detail and documentation. So this handling fits right? Wrong. A lot of people understand the lowered volume of documentation in Scrum as “do no documentation at all”.

The difference is on the emphasis on “unnecessary”. This means leave out anything that you do not need or will not need in the immediate future – but still do EVERYTHING else.

For Stories this means you need to look at your stories regularly to find out what they are in and if they are ready to be tackled in a sprint. If do not track this status closely you might end up with a lot of rough ideas that lack refinement or details at the time they should be put into a sprint. In the worst case you look at your backlog and marvel at all these stories and elements in there – without knowing that most of them are missing crucial refinement.

The end result is that you will spend a lot of time in your planning meetings trying to salvage the situation or –even worse – do not spend the time and have the team work on unclear requirements and scenarios. To get around this issue my teams and I developed a story lifecycle called “Story Maturity”. This lifecycle tracks the story from inception to sprint-readiness and sets ground rules for each step.

Story Maturity

So how does this work? First of all we acknowledge that stories are living documents that evolve from a raw state into an actionable item. However this does not occur automatically – a story does not ripen like good wine – it requires effort. Some stories will be a no-brainer and easy to refine some others require more attention – but either way you and your team will have to spend the time on getting them in shape for the sprint – BEFORE the actual planning meeting starts!

Story Maturity follows a set of status values and rules for their handling which are outlined below:

Initial

The story has just been discovered. It lacks necessary detail and may just be a snipped that you wanted to put in not to forget it. Stories in the initial state always go into a special backlog. This may be the overall backlog or a “fountain of ideas” backlog where new stories gather. Do NOT put them into Release Backlogs or Sprints or you might otherwise end up with a lot of clutter that needs to be weeded out.

Stub

This story has received some work but is still missing crucial information. For example the actual story is missing (“As a ….  I want to….”) or the Acceptance Criteria were not filled out. The Story remains right where it is and will have to be worked on – usually by either the Product Owner or the discoverer of the story idea.

Unclear

This story has the necessary filling but something is still unclear. Perhaps the requirements are not properly measurable, perhaps the goal is not clear. This state is usually set if during planning a lot of questions or conflicting views were raised. You put this story under close watch and get the responsible people together to make it more precise. The story remains in that state until the responsible people have agreed that the story is clear enough to be estimated.

Estimation-Ready

The story is clear enough to run through a quick estimation. This means it has the actual story, description and acceptance criteria filled and can easily be understood by all team members. A story in this state can be PROMOTED by the Product Owner (and ONLY the Product Owner) to move from the “Fountain of Ideas” into a regular Release Backlog. The creator of this story should either pitch the story before the sprint planning meeting or do an impromptu elevator pitch of no more than 60 seconds to get a story promoted.

 The next step is to do a short poker session of about TWO MINUTES. Yes, two minutes. No longer. Do a quick poker session and if you have estimates that are very close together (no more than one step apart, like 5,5,8,8) you either take the majority or the higher number. If you see a discussion breaking out or if the estimates are wildly distributed the story many not be as clear as it should.
The team should then decide if they want to spend the time now to make discuss the story or if it has to be put to “Unclear” and will not be part of the sprint being planned.

Depending on the situation a team might immediately continue with the Pre-Estimated step if the story is likely to be tackled in the current sprint. If it goes back to the backlog this is where you can stop and move on to the next item.

Pre-Estimated

This state means that the story has passed through a pre-estimation session with all the requirements for it. The story is usually in very good shape and can be plucked from the backlog. To get it “Sprint-Ready” the team has to do two simple tasks:

  • Check if the story is still applicable and clear in its current state
  • Do a final poker session

If both of the above tasks are completed the story can now be set to “Sprint-Ready” and put into the backlog of the upcoming sprint.

Sprint-Ready

This story is good-to-go!  🙂

Story Promotion

The Product Owner is accountable for both a project’s success and failure. He or she should therefore be the only person that can have a final say on what gets in a release and what does not. Therefore newly discovered stories do not just waltz into the release or sprint backlog – they have to be pitched to the Product Owner.

The Product Owner should regularly look into the separate “Fountain of ideas” backlog and be open to people trying to pitch their stories. However at the end of the day the Product Owner has the final say on the contents of the release backlog.

That way you can ensure harnessing the full creative force of your team and stakeholders while not diluting your backlogs with unrefined ideas.

Benefits

What this story lifecycle called “Story Maturity” gets you is transparency on the work necessary before a story can be tackled and a clear indicator if you can dare put it into the next sprint or not. By following these indicators closely and being very honest while doing so you can cut down the time necessary to spend in the planning meetings.

We went from three days planning to less than three hours following that lifecycle.

The Bottom Line

By acknowledging that User Stories are a living document that evolves with the right amount of effort you can create a meaningful easy-to-use backlog that will show you exactly what is ready to be tackled and what needs additional work. You also reduce the time spend in planning meetings feverishly trying to cobble together work items.

In the end your team will spend a lot less time sitting in meetings and a lot more time doing what they love: Creating meaningful software.

Why Traditional Prioritization is Evil

Have you ever had a conversation like this:

These are your five top priority items.“
– „Which one is the most important one?“
All of them.”

Or something like this:

We have to set the priority to High – all Medium or Low items will most likely not make it anyway.”
If so you’ve likely been in Priority Hell.

Priority Hell is a place where every single item is of utmost importance, where there is no clear distinction between all the “High Prio” items, where Priorities like “Very High” or “Urgent” have reared their ugly heads. Priority Hell is also a place where everything is being worked upon but nothing gets beyond “Almost done”.
Priority Hell is a scary place.

The Root of All Evil

You might ask yourself why I cast priority in such a bad light even though it is supposed to give us guidance on how to proceed where to concentrate our efforts. And you are right that priority in general terms is GOOD. Focus is also good. But avoid flailing around aimlessly in hopes of tackling the right things first. What’s bad is the way priority is implemented and used in most of the current work processes.

For the sake of this post I’ll concentrate on the implementation of priority in Rational Team Concert – acknowledging that it is used as the main choice in project tracking and collaboration inside SWG and a lot of teams already use it. However all of the critique can be applied to other tools such as MS Project or even Excel.

Now let’s look at how priority is implemented:

You usually have three options: Low, Medium and High.
Since you can assign the category freely what becomes High or Low is entirely up to you. Sound good so far? Read on.

Opportunity Cost

What prevents you from setting everything to high? Nothing – and over time there will be a lot more things on High priority that you would imagine. The reason for this – in my opinion – is that the freedom to assign everything to high alleviates the need to make a hard choice and to weigh elements against each other. Economists refer to this as opportunity cost, meaning the lost value of the option you discarded. And make no mistake – by having to choose between two elements in terms of priority makes you take into account the risk that the lower-prioritized element will maybe not make it. It’s a lot easier to just assign both to “High” priority and assume you do not have to make a choice.

Assume that you have your list of elements and got about six elements with “High” priority – which one is the most important one? Which is the second-most important?
“All of them are important, silly!” you shout in anger – but what will that get you? Your team will start on all of them in parallel either rigorously multitasking or splitting the resources across the different elements.
Following the stream of recent publications one can assume that multitasking is one of the biggest efficiency killers of the modern work era – that’s why for example Scrum dictates that no changes to the team or plan are made within the sprint and that team members are assigned to a single team only. The same with splitting resources – assuming that your workforce is not large enough to create six separate teams to work on these items you will most likely starve certain items from manpower and knowledge.

Both factors cause work to progress slower and less efficient ultimately leading to the situation where everything is “almost” or “80-90%” done but nothing is really finished!

If you are working with a small team of about four to nine people (managers excluded) it is absolutely necessary to avoid starting multiple tasks at the same time – otherwise your resources will be spread too thin. Scrum for example suggests that instead of fanning out the ENTIRE team will tackle the top priority story from the backlog before moving on to the next one.

A Question of Leadership

For that you will need a clear distinction of priorities. A ranking has to be established that also addresses the order of items within a priority.

This ranking is a mixture of both the technical need of the item and the overall business need in terms of the project.

This integration is a leadership objective that needs to be covered by the Product Owner to be successful. On most teams the Product Owner has detailled business knowledge but only limited technical insight. For a knowledge worker this is just the other way round: She understands an item on the technical level but may lack the business knowledge. Only by integrating both the business need (following customer value, strategic alignment, etc) and the technical need (architecture requirements, technical constraints, etc.) can a reasonable piority be established.

It ultimately boils down to the team, with the Product Owner in a leadership role, to steer the project to deliver the right value at the right time and not build an imaginary ivory tower.
This steering towards delivering value is what relative prioritzation can deliver.

Relative Prioritization

A team following a ranked list of elements can focus efforts on achieving the highest, unfinished element on the list before moving on. This ensures past work is actually completed before opening the next can of worms. Also you are directly following customer (or Product Owner if you will) value – achieving the most critical elements first.

Ranking – in Three Easy Steps

Okay – “Easy” might stretch the truth a little. Doing the changes is easy living them might be more challenging.

Step 1: Get rid of traditional priorities

This first step forces you to let go of traditional priorities as it effectively blocks access to and knowledge of it.

Step 2: Use the “Ranked List” view for all planning and sprints

Then set the “Ranked List” to be used as the default view so you have a clear picture of the project priorities at all times.

Step 3: Work with ranking for prioritization only

The last step is to step up on the discipline side by only addressing the top element on the list and only that.

If the element is too small – think about bundling work differently so your entire team can work at least a day on a single story.
If some people cannot contribute to an element find out why. The most common reason is lack of skill in a particular area. If so actually take this as an opportunity to do skill transfers using techniques like Pair Programming.
If the element concentrates on a single area of work but will later be integrated with other components find out how you can do a little slice of integration now. Agile & Scrum prefer doing a “vertical slice” or “End-To-End” approach by creating a sliver of integrated functionality on all layers of the project instead of big, separated chunks.

Apart from the tackling of work you will also focus on ranking new elements as they come it. If you let them rot at the end of the list – chances are they will not be picked up in time if your team follows the “Top element first” procedure diligently. By doing ranking close to the item’s creation you are also working on a fresh memory what this item was all about – thus reducing the time to remember or fetch information later.

Both parts of Step 3 will not only ensure completion of elements in the correct order it will also surface issues you might have with team skills, work package size and alignment with the “end-to-end” approach.

The Bottom Line

Traditional prioritization in the broad “High”, “Medium” and “Low” categories leads to ambiguous item priorities. Which one of the “High” priority items should be addressed first? Should all of them be addressed at the same time? Also the addition of new requirements and work items can bloat a category severely leading to the “Everything is High” syndrome.

The result is too many open work items, everything “almost done” but nothing really finished and a lot of time and resources lost on multitasking.

A way out of this situation is to do away with the traditional prioritization categories altogether and adopt ranking.
Ranking ensures that a clear and unambiguous order of work is established, items are prioritized in relation to each other and the team as the ability to focus all efforts on finishing the most important work item first before moving on to the next one.

Scrumerfall (or: You’re Problably Still in Waterfall)

The transition from classical project management and development to Agile & Scrum can be quite drastic, turning the way work is done on it’s head (TDD) or even doing away with some things altogether (long isolated phases).

A lot of teams struggle through the transition – especially while working with legacy code that did not see the light of day on the green fields of Agile development but was created under the unyielding whip of crunch time.

Leaving all that – and the accumulated habits –  behind is difficult.

It’s therefore all the more compelling to map existing structures and workflows and plug them into the “new way of doing things” – and then call it “Agile”.

During every single Scrum training I received over the last years the trainers always issued a stern warning to be vigilant for signs that you are not really Agile but just pretending to be.

This creates (at least) two problems:
– You are not reaping the benefits of doing Agile & Scrum
– You are stuck with the issues of your old processes & habits

The first step to address both is to realize if you are deviating from the Agile path and then carefully plot your way back.

This blog post is based on my own experiences and understanding of the Agile & Scrum processes and intended to give you a few pointers and suggestions.
It’s not an attempt to declare what is “the right way to do it” – that is ultimately left for each team to decide on it’s own.

Without much further ado – let’s get started!

1. Stabilization / Hardening Sprints

Have you ever added Sprints at the end (or in regular intervals) where code changes are reduced to a minimum and all efforts are focused towards ironing out the bugs & integration issues?
If so you have probably created something like a Stabilization Sprint.

This kind of Sprint is more-or-less a direct equivalent of the Waterfall end phase where all QA testing and bug fixing is applied to the project. It’s where all the big integrations happen.
It’s also the time where things (latest) go south. Issues crop up like crazy, the integration fails and a storm front of crunch time is headed straight for you.

When following the concept of Scrum that only code that is covered by exhaustive, automated tests and accepted by the Product Owner is allowed into the release code how can that happen?

Well in theory it should never happen. And here’s where theory ends.

Stabilization Sprints and integration issues are a sign that automated, isolated quality control (TDD, Continuous Integration) is lacking.
This is an issue most often found with legacy code that wasn’t written to be properly tested. It could also hint at a team relying a lot on manual tests.

Either way you are highly vulnerable to unexpected stability issues and late-game deal-breakers.

To address this issue is to ensure high unit test coverage, deploying a fully automated CI system and doing a full test/integration cycle daily if not more often.
Some teams automatically integrate & test code every 15 minutes.

If you already have all that implemented find out what is causing the need to spend two or more weeks on hunkering down and squashing the bugs & quality issues.
Because you should be release-ready at the end of each sprint.

2. Sprint Zero

Have you ever added a Sprints with the number zero to your planning? Or even multiple ones (Sprint 0.1, Sprint 0.2)?

This kind of Sprint usually comes up when a project is something requiring a lot of upfront research and preparation. It includes clarifying the requirements, researching on technologies, setting up the development environment and so on.
Sprint 0 is an equivalent of the Plan/Design phases of Waterfall.

Now here’s where it gets controversial:
I think that spending time on research and preparation is time well-spent and it seems, depending on who you ask, the Scrum world is undecided if Sprint 0 is okay or not.
However let’s think about what Sprint 0 actually symbolizes: No customer value delivered. (That’s why it’s not Sprint 1).

And that – in my opinion – is not a good idea.

The goal of Agile & Scrum (and especially XP) is to get you writing code and generating value as fast as possible. Sprint 0 gives up on the focus on delivering customer value entirely.
It turns the entire time spent into sunk costs – essentially forcing the Product Owner to commit resources & time for Sprint 0 and at least another Sprint before value is created.

Instead of doing a Sprint 0 try a regular Sprint and use the time for prototypes and to implement the brutally simplest thing to do – even if it’s just a big fat hack.
Initiatives such as Hack Days yield mind-blowing results in just a single day. And they show what is possible and what is not by creating code that you can run and toy with.

And if you now think “Ah, but Hack Days are different” – what’s the difference? If you can be highly productive in a single day, what keeps you from doing the same in your regular project?
What can you change to enable it?

3. Sprint Length

How long are your sprints? 8 Weeks? 3 Months? Do your “Sprints” look more like a month-long death march?
Also did you ever extend the length of a Sprint because not all Stories could be closed at the regular end date?

If any of the above rings true you might be still working with the time scale & behaviors of regular project planning.

Scrum defines Sprint lengths to be exactly 30 calendar days.
Agile in general is more flexible depending on methodology used – going from seven days (XP) to six weeks (RUP).

With Agile teams can deliver smaller increments a lot faster than using regular project planning.

Both of the teams I guide as a Scrum Master are on two-week sprints. Both deliver solid customer value at the end of each sprint.
We had a lot of discussions on the right Sprint length and also tried out one week and three weeks but in the end two weeks were the ideal time frame.

Before that? Well … we were taking months between deliveries.

If your team is at the very limit of four/six weeks and still struggling – it’s not time you’re fighting, it’s most likely code quality (see 2.)

Lastly one personal remark on sprint extensions:
Do not extend the length of a sprint after it has been started. I did this once with one of my teams and it confused the hell out of people (“The sprint ends this week – right…?”).
We also de-synced from other teams leading to even more confusion down the road. While the underlying reason (a lot of people where away on holidays then) was sound the course of action was not.
It would have been better to look at the time frame ahead of the planning and check with the other stakeholders to see if there are any unexpected side-effects.

The Bottom Line

The transition from traditional project planning to fully embracing Agile & Scrum is long and can sometimes be difficult as it forces you to break with established processes & habits.
Not allowing this break to happen can cause you to be stuck with the worst of both worlds.

Three common signs that your team is still in the transition phase are Stabilization Sprints, Sprint 0 and Overlong Sprints.

If you consider yourself “doing Agile” and encounter any of these signs – it might be wise to check where you actually stand.

Do you deliver customer value quickly? Can you ensure that after every Sprint you have something stable? Something created to easily find the acceptance of the Product Owner and Stakeholders?
Concepts such as Test-Driven-Development, Continuous Integration and ultimately DevOps show a way to be ready. Every time. All the time.

So what’s holding you back?

Fund Teams. Not Projects.

Who hasn’t experienced the following scenario:

A project was canceled and suddenly you have a lot of people that need to be either relocated to other projects removed from the company.

The reason why this happens is that investment is attached to projects. Following the basic business logic projects are a way to convert some money into more money – or at least more money that other alternatives would generate.

As a result of the available funding teams are assembled to follow the project’s vision through and create something that will ultimately return multiple times the investment.

While I agree with the notion that businesses are there to make money I strongly believe that basing team coherence on the association with projects can be hazardous and costly for the company.

And here is why.

The Constant Reset

Based on Tuckman’s observations on team dynamics we know that teams are not simply created – they evolve over time. Going through the phases Forming, Storming, Norming, Performing (and Adjourning).

 Not surprisingly a team is most productive in it’s „Performing“ phase. Team members have gotten to know each other, working standards have been established and trust has been built. The team can focus on delivering.

Reaching the „Performing“ phase takes time – sometimes a lot more than six months. Now add to this fact projects that are the basis for the team’s existence. As soon as there is a change in the project – for example cost reductions leading to less head counts available – the team dynamic is disrupted. The team will most likely revert to an earlier stage such as Storming leading to conflict and severely reduced performance.

 Previously this was less of a problem as projects tended to run longer usually for years.

With the advent of Agile development we will (hopefully!) see smaller more nimble projects, coming to life and retiring in reaction to the business needs.

While this nimbleness will certainly bring with it a lot of benefits such as lowered monetary commitment and risk it also carries with it the cost of team coherence.

A team that is constantly being reassembled because it’s underlying project is frequently changing will rarely have the time to settle down and get to the „Performing“ stage.

The team dynamics will be constantly reset to their infancy.

The Cost of Constant Team Changes

With team members constantly having to go through the earlier stages of team development they are tied up getting their bearings and finding their spot inside the new team.

This takes away time and energy from their capability to perform the job they were hired for leading to decreased performance, lowered satisfaction with their job and in extreme cases even workplace aggression (See also: Workplace violence and workplace aggression / Baron, Neumann / 1996).

Another potential problem is the negative impact on the willingness and/or ability to form (professional) relationships with co-workers.

Just think about it: If you know already that all these other strangers on your team will be none of your concern in less than a year why bother getting to know them? Why spend the energy and time to socialize if you will have to go through the same steps again in the near future?

This problem is very similar to the one faced by children having to constantly relocate during their childhood ultimately being less capable of forming lasting relationships, having lower life satisfaction and expectancy (see also June 2010 issue of Journal of Personality and Social Psychology).

Both of these problems are amplified when the teams are not co-located.

Integrating remote workers is a challenge on it’s own.

Most literature focused on virtual teams will cover the feeling of isolation and lack of integration with the overall team. Why? Because these issues can be just as problematic as the ever-present challenge of effective communications. Many experienced leaders recommend overcoming these issues and creating a feeling of belonging by engaging the team members in conversation, getting to know them, listening and showing your appreciation for them not only as a professional worker but also as a human being.

 Now imagine having to go through this every few months – either as a leader or a professional.

 Taking into account the above effects of constant team changes can create a negative impact the on business in the form of lowered performance and employee satisfaction that quickly outweights the benefits of being able to reshape the team landscape in reaction to the market.

 Having said that – what can be done both reap all the rewards of being Agile and responsive while creating a pleasant work environment?

Fund Teams – Not Projects

Putting the money where the people are might sound obvious – but it’s quite a change from the existing funding approach.

The idea is based upon the thought that the workforce is to be considered well-trained and motivated and established teams are ready and willing to attack new projects. (If you are struggling with an unmotivated, unskilled workforce that is rejecting new projects you are having a completely different problem on your hands).

Instead of funding a project and stuffing people into it – fund a team!

The team knows it’s coherence will be respected and can spend the time and effort to get to and remain at the „Performing“ stage, creating strong bonds between each team member.

 Once you have a new project you now take a look at your available teams and assign the project to the most suitable team. That way your worry is less of getting people into funded projects but more a decision of which project to tackle first.

 Agile and Scrum support this notion with short-term commitments taken up by self-organized teams. This way you can quickly attempt a new project without having to factor in all of the team dynamics. If you are satisfied with the project – let it run. If not stop it and give the team another one of your ideas to chew on! Also with the underlying T-Shaped capability model you have (or can create) a workforce that is able to handle a variety of project types from day one instead of having to painstakingly assemble a collection of specialists by scouring other projects or waiting for resources to become available.

There are some drawbacks to this approach with the main one being that you can no longer easily tie expenses together with (future) income as the expenses are defined by the team while the income is a result of a project attempted.

Also the Product Owners / Program Managers are forced to be able to whip out a new project idea latest if an existing project does not seem to pan out. However I’d be wondering if that isn’t exactly the job these people are already doing.

The Bottom Line

Basing teams coherence on the existence and shape of their underlying projects can be hazardous for the business if projects are created/changed/retired in quick succession.

The adoption of Agile will (hopefully!) drastically increase the frequency at which projects are aligned with the market needs. This in turn increases the frequency at which projects and teams change.

This constant change prevents teams from performing optimally and can cause severe negative effects such as workplace aggressiveness, isolation and ultimately employee dissatisfaction.

To reap the rewards of Agile project management while creating a pleasant work environment the team coherence has to be decoupled from project assignments.

This is achieved by funding teams instead of projects.

The end result is a productive, satisfied workforce able to tackle new projects quickly.

This in turn gives you the freedom to start new, promising projects easily while making it less painful to retire failing ones.

Start. Now.

Some of the brightest ideas never saw the light of day. Some of the best projects were never started.

Why?

I think everyone is carrying around a large selection of ideas, new ways to get stuff done and interesting projects. But I also think that everyone knows the pressures of the day-to-day business having more tasks and objectives than can be completed in the time available.

With this time constraint in mind we begin to prioritize tasks usually putting day-to-day business needs first while pushing the other seemingly less pressing matters aside. This can go on for months and even years keeping you busy but piling up a lot of unrealized potential.

It’s this unrealized potential that carries the long-term benefits, such as learning something new, creating something magnificent or treading the road less taken. And it’s these activities that keep you in the game and ensure your division, your team and ultimately you stay up-to-date and relevant.

So why are we not doing all of this if it is so important?

The Psychological Hurdle

The problem with new things such as projects is that they are always something unknown. And the unknown can be pretty scary. You are leaving the proverbial comfort-zone and risk spending your scarce time and resources on something that may not pay off.

And looking at a lot of the projects and learning activities we’re talking about a lot of time and resources. Looked at the CISSP or PMP certification? Tried running up a side-project recently? That’s months of work. „I don’t have the time for that!“ you might be thinking and you are right.

Wait – what?

If you take a look at the effort as a whole and all the unknowns attached to the project that’s a lot of commitment demanded from you. And it’s totally okay to be unwilling to sign up for the entire package. But you don’t have to. Here is where Agile can help you in your personal and professional development.

 Agile and Scrum twist the notion of traditional project planning and commitment around by acknowledging that committing for a large amount of work over a long time period is risky – so you don’t do that.

 Instead you create a short term goal. Something that is maybe 14 or 30 days away.

You only commit to something that you can achieve in that short amount of time – as little as that may be. And you only commit the resources you can muster for that short amount of time.

 This may mean that you only commit to work on a single chapter of the CISSP/PMP certification guides or that you only do a small prototype for your project. You don’t write a book, you write a chapter or just a single page.

The goal is to get you started as quickly as possible.

Don’t stand at the foot of the mountain staring up – make the first few steps and then look back at what you have accomplished so far.

 If you find out that you are going the wrong way or don’t like where you are going – stop and look at other choices. That way you are always in for just a few steps and not committed until the bitter end.

But if everything looks okay and you’re feeling good – by all means, go a few steps more.

Empirical Improvement

Projects – by definition – are always something new.

We already talked about that something new is usually scary because it carries a lot of unknowns. Project Management theory (and practice) tells us that at the beginning of a project we know the goal we want to reach but have virtually no knowledge how to do this best.

The notion of planning everything beforehand is something that works for well-understood processes. This is called the „defined“ approach.

You ensure that for fixed given input you will always get a specific output when processed. Most of mass-manufacturing works by using defined approaches. Human nature, especially when one is risk-adverse, favors having a clear plan and defined parameters beforehand.

Projects break new ground so the way to reach the goal is usually not very well-understood, sometimes even the goal is hazy. Trying to define everything beforehand is trying to shepherd cats – it does not work. It’s ironic that at the point of least knowledge we try to do most of the project planning.

So let’s not do that anymore.

Agile and Scrum favor the „empirical“ approach.

As described by Ken Schwaber in his standard book „Agile Software Development with Scrum“ the empirical approach focuses on observation and learning instead of following a strict plan.

 In concrete terms you start your project based on the knowledge and assumptions you have now let it run for a while and then compare the results with your expectations. Through this comparison you learn more about the goal and the road to reach it. You also learn a lot about how successful your way of working is.

The important part here is that you actually spend the time on reflection and learning.

 I know of a few companies that have implemented ISO quality processes – including reviews – but apart from doing the reviews there is little outcome. Review results are nodded-off and then quickly tucked away. As a result you get the worst of both worlds: The added work of following the process and the lack of quality by not learning to improve.

 Agile and Scrum also recognize that mistakes will be made. Making mistakes is human. Making mistakes is okay.

So instead of focusing on trying to be flawless the goal is to take a look at why things went wrong and to look early and often. The earlier you find out that something’s going wrong the more time you have to act and improve.

The Bottom Line

The iterative, empirical approach of Agile & Scrum allows you to tackle large, risky projects without having to commit yourself until the bitter end.

 Instead you set yourself small short-term goals and only commit yourself for that time frame.

At the end of the time frame you take a look back and check if you are satisfied with where you are.

If you are okay and feel you are going in the right direction – set up another short-term goal and continue. If you feel you are going the wrong way you have the freedom to stop and reorient yourself.

 By adopting the empirical approach you do not try to plan for every step of the journey – just for the few steps ahead. You observe and learn as you progress adjusting your course and approach based on the experiences you make.

 With the combination of these two concepts you can quickly get to the fun part:

Getting things done. Achieving (small) goals. Going home at the end of the day knowing that you achieved something valuable.

So start. Now.