Scrum & Kanban – Different, But Compatible, Strokes For Different Folks

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.

Should We Get Rid Of The Product Backlog?

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.


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.


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?

Learning, Believing, Knowing – Does Peru Exist?

“Learning is acquiring new, or modifying existing, knowledgebehaviorsskillsvalues, 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 factsinformationdescriptions, or skills acquired through experience or education.”

I was pondering this morning about the difference between LearningBelieving 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 learnthat 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?

Should We Estimate Software Projects… At All?


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“).


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 🙂

The Horror Of The Scaled Agile Framework

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 meeting 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.