We Have Come To Deliver Value!

The Agile Manifesto, in my opinion, is a decent document. By no means perfect, but still pretty good. I happen to interact a bit with a few of the principles on social media, and I get the sense that if they had written the document today, they might use different language in some places. But I could be completely wrong about that. Nonetheless, the Agile Manifesto is a pretty good and useful document that anyone interested in Agile should pay close attention to. (Many close “Agile” friends disagree with me on this point – they are all wrong).

Why should we pay attention? Because I believe that wrong, yet popular, interpretations of certain principles leads to some confusion. Case in point, most people I speak with, would have you believe that an Agile principle is “we deliver value.” That sounds like something any reasonable person would want to do. Never mind that the concept of “value” is a bit nebulous. Ron Jeffries, in his book, The Nature of Software Development, defines value as “what we want.” Well, who is “we”? Mark Schwartz, in his book, The Art of Business Value, makes the case that business value can be tricky to define. (Both great books by the way. If you don’t you own a copy; I’m not sure what you’re waiting for!)

The point is that value is hard to define. Value might not even be a fixed target. You know, complexity, double-loop learning, and all that jazz. For example, in an Enterprise IT setting where team members develop internal tools for other team members to use as part of the business processes, how would you define value? Where is the value created? When is it created? Who is the value created for? All great questions that require answers if we’re going to walk around telling people we “deliver value.”

But here’s the catch. The Agile Manifesto says something slightly different from what I hear people say. This is what Principle Numero Uno says:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Wait a second. Valuable software? Hmm. Is value shorthand for valuable software? Is that what people mean when they say they delivered value? Is that what you mean when you talk about value? Not in my experience. I think people have grander aspirations than valuable software. I think they’re thinking outcomes and impacts. I’m thinking it too. In fact, I’m not just thinking about it, I’m writing about it. I want the software I develop to help my organization achieve desired outcomes and have the intended impact. But does software have to create value (whatever that is) before we consider it valuable?

In my opinion, valuable software is software that people find useful or helpful. It’s software that is important. It’s software that makes those who use it more effective at their jobs. It’s software that’s beneficial to the organization. (Yes, I did use synonyms of valuable). It’s software that addresses the needs of the stakeholders. We know our stakeholders, right?

Valuable software may not always (at least not immediately) create value (desired outcomes and impacts) because value is impacted (excuse the pun) by many variables, many of which have nothing to do with software. In other cases, valuable software delivered is not intended to create value (as we often define it). And yet in other cases, connecting software delivered with value is near-impossible or at least extremely difficult.

Just because we can’t easily tie software changes to business value doesn’t mean we shouldn’t care about outcomes and impacts, we should. Our processes should give us confidence that our valuable software will eventually create value. But we can’t wait till it creates value to consider it valuable, can we? I don’t think so.

So what do we do in the meantime? I suggest we focus on delivering valuable software.

Advertisements

Are We Done Yet?

Recently, there has a been a bit of talk about being done in the context of Agile software development.  If I’m not mistaken, as far as Agile frameworks go, it would seem that the Definition of Done as described by Scrum influences many an Agile team. We also know that there are variations on this as well such Done-Done and Done-Done-Done.

But when are we really DONE?

In some regard this depends on how we define done.  Is a movie done when production is over?  Is a presentation done when the slide deck has been prepared?  Is a meal done once it has been cooked?  Is a software increment done when coding and testing are complete?

Teams engaged in real (there is a lot of fake and dark Agile out there) Agile software development are guided by a set of 4 values and 12 principles.  The very first principle in the Agile Manifesto goes as follows:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

When we use this principle to guide how we define done, I cannot understand how we can consider ourselves done until we’ve delivered an increment of value to our customers. Not just deployed (and hidden behind feature toggles or something like that) but delivered such that our customers can interact with the increment in some form or fashion.

So the next time your team debates whether you are done, ask yourselves if your customers are using the increment.

(Thanks to Mia Augustine for inspiring this post).

P.S. IMHO Scrum’s Definition of Done (in the best case scenario) is really (more appropriately named) Definition of Ready To Be Delivered.

Tips For Working Without Timeboxes

My previous piece on timeboxes led to a fair amount of dialogue on Twitter.  Some of it was positive and some of it was critical.  However, a particular tweet (that led to some back and forth) stood out to me.

In the absence of “real deadlines”, do we need to timeboxes to rein in our development teams?

