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.

Advertisements

Does Your Agile Process Mimic a Production Line ?

Disclaimer: This post is for individuals, teams and organizations genuinely interested in Agile.

I am noticing a certain trend in software development where teams make their software development process mimic a production line by treating each software development activity as a separate station.  Their “boards” make every activity a separate column.   A number of teams do this in the name of implementing the Kanban Method while others do it because it represents what they are used to.  Why is this the case?

Two reasons immediately come to mind (I’m sure you can think of more):

  • Work items take more than a few days to complete
  • Work items are acted upon in a sequential manner

If your work items consistently take more than a few days to complete, what actions is the team taking to address this?  Have you asked yourselves why?  Is the nature of the work such that working software cannot be completed in a few days?  Everything has to take a few weeks or months?  Is the team focused on too much stuff at the same time?  Maybe everyone is working on their own unique items and is not working together (collaborating) to complete items in a timely manner?  It is a known fact that the less work we have in progress, the more we get done and the less time it takes. In spite of this known fact, many organizations/teams/individuals fail woefully at limiting work in progress.

I still find teams that believe software development has to be sequential (in the small) just like a production line.  Many have described this as mini-waterfall.   Each role on the team represents its own “workstation” and for the work item to be completed, it needs to pass through all the workstations via hand-offs.  A classic indicator of this is a team where the testers complain that they have no time to test in the Sprint (another reason why teams abandon time-boxes for Proto-Kanban).  For example, a user story would “flow” in this manner:

Analysis -> Design -> Code -> Test -> Deploy

(The fact of the matter is that if it takes a few days to complete a user story, these activities would overlap to the point that making them explicit would provide little value.)

What if instead of having work move in a sequential manner we have all the roles performing their activities on the user story concurrently?    What if the work item was the center of the universe with multiple actors acting on it at the same time?  What could happen then?

There are some major implications with this approach.  For starters, it would mean we focus multiple team members and roles on as few work items as is possible.  A business analyst, engineer and tester (for example) all working together at the same time on the same thing.  If you don’t think this is possible, let’s have a chat.  Or perform a Google search.  Or ask an Agile practitioner.

This is a fundamental shift in the way we traditionally approach how we work in software development. (In the first Kanban system I ever designed, it was a rule that more than one person should be working on a item that was in development.  Team members and partners in the other departments initially found it strange as they were not used this but eventually came to appreciate this approach as it enabled us to deliver software more effectively.)

The feedback I receive from people when I bring topics like this up is that things are working just fine and hence they have no reason to do anything different.  No reason to decrease the time it takes to complete user stories. No reason to change the way they work on their work items.   In my opinion, these people have totally missed an important point about Agile (and Lean) and that is the relentless commitment to continuous improvement. The commitment to finding better ways to do our jobs even when the current ways seems to work well.  The commitment to being the best we can be. These individuals, teams and organizations are completely missing a critical component of the Agile mindset. 

So does your Agile process have to mimic a production line?

What’s Wrong With Scrum – Part III

Earlier this year, I started writing on the limitations of Scrum as a result of articles I had come across.  In my first article, I was critical of the individuals (largely Scrum Masters) responsible for guiding Scrum adoption in organizations. In my second article, I took a look at the system (and those who create them – leaders and managers) and wondered aloud as to whether the organizational constructs actually supported Scrum being effectively leveraged in our organizations.

It is possible, readers came away from my first two postings with the impression I believe nothing is wrong with Scrum –  it’s perfect – and dubbed me a Scrum zealot of some sort.  Well in case you did, maybe this last post will leave you with a different impression.  Maybe.

Scrum is defined as: a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.  This definition would seem to imply that as long as a team is in the business of delivering products, Scrum should be a fit.  Is it really as simple as that?

I rarely hear productive dialogue around the scenarios when and where Scrum (the process framework itself) isn’t a good fit for a team developing products, so I’ll attempt to start some dialogue here.  In my opinion, for Scrum to be a fit, the holistic nature of the work the team is doing needs to be in alignment.  When could the nature of the work not be a fit?  I’m going to attempt to identify these situations via the lens of the VUCA framework.  VUCA stands for volatility, uncertainty, complexity and ambiguity.

Volatility

Volatility refers to how much change is occurring.  In the context of Scrum, I see this as how does the rate of change impact how we plan.  Let’s consider Team A that gets to their Sprint Review and identify they did not deliver what they had planned because they had to deal with new work that emerged during the Sprint (not because they planned poorly which many teams do!).  Or maybe every Sprint there is a discussion around canceling the Sprint because the Sprint Goals keep changing due to emerging market factors.  Maybe emergency customer requests or defects have to be addressed in order to keep major accounts. The nature of their work is so volatile, they cannot plan any further out than maybe a day or two.  In this case, Scrum may not be an appropriate fit.

Uncertainty

Uncertainty is focused on the degree of predictability we have.  Scrum works well for handling unpredictability around what will satisfy the customer because the framework requires customer engagement throughout the process. On the other hand, Scrum expects certainty around what the team will be working on in any given Sprint and the goals they have.  If we cannot arrive at a level of certainty around what exactly we will be working on in a Sprint (maybe due to volatility), Scrum may not be a fit.

Conversely, if there is little uncertainty about what needs to be delivered such that (for example) customer engagement has little impact on delivering a work product that meets the desired goals or if the team just needs to plow through a laundry list of items and ordering (or prioritization) is not particularly important or if potentially releasable increments are not needed during the duration of development, then Scrum may not be valuable as a framework for delivering products.

Complexity

Agile frameworks and methods are designed to deal with the complexity involved in the development and delivery of products.  But what if your work is not complex?  What if it’s simple or complicated?   While complicated work is difficult/hard, we know the steps we need to take and the “end is largely known from the beginning”.  Simple work is like complicated work except we don’t have the ‘difficulty’ property present.  In either case (with simple or complicated work), the amount of discovery that occurs while we are doing the work is minimal and hence the benefits of Scrum itself is probably minimal.  If we don’t need to inspect and adapt, then the events Scrum provides for this are probably overhead.

Ambiguity

Ambiguity has been described as the presence of “unknown unknowns”.  It seems to me “unknown unknowns” are always present except in the simplest of endeavors.  The question we need to answer is this: how much of our work is characterized by ‘unknown unknowns’?  It’s my personal opinion that Agile (and hence its frameworks like Scrum) work best in situations where the work has a balance of ‘known knowns’, ‘known unknowns’ and ‘unknown unknowns’.  When ‘unknown unknowns’ is the predominant characteristic of the work, there may be better frameworks for managing such work.

So yes, it’s quite possible, that the nature of a team’s work may be such that the Scrum framework is not the best framework for managing the work. We can only come to this conclusion when we take the time to objectively profile our work.  Objectivity is key here and worthy of another post.

It’s at this juncture I need to remind us that Scrum (and Agile by extension) are not THE goal.  Your organization has business goals that are extremely important.  Your team has hopefully been asked to own making a contribution towards these goals.  Agile (and its frameworks and methods) may enable you achieve those goals in a manner that is fulfilling and rewarding and yet it is important that we continuously assess, with a critical eye, the frameworks and methods we have chosen and make sure they remain a fit.

I find many teams and organizations give up on Scrum because it makes them uncomfortable as it shines a light on both team and organizational dysfunctions, NOT because the nature of their work is not a fit.  To make matters worse, they then distort Scrum by redefining it to meet how they would like to work.  When we give up on Scrum or any other frameworks for the wrong reasons, we have placed a self-imposed cap on what we could have accomplished.  Our new approach doesn’t really solve our problems; it just introduces a brand new set.  Isn’t that a crying shame?

I hope these three articles on Scrum provide you with thinking tools that help you choose ways to work that are both fulfilling and extremely effective.