Other

People need estimates. So they can predict how much software will cost and how long it will take.

People need umbrellas. So they don’t get wet when it rains.

Although, some people don’t need umbrellas. They have awesome waterproof jackets with hoods. They have solved the problem of “how do I stop getting wet?” with a different solution to the humble umbrella.

People need to know what time the trains are running so they can plan their trip to work. Some people do not need to know this because they take the London Underground, where trains typically arrive every 2 or 3 minutes.

What’s your point, Neil, you might be asking? My point is that when people are debating against the #NoEstimates movement, they always seem to gravitate toward the same two arguments:

• People need estimates, so we should provide them

• We cannot simply start building software without having an idea how long it will take or how much it will cost

To the first point, people only need estimates if we determine that the only solution to the problem of wanting to know “how long and how much” is to make a guess. People who have found other solutions to that problem do not need estimates.

I now wonder: just because the people who still need estimates have not discovered any alternative solutions, does that mean they need estimates or that they think they need them? Or simply prefer to use them over other solutions?

People do not need umbrellas. They need a way to stay dry on a rainy day.

To the second point, I categorically want to put an end to the myth that #NoEstimates equates to #NoPrice or #NoDate. If you read my previous blog posts on the subject or read my tweets you will hopefully understand that my point is the absolute opposite. We DO need a price and/or a date. The only difference is how we arrive at those things.

With estimation, you guess one or both of them (and, in doing so, have a stab at scope too – otherwise what are you estimating?)

With #NoEstimates you set the price and/or date, either through experience and choice (for e.g. setting price/date for the kind of work you do regularly, with a fixed team and cost) or through a real budgetary or time constraint (e.g. “I’ve only got $100k, what can we build for that?” or “The Australian Open starts in 3 months so the Aus Open app needs to be ready to go live the day before”.)

You then incrementally and iteratively deliver, setting mini-constraints within the wider constraint that breed creativity, innovation and predictability of delivery, and have a flexible working and payment arrangement with the customer.

People need certainty about what they will get and how much they have to spend. Unfortunately there is no certainty in software design and development. However, I would argue that #NoEstimates gives greater certainty than estimating does.

When estimating a date or cost you are creating uncertainty around those things, because you are guessing. You are saying “we’ll deliver somewhere between here and here”. However, if your delivery date and/or cost is set by a real constraint, as advocated by the #NoEstimates approach, you have created certainty around those things.

Yes, you may decide to shift the date/cost as you get closer to the initial figures, or once the customer decides they are happy with what they have. You have been delivering frequently and learning about what you are building. You have been creating data, such as throughput and cycle times, and using heuristics and slicing to reduce work increment size, so informed decisions can be made along the way. But you will only go beyond those initial figures if the emergent value of what has been built, and other data you have gathered, suggests that you should. Scope remains uncertain whether you estimate or not.

People still need 500-page business requirement documents. People still need separate test teams and development teams. But there are alternative solutions which may render these needs unnecessary. The alternatives to estimation are real, both at the project and the portfolio level, and are being used by many people across the globe in varying sized businesses.

All I ask is that we consider those alternatives and do not stop searching due to need.

Other

Other

It is no secret to my Twitter followers, and perhaps beyond the Twitter-sphere, that I am on a crusade of sorts to get people considering other ways besides estimating when it comes to costing software development projects and tasks. Such a view remains controversial, even among Agile practitioners. People argue that there is no alternative; customers want estimates, so we must provide. Stakeholders need to know when things will get done. Estimation is seemingly one of the few remaining immutable practices hanging over from the Waterfall era.

One of the common criticisms of my view is that it is unduly dismissive. When asked by our boss or a customer for an estimate, we can’t simply palm them off and say “I don’t estimate! Talk to the hand, sir!”

Of course this is true. But I should point out that I actually see nothing wrong with being asked for an estimate of how long something will take. What I object to is being asked to carry out (or ask my team to carry out) estimation rituals whose results will then be used for making important business decisions.

We cannot palm people off, but what we can do is offer alternative, empirical approaches to traditional and “Agile” forms of estimating, explain exactly how we will provide the required information and why such approaches offer advantages over guessing “how long” or “how big”.

First off, I would suggest that there are many problems with the “how long/big” approach, the biggest of which is that such an estimate does not take into account the:

• Inherent unpredictability of building software
• Current work in progress (i.e. the team/dev may not be able to start the work “now”, or even for a few days, weeks or longer)
• Capacity to do the work (i.e. the team/dev may make the estimate based on certain assumptions of team size which turn out to be false, or a colleague being there who ends up not being), nor
• Any upcoming changes in priorities (i.e. something may jump above the piece of work in priority).

From a task point of view, what is estimated as a “10 minute job” may end up taking a day or longer due to one or more of the above. I’m sure you have seen this situation many times over. From a project point of view, this situation is magnified and can be hugely costly, even catastrophically so. 3 month projects become 6 months. 1 year projects become 3 years.

In a situation where there are small tasks flowing through from the customer to the development team that are unpredictable in their timing (e.g. BAU work queues, feature development, etc.), a far better, probabilistic approach to get some semblance of predictability is to do the following:

• Measure actual lead times of every piece of work and plot them in a Lead Time Distribution graph
• Measure throughput (you can start by simply counting the number of cards in the “done” column at the end of every week)
• Use a fixed WIP limit on cards in progress (start, if you like, with the natural limit of team size)
• You can now use Little’s Law to calculate average lead time for a card at position n in the queue, i.e. (WIP + n) / throughput:
  • e.g. Number of cards done in 1 week = 20, therefore throughput = 4 cards/day
  • Team size = 2, therefore WIP = 2
  • Lead time = (2+1)/4 = 0.75 days (i.e. on average it will take three quarters of a day for a card at the top of the queue to be delivered)

With the same formula you can predict where a card 2nd, 3rd or xth in the queue will get done, which is very helpful for guiding your prioritisation:

e.g. Using the same example above, a card 2nd in the queue will likely be done in 4/4 = 1 day, while a card 6th in the queue will likely be done in 8/4 = 2 days

Bear in mind the only way this formula can provide useful numbers is by having a WIP limit that is fixed (as far as possible). There will of course be variability in how long each card takes, but the law of large numbers will even this out to an acceptable average and it’s certainly far more scientific than asking people to estimate each card.

Note that if you use Scrum, and thus the team breaks down features into small tasks just-in-time at the beginning of every Sprint, you can use the same principles as above to determine when a new feature might be delivered (Scrum has a WIP limit over the Sprint length of the number of tasks in the Sprint Backlog, throughput is the number of “done” stories/tasks divided by the Sprint length, etc.).

Over time you can achieve a higher level of confidence with the predictions as you start to identify and split out different work types, determine probability of delivery times using your Lead Time Distribution graph, etc.

What about “how long will this project take?” !! Warning !! You can scale this approach up to the portfolio level. But… do bear in mind that building an entire software product rarely has a finite end point or a repeatable result because it is not possible (nor desirable) to define all of the scope required to deliver a delightful, valuable outcome. Use such predictions with extreme caution. There is no substitute in software product development for creating certainty around costs and delivery times via fixed agile teams delivering working software early and often, short feedback loops with the customer, etc.

So, next time you’re asked “how long” or “how big” about a software project or task, don’t palm off your boss or your customer with simply “I don’t estimate!”. Perhaps you might consider answering: “I don’t estimate! But… here is how we can save ourselves the cost of estimation meetings and make empirical predictions going forward to answer these questions with more confidence.”

Other

Other

This is the second in a series of blogs about why I believe we should not be estimating software projects. The first post talked about estimating at the team level, whereas here I talk about the contractual level and how to arrive at more Agile, iterative working arrangements.

Agile team, same old contract

Traditional software contracts, particularly with external parties, are based on:

Many, if not most, of today’s software contracts are based on similar premises, even in supposedly “Agile” projects. In order to mitigate the risk of their deliverable running late and bumping up the cost, many customers demand fixed price contracts. Others demand that the supplier contractually fixes the delivery date to ensure meeting some obligation around the date and shy away from time-and-material engagements. Suppliers often like the fixed time approach as well because it creates predictability around cost. Fixed price contracts provide certainty around the project’s ROI, assuming it can be delivered at a low enough cost, and customers like to know how much they are spending.

There is nothing inherently wrong with any of these approaches or the reasons behind doing them. The problem lies in how we arrive at delivery dates and prices. In order for a contractual engagement between a supplier and customer to be worthwhile to the supplier it must deliver a positive return on investment. Usually this means that the money received from the customer for the supply of the product or service must exceed the money spent by the supplier providing it. So how do we balance that equation? Customers want certainty they will get what they want in the agreed timeframe and/or for the agreed price, while suppliers want to make sure they make a profit on the engagement. Seems simple enough. But what is missing from these scenarios? Even if both parties accept the well-understood iron triangle of time/cost, scope and quality, and that at least one of the three must be variable, is this enough on which to base a low risk and mutually valuable contract? I believe the answer is no, and not just because scope needs to be movable.

Quality is variable, not fixed

What?! Sounds controversial but I believe it to be true. In addition to the need for scope being variable, Agile folk also tend to talk about quality being fixed and uncompromising, meaning that time and cost can also be variable to deliver the best possible outcomes. Aside from the fact that leaving the cost and/or completion time of a project open is generally deemed an unacceptable way to conduct business, and likely why many businesses shy away from “Agile” contracts or working arrangements, I actually think it is un-Agile to fix quality. By this I’m not talking about code quality (the debate about what are bugs and acceptable levels of bugs in minimum viable and evolving products is for another blog post, another day). I mean quality in terms of what the customer defines as quality, and for me they are the only ones qualified to do so. IMO quality is an ever-changing variable in a project, just like scope. The difference is that the customer defines quality, either explicitly or implicitly, consciously or unconsciously. Scope, however, is defined by the supplier. Personally I think of quality in the context of products and services as:

“A subjective meeting of a need or requirement to the satisfaction or delight of the customer.”

Don’t deliver the requirements, deliver what the customer wants

Agile contracts – the reality

So what really is an Agile contract?

Fixed price contracts are fine. Fixed time contracts are fine. But here are the caveats:

• Do not fix time based on an estimate of cost because that inherently means you are agreeing to up-front scope detail that will likely bite you on the arse later and restrict the customer’s ability to request changes (and yours to welcome them) for their competitive advantage
• If the customer does not fully understand and embrace the inherent unpredictable, creative and innovative nature of quality software solutions then work with them at your peril
• If you don’t want to turn away work so you try and agree scope with the customer because “they insist”, and then base dates and times on estimates, do not pretend this is an Agile contract and make sure all parties understand the implications of this
• Know your costs by having a fixed team and determine a “final” delivery date, or allow the customer to determine it
• If the delivery date is acceptable to both supplier and customer then you now have a certain delivery date, no guesswork required; if the customer wants delivery sooner, reduce the price AND the expectation of quality
• When you purchase something more cheaply outside of software, e.g. a cheap old banger of a car, you can assume you will likely receive a lower level of quality – why is software any different?
• Negotiate a flexible, iterative, drip-funded contract that allows the customer to retreat early (either because they’re already happy with their product or because they’re not happy with the progress; if it’s the latter learn from their feedback, improve and move on)
• The aim is to delight the customer and make a profit so do not simply do what they ask you to do; they are buying your expertise and guidance for meeting their need, so don’t take this responsibility lightly and think you’re serving the customer simply by “delivering customer requirements”
• Deliver early and often (duh!); iterate, don’t just increment, and make this part of the working agreement
• If possible give the customer a sense of the kind of outcome they can expect for varying price and/or delivery times (based on previous work done by your company) and given them options to “upgrade” or “downgrade” (see my 99-second presentation on Alternatives to Estimation)

Remember we’re supposed to “welcome” change?

Yes, don’t try and fix scope. But be prepared to move around on quality also. Allow the customer to accept an earlier version of your product because it does the job and they’re delighted they don’t need to spend any more cash on achieving their desired outcome. Or to love their product so much that they now want to spend more enhancing it. This is variable quality, in my book. Variable scope refers to the cost-side of building software; the amount of work we need to do to reach a specified outcome. Variable quality refers to the value the customer feels they are getting. It’s subjective, dependent on the customer and their particular circumstances. Delivering high value outcomes to the customer may cost more than lower value outcomes or they may not, depending on what the customer feels about the iterative outcomes. That “old banger” that you bought for $1000 may actually provide very high value and quality to you personally. Or it may be housing a classic engine that you didn’t previously know about, giving it emergent value. To someone else it’s a worthless piece of junk.

In the same way software solutions, products and services are entirely subjective in their quality. Some people think Microsoft Word is awesome and feature-packed and they base their entire business operations around it. Some think it is terrible, buggy and doesn’t do anything they want it to do. Let’s not pretend that delivering “quality” software is a predictable outcome any more than fixed scope is.

Variable quality pertains to the wonderful opportunities we ought to have with Agile software development for correcting the course and building the right thing; truly welcoming and embracing change for the customer’s (and our) benefit. This is what Agile contracts should be about IMO. Remove the uncertainty of time and cost by making them certain, and celebrate with your customers or suppliers the uncertainty around exactly what will be built. Why not consider basing your contracts on a mantra more along the lines of:

“We guarantee we will work with our customers’ time and budget constraints to iteratively build and evolve a delightful outcome to an agreed level of expectation?”

Other

Other

Introduction

This is the first in a series of essays exploring the huge topic of estimation within software development projects.

There are many different contexts in which estimates are given, and I am going to try and cover off as many as I can think of in these blogs, but the pattern of my argument will remain consistent: I believe we ought not make decisions in software projects based on estimates and that there are better alternatives for both the suppliers of software products (financially and ethically) and their customers (internal and external). Many of these alternatives are being used in real companies delivering to real customers with great effect.

Given the vastness of the topic, this post focuses purely on the scenario of one Scrum (or other method of iterative product development) team delivering a software product without estimating. Issues of scaling up or down capacity (adding or removing teams) will be covered in a later post about estimating at the portfolio level.

Will we deliver on time?

This is a question that often gets asked of a software development team at the beginning and throughout a project, and is a key reason why many believe we need to estimate. However, the ironic twist of seeking predictability by making predictions based on guesses is not lost on most people. We all know, or at least suspect, that we’re plucking numbers out of thin air. That we don’t yet know or understand the solution. Or the domain. We comfort ourselves by calling our guesses “educated” or “quick and dirty”, to justify our using them to make important business decisions.

Building software is by its very nature unpredictable and unrepetitive. While building software we cannot easily break down the work into same-sized, repeatable widgets like we can when manufacturing car parts. Unlike car production, the exact product we are building is unknown until we’ve built it, so how can we break the work down into smaller parts up front? One increment of software is not like the next. Software development is a creative, variable pursuit, and solutions are often revealed as we go along. For this reason, fixing scope in software projects is not really possible. Even if it were, it is becoming widely accepted that attempting to do so is undesirable because such an approach does not allow for (or, at least, does not embrace) emergent design, requirements, change and innovation. If we accept that scope is always variable, we must also accept that the delivery date may end up as a moving goalpost while we scamper to deliver what we think is fixed scope “on time” and “on budget”.

So, if it is true to say the concepts of “on time” and “on budget” are usually based on an estimate of how long it will take (and how much it will cost) to build software to meet a fixed set of requirements, rather than a concrete time or budget constraint, it is likely fair to say that we may take longer to deliver the software than we initially estimated. Yes, we may also be quicker than we thought. Or we may get our estimate just right. But, regardless of the outcome, does it actually matter how “correct” our estimates were? Does the act of estimating our work have any impact at all, positive or negative, on the delivery of great software or its return on investment?

Vision is key

To build software we need a clear vision and shared purpose of what success looks like. When commencing with a potentially valuable software initiative we need well understood high level goals, not the detail of how we will achieve those goals. In true iterative fashion we can then align our just-in-time decisions about how we will improve the product in the next iteration (i.e. what we will build next, aka top items in the Product Backlog) with these goals. I posit that trying to estimate how long it will take to deliver software to achieve one or more high level goals, and then basing real decisions on this estimate, is a questionable approach. Don’t we want our solution and architecture to emerge? Don’t we we want to welcome and embrace changes for the customer’s competitive advantage as the product evolves and becomes more real to the users? These are key principles in the Agile Manifesto and I believe they lie at the heart of a truly Agile approach to building software.

Remove the unknowns

Instead of depending on an accurate estimate for predictability we can take away the unknowns of cost and delivery date by making them… well, known. The Product Owner can fix the delivery date based on a concrete budgetary and/or time constraint (e.g. 3 days before the Australian Open starts for the Australian Open app is a concrete time constraint, and “we have to build something for $30,000″ is a concrete budgetary constraint). Within that constraint the team can then fix incremental delivery dates (e.g. end of every Sprint) to allow focused effort on iterative product evolution (it’s not good to have priorities changing every day on a whim) and provide the opportunity to deliver early and/or under budget. This approach is also useful where there is no concrete budget or delivery date, although the need for interim release dates diminishes if the team (and organisation) is mature enough to have a continuous delivery model.

Estimating sprint velocity is waste

Rather than fix the solution up front (which is required in order to give a “how long” estimate), or make forecasts every Sprint about how many points or stories will get done, I believe teams ought to commit at the outset to building and delivering the best possible product by a given date and/or for a given amount of money. For me, release planning using, e.g velocity (“how many points can we deliver by the release date?”, or “what is our release date given our remaining scope and velocity”) is contrary to an iterative approach (holistic, evolutionary improvement of the product) and is more in line with a purely incremental approach (delivering a pre-defined Product Backlog feature by feature).

When we estimate and use velocity as a planning tool we are making an assumption of how much can get done in a time period. For that information to be useful and meaningful we need to have an amount of stuff in mind that we want to deliver (i.e. a fully estimated Product Backlog). I don’t think it would be too controversial to suggest that all the time (and therefore $$$) spent on estimating backlog items that do not end up getting delivered is waste (at least in the Lean sense).

But what about all the time and $$$ spent on estimating backlog items that do get delivered? To answer that question, I will ask one more question: “Did the PO ever prioritise one story over another based on it having a lower estimated cost (story point size)?” If the answer to this questions is “No” then I conclude that all estimating in this context was waste because no decision was made based on the estimates that were given (instead the PO simply prioritised the highest value stories). If, however, the answer is “Yes” then estimates controlled what I believe should be value-based decisions. Estimating a backlog up-front and then release planning using velocity is a cost-based approach. While costs are obviously important in running a software project and, indeed, a business, if decisions are made purely on cost then some of the great software we use and rely upon today (e.g. much of what is made by Google, Facebook, Apple, Yahoo, Spotify, etc.) would never have been built and we would have one explanation as to why there is so much crap, expensive, bloated software in the world.

Iterate, don’t estimate

I believe iterative (Agile) development is 100% about making decisions based on customer and/or business value, using empiricism over guesswork and fixing cost by having a fixed team (a la the Spotify “squad” model) with known timeframes (frequent, predictable release dates as opposed to “deadlines”, which are release dates for “fixed” scope based on imaginary constraints). Knowing our costs and delivery dates gives us certainty which allows us to embrace the delicious uncertainty of building great software.

btw – Having a fixed delivery date doesn’t mean that we will necessarily stop building our product on the delivery date. We may have already stopped or we may choose to continue. What it does mean is that we will continually make go/no-go decisions based on the emergent or potential value of what we are building rather than estimating the cost of a particular solution.

Shift focus to “small”

From the team’s point of view, I believe it is far more valuable to get better at breaking down stories JIT (and only JIT – any earlier is potentially wasteful) to be as small as possible (or, at least, as is practically possible) than to “increase velocity”. For me, a high-performing team has the ability to deliver frequent ”done” increments to the product that can derive immediate feedback and/or potential value for those using it. Clearly the smaller the increments the more frequently delivery can happen, which leads to shorter feedback loops and increased learning and flexibility for the PO to prioritise emergent features over features she originally thought she wanted/needed that have diminished in value, or even take a complete change in direction. This, in my opinion, is far more in tune with true business agility.

The importance of how many stories or points gets delivered in a Sprint becomes truly insignificant when the team is delivering frequent changes to the product and putting them in the hands of users. This, for me, is the crux of why software projects are trying to embrace an Agile approach. But until the estimation stops I believe we’re being held back from true high performance which can deliver awesome outcomes for customers.

Further Reading

• Splitting user stories by the quality of solution – Neil Killick
• What price estimation? – Neil Killick
• Should we estimate software projects… at all? – Neil Killick
• If you found estimates bring no value – what would you do? – Woody Zuill
• A thing I can estimate – Woody Zuill
• Can we code without estimates? – Woody Zuill
• Story points considered harmful or why? – Vasco Duarte
• Stop using story points – Joshua Kerievsky

Other

Other

I love this approach to splitting up user story value by considering vertical slices through the technical solution.

Iterative and incremental development is a tricky art to master. Delivering very small increments of value takes some practice. With iterative development we must be happy to frequently revisit areas of the system that we are building as we learn more about them, which is quite different from the traditional approach (broad and shallow engineering versus narrow and deep).

This is where I believe the Agile Manifesto authors were coming from when they spoke about “Simplicity, the art of maximising the amount of work not done“. Implementing the simplest technical solution in order to deliver value quickly. It does not necessarily constitute the final solution, and it certainly does not mean “quick and dirty”. We still need code quality (unit/integration/acceptance tests), and the goal is to have a usable system. Something we ourselves would be happy to use and would be able to provide feedback on.

But for an individual user story we are simply trying to meet the goal of that story in the quickest and simplest way possible while providing an acceptable technical solution to meet that purpose. If the code is simple and maintainable we can easily build upon it if required, and the required architecture will evolve as we both iterate and increment.

So we want stories as small as possible (no more than a couple of days of work) and with the simplest acceptable solution under the covers. A good way of looking at it is “what’s the minimum amount of code I need to write to pass the acceptance tests?” (this approach of course leads naturally into the worlds of TDD and BDD, which I encourage you to read more about).

Working this way enables us to get early feedback on the feature and decide whether to invest more effort (via more stories) for that feature, thus allowing the flexibility for the product owner to prioritise a different area of the system if (s)he so wishes.

Some further reading about splitting user stories:

Have a great weekend everyone. Perhaps consider making the goal of your Sprint Planning meeting on Monday to split your stories down even smaller using some of the excellent techniques available. The benefits are numerous.

Other

Other

So you want your team to deliver software faster?

To demonstrate why this request is nonsensical first imagine a mature, high performing Agile team who delivers on average 10 stories of roughly the same size in every 2-week Sprint (i.e. 1 story per working day).

Now imagine we asked the team to take on just ONE story every Sprint. Their capacity is 10 stories, but we ask them to only deliver 1. What might happen?

Well, we can’t be sure but it is fairly safe to assume that the 1 story is guaranteed to be delivered. We can also be pretty sure that it will be of an extremely high quality, given that the team are working well under capacity and so have plenty of time to dedicate to ensuring a bug-free and pleasant user experience. They may also spend extra time on exploratory testing, ensuring that the whole product, of which this story is a small part, is not hiding some ugly buggy behaviour. If they do find some bugs, they may fix them and add some tests to their regression suite to ensure the bugs don’t recur, increasing the holistic quality and maintainability of the system.

Given that the team knows they are an awesome, high performing team and they have plenty of time to spare in the Sprint, they will likely spend a large portion of their time not working at all. Having fun. Slacking off a little. Giving their brains time to breathe, to reset. Enhancing their team culture and spirit.

From a planning point of view, we may not have speed but we sure have predictability. We know that the team delivers 1 story every Sprint so we can very easily figure out when our product will be delivered with close to (if not exactly) 100% confidence.

OK, now let’s instead imagine we ask the team to deliver 2 stories per Sprint. It’s not too much of a stretch to assume we would get a similar result to the above, except this time some (albeit small) sacrifices will be made. Perhaps some of the extra, luxury activities will be left out. Perhaps all of the aforementioned activities will be done but with less time spent on them. So a little less story and product quality. A little less fun and recuperation time. A little less team building. While it’s highly likely that the team will surely deliver the 2 stories, the probability is slightly less than when we asked them to deliver 1 story. So we have a little less predictability.

What about if we extend this scenario to 5 stories? Then 8? Now imagine we’re struggling to hit a contractual deadline so we feel the need to “speed up”. So we ask the team that predictably delivers 10 stories to deliver 12 (now we’re over capacity). Or even 14?

Hopefully you can see where I’m going with this. The more stories we ask the team to deliver, the less time they can spend on quality, the more likely shortcuts will be taken, the more likely technical debt will be incurred, the more likely team culture and effectiveness will suffer, the less fun will be had, the more fried the team’s brains will be and the less predictable we will become at delivering software.

Read that again – the “faster” we ask (or worse, tell) our teams to go, the less predictable at delivering software we become, and that software is more likely to be of a lower quality. Allowing our teams to deliver at a constant, sustainable pace ensures quality, predictable software delivery, a higher chance of happy teams and happy customers, which leads to higher business value (e.g. profit).

In short, by allowing the team to find the right balance and deliver high quality software at their capacity, a cycle of success is created.

So, managers, please think twice before asking your teams to speed up, i.e. deliver more stories (or story points) than usual in a Sprint or sequence of Sprints. It’s like asking a marathon runner to start running faster after 32k for the final 10k – you’re increasing the chances of long term failure (not completing the marathon at all due to fatigue) for a potential short term gain (running some quicker kilometers).

Other

Other

If I want someone to, say, build me a website, in most cases there are two possible constraints I have. I either have a maximum amount I want (or have available) to spend, or I need my website delivered by a particular date. In a truly Agile project, both of these are the same for the supplier because there is a fixed team, i.e. time constraint = budgetary constraint.

Back to my requirements. Let’s say I have $5000 available. If I engage a web design company, I can choose to not tell them my constraint, perhaps because I want to save money and get the “best/cheapest quote”. I can simply ask “how much will my website cost, given that I want x, y and z?”

This is the predicament many software companies have – how do we determine a price for the customer? The answer is invariably to take the customer’s requirements, devise a solution and estimate how long that solution will take. This will then derive the cost to the company, which will determine the price to the customer.

As customers, let’s stop and think about this. Is this the approach I want the web design company to take? Does this provide the best possible value for me? When I engage the web company, would I rather the following:

A: Stay shy about my $5000 budget, and the company comes back and tells me they can build my site for $4500, having based that decision on a fixed design/solution and guess of how long that design will take to build. Perhaps they’ve actually shaved time from the team estimates in order to under-cut a competitor. Perhaps they’ve added on time as a “buffer”, increasing the price for me. We will sign a contract based on a SoW detailing what I will get for my money. If I want to change any of the detail as I start to see the website built I will need to pay extra or I will need to drop out some of the originally agreed features. These small increments will need to be costed accordingly, again based on a guess of how long the new feature will take compared to the original feature.

B: Reveal my budget. They come back and say that my $5000 buys 5 weeks of work, and the team will build the best possible website they can for that price. They might show me examples of other clients’ websites that cost around $5000 to give me an idea of the quality my website will be. They will work with me in weekly iterations to ensure I’m happy with the progress, can change things as we go along and that the key things that are important to me are always being built first. They will deploy my site to a demo URL daily so I can see the site evolve and provide feedback at any time. If after a week, or two weeks, or 3 weeks, I’m not happy with what is being produced I can choose to end the relationship. This makes it clear to me that the web company is absorbing much of my risk and they are very confident they will do a great job for me. I as the customer am the one gauging the progress against my requirements rather than them estimating that they are “on track”. They want to form a working relationship with me in order to build the right thing, and that they might get my repeat business. That I might recommend them to my friends and colleagues. Their mantra is to delight their customers.

Option A requires estimation (guessing/risk/uncertainty), upfront design and makes change hard. Option B requires no estimation, design can change and emerge as we go along, embraces changes as I see the site evolve and shows a company wanting to work closely with me to achieve a result I am delighted with. One that is prepared to front extra risk (of losing money on the contract) because they are so confident in the quality of work they do and of the relationships they form with their customers.

I know which I’d choose. How about you?

Other

Other

I find it curious when people criticise Scrum as if it is competing with Kanban. I don’t believe it is, and I don’t believe it is particularly worthwhile debating Scrum vs Kanban as two Agile methods because that’s not really the case. Kanban and Scrum have quite different purposes (although they do perhaps have similar intentions).

Put simply, the purpose of Kanban is to create a kaizen culture, one whose primary concern is that of learning, improvement and process evolution using “the scientific method”. Conversely, despite Scrum having lofty yet admirable aims of “changing the world of work”, the purpose of Scrum is to enable teams to develop products effectively. Scrum is generally a bottom-up, team-based approach and so, as the Kanban brigade rightly point out, it is not particularly (if at all) effective at instilling a kaizen culture (fortnightly team retrospectives, even done well, do not create a culture of continuous improvement in an organisation). It’s also not great as an enterprise solution to perceived effectiveness problems unless the organisation really understands the cultural implications of moving to Scrum across the board and has a collective mindset that can buy-in and adapt.

But here’s the rub. To me it’s not about whether an organisation should choose Scrum or Kanban – both are frameworks or methods for different contexts and different intended outcomes. Many companies have identified that they are crap at delivering software and want to get better at it. Rightly or wrongly, these companies are not seeking a kaizen culture. They simply want to deliver software better (by their terms), not improve their effectiveness overall. I am not saying this is a good thing but at least by choosing Scrum to (try and) improve their software delivery it might just get them thinking about the importance of learning and improvement to overall organisational effectiveness. I know from personal experience of coaching new Scrum teams (imposed or not) that they begin to get curious about Scrum and Agile, and then the curiosity spreads to Lean and Kanban. A good coach will introduce teams and their managers to Lean and Kanban concepts and techniques within Scrum (or evolving away from it as the team grows in confidence) as part of a drive for true self-management, measuring, learning and improvement. I have seen, and been part of, many Scrum-ban implementations. They may not have changed their companies for the better as a whole but they certainly helped those companies deliver software better, which is what Scrum ultimately is intended for.

As for the argument about Scrum prescribing roles, meetings and processes, I believe this is down to mindset. If rather than describing the Scrum framework by what it “prescribes” (I prefer the word “recommends” but I will continue to use the word “prescribes” because I see no harm in prescribing something within a framework that one chooses to use) we instead describe it by what it intends, Scrum is a framework for enabling teams to iterate over a product until the business or customer deems it valuable enough to ship. So, if you’re in a position where you want to develop a product iteratively (or at least incrementally) and want to put a team together to do that, Scrum is (potentially) an excellent choice. If you were to choose just Kanban for developing a product, which of course you could, then by default you will not be changing anything about the way you currently work. This is not necessarily a good thing.

For example, Kanban does not prescribe iterations but often Kanban implementations use some kind of iterative process (even if it’s just having a fortnightly review of the product) and teams do this for good reason. Sure, having iterations (Sprints in Scrum) doesn’t guarantee an iterative and incremental approach to building the product but it at least hints it might be a good idea. Even if you don’t fix your scope within the timebox it still makes sense to have (say) fortnightly demos and a chance for everyone to review and evaluate the product holistically. This is a sound and effective approach to software delivery, as borne out by the Agile Manifesto’s recommendation of measuring progress via working software and delivering value early and often.

Similarly, Kanban doesn’t prescribe cross-functional teams, so if you happen to have silos of developers, testers, designers, etc. working in a Waterfall fashion with hand-offs then you will continue to work in that way and not reap the benefits (at least early in the game) of forging collaborative relationships and working as a cross-functional team until such time as the kaizen to try this is agreed upon. This approach may be better in the long run in terms of organisational effectiveness, but in the short term it could be a slow path – too slow for the business to accept – to delivering shippable increments early and often and measuring progress with working software.

Being a framework Scrum prescribes meetings and roles, but without them there is no guidance toward effective delivery of value early and often or the aim of breaking down complex problems by building an end-to-end shippable product in increments as a team – in other words, if you take these meetings and roles away it’s not really a framework is it?! The meetings point out the importance of continuous business/customer feedback, prioritisation and trade offs (as does the Product Backlog), just-in-time planning, correcting your course, team process improvements etc. The roles point out that there is conflict in the traditional Project Manager role between serving the team and serving the business, and that an iterative (Agile) approach to software development requires coaching at both the team and business level, hence the Scrum Master and Product Owner roles.

A product development framework without some semblance of structure renders it useless as a framework. If the framework is abused (as it often is, but this is not the fault of Scrum) then its effectiveness will be diminished or negated completely. But this does not mean that Kanban is better than Scrum for product development or that Scrum should not be used. In the right context and with the right mindset, Scrum can be extremely effective.

To be honest it all depends on context (as it always does) but, put simply, if an organisation wants to change in terms of improving software delivery, Scrum may well be more effective than Kanban. If an organisation recognises that it needs to embrace a kaizen culture, not just to be better at shipping software, then pure Kanban could be the way to go. But trashing Scrum because it is not always good as an enterprise solution (ironically it can be but doesn’t prescribe how to do this) or because it defines structure (which guides towards effective practices congruent with Agile) seems glib to me.

Scrum and Kanban are different approaches for different contexts but can work beautifully together in certain situations (generally product development in a team and company of the right mindset to be open to new collaborative, approaches to delivering value). One can evolve into the other, either way. They are both interesting and have noble principles. There is much to learn, and teach, in both.

Other

Other

What’s wrong with the Product Backlog?

Many companies and teams are using the idea of backlogs to help them evolve, visualise and order their portfolio of work. In terms of the work required to bring a particular product to fruition, the Product Backlog is often used in conjunction with an iterative development approach as an alternative to documenting a fixed set of requirements and a solution before development work is started.

However, the Product Backlog concept niggles me quite a bit and has actually proven in my experience to be a poisoned chalice in some respects. I actually now believe that constantly adding, removing and tailoring requirements (or stories, use cases, whatever) on the Product Backlog is (especially in the wrong hands) a fairly ineffective and costly approach to building software.

There are several reasons why I believe this to be so:

• It thwarts innovation
• It compromises the holistic vision of the product
• It creates a “requirements black hole”
• It causes a maintenance overhead (cost, inefficiency)
• Large queue = high cycle times
• It makes it difficult for the PO to understand dependencies
• It trivialises role of PO to one of ordering/prioritisation

Thwarts innovation

A Product Backlog is supposed to be a list of things we might want in the product, ordered by value (value pertaining to importance, ROI or whatever the Product Owner deems to be worthy reasons to satisfy certain particular requirements as the next priority). However, what it often ends up becoming is a big long list of everything we (think we) need to build in the product. Aside from the fact it becomes increasingly difficult to maintain and make sense of this list, building the product becomes a ritual of ordering the backlog and the team building the top things from the backlog in iterations until the product is deemed ready to “go live”.

A problem with this approach is the same problem that one has when building a product based on up-front specification documents – it is not promoting innovation in the product’s evolution. If things are on the backlog then it seems a reasonable assumption that someone has put some thought and time into why that thing should be on the backlog, so there is a tendency (for the PO and team) to want to build the product “as is” and not upset the apple cart too much. In short, the backlog becomes nothing more than a list of up-front requirements which may as well be in a BRD.

A truly iterative approach to building software allows requirements, design and architectural improvements to emerge as we go along. This sometimes means scrapping the whole thing and starting again. If we simply “work from the backlog” we may not pay the necessary attention to determining how best to evolve the product and instead go for the easy option of simply churning out the stuff already on the backlog.

In Scrum, the Sprint Review is intended as a meeting to review the evolution of the product and how it should be taken forward in the next Sprint. Many companies instead have a “Showcase” to demonstrate what has been achieved in the last 2 weeks. This approach completely negates the importance of feedback and putting our heads together to determine the best bang for our buck over the next 2 weeks, i.e. “reviewing” the product.

Many companies plan 4, 5, 6 or more iterations in advance, lining up the “stories” to be done in those iterations and completely skip the innovation part.

Compromises holistic vision of product

For iterative development to work well we must continually evaluate the product as a whole, i.e. we must iterate and increment simultaneously. The Product Backlog does not promote this concept.

Again, there is a tendency when working with a list to just work through the list – to add purely incremental value rather than a holistic approach. This can lead to much re-work, delay and added cost, both from a product value and a technical/architectural point of view.

Requirements black-hole

The idea with the Product Backlog is that we can easily add new requirements to it and re-order things so that if a new opportunity emerges while we’re building the product we can easily prioritise that opportunity and deliver the value fast. In reality what happens is that stakeholders ask for features and the PO adds them to the backlog to keep them happy. This (rightly or wrongly) sets expectations. And with expectations come a whole barrage of politics. The problem here is that the PO can give no guarantees whatsoever that the feature being asked for will ever be built, i.e. the goal posts are moving. Thus the backlog becomes a “requirements black hole”. Do not under-estimate the negative effects of this in terms of trust among colleagues and meeting your goals.

A stakeholder once said to me “when I’m told my request is on the backlog I immediately know it will never be built”. This is often a reality, so is there a better way?

Maintenance overhead

Not only is the Product Backlog a potentially enormous list of stuff, it’s a list that needs to be constantly groomed, usually at least fortnightly, to ensure the highest value things are at the top. Whether you use a backlog management tool or index cards, this creates a significant maintenance overhead (inefficiency) for the PO and team (and potentially other stakeholders).

The backlog can quickly become the focus rather than the product itself, and as it continues to grow it becomes increasingly difficult to prioritise or focus on the highest value things to build.

Large queue = high cycle times

Every new requirement added to the Product Backlog increases the average cycle time to deliver functionality to the users. Having a large Product Backlog can adds weeks, months or (dare I say it) years to cycle times. Is it particularly “agile” to tell a stakeholder that it will take 6 months to deliver a piece of functionality that in effort terms is only a 2-week piece of work? This situation can arise if you let your backlog get out of hand. All the dead wood requirements sitting down the bottom that everyone has forgotten about (but is afraid to delete) are preventing you from being responsive to the market or attacking new high value opportunities.

This potentially means those features that could give you competitive edge in the market will be scrapped for being deemed to take too long to deliver.

Dependencies

A large Product Backlog inevitably creates dependencies among items. Innocently adding a requirement to the backlog can eventuate in a cascade of dependencies that can add months to a project. By glancing at the backlog, are these dependencies transparent? Generally, no. They are invisible to the naked eye and thus have far reaching implications for the PO when trying to effectively order the items on the backlog. It can be extremely frustrating for a PO when the highest value items – requirements that they have taken time, negotiation and effort to prioritise and move to the top of the list – move down the list because of technical or other dependencies.

Taking a more holistic approach to the product makes it easier to dissolve these dependencies.

Trivialises role of PO

The larger the Product Backlog, the more time the PO will need to spend ordering it. This means more prioritisation sessions, more cost-benefit analysis, more workshopping, more estimating in order to determine size for ROI purposes. Little wonder that Product Managers are reluctant to take on the Product Owner role.

The Product Backlog can potentially trivialise the PO role to one of ordering and prioritisation of work rather than concentrating on building the best possible product with which to penetrate the market or increase the value of the business.

So, what’s the alternative?

To my mind, and in my experience, the important things about a product rise to the surface if you are doing proper Just-In-Time planning. By using the Sprint Review and the Sprint Planning meetings properly, the team and PO can properly gauge the evolution of the product and what direction it needs to take next. Why is a Product Backlog required for this? If you can’t remember what needs to be done, it’s not important. If you can remember what needs to be done, you don’t need it on the backlog!

I have found an evolving product roadmap can much more effectively align stakeholder expectations with what’s actually being built. A roadmap is very clear, easily interpreted and gives interested parties the information they crave. In the Sprint Planning meetings, why not ask yourself “How should we take this product forward in the next 2 weeks, and what can we realistically achieve?”. This focuses everyone on what is achievable which helps with simplicity of design as well as focus on value. Then update the roadmap with the new or changed high level ideas emerging from this planning session, and the rough delivery timeframes. It is a mistake to just focus on the next increment of the product in each Sprint Planning meeting. Each iteration should be an opportunity to re-align everyone with the product vision and what the best approach for the next 2 weeks should be.

Conclusion

A Product Backlog done well should paint a picture of the product. It should tell the story of what you aim to achieve. You should be able to show the Product Backlog to someone completely uninvolved and they can gauge exactly what the purpose and vision of the product is. What innate user need it is meeting. The “why” of product development.

If your backlog is simply a long list of stuff that will most likely never be done, perhaps you can look at an alternative approach?

Other

Other

“Learning is acquiring new, or modifying existing, knowledge, behaviors, skills, values, or preferences and may involve synthesizing different types of information.”

 ”Belief, a psychological state in which an individual holds a proposition or premise to be true”

 “Knowledge is a familiarity with someone or something, which can include facts, information, descriptions, or skills acquired through experience or education.”

I was pondering this morning about the difference between Learning, Believing and Knowing. The differences may seem obvious but I’d like to explore whether the following is true:

• Does learning lead to knowing or merely to believing?
• What constitutes knowing something?
• If a fact requires experience to confirm it, what if we have no experience of the subject of the fact?

We say things like “you learn something new every day!” but how much of the stuff that is absorbed into our brains on a daily basis is actually learning? Since I started using Twitter a couple of years ago I feel that I have learned very much from many people on many subjects. Similarly, as I read blogs, articles and books and talk to people I feel I am learning more and more. But what do we mean when we say we are learning? Do we mean that we are acquiring new facts (or believe we are) or are we merely merging what we are being told and what we have seen and read into our own opinions and views of what we know?

Does Peru exist?

This seems a silly question but I am using it to make an important distinction between knowledge and belief. Of course the answer to this should be a unanimous “yes”. But why am I so sure that Peru exists? I have never been there. I can’t remember talking to anyone who says they have been there. The reason I know it exists is that there is overwhelming evidence to its existence that I have observed. I have seen pictures (claiming to be) taken in Peru. I have seen video footage (supposedly) shot in Peru. I’ve seen (what I’m told is) Peru on satellite images of the Earth. It is a “fact”. Right?

“A fact (derived from the Latin factum, see below) is something that has really occurred or is actually the case. The usual test for a statement of fact is verifiability, that is whether it can be proven to correspond to experience.”

Hang on, so I can only verify that Peru’s existence is a fact if it has proven to correspond to experience? Well I have no experience of Peru, other than the pictures, video, etc. that I’ve seen, so until I’ve actually got on a plane and gone to Peru can I be absolutely 100% sure it exists? If I’m really pushed may my confidence level only be 99.9999999%? I’m relying on other people’s proof and experience for me to be so sure that Peru exists. Rather like we rely on scientific understanding of the world to establish facts that would be impossible for us individually to verify (like gravity) and reject information that is not established as fact (like the existence of a higher being, intelligent design, etc.).

I don’t remember the instant when I first heard there was a country called Peru. Let’s assume as a child I heard someone mention it and I asked my parents “What’s Peru?”, to which my Dad answered “It’s a country in South America”. Now, my question here is: at the point my Dad told me of Peru’s existence as a country in South America, did I learn that Peru exists or did I simply begin to believe that Peru exists? I was a child so I was also told of Santa Claus and the Tooth Fairy’s existence. What made Peru’s existence more real to me?

Do I know anything?

To give a current, grown up example, I follow a gentleman on Twitter called Bob Marshall (@flowchainsensei) who, among his other achievements, created the Marshall Model of Organisational Evolution. In Bob’s words:

“Simply put, the Model explains how the effectiveness of any knowledge-work organisation is a direct function of the kind of mindset shared collectively by all the folks working in the organisation – managers, executives and employees, all.

effectiveness = f(mindset)”

Since I first learned of the Marshall Model’s existence (I observed it personally, and so can you with the link above, so can verify as a fact that the Marshall Model exists), I have read more about it, interacted with Bob on Twitter and blog posts and from all this have gleaned a genuine interest in organisational effectiveness (thanks Bob, if you’re reading this).

What’s also interesting to me though is how I have embraced the rightshifting concept to a point that I tell others about it. I now know not only about its existence but also what it tells us about organisations. Or do I? Bob came up with the model and so obviously believes, knows it to be a true reflection of organisational effectiveness. But when I read more and talked to Bob about it, did I learn more about the model or do I merely start believing more in the model? Do I now know that effectivness is a function of mindset, do I merely believe it or have I simply learned that someone else believes or knows it?

I have always felt in my career that there are certain types of organisation when it comes to culture and how they get things done, and certainly prosper more readily in, to use Bob’s model, the more rightshifted organisations. So is there a chance that when I saw the Marshall Model my cognitive bias leaned me towards the principles and helped me embrace it as observable and true? Or do I actually have evidence that the model is true and thus I have learned the model’s effects as fact?

My cognitive bias also leaned me towards Agile because the values and principles align with me as a human being. One might call this “mindset“. I coach Agile principles and practices and have observed certain behaviours causing certain results, some repeatedly. But all of my experiences and what I constitute as knowledge is all based on my own view of the work and the world. Without continued learning on everything I think I know about, even things I consider myself an “expert” in, I cannot be sure that I actually know enough, or will ever. For all I know, everyone else I encounter might think I’m a complete duffer when it comes to product development even though I think I’m quite good at it!

Learn to learn

We all use our knowledge every day in our work and our personal lives. I do think though that it’s very important to acknowledge that much of what we think we know may actually just be things we believe and have never actually verified them to be fact.

This is one of the many reasons why learning is the key word from the three used in the title of this post. We cannot know, even believe in something until we have learned about it. I learned about God as a child and started to believe in Him. I learned about Santa Claus and believed in Him too. But I never really knew that either existed. I certainly thought I knew (presents arrived on Christmas Day), but I didn’t. Unless we recognise that we must learn how to learn, then continue to learn daily, infinitely, we cannot purport to truly know anything.

What do you think you know?

(Definitions are courtesy of Wikipedia.)

Other

Other

What is Agile?

In preparation for my presentation at the upcoming LAST Conference, entitled “Being agile over buying Agile”, I decided to try and capture in a couple of simple diagrams what Agile is (or what it represents). When we strip back all the Agile stuff out there, how can we very simply describe the members of the Agile family?

There are many principles, processes, tools, methods, methodologies and practices that are given the Agile label nowadays, so it is in some ways unsurprising that there is so much confusion and misunderstanding. Well the good news is that the reality is far simpler. The term “Agile” refers specifically to the collection of knowledge captured in the Agile Manifesto. That’s it. Agile can be taken to mean so many things that many are overwhelmed by the sheer quantity of Agile “stuff”. But really it’s very simple.

It’s not just about agility (with a lower-case “a”). Team and business agility is indeed promoted via various facets of Agile (and Scrum, the most popular Agile product development framework) but is only a small part of Agile. However, Agile is represented by only 4 key statements (Agile Manifesto) and 12 principles (also described on the Agile Manifesto website), many of which are really saying the same thing. I posit that this diagram encapsulates Agile in its entirety.

For those of you who prefer bullet-points, here is Agile described in such a manner:

• Individuals and interactions over processes and tools
  • Business people and developers must work together daily throughout the project.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software over comprehensive documentation
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Working software is the primary measure of progress.
• Customer collaboration over contract negotiation
  • Simplicity–the art of maximizing the amount of work not done–is essential.
• Responding to change over following a plan
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Self-organisation
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
• Technical excellence
  • Continuous attention to technical excellence and good design enhances agility.
• Continuous improvement
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
• Sustainable pace
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

What about Scrum?

There is similar confusion about what Scrum is and isn’t and its place in the Agile world. Again, Scrum is a simple framework but is difficult to master, usually largely due to organisational challenges. The following diagram describes the key principles highlighted in the official Scrum Guide.

That’s it! I haven’t listed the roles and artefacts because these are generally well-known. What’s most interesting to me is why the principles of Scrum (and Agile) are often misunderstood and/or intentionally or unintentionally neglected by organisations attempting to adopt Agile/Scrum, leading them to trip up and not reap the benefits (or ditch Agile altogether).

Why is Scrum described as an Agile framework?

To answer this, let’s begin by looking at where Scrum and Agile principles align:

Daily interactions

Agile says: “Business people and developers must work together daily throughout the project.”

Scrum says: “Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated Increment in the remainder of the Sprint.”

Every Scrum team has a Product Owner who represents the business and customer interests. Scrum teams have a Daily Scrum, and it is implied throughout the Scrum Guide that the PO is a crucial and integral focal point for the team’s priorities.

Working software

Agile says: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Scrum says: ”Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.”

It should be noted that Scrum is not only for software development; it can be used for any kind of product development. However its iterative approach to delivery, when used with software, seems congruent with the Agile principle of delivering working software frequently. Scrum is conducted around Sprints of up to 4 weeks in length, and a product increment is delivered in each Sprint. Interestingly, while Agile has a “preference to the shorter timescale”, it deems it acceptable to deliver software every “couple of months”. Scrum explicitly states that 4 weeks is the maximum length of a Sprint because beyond that timeframe predictability suffers and risk increases. Therefore it can be argued that Scrum promotes faster delivery and feedback loops with the customer than Agile does.

Customer collaboration

Agile says:

“We value customer collaboration over contract negotiation.”

“Simplicity–the art of maximizing the amount of work not done–is essential.”

The simplicity principle can be taken to mean that constant customer collaboration will minimise the work done because only the highest value backlog items will be worked on in each Sprint. It may also refer to simplicity of design.

Scrum says:

“During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. This is an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.”

“The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.”

Responding to change

Agile says: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Scrum says: ”The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.”

Scrum allows the Product Owner to add new items to the Product Backlog at any time, as well as change the order of existing items. This means that new requirements, if they are deemed of high value or priority, can be scheduled for the very next Sprint.

Self-organisation

Agile says:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

“The best architectures, requirements, and designs emerge from self-organizing teams.”

Scrum says:

“Scrum Teams are self-organizing and cross-functional.”

“They [development team] are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;”

“[Scrum Master coaches] the Development Team in self-organization and cross-functionality;”

“The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint.”

“By the end of the Sprint Planning Meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.”

Technical excellence

Agile says: “Continuous attention to technical excellence and good design enhances agility.”

Scrum says: “The Development Team may also invite other people to attend in order to provide technical or domain advice.”

Scrum does not prescribe how the work will be delivered and thus does not talk about technical practices. Agile says that “technical excellence” is a good idea but is again silent on specifics. The conclusion we can draw from this is that the “Agile” technical practices we hear of such as TDD, BDD, continuous integration, continuous deployment, pair programming etc. are not really Agile practices at all, strictly speaking. There is no specific mention of them in the Agile Manifesto or the Principles. However, these XP practices are generally considered to be highly effective (even “best practice”) in software engineering and as such are congruent with the Agile principle of “continuous attention to technical excellence”. It is therefore considered wise for development teams to use some or all of these techniques when working within the Scrum or Kanban frameworks, not just XP.

Continuous improvement

Agile says: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Scrum says:

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”

“[The purpose of the Sprint Retrospective is to] Identify and order the major items that went well and potential improvements; and, Create a plan for implementing improvements to the way the Scrum Team does its work.”

“By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.”

Sustainable pace

Agile says: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Scrum says: Nothing specific about this, although the Scrum Guide does talk about the development team “forecasting” how much work to pull into the Sprint Backlog based on what they have delivered in the past. It does then seem that sustainable pace and the avoidance of “death marches” is very much an Agile principle, not Scrum (or at least is more prominent in the former).

Teamwork

Agile says: Agile mentions teams in the context of collaboration, self-organisation and continuous improvement but does not say anything else on the subject.

Scrum says: Everything in Scrum is about the team. Teamwork is described in the Scrum Guide as key to a successful Scrum implementation, particularly with regards to shared activities (cross-functional teams with no roles, sub-teams or titles) as well as the above Agile principles.

That said one could imply by Agile’s description of teams that they are referring to cross-functional teams. If a team is able to ship working software regularly then by inference they must have all the skills required to be able to achieve this, inferring cross-functionality.

Empiricism

Agile says: Nothing about this really. It does not mention estimation or the use of data for planning. It does put a focus on working software as the primary measure of progress but does not explicitly promote empiricism as Scrum does (inspection, adaptation and transparency).

Scrum says: “Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.”

Servant leadership

Agile says: Agile does not talk about leadership or management of any kind, whereas Scrum describes the leadership qualities required of the Scrum Master. It could be argued that Agile takes a more company-wide, customer-centric view of collaborating with “business people” and “users” (outside of the team), whereas Scrum focuses largely on the team’s interaction with the Product Owner and thus places more emphasis on the leadership required. Indeed the words “customer” and “user” (in the end-user sense) are not even mentioned in the Scrum Guide.

Scrum says: “The Scrum Master is a servant-leader for the Scrum Team.”

Summary

So it can be seen that there are several principles and practices that can be summed up fairly simply in Agile and Scrum. Most are intertwined but Agile makes a bigger deal about some and Scrum makes a bigger deal about others.

Many of the terms used today when talking about Agile are more Lean principles, such as building the “right thing” by validating hypotheses in the market. Feedback is considered crucial to Agile development but is barely mentioned. Agile and Scrum both seem to focus on the relationship with the customer or the business stakeholders and embracing changing requirements (which implies feedback is required) rather than making feedback the key factor.

Technical practices are covered in XP, which is considered an Agile framework (like Scrum) due to being iterative in nature and the focus on quality and technical excellence. Team practices such as pair programming, swarming, “stop starting, start finishing” are nowhere to be seen in Agile or Scrum. Nor is the term “the art of the possible”, which is often quoted as an Agile phrase regarding what can be done if you get people in a room and re-focus them on the higher purpose.

Process visualisation is also notable in its absence. Queue theory, activities, swimlanes, task boards, identifying bottlenecks, limiting WIP, etc. have more of a background in Kanban but are considered by many to be “Agile” principles or practices, perhaps because their implementation traces back to the key Agile Manifesto statements and principles.

Either way, what “Agile” and “Scrum” are is simple in some ways and complex in others. Some even describe them as philosophies rather than collections of frameworks, methods, processes and tools. They key point is that rather than getting too bogged down in what is and what isn’t Agile, let’s instead focus on our goals and how to get to them more effectively.

Other

Other

One of the things I love about the Melbourne Agile, Scrum, Kanban and Lean community (and indeed our global brothers and sisters) is that we are a group of like-minded (although we dissent and disagree to much positive effect), passionate folk who crave for improvement, love to learn and want to make the working lives of us and those around us as fun and fulfilling as possible.

We want to look after our people and delight our customers. We want to LOVE coming to work, not moan when the alarm goes off on a chilly Monday morning. We want to learn new techniques, new practices and new methods to help us and our colleagues become more and more effective. We think of people who do valuable work for an organisation at any level as PEOPLE, NOT RESOURCES. We want to live by principles and ethics rather than by rules and regulations.

What about me personally? Well, I cannot speak for the rest of the community, but I am not satisfied by the daily grind. I am not interested in coming to work, doing “my job” and then going home. I reject not having a passion for, or caring about, what I am producing. I do not want to be hindered in accomplishing things by reams of unnecessary and costly red tape, process and procedure. I do not wish to work with dispassioned, disengaged and unmotivated colleagues day in day out who complain about their jobs every day but do nothing to try to improve it because it’s too hard or because they fear being made an outcast.

This is why I personally love Agile, Scrum, Kanban, Lean, Systems Thinking and all of the wonderful knowledge work, principles, practices and community around these topics. And this is why I am excited about the upcoming LAST Conference.

How about you?

Other

Other

Introduction

Over the last couple of months I’ve really started to understand how important WIP (work in progress) limits are to an agile delivery process. Rather than getting too technical and talking about how cycle times can be derived with throughput and WIP (Little’s Law), or delving into some other, less tangible benefits of limiting WIP, I want to explain in plain terms why this practice is critical to enabling business agility.

The concept of limiting WIP is normally associated with Lean and Kanban principles but is often ignored (or misunderstood) as having anything to do with Agile. However, if you think about it, WIP limits are absolutely essential to allowing a business to respond to change quickly and change priorities for what work should be executed next.

Agile team? I think not…

If you think you are working in an Agile team, consider this: If the business owner walked over to your team area with an index card in her hand (or, more realistically, a value proposition in her head which you will hastily write down on an index card!) and asked how quickly it could be delivered into production, what would your answer be? Let’s assume that the team asks a few questions and breaks down the feature into a couple of stories, each roughly the same size as other stories they implement – so probably 6-8 days of work (if you don’t already know your team’s average throughput, start measuring it NOW!). With those assumptions in mind, do you know the answer to Gillian’s (yes, let’s call her Gillian) question? If you do, would the answer be days, weeks or months?

If your team had no other work in progress, obviously the answer would be 6-8 days. They can get started on it right away, so the predicted delivery time is equal to the time predicted to be expended on the feature. That sounds very reasonable, right? OK, what if the team currently had 3 other cards in progress (so 5 in total)? Continuing with our assumption of 3-4 days turnaround per card, we’re now talking 15-20 days. Still pretty reasonable I suppose. Now consider if your team had 10 other cards in progress (12 in total)? We are now talking about a 6-8 day feature taking 36-48 days to be delivered into production – that’s 7-10 weeks.

The emerging point from this example is that the more cards your team currently has in progress, the longer it will take a new, top priority card to be delivered into production. Therefore I would be so bold as to say that if you allow too much work to be started (thus in progress), your team really isn’t very agile at all. The whole point of agility (indeed, by its very definition) is to allow the business to be able to quickly respond to changes in the market and be flexible with its portfolio of work in order to deliver maximum value at any given time. Your “Agile” team – with its cards and columns on the wall, its burnup and burndown charts and its daily standup meetings – takes up to 10 weeks to push a new feature costing just 6-8 days of effort into production.

Scrum limits WIP

Those of you using the Scrum framework may never have considered the reason why scope is fixed within a timebox, and why the principle of “stop starting, start finishing” is so key. Fixing scope to what the team feel they can achieve (capacity) means that the WIP of the team at any given time is limited to the number of items in the Sprint Backlog, preventing the situation above.  i.e. it implicitly applies WIP limits. Any new priority card can be brought into the very next Sprint without having to wait for other queued-up cards to be implemented. This is one of the key reasons why Scrum is an excellent framework for promoting business agility when it comes to product development.

Summary

I hope you can see that if you’re not using Scrum (perhaps a pure Kanban approach), it is crucial to limit the WIP of your team. Even if you are using Scrum there are extra benefits to be had from implementing queue limits within the Sprint timebox (Scrum-ban), especially if your Sprints are longer than 2 weeks and you are employing continuous delivery.

It’s often tempting for a team to start new work rather than wait for a blockage to disappear (e.g. wait for the Product Owner to be available to accept a story), or for a manager to think they are doing the right thing by increasing the number of hours the team are spending working on deliverables (i.e. increasing efficiency). However, you must bear in mind that the act of bringing more work into play will increase the average time it takes a card to be delivered into production and put in front of your customers.

Sometimes, from the team’s point of view, it makes more sense to wait a couple of hours for the blockage to disappear rather than succumb to the temptation of filling your every hour with actual work. From the manager’s point of view, recognise the important of “slack” time and how it speeds up your delivery times.

Other

Other

Introduction

After a year or two of “having a hunch” about this, and after many years of either estimating work or working to someone else’s estimates, I’ve now finally come to the conclusion that the use of estimation of any kind in a project is not only a waste of time but is actually destructive.

I am fully aware this is an extremely controversial statement, so I am going to be as thorough as I can in explaining how I came to this conclusion via experience, data and validation. Indeed, when I read Duarte Vasco’s post about this several months ago, I saw his “point” (no pun intended) but also argued the merits of using story point estimation for the purposes of:

• Up-front sizing of a project to determine its validity within a given budget or timeframe
• Increasing shared understanding and knowledge within the team based on the discussions that arise from a Planning Poker session
• Allowing the PO to make trade-off decisions between different sized stories (based on ROI)
• Measuring team velocity
• To continually validate the initial project sizing by predicting scope-fit within a given release date
• To allow the team to measure and improve its performance

Why shouldn’t we estimate?

I have since come to the conclusion that some of these things do not need to be done at all, and the other things can be done without the need for estimating (guesswork) of any kind. I would now additionally argue that even if you acknowledge the shortcomings of estimation and use ranges, account for uncertainty, etc., the act of estimation in itself is destructive for the following reasons:

• “Fixed” scope project delivery expectations are often (always?) based on an up-front estimate of scope (guess) and how long that scope will take to be delivered (another guess), leading to the obvious dysfunctions like death-marches, low quality, etc.

If the budget is fixed, there is no way of going “over budget” in order to deliver the fixed scope. Yet “over budget” is a common term used when describing failed projects. If your budget is truly a constraint then you will only deliver what can be delivered. Agile methods ensure that what you deliver is of the highest value to the business.

I chatted to a team member earlier and he complained of feeling pressure to increase velocity. I asked him where this pressure was coming from and he said that it stemmed from the concern that the project will fail if the team isn’t able to deliver more stories more quickly. No one is actually specifically asking the team to deliver more, but there is an implied pressure to do so because they are aware the budget is running out. This mindset comes from years of poorly funded, gated projects, death marches, focus on productivity rather than quality and canned or failed projects.

• Asking teams to estimate how long their work will take (or how many points they will deliver in a Sprint or a Release, same thing) has connotations that their output is being measured by an external party (manager), creating an environment of fear and massaging figures to reflect what is desired rather than what is predicted

To increase velocity the team simply needs to over-estimate stories to give the illusion of delivering more. They may not consciously do this but it may happen sub-consciously. The project manager pats them on the back, but all that has happened is the same amount of “done” working software has been delivered.

It’s time to get real and use real data to reflect real progress, whether it’s good news or bad.

• We shouldn’t be defining all our scope up front, meaning we shouldn’t estimate all our scope up front, meaning we shouldn’t be defining our delivery date based on our scope

We should be fixing our Release 1 delivery date and aiming to build the best possible product by that date (variable scope).

As soon as we introduce the word “estimation”, the default mindset is to consider “how long will this project take?” (if this isn’t asked explicitly). This causes us to consider the complete scope and duration of the project (this is anti-Agile and I won’t go into why it’s a bad idea because enough has been written about that already elsewhere)

How do we size a project?

Short answer – you shouldn’t. If you don’t have a firm deadline for your project (e.g. day 1 of the Grand Prix for a Grand Prix app), you will have a budget for your project (set by the PMO or the external customer), from which you can derive a deadline. The smart thing to do is to then plan an interim release (say at the halfway point) where you can gauge how the project is going based on the working software measure.

For example, if your budget gives you enough cash for ten 2-week Sprints (given a fixed, 100% allocated team), clearly you need to assume that your go-live date is in 20 weeks time. But the aim should be to get working software in a production environment in 2 weeks time (after Sprint 1). You should then iterate over the product, allowing requirements (scope) to emerge and shape the direction the product takes, and take time to reassess after Sprint 5.

These things are not predictable up front – estimation will set you up with a load of scope (expectations) that will not get delivered and will only create unnecessary analysis time (money) and pressure.

How does the team get shared understanding of a story?

Simple. When a new item is added to the top of the product backlog, the team will discuss it in Sprint Planning and break it down if necessary. If it doesn’t need breaking down then it is likely already well understood. If it does then the act of breaking it down will necessitate conversations around the implementation detail that will facilitate shared understanding.

In short, the team does not need to be in an estimation session to discuss and break down a story.

How can the PO make trade-off decisions?

The PO probably needs to know the ROI of a story when introducing it to the team to be delivered. In order to calculate the ROI she needs to know how much it will cost to be delivered (how long).

Here a team would estimate the item using story points and then the PO, armed with the team’s velocity, can estimate the item’s ROI. But without story points how can this be done?

This is where the concept of “implicit estimation” comes into play. In order to create predictability in the flow of work, the team will break down stories just-in-time (in Sprint Planning) so that they are all roughly the same size. This is something that happens naturally throughout the course of the project. Over time the size of stories normalises because the team naturally wants bite-size chunks to work on in the short time period of the Sprint. They get used to delivering a certain number of stories, give or take, in a Sprint.

So for the PO to cost the item, she just needs to ask the team if it is understood or needs breaking down. If the PO considers it high enough priority she will want to introduce it in Sprint Planning so that it gets built right away, if it makes sense to do so. Sprint Planning is the place for the team to break down the story if required and decide if it can be delivered in the Sprint. If it can, the cost of the item is essentially 2 weeks of team wages (assuming production deployment is done at the end of the Sprint – a continuous delivery model can improve speed to market and ROI, but that’s a discussion for another day).

If the item can’t be delivered in the Sprint, the PO can simply look at how many stories have been spawned from the epic item and determine the likelihood of it being delivered in the next Sprint or the Sprint after, based on how many stories the team usually gets through. This leads me nicely on to the topic of how we measure velocity in the absence of story points.

How do we measure velocity?

Now I’m moving firmly into Duarte territory. The answer is we count stories rather than accumulate story points, hence negating the need to estimate. As I mentioned before, teams break stories down into roughly the same size, so counting how many stories are delivered in each Sprint makes for a satisfactory measure of velocity. If the team usually delivers 5 stories with zero defects and then one Sprint delivers 6 or 7 stories with zero defects, an improvement has been made (disregarding variance, which exists whatever unit you use to measure velocity).

Due to the hunch I mentioned earlier, I have been tracking velocity as both story count and points for my current team and making projections using both methods. As I suspected (and as Duarte points out with much supporting data), story count provides just as good, if not better a measure of progress and predictability as story points do. Therefore why spend all the time, cost and effort on estimation sessions and velocity calculations?

While story count works great for velocity, I would still warn against using this or any other velocity measure as a way of predicting when you can deliver. You should know when you are delivering and only be predicting what you can deliver at that date. Don’t leave your delivery date to chance, even if you are using historical data rather than guesswork to predict how many stories can be done.

What you can do, however, is use velocity to help the PO understand scoping trade-offs in the backlog (“the data tells me the team can deliver 20 more stories before the release date, so I’ll make sure the most important 20 are at the top of the backlog“).

Conclusion

It’s taken me several years to come to this conclusion. But, if you think about it, people laugh and joke about estimates all the time. Everyone knows they’re a guess. Everyone knows they’re wrong. Yet we continue to do them. I believe it is time for us to acknowledge that it makes far more sense to eliminate the risk and cost of estimation completely and use only empirical data (as Agile and Scrum promotes) to make predicitions.

In a world without estimation overhead the team is likely to be more happy and productive, the inefficiency of spending time on estimating rather than delivering working software is eliminated and the PO will have real data with which to make decisions rather than guesses made under pressure.

To summarise:

• Don’t estimate your delivery date – base it on your budget or a firm deadline
• Don’t estimate your scope – allow it to emerge in order to reap the benefits of building products with agility
• Don’t explicitly estimate product backlog items (stories)
• Use historical data (story count) to predict scope delivery on a given date
• Use just-in-time implicit estimation (story breakdown in Sprint Planning) and past data to estimate cost (ROI) of story delivery

I don’t like to guess, but I predict that not estimating your projects will make success far more probable

Other

Other

The misunderstanding that the MVP is a “barely good enough” version of the “full” product is widespread and completely wrong. It’s not about putting out a half-arsed product. The point is you do not know what your “full” product actually is, however innovative you think your idea is or how well you think you’ve defined features that you think will make the product as good as it can be.

Building an MVP is about validating your assumptions around the benefits you believe your product will provide to its intended user base (and, indeed, whether your intended user base is actually the right user base – early adopters are often from a completely different demographic than your original assumptions suggested).

The word “viable” is key. You need to identify the “killer” features that fulfill the product vision and then focus only on those features and making them extremely compelling (indeed, they should be kick-ass!) You should think of the MVP as a *full* product with the minimum feature set that meets the innate customer need – the other ideas for features that you brainstormed are not validated as viable and may never eventuate, so don’t waste time thinking about them until they are validated.

The first iPhone is the perfect example of an MVP. A brilliant product, lacking the features that the new iPhones have but, crucially, it was a full product in its own right. Apple didn’t spend time and money packing every feature under the sun into it. They focused on the killer features and did them spectacularly well.

Google is another example of a well executed MVP. The original Google search engine was simply a text box in the middle of a white page with a search button an a Google logo. However, the killer feature of allowing users to easily find relevant information on the internet by searching was all they focused on, and they did it brilliantly. It was not a half-arsed product. The point was that the future direction of the company was dictated by validated learning in the market rather than simply building features that they thought were a good idea. If they had spent time on worrying about an integrated experience with Google Maps, Gmail, Latitude, etc. they would never be where they are today.

Think about the products you love today, and then think about all the features in them that you never use. Think about the core reason you use them – the innate needs you have and are trying to fulfill. If you’ve got a fantastic idea for a new product, make sure that your first release is minimum in feature set but maximum in feature awesomeness. This is what building an MVP is about. And maybe you will be able to sell your brand 18 months later for $1 billion too!

Other

Other

I’ve just watched a presentation that’s made me so angry it’s prompted me to write my first blog post in ages! Sorry I’ve been away so long

I’m not a fan of the “Scaled Agile Framework” to say the least. Dean Leffingwell is in on this, a man who I generally find myself agreeing with. However this framework is a horrible, pure money-making bastardisation and Frankenstein of Scrum, Agile and Waterfall that is being sold to large companies who are too afraid to really change and just want to increase productivity, reduce defect counts, etc. and find a place in the “Agile” world for their managers.

The whole concept of iterating over a product rather than simply incrementing features is fundamental to Agile and Scrum but completely bypassed with this framework. Continuous delivery in order to tap into the market as early as possible and adapt the product is ignored (instead a 2-day release plan is held in which all the features the PM wants done in the next 10 weeks are broken down into user stories and put into Sprints – yuk).

There is even a “hardening Sprint” which is a fancy term for a 2-week phase for bug-fixing and deployment activities because companies “really need it” (read it’s too hard to truly get things “done done” so we’ll leave time for it at the end – of course “the end” is a deadline date based on an estimation of how long all the features will take to build – i.e. guesswork around fixed requirements – ring any bells?). Yuk yuk yuk!

Scrum scales perfectly well without this framework, thank you very much! Each product has a backlog, which is derived from an overall program backlog at the portfolio level. Each product has 1 to many synchronised teams – done! Why synchronise the whole frigging organisation’s product development?! Yeah like that will work. Means any one team can’t adapt their process because it’s locked in to the organisation’s “Agile” framework.

Scrum-at-scale is far better because it holds true to the founding principles of Agile and Scrum but also allows hundred of people to be working together towards a common goal. If the business needs to change program priorities then they can do because they are doing Scrum! Simply cease work (if required) on the product or work stream that is being moved down the backlog at the end of the next Sprint and start the team (or a different team) on the new product.

Rant over – for now! Be interested to hear what others think.

Other

Other

Prioritisation is a technique for establishing an order for the work to be completed that provides the business with the most important things first. Unfortunately, the MoSCoW (“Must have”, “Should have”, “Could have”, “Would have”) method usually results in 85-95% of “Musts” which effectively renders the process redundant. If we assume that we will only release the software once the key business stakeholders are happy that the critical features are present then it is more effective to regularly order the backlog rather than simply apply MoSCoW. The “Musts” will become apparent as the software evolves and people are actually using it.

Follow these steps every couple of weeks or so to make sure that you have a nicely groomed and ordered backlog to feed into Sprint planning or your Kanban queue:

1. Get the Product Owner and any other stakeholders that have input into business priorities into a room
2. Explain that the meeting is timeboxed to 30 minutes
3. Reassure everyone that while you will be asking them to perform some tough prioritisation decisions, the exercise is not about moving requirements out of scope – it is about establishing a priority order to allow the team to deliver maximum business value
4. Lay out the product backlog index cards on the table (if you have more than 40 items on the backlog then generalise some items into epics or themes so that you only have 40 or less cards with you)
5. Ask the participants to split the cards into two equally sized columns – priority 1 and priority 2 (if you have an odd number of cards then allow them an extra card in the priority 1 column)
6. Once this is done, rename the priority 2 pile as priority 3 and put aside
7. Now repeat step 5 for the priority 1 cards
8. You should now have 3 columns (in priority order) of cards, with no more than 10 cards in each of the first two columns
9. If you still have time, you can now ask the participants to order the priority 1 cards – this can be quickly achieved using a bubble sort technique
10. Ask the participants to choose between the top 2 cards – if their choice is the 2nd card then swap it with the 1st card
11. Now ask them to choose between the losing card and the next card down – again, swap if necessary
12. Repeat this process until the 30 minutes is up or until the participants are happy with the order

Example bubble sort of numbers:

7,5,9,3,1,4,10,8,2,6

1st sort: 5,7,3,1,4,9,8,2,6,10

2nd sort: 5,3,1,4,7,8,2,6,9,10

3rd sort: 3,1,4,5,7,2,6,8,9,10

4th sort: 1,3,4,5,2,6,7,8,9,10

5th sort: 1,3,4,2,5,6,7,8,9,10

6th sort: 1,3,2,4,5,6,7,8,9,10

7th sort: 1,2,3,4,5,6,7,8,9,10

Good luck and happy prioritising!

Other

Other

1. Identify high level requirements (epics and stories) and size them XS, S, M, L or XL (T-shirt sizes) so that each story in each category is roughly the same size (in terms of effort) as the other stories in that category
2. Ensure that the XS stories are extremely small pieces of work that cannot be broken down any further (like a 5 minute change to the system) – if you do not have any of these, break down the S stories to ensure you have both XS and S stories
3. Now have the project implementation team (i.e. devs, testers, analysts, etc. – not product/project managers) perform Fibonacci Planning Poker estimates (1,2,3,5,8) for 5 stories in each of the S, M, L and XL categories (we will assume all XS requirements are 1 point)
4. If there are less than 5 stories in a category, or not many more, simply estimate all the cards for that category
5. L or XL stories that are larger than 8 points should be made XXL and re-estimated including the 13, 21, 34, 55 and 89 point cards
6. If you have estimated all stories in a category, simply total the points for that category, otherwise total the points for the 5 stories you have estimated, divide by 5 and then multiply by the total number of stories in the category (we can do this because we determined that the stories in a given category are roughly the same size)
   e.g. 10 S stories, 5 estimated = 2,3,3,2,3 = 13/5 * 10 = 26 points
7. Simply add the point totals from each category to give you your project total
8. Now the team should decide roughly how many points they can complete in a Sprint in a pessimistic to optimistic range, e.g. 20-30 points
   (this part is less than ideal because the real velocity will be established once the team starts the project, and thus the estimate will become increasingly accurate as the team’s output becomes more predictable and scope changes emerge – however, it is a reasonable baseline)
9. Estimated no. of Sprints = Total Points / Sprint velocity
   e.g. Total points = 320
   320/20 =  16 Sprints
   320/30 =  11 Sprints
10. Take the mean of the range to form a final guess at the number of Sprints required to complete the project (in this case 14 Sprints +- 21%)
11. As the project goes along remember to adjust the total project size by adding/subtracting points when the initial estimates are adjusted (or stories are added or removed)
12. Now the projects’ progress can easily be tracked be “burning up” points completed against total project points
    e.g.  After Sprint 3, 50 points have been delivered and total project scope has increased to 340 points
    % project complete = 50/340 = 14.7%
    Total expected Sprints = 3 / 14.7% = 20 Sprints (> 16 Sprints)
    ==> OFF-TRACK, consider removing scope or delaying launch

Happy estimating and good luck with your projects!

Other

Other

The term “business value” is bandied around a lot these days when talking about the benefits of Agile software delivery. Agilists argue that more business value can be achieved through Agile than through traditional methods such as Waterfall.

But, what exactly are they talking about when they say “business value”?

I would define business value as something which is of potential short, medium or long term benefit to the business by means of increasing customer happiness and/or ROI. It doesn’t necessarily pertain to revenue or profit, at least in the short term. Sometimes you’re just trying to build a user base of people who love your product before you think about monetising it.

I would say you are more likely to deliver functionality that provides business value by working in an Agile way. One reason for this is that the time between someone having a marketable idea and that idea becoming part of functioning software is far shorter in an Agile project than a Waterfall project. In fact, in a Waterfall project marketable ideas do not really have the opportunity to come to the surface at all because all requirements and design are defined up front, and even if you push a change through the change request process it still could be months before the idea gets built and put in front of users.

In an Agile project users will get their hands on the product very early so will be able to provide lots of input into the product’s evolution, and this input can turn into software updates very quickly. Thus the chances of ending up with a product that no one uses are far lower.

In short, by building things incrementally and iteratively it is quicker and easier to identify emerging business value.

Other

Other

I hear, read and observe this a lot. About the Product Owner (PO) not having the “day-to-day availability”, and so therefore someone else is working with the team as a go-between (usually a BA, sometimes an iteration manager, ScrumMaster or tech lead).

My reaction to this is simple – if the person being referred to as the PO doesn’t have time to fulfill the PO duties as part of the Scrum team then they shouldn’t be the PO. The role of the PO is very clear – they must be at Sprint Planning, they must be in charge of the backlog, they must be available to answer day-to-day questions from the team and they must shield the team from the stakeholders so all requirements gets funneled through one person.

In reality the PO role is the most problematic one in “agile” companies, or those trying to transition, because companies are not willing to assign it correctly. Instead they assign a BA to the team and expect them to do the PO role, but minus the empowerment and authority required. So the BA ends up continually having to run around getting answers from the PO (who doesn’t have day-to-day availability) and making decisions on the ground that may not be congruent with what the PO actually wants. Believe me, I’ve been there. It doesn’t work very well.

Solution – the PO must make time to be the PO. If they cannot, they must accept that they are not the PO and give full empowerment to someone else to be the PO. If an agile BA, who knows the product vision well, makes sense in this situation then that’s fine, but they must be allowed to be the go-to person for the team, to make day-to-day decisions with the team on priorities, implementation choices, etc., and not to have to constantly confer with the PO to “get shit done”.

Other

Other

In my job search I often see “agile” roles listed such as “Iteration Manager”, “Agile Project Manager” or “Agile Delivery Manager”. My question is: does the manager role, or even the word, have any place in a truly agile software delivery space?

For me, one of the key principles of agile is the removal of false hierarchies when it comes to “getting shit done”. Simply by having the word “manager” in the job title it implies the old-school command and control style of leading. The truth is, delivering software in an agile way does not require a manager, as such. Small, focused, cross-functional delivery teams that include a product owner and a ScrumMaster will “manage” all aspects of the delivery of the product by means of communication, collaboration and working together as a tight unit, whilst promoting both inward and outward visibility.

The term “iteration manager” in particular concerns me too because it usually indicates that the business is running a form of Scrumbut, where Scrum has been bastardised into a hybrid methodology that may have iterations (we mustn’t call them “sprints”!) but has perhaps lost some of the key scrum principles. It seems that Australian businesses are afraid to embrace Scrum in its vanilla form and specifically recruit ScrumMasters.

The ScrumMaster role is clearly defined, as are the other roles in Scrum, and this is why I favour vanilla Scrum, particularly in transitioning companies. When pointing the business to why you are doing things in a certain way, you can simply point them to numerous Scrum resources such as the Scrum Guide. By doing a hybrid methodology, it is a lot harder to get buy-in because the role descriptions have been refined from true Scrum roles.

Agile is about working together, valuing each other’s roles and responsibilities as equally important in getting the job done. It’s about servant leadership, not command and control. It’s about mutual respect, learning, improving and humility in one’s own abilities.

Don’t get me wrong, it’s terrific that more and more companies are trying to hire people with agile values and experience. However, when looking for really good agile people it’s important to look at the job title and description and ensure that it really is the agile role that it is implied to be. True agilists do not like terms like “manager”, “project”, “control”, “resources” (when referring to people), even “iteration”.

Other

Other

When I was operating as a BA for one particular company, so much of my time was wasted chasing product people for answers and getting different views and priorities depending on who I spoke to (the other BA’s faced exactly the same issues). Sometimes people didn’t show up for meetings, or were really late and unprepared. Sometimes they hadn’t read the necessary documents/emails (or at least had not provided timely feedback on some of the crucial ones). No one seemed to want to make a decision in case it came back to bite them.

There should be a single product manager/owner for every product who:

• Is a single point of contact for all questions and decisions around the product
• Is capable of articulating the product they want
• Understands the company vision and priorities and ensures that the desired product fits into these
• Understands the two-way commitment and trust relationship required with the team enlisted to develop the product
• Takes on board feedback from other stakeholders but ultimately is the single-point decision maker
• Is fully empowered to make decisions about release dates and features and not be usurped or undermined by anyone, including upper management (i.e. all other stakeholders, including CEOs and company owners, need to step back and trust/empower their product managers to deliver the kind of product they want within reasonable timeframes, and not get too involved in the detail or change direction over the head of the product owner)
• Is available to the team at all times for estimation, planning and other key iteration meetings, to answer questions and to make decisions (i.e. ideally on site)
• Listens to the team’s opinions on the products (there are often fantastic ideas circulating around the company that do not get listened to – why not set up an ideas Wiki to address this?) and advice based on their technical expertise

Unrealistic expectations regarding dates and features

• Often the delivery dates bandied around are seemingly arbitrary. Make sure delivery deadlines mean something, otherwise why should the team trust the business that all their effort is worthwhile? It’s one thing asking people to bust a gut for a particular date if something important is happening on that date, but PO’s or other stakeholders often seem to push for dates just for the sake of it. If that’s not true, this has to be communicated to everyone.
• Common sense dictates that a PO cannot say “here are all the features I want and here is the date I want it on” – the maths won’t always add up so there needs to be negotiation on either scope or time right from the start of the project (quality should be fixed). You’re much better off focusing on delivering working software with the key/killer features and release iteratively, making improvements along the way. You’re destined for disappointment if you make a date the key factor.
• The way to get software to market quicker is not to tell the developers to work harder – it is to sort out the information channels into the teams. Single product ownership is key here, as well as allowing teams to focus on one product and platform at a time. Also, make sure that there is a relaxed and fun culture in the company to get the best out of your workers. Often companies allow a strange atmosphere of doom and gloom to fester, especially when false deadlines are missed, and this has a very negative effect on people. No matter what the situation is in your company, there is a lot to be optimistic and positive about, and staff will respond to such an atmosphere and become more productive.

Lack of product direction/vision

• Make sure the PO’s are giving you answers. Don’t settle for “can’t we just do x” or “let’s just do an interim solution for now”. Often all it takes is a 1-hour workshop to save thousands of dollars of wasted development time on a short-term bandaid fix that will need to be changed at some point soon. Getting product direction too late in the day always increases the risk of not delivering on time.

Business needs to listen to the technical people

• Often software companies have excellent technical people and people whose daily lives are spent developing the products. Their voices should be heard and respected when talking about technical issues and about what they think constitutes a good product. If the developers don’t think the product is good then you potentially have a dud product.
• PO needs to listen to advice from the technical team. It is not always the dev team’s fault! The PO’s should be held accountable too. The truth is, the technical team are the subject matter experts on delivering software. The PO’s should be telling them what the product is and they should be entrusted to deliver it in the best way they see fit.

Real world Example

This is an extract of an email I sent to the CEO explaining the dysfunctional situation we were facing. I have changed the names of people and products and edited content where necessary. Bob is the PO and Trevor is the company owner.

We explicitly explained to Bob and others at the product inception of SuperDuper that the best chance of having a working product on the 29^th would be to focus on making the cricket version have exactly the same basic game rules and mechanics as the previously implemented basketball version and then add on any required feature changes if they still make sense after doing some user testing.

This was the right way to go for a number of reasons, not least because Trevor wanted a consistent product that could be rolled out quickly across sports. This advice was ignored. We then re-iterated the advice coming into iteration 2 and said there was a risk of not having a working product if we changed the game rules. The business chose to ignore this advice and even started to think that we were deliberately refusing to develop the requested feature because it was too hard. Nonsense. What we were saying was that no one could know whether the feature was good or bad, it made the product experience across sports inconsistent and it created technical complexity in the codebase, therefore we’re better off delaying the decision to do it until we’re absolutely sure that it is a feature that players will respond to and like. Basically we were offering Bob a working game and he chose the risky option of developing a feature that was only good in one person’s opinion. Yet the team was asked to perform miracles now to meet the date.

Lack of business visibility

 The teams do not know what is going on in the business. Are we a mobile company or an all-platform games company? What are we aiming to accomplish in the next 6-12 months? What are our revenue models? What marketing are we doing? No one on the floor can answer these questions, and we never get straight answers from the business. This visibility is critical for a successful company that wants motivated staff who care about delivering games and take pride in what is delivered.

Lack of capacity

•  There are not enough people to do the amount of work that exists. New people are trickling in but new developers need a few weeks of ramp-up time before they can become fully productive.
• In terms of this product team, we had 6 full-time developers when doing the cricket game and now only have 3-4 (we’ve had a guy on paternal leave, people sick and the dev lead busy dealing with an outsourced dev team). We lost 3 good devs from our team after delivery of the cricket game, all key team members. We have one new guy replacing them. This not only reduces production capacity but also makes it impossible to predict velocity (and thus accurate estimates of delivery dates for a given set of features). We need consistent teams in place which will become better at estimating and increasingly predictable the more iterations they work together.

There are many other issues I could go on about (largely political) but this blog is already long enough to give you a flavour of the things we’re facing. The good news is that I believe they can be fixed, and I will continue to voice my opinions and do whatever I can to make it happen.

I’m happy to discuss any of this in person and offer any more advice as to how we can get everyone in the company on board with the same vision, priorities and plan for knocking out quality, fun games quickly.

Other

Other

I want the world in 6 days!

DDD is a reality of every business but should not be because it creates false expectations, unnecessary pressure and panic. Read more

Other