As promised in the previous post, I’d like to share some approaches that teams I have been on have used to reduce their dependency on timeboxes.  I do want to be very clear that I have also used these techniques in conjunction with timeboxes.

Ruthlessly Delivering Small Increments Of  Value

Regardless of whether you use stories or not (all our work does not have to be represented as stories), I will encourage you to decompose your work into small bites of customer value.   The INVEST method (associated with user stories) is a good guide to use. Each ‘increment of value” should take a few days to complete. 

There is a common misconception that I often encounter which suggests that the bites of value a team works on should be exactly what will be “released” to the customer.  I believe this to be a grave mistake.  Let me illustrate with a common example.

Imagine a team is developing an API that supports GET, PUT and POST as methods.  Let’s also imagine that the team decided the API will not be made available to customers until all three methods are implemented.  Should this be treated as one bite of value or three bites of value?  Most technology folk I know will argue that it should be one bite of value because it will not be released until all the methods are supported.  I probably would have argued for this earlier in my career as well.  Well now I beg to differ.

It is clear (at least to me) that there are least three units of value available with this API and while it is true that all three methods need to be implemented before the API is made available, each method can independently be developed and validated for proper function. If each method was treated as its own “story”, we’d find that each story meets INVEST criteria.

But what difference does it make?  After all, nothing will be released until all three methods have been implemented.  That is fair point.  And yet I’m compelled to ask the following questions:

  • Why would we delay (internal) feedback on the first method just because the second and third methods haven’t been implemented?
  • Why would we couple the the release of value with deployment?
  • What if it so happens that we learn that we can release the API progressively?
  • Why would be knowingly limit the options of how we approach the work?

As I learned many years ago, “bite small, chew fast”.  There are many tips on how to split/slice stories.  Google is our friend.

Limit Work-In-Progress

Timeboxing, done right, helps us to be extremely selective about what we want to accomplish in a given timeframe.  We take the time to understand the capacity available to us and then select the most appropriate work that we think we can get done in that time period.

The good news is that we shouldn’t require a time constraint to explicitly limit our work in progress.  It’s a proven fact that the more work we have going on concurrently, the less we actually get done.  Unfortunately many organizations don’t pay attention to how much they have going on and instead attempt to ensure that they are operating near 100% utilization which invariably slows things down and ensure.  Teams are primarily rewarded for how busy they look.  I see many Product Owners struggle with limiting work in progress.

A word to the wise about limiting work in progress. If we don’t limit the size of the unit of value as well, we’ll still be working on items for an extended period of time with little to show for it.

Quantifying Desired Product Qualities

I am a fan of the work of Tom Gilb, EVO and Planguage.  If you’re not familiar with any of these, you should probably look them up (and also watch this talk by Tom).  I believe that there are ideas from Tom’s work that can be of help to those of us in the business of developing software products..

For example, when we say that our API should be fast, what do we mean by fast?  Or when we say that the website should handle a lot of users, what do we mean by a lot?  These are qualities that our solution is supposed to have that are often simply described in qualitative terms.  Qualitative attributes leave up to the imagination of whoever is responsible for ensuring that product has the desired quality.  In the absence of explicit quality attributes, teams succumb to pitfall of gold plating.

Specifying in quantitative terms what “goodness” will look like is critical if we want to stay focused and avoid going down rabbit holes.  One could argue that this is the Specific (S) and Measurable (M) from SMART Goals applied to our work items.

In summary, while I’m still a fan of using time boxes, there are ways of working that can reduce the dependency of a team on explicit timeboxes.  Regardless of whether you use timeboxes or not, you will still benefit from adopting these techniques as you do your work.

Should A Scrum Master Have A Goal To Make Themselves Unneeded?

It has become quite common to come across articles or posts that state that the goal of a Scrum Master should be to make themselves unneeded or as a colleague recently put it, “put him or herself out of a job”.  I disagree.

The role of the Scrum Master is clearly defined in the Scrum Guide.  To summarize, the Scrum Masters provides service and help to the:

  • Product Owner
  • Development Team
  • The Organization at large

Suggesting that the goal of the Scrum Master is to make themselves unneeded is to suggest that the Scrum Master should be focused on either ensuring that (a) the services they provide are no longer needed and/or (b) someone else besides them provides these services.  In other words, ensuring that they are temporary!  In my opinion, this completely misses the point, is an unnecessary distraction and a potential source of much frustration.

The goal of every team member should be to make a contribution to the team in support of its quest to be successful and this includes the Scrum Master.  The goal of the Scrum Master should be to provide the help needed so that the team can effectively and efficiently deliver software that is valuable.  It is not to make themselves unnecessary.

How about coaching? Is that a permanent thing?  The Scrum Master coaches three distinct groups and even if the Product Owner and Development Team arrive at a point where they no longer need coaching, I’m not convinced the “Organization at large” in a complex environment (ever) arrives at such a point.  Never mind that the Scrum (Agile) body of knowledge continues to evolves, rarely ever does the system remain the same.  If you know of any organizations that have arrived at such point where they could no longer benefit from continued coaching, please feel free to share.

But for grins and giggles, let’s agree that it is actually quite possible for an organization to get to the point where (a) the help provided by the Scrum Master is no longer needed or (b) other roles in the organization can effectively and efficiently provide this help as it changes (because it will change).  In my opinion, this then is simply a by-product of the Scrum Master’s continued service to the organization and is not a goal that is defined upfront.

And yet, if you insist that the goal of the Scrum Master is to make themselves unneeded, then I have a book recommendation for you.  Check out  Obliquity: Why Our Goals Are Best Achieved Indirectly.  It might be beneficial to you on your journey to make yourself unnecessary or unneeded.

Thoughts on “Managing” Software Development

I’ve written in the past on management and managers and you can find some of those thoughts here however I want to share some additional thoughts.  These thoughts are basically my answer to the question of: what does a Software Delivery/Development/Engineering manager do?

(Even if you’re one of those who believe managers are not needed in knowledge work, I’ll crave your indulgence to read on).

(I do believe that Software Development/Engineering Manager are better role names than Software Delivery Manager but I digress).

It is dangerous to define the job duties of a role without taking into consideration the guiding philosophies of an organization.  For example, let’s just look at the concept of the manager. The definition of management (and hence managers) in an organization that adopts the principles of Frederick Taylor will be markedly different from that of an organization that adopts the principles of Edward Deming.  In other words, roles are not defined in the abstract.  The organizational philosophy ultimately defines the role.

I belong to the school of Deming when it comes to management, and as a result, my definition and description of a software delivery manager is going to be based on Deming’s view on management and managers.  I posit that real Agile and/or Lean organizations take a similar stance.

A software delivery manager is a “manager of software delivery” and if we decompose the role into its component parts we have manager and software delivery.

Douglas McGregor basically describes the Taylorist manager as person who works with the assumption that:

…workers have an inherent dislike of work and hence needs to be directed, controlled and threatened with punishment in order get them to work hard to achieve company objectives  

The Taylorist manager is all about control and external direction ergo this manager focuses on defining how the work should be done by the individuals on the team and then measuring individuals to ensure they are meeting pre-determined targets the manager defined.  This manager leaves little room for individuals and teams to self-direct as these managers need to do all the planning and provide all direction.

So how does Deming describe as the role of the manager?  According to Deming (excuse the gender-specific tone), a manager:

  1. Understands how the work of the group fits with the aims of the company. He teaches his people to understand how the work of the group supports these aims.
  2. Works with preceding stages and following stages
  3. Tries to create joy in work for everybody
  4. Is a coach and counsel, not a judge
  5. Uses figures to help understand his people
  6. Works to improve the system that he and his people work in
  7. Creates trusts
  8. Does not expect perfection
  9. Listens and learns
  10. Enables workers to do their jobs

Deming is not alone in his thinking.  Other management thought leaders such as McGregor, Drucker, Ackoff, and Senge all share the same thoughts.

If I were to summarize, I would say that the role of the Agile (and some would say modern) manager is to:

Create an environment where people and teams can do their best work for themselves and the organization in a manner that is both rewarding and fulfilling

The modern manager realizes that s/he is dependent on their team to be successful.  The team is also dependent on the manager.  In a nutshell, the team and the manager are interdependent.  The manager and the team share in the responsibility of developing and delivering software.

(If you work for an organization that says they are Agile and but exhibit Tayloristic management tactics, I hope for your sake that the organization is in the early stages of Agile cultural adaption.  If they aren’t, you’ve been warned).

So we’ve defined manager but how about software delivery? Software delivery is simply the aim of the system that the manager and their team(s) belong to. This system has the goal of delivering software that addresses the needs of stakeholders.

What then are the duties of the software delivery manager?  Here are a few that immediately come to mind:

  • Provide clarity to team members and teams on organizational objectives and what achieving them entails
  • Define operating constraints and boundaries for teams in which they operate
  • Provide teams with the appropriate authority, resources, information and accountability
  • Provide career guidance and coaching to individual team members and teams
  • Staff teams appropriately within budgetary constraints.  Manage their budget responsibility
  • Partner and network with other managers in the organization in addressing organizational impediments
  • Provide feedback to the teams on the software that is being developed.  Engage in product “inspect and adapt” sessions.

What else would you add to this list?

While we’re talking about software delivery teams, I need to remind us that in Lean and Agile organizations, the work is done by cross-functional teams.  The implication of this is that software delivery teams will often be composed of individuals from more than one functional group in the organization.  A software engineering delivery manager will often need to team up with managers from other functional groups in the organization e.g. infrastructure manager and together they will provide the team the support it needs.

It’s also important to remember that Agile teams (regardless of the framework of choice), as a part of being cross-functional, have a role on the team responsible for championing the product (or something similar to a product).  This role, often referred to as the Product Owner, and not the software delivery manager, decides what the team should focus on.

So there you have it.  These are my thoughts on the Software Delivery/Development/Engineer Manager.  I anticipate that some readers will disagree with me.  Please share your thoughts in the comments.  But as you disagree with me, take a moment to explore why it is that you disagree with me.  In fact, I would implore that you examine the underlying philosophy and mental models that inform your definition. Where do they come from?  Do you know?  Are they based upon Taylor’s Principles of Scientific Management, Deming’s principles or something else?  

Our actions reveal our beliefs.

Time-boxes, goals and realizing outcomes

Goal is defined as:

the end toward which effort is directed” or “the object of a person’s ambition or effort; an aim or desired result.

I don’t understand the debate over the Sprint Goal.

I also don’t understand how a teams can function and focus without goals (be they implicit or explicit although I would suggest that there is a danger in not making goals explicit).

If a team carves out a fixed set of time (a time-box) to do some work, they already have, albeit implicitly, established a goal i.e. completing a certain amount of work in a certain amount of time.  I don’t consider this type of a goal to be a best goal we could come up with because it’s output focused and you know I favor outcomes over outputs.  I will concede however, that this type of goal is probably better than no goal at all.

From the Scrum Guide, the Sprint Goal is:

an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Seems pretty straightforward to me with a lot of latitude for the Scrum team to create their goal.  What do you think?

If your time-boxed work period has no goals, no aims, no objectives, no desired end what exactly is your team doing?  Where are you headed?

(I’m pretty sure some folks reading this are thinking to themselves that time-boxing is an archaic practice and should be dropped altogether.  Stay tuned for my next post).

And while this post has focused up till this point on teams working with time-boxes, I will go even further to suggest that any team that is developing and delivering software in support of a broader organizational vision – yes I’m looking at all the teams that say they are using Kanban out there –  that doesn’t have time-bound (see Agile Manifesto Principle #3)  goals is operating irresponsibly.

Goal are very useful.  Use them wisely.  Use them well.

Velocity is NOT about Productivity

I happen to participate in a couple of Lean and Agile subject matter groups on LinkedIn. This is my way of learning and sharing.  In my opinion, any serious Agile practitioner should join and participate in such types of groups (no it’s doesn’t have to be on LinkedIn). I personally learn more from these groups than from workshops and certifications classes.

I’ve observed over the past year that not a week or two goes by without someone having a question around Agile velocity on one of these discussion groups.  Interestingly enough, their questions are never about how to use velocity for forecasting and/or planning. No, the questions are always about how to increase or improve their team velocity.  As an example, check out this very recent velocity conversation.

Why are so many of the velocity questions focused primarily on productivity?

Unfortunately, many of these well-intentioned posters find themselves in organizations where velocity is considered to be a primary measure of productivity.  Not only do organizational leaders use velocity as a measure of productivity, we find some Agile practitioners (sometimes unintentionally) doing so as well.  I’ve seen postings on LinkedIn where teams are congratulated for increasing their velocity.  I’m saddened and disappointed that in 2016 we’re still talking about velocity in this way.  I’m not sure what got us here but instead of simply complaining, I am compelled to share my thoughts in the hopes that it may help someone or some organization now or in the future.  Paraphrasing Peter Block, start with the room you’re currently in.

First of all, let’s agree on what velocity in the context of Agile software development is. Operational definitions are extremely important and I think defining velocity will do us some good.  Velocity can simply be defined as the:

Sum of effort estimates completed in an iteration (see the Agile Alliance reference for more information of velocity).

Any other usage of the term in an Agile software development context is a redefinition of the term.  Agile velocity doesn’t refer to how fast a team works.  It’s not even the count of items completed in an iteration (that could be throughput). It how much of our effort estimates did we complete in an iteration.  No more, no less.  That simple.

As the Agile Alliance article makes clear, velocity is primarily a planning instrument. Carefully read the article as it provides a pretty good explanation of the purpose of velocity and what it should be used for.  Pay attention to the common pitfalls as well.

(However I must point out that many Agile teams effectively forecast and plan without using velocity.  Stated differently, velocity is not a requirement for forecasting and planning.)

But maybe you still think that we should be able to use velocity to gauge how productive our team is.  Maybe the information presented so far is not convincing enough for you. In that case, let’s take a moment to dissect what it means for a team to increase its velocity.

If velocity is the sum of our effort estimates, increasing our velocity would mean that we have to increase the sum of our effort estimates completed.  On the surface, it may seem that this would be easy to do.  All a team has to do is increase the number of items it completes and their velocity will increase.  However, completing more items doesn’t assure us of a velocity increase because we can’t assume that our estimates are the same or larger than our estimates for previous iterations.  In fact they could be smaller and our velocity could actually decrease and yet it would be a good thing!

For example, let’s assume a team had a velocity of 20 points in Iteration 1, which meant they completed 4 stories each estimated at 5 points.  Then in Iteration 2, they had a velocity of 18 points after completing 6 stories, which were estimated at 3 points each. Were they less productive in Iteration 2 because their velocity went down?  What if they completed 7 stories in Iteration 3 and each of those stories has an estimate of 1 point? Are they still less productive?  How do we know?

Don’t forget that velocity is calculated using “effort estimates”.  Estimates are subject to many factors that I won’t get into in this article and yet its important to remind ourselves that each iteration the team is solving problems they have never solved before. The team effort estimates could go up due uncertainty and complexity and it would have nothing to do with how productive they are.

Determining how productive a team is based on how much of their “effort estimates” they complete totally misses the point.  I think Deming would refer to this as management malpractice.  It’s that bad.

And yet teams can easily increase their velocity.  In fact, it’s not hard at all.  All they need to do is make their effort estimates larger.  I’ve seen many teams do this in my career. I’m not sure your organization really wants that.  Riffing off of Goldratt:

Tell me how you’ll measure me and I’ll show you how I’ll behave.

So encouraging teams to increase their velocity is simply something organizations that are intentionally adopting Agile should not be doing especially if they don’t want their teams to game the system.  I will go further to suggest that using velocity to determine predictability (in the small) is in serious danger of missing the point of velocity as well. There are there better ways to do this and I will be addressing that point as I finish my series on predictability.  If you missed the first two posts, check out Part I and Part II.

After all this talk on velocity, I am moved to remind us that the primary measure of progress for an Agile team (and organization) is the amount of software that has been delivered to users and that the users find valuable. All other measures are secondary and tertiary.  Velocity can be used to help forecast and plan (and there are possibly better alternatives to it) but let’s not use velocity as a measure of productivity.  If you must use velocity, use it responsibly.

Predictability in Software Development – Part II

My previous post asserted that predictability at the business or organizational level is having teams that consistently deliver solutions that enable desired business outcomes. These organizations and business are predictable in the large.  Predictable organizations have the ability to change course even as the ecosystem they are a part of changes.  Ergo,  my second assertion:

Your company values adaptability over predictability 

This is not to suggest that predictability is not important.  In fact, it is quite the opposite. In the ever-changing business landscape that now confronts us, organizations are required to adapt in order to survive.  In order to be predictable, organizations must be able to adapt.

(I will concede that it is possible that your business cares about predictability more than it cares about anything else.  I just don’t interact with a lot of those organizations these days.)  

Organizations that possess a high degree of adaptability have the capacity to change course in a largely frictionless manner.  They have the characteristic of responding to changes in the ecosystem and changing direction as needed, effectively and efficiently.

An organization can only adapt as quickly as its component parts can adapt.  More specifically, a product organization’s ability to adapt is a function of their individual product development teams ability to adapt.

Agile places tremendous value on teams being able to adapt as change emerges.   In fact the Agile Manifesto states that we value:

Responding to change over following a plan

and backs that up  with following the principle of:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage value number

Many Agile practices enable teams be in position to respond to change in a productive manner.  Here are a couple of them (in case you’re not familiar with Agile practices):

  • Focusing on the “what” over the “how”
  • Working in small increments of value (days not weeks or months worth of work)
  • Short delivery cycles; weeks over months
  • Stakeholder feedback on a regular cadence
  • Pair-programming/test-driven development
  • Continuously running automated test suites that validate product suite
  • Feature teams developing features
  • (I’m sure you can add more to this list)
  • Etc etc etc

Teams that leverage all these practices (and more) are in a position to respond to change very effectively.  I find however that many organizations that claim to “be Agile” are only partially committed to a few of these practices and then wonder why it’s so difficult for them to change direction.  Coincidentally, these organizations seem to also believe that Agile is about delivering software faster.  (If that’s you, it’s possible that you’ve been misled).  To top it off, these organizations often respond to their inability to adapt by instituting heavy processes and protocols that are focused on ensuring that they won’t have to adapt!

Here is a thought exercise for you: If at this very moment, your team was asked to stop working on a particular initiative and release it into production so that your customer could start using it and the team could start working on a different mission, would your team be able to do it?  How many days, weeks or months would it take for your team to be able to release a product increment at this very moment?  Would you be able to release anything at all?

If an organization desires to be predictable in the large, its teams need to be able to effectively adapt in the small.  When teams holistically adopt Agile-based approaches to software development, they place themselves in a position where they can respond to change in a predictable way.  Could your organization and teams benefit from this ability?

But wait, we’re not done yet.  There is the little matter of predictability in the small. My next post will be about that.  Stay tuned!

Predictability in Software Development – Part I

Recently, I’ve been part of few conversations regarding predictability and commitments.  It is the opinion of some that Agile teams should be able to make and keep their Sprint commitments as it pertains to outputs (points, stories, card counts).  It has also been suggested that measuring a team’s consistency on delivering on committed deliverables (outputs) is a good metric.  After all, the thing our businesses values the most is predictability.

Here is the challenge I have with these assertions.  They are based on the premise that the team should know enough about how they will address problems such that they can make a highly confident prediction on what they will complete before they actually start the work i.e. pull it into a Sprint (or do something equivalent).  Is this the case for the problems your teams solve? Is your team highly certain on how to solve problems (both functionally and technically) before they actually start solving them?

The Chinese restaurant around the corner from my house is very good at telling me how long it will take for my vegetable fried rice order to be ready because they do that multiple times a day.  My barber is very good at telling me how long it will take to cut my hair because he’s done it for me for the last five or so years (and I haven’t changed my style).  The folks who change my oil are pretty good at letting me know when to come and pick up my car.  They’ve been changing my oil for almost eight years.  Are your teams solving the same (or similar) problems from Sprint to Sprint?

I often find teams spending a ton of time (days) upfront trying to determine what needs to be done so that they can make and meet their commitments.  If they discover that they will not be able to meet their commitments,they take shortcuts (specifically in code quality) to ensure the commitment is met. When they don’t meet their commitments, they begin to look for someone on the team to blame.  If they can’t find someone on their team, they look for someone on some other team.  Are these the behaviors you want on your team(s) and in your organization?  To be fair, with a heavy dose of upfront planning, a set of stable requirements, stable technology, stable team (and a bunch of other stable factors), you may be able to achieve such predictability in a non-damaging manner.  What are you willing to pay to reduce uncertainty to a point where your team always deliver output targets?

I believe some of the mass movement to Kanban is as a result of the commitment pressure uninformed leaders place on their teams.  The distortion of Scrum – Dark Scrum – has led teams to look for alternatives. Unfortunately, this is the wrong reason to make process changes but people will do what they need to do to feel safe (and in the process mask real problems).

My tone so far probably leaves you thinking that I believe we need to punt on predictability in its entirety in software development and just let things evolve as they may.  That’s not the case. However I do strongly believe that it’s critical that we (especially business leaders) appreciate the uniqueness of software development and the challenges around predictability that it presents.

What does predictability really mean in software development?  Is it that a team consistently completes a certain number of points or stories in a given Sprint?  Would that make them predictable?  Possibly, but that’s not my opinion.

Agile is concerned with managing the unpredictable nature of software development and delivering on business outcomes ergo Agile teams that are “predictable” are teams that consistently deliver solutions that enable desired business outcomes.  My next post will look into this further.