Author Archives: James Wyllie

Increasing Capacity: A Question of Capability

“When is it going to be ready?”, “How long will it take?”. As someone involved in software delivery, you are probably asked these questions or something like them, every day.

However you choose to answer the question, you’ve probably taken into consideration the capacity of your team. For most people, capacity is simply a case of counting the number of people in the team, and making an assessment of how much work those people can get through in a certain time period. In order to understand how to increase team capacity, the temptation is to think in the same terms. In doing so, you are only able to draw one conclusion: to increase team capacity you have to add more people.

A number of books have been written on the dangers of thinking in this way, most notably The Mythical Man-Month. These books focus on dispelling the myth that adding people to a project has an immediate positive effect on team throughput. Thinking longer term, if throwing people at the problem isn’t always the right thing to do, or we aren’t able to take on the additional cost of doing so, how do we increase team capacity?

Capacity isn’t simply about the number of people doing the job, it’s also about how they go about it. Their capability. If we put a focus on work management: limiting work in progress and reducing batch size, and couple it with engineering practices such as continuous integration and pair programming, we begin to increase a teams capability. This capability manifests itself as a reduction in waste as fewer defects are injected and knowledge is shared, and a reduction in lead time as deployment pipelines are automated alongside some of a teams testing effort. Not only does our software reach our customers more quickly, it’s of a higher quality, resulting in less rework. That leaves the team more time to focus on the new features that add value for our customer.

Increasing capacity isn’t simply about adding more people to the team. It’s also about increasing capability, by optimising the way in which the team produces software. In this way we can keep teams smaller and more focussed, helping to control our costs.

Probabilistic Forecasting

Probabilistic forecasting is an alternative to an estimates based approach. Rather than asking your teams to break down a lot of work up front, and then estimate it, we can use past data generated by the team from the work they’ve already done to extrapolate a forecast of what may happen in the future.

In his post last year: Little’s Law, David Lowe describes the relationship between lead time (LT), delivery rate (DR) and work in progress (WIP). If you were inspired by David’s post, and are already focussed on limiting WIP in order to reduce lead time and increase delivery rate, you will probably be collecting data. We can take an average of this data over time to create a forecast.

Before we look at the maths, I want to touch on process. We know that if we want to be successful, we need to be pulling in the same direction. A good way to achieve that is to make our objectives and goals clear. In order to create our forecast, it helps to visualise those objectives and goals, and eventually the work we are going to undertake to achieve those. With reference to the diagram below, we can see one to many relationships between our objectives, goals and stories.


If we try to remove as much variance from the sizes of our stories as possible, and break each goal down into a set of stories that are all roughly the same size and all relatively small, we can use them, with our average lead time (ALT) and our average delivery rate (ADR), to create our forecast.

      If; G1 = Goal1
      and; Sn = number of stories in Goal1
    then our forecast for Goal1 is; G1 = (Sn  /  ADR) + ALT

Where ALT is the time it will take the first story to flow through our system.

If we’ve done a similar job with our goals as we did with our stories, and they are roughly the same size as each other, or we’ve sized them relatively (e.g. we know that Gn is twice as big as G1), then we can extrapolate a forecast for the entire objective, by simply breaking down the first goal, just in time to work on it.

      If; O1 = Objective1
      and; Gn = number of goals in Objective1
    then our forecast for Objective1 is; O1 = Gn x G1

As we undertake the work for Goal1 our ALT and ADR will fluctuate slightly. Very quickly we can adjust our forecast accordingly and communicate that to our stakeholders. Having delivered the value of each story in Goal1, and the goal itself, we can then repeat the process for Goal2 just in time to work on it, and so on until we’ve either completed all of the work for the objective, or we’ve decided to stop working on it.

Responding to Change – A Decorator’s Story

This weekend I set myself the objective of decorating my bathroom. I enlisted some help, took 2 days off and set about planning the work.


The plan consisted of several goals: take the old tiles off the wall, remove the old shower, plaster where necessary, attach the new shower, tile the walls, take up the floor tiles and lay new ones. On paper this seems like a lot of work for two people to accomplish in 4 days, but as always our estimates were on the positive side of reality. We felt it was possible.

It was all going well. The old tiles came off the wall quickly and the old shower came out easily enough. Then we ran into our first problem. Damp. We had to remove much more plaster than we had hoped, and the wall had to dry out before we could put up new plaster. Our plans changed. While the wall was drying, we started to take up the floor tiles. We estimated it would take one of us a day, it took twice that long. On top of that, we found that the new shower had to be plumbed the opposite way around to the original.

Our plans changed again. Having now plumbed in the shower and plastered, it wasn’t dry enough to tile on. We moved onto tiling the floor. By this time we knew we weren’t going to finish ‘on time’ so we prioritised the areas of the floor that would be used the most. Under the toilet, by the bath and the sinks, while ensuring the least amount of cutting. We managed to tile half the floor.

As I write this, my bathroom is half done. We had to respond to change several times, but as the solution was determined up front, any changes were simply to account for new work that we discovered, the original work still had to be done. It was a deterministic undertaking.

That got me thinking, what if it wasn’t? What if this was an entirely empirical undertaking like software development? What if we were given a problem and had to find the solution? Would we have defined the solution in its entirety up front, estimating it, removing flexibility, limiting our options and our ability to respond to change?

No. Why would we? We can solve the problem in any way we want to, our solution doesn’t need to be entirely determined up front. We can have a plan, but not stick to it rigidly. Our requirements can evolve, and our stakeholders will be close by helping us make vital decisions.

As a team, we can respond to change.

Photo Source: WheelersLtd

Alignment a.k.a Collaboration

The principles behind the agile manifesto are clear in their message on collaboration: “Business people and developers must work together daily throughout the project.” Yet, there are still companies out there where the visions of the development teams and business teams do not align. They either have different targets or they simply haven’t taken the time to understand each other’s context.

Recently, I was asked to categorise the work that my software development teams are doing. I was given a list of options to choose from, which included ‘Tech Initiatives’ and ‘Domain Initiatives’, where ‘Domain’ relates to a business unit that comprises both development teams and business teams. These categorisations confused me.

If we have true alignment, a shared vision and collective goals we are working towards to realise that vision, then why would we categorise any software development as a Tech Initiative? Every single piece of  work delivered by software development teams should deliver some business value. That value will be assessed relatively in conjunction with the team’s stakeholders, and prioritised accordingly.

So I decided to categorise all of our work as domain initiatives. My hope in doing so is that it sends a message – Software development teams can’t be Agile on their own, it’s a collaboration. Visions and goals should be aligned.

Are You Getting Value From Stand Ups?

I’ve been attending stand ups for the better part of 10 years. I’ve been to some good ones, some bad ones and some really bad ones. More recently, I’ve been helping the teams I work with now, to get more value from them. We encouraged ourselves to think about what we want from our stand ups. Here are some of the questions we asked.

What are stand ups?

Stand ups are that vital touch point with the rest of the team. Stand ups are short, face to face, verbal ‘meet ups’, where knowledge and information can be transferred between team members.

What do we talk about?

What did I do yesterday? What am I doing today? Am I blocked?

These are the three standard questions asked and answered by people at a stand up. They are a great starting point and they do convey some information that other people may find useful, but as a team evolves, are these questions still relevant? Is what you did yesterday really valuable to the other members of your team? Doesn’t your whiteboard show what you are working on and the progress you’ve made? The person you’ve been pairing with will certainly know what you did yesterday. The knowledge and information you want to convey each day will likely change, and context is key.

When do we hold them?

Co-location is ideal, but in recent times, remote working and globally distributed teams have become more and more common. First thing in the morning could be a good time? For us that means we’ve all got coffee and everyone we are expecting at the stand up, is available. This will usually be at 10am in London. However, if we had team members based in New York too, it may be more appropriate to hold it at 3pm.

Who attends?

The scrum guide states the following about the ‘Daily Scrum': “The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.” A good rule of thumb might be that the people that need to be there to affect change, are the people that should attend. For the most part, this will be the development team, but in practice it may be prudent to bring others in as needed.

Are there any common problems?

  • We have stand ups, so we don’t communicate between stand ups
  • There are 50 people at our stand up (or more than is required to affect change)
  • Our stand up takes 3 hours (or more than 15 minutes)

If these problems sound familiar, perhaps it’s time to assess the value that your stand ups are delivering?

Software Development is a Team Sport

My last post: Testing is an activity, not a role,  prompted a few comments on Twitter from my friends in the testing community.

Most people didn’t think the post went far enough in explaining that although testing may indeed be an activity, it’s probably more than one activity, and that different activities require different skill sets. I want to address some of that here.

In essence, I’m referring to software development as a team sport, the difficulties that arise when trying to evolve to Agile delivery methods from more traditional delivery methods, and how we might go about breaking down those barriers between Development specialists and Testing specialists, promoting the team ethic. Everyone is responsible for quality, therefore everyone should undertake some form of testing. What testing is undertaken by each team member will probably be determined by their chosen specialism.

So how do we go about breaking down those old barriers? Should the whole team understand the chosen automated test framework? Should a Product Owner be able to write conditions of satisfaction in a Given, when, then format? Should any Developer in the team be able to pick up any story regardless of language or technology?

The answers to all of these questions could be yes, but as always, context is key. Some teams may have a good balance of Developer and Testing Specialists, some may not. Architecture will also play a big part in determining what testing may take place, and when.

When making the transition from a traditional delivery method to a more modern approach, the important thing is to put an emphasis on working together as a team. The team can then define what testing takes place, who does it and when, taking into account the skill sets at their disposal.

Testing is an activity, not a role

In traditional software development environments, testing may have been something that was outsourced. One group of people wrote the code and handed it off to a different team for testing. More recently, as the Principles of Agile were created and the Scrum framework in particular was popularised, cross functional teams have become the norm.

The Scrum Guide states:

Development Teams have the following characteristics:

  • They 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;
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
  • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

I’m a firm believer that testing is an activity, not a role. This mindset appears to be supported by the third, fourth and fifth points above. Getting to that state while forming teams from groups with well established specialisms can be difficult. Scrum as a framework for delivery doesn’t address this, but it; “functions well as a container for other techniques, methodologies, and practices.”.  A team that decides that Scrum is for them will need to think beyond its boundaries. XP describes techniques and practices that can help.

Teams that practice TDD are able to treat testing as an activity. Developers writing code can write unit tests (first), other Developers can write automated acceptance tests, and any manual exploratory testing can also be undertaken. If these things are coupled with keeping changes small, feedback from tests comes quickly and quality software can be delivered frequently with relative safety.

As a Developer I work with put it; “this requires discipline”.

Working Left to Right

In western societies we read from left to right. We are conditioned to look to the top left first. During a recent stand up, a team member pointed out that our kanban board asks us to do almost the opposite.

Our work is pulled from left to right. Those work items that are closest to being live are naturally further to the right, and given those are the most important work items, that appears counter intuitive if we naturally focus on the opposite side of the board first. We decided to run an experiment.

We hypothesised, that if we reversed the order of the columns on our board, putting the ‘Celebrate’ column on the left and the ‘Ready’ column for new work items on the right, that we would naturally focus on the work that was closest to production deployment. The changes were made, and we agreed to review them in our next retrospective.

The results were unanimous. Every team member is of the opinion that the board is now much more intuitive, and that by reversing the order of the columns there is a natural focus on the work that is closest to live. We still have a pull system in operation, only now the work flows in the opposite direction.


Fixed Everything Projects

To most of us, the problems with fixing cost, scope and time are obvious. How do we know we can deliver all of the scope, in the time we’ve been given, with the people we have to do it?

The short answer, is that in most cases you can’t especially if you want to be able to respond to change and maintain the quality of your product. The concept of the Iron Triangle helps us understand the problem. It tells us that in order to maintain the quality of our product, that we can only ever fix two corners of the triangle.


In a lot of software development projects our cost can be defined as the cost of our people, the development team, which has a fixed size. You may be able to bring more people onto a project, but that can have many negative effects (see The Mythical Man month). Time (or schedule in the diagram above) could be defined by a given deadline, or by estimates provided by the development team that are being used to calculate a delivery date (see my post: To estimate, or not to estimate: That is the question for my views on how to work without estimates). Scope is defined as the project objective broken down into requirements for delivery, plus any change that occurs during the project life cycle.

If we assume a fixed cost, then either the scope or the time has to be flexible. If time is fixed, then we have to work on requirements in priority order until we have run out of time. We then take a decision with our customer as to whether to continue working (thereby adding more cost), based on the value of the scope we haven’t yet delivered. If scope is fixed, then we will continue working on requirements in priority order until we have delivered everything that was requested.

Ultimately, by focussing on the Principles behind the Agile Manifesto, delivering value early and then throughout a project, discussions about fixed time and scope are moot, with requirements evolving based on feedback from customers, and the decision to stop, an easy one to make at any point given the value already delivered.

Do ALM Tools Encourage Communication Waste?

Application Lifecycle Management (ALM) tools are supposed to make our lives easier. They provide a one stop shop where we can author and store requirements, manage bugs or issues, manage projects and even manage the build and release of software. Some of them even act as Source Code Management tools as well, but are they truly helping to make our lives easier?

Individuals and interactions over processes and tools

In his recent post, Individuals and Interactions Over Processes and Tools, Jiten Vara touches on the role of tools in software development as a distraction from real face to face communication. I want to take this one step further and suggest that they actually encourage waste.

At a recent #LeanCoffee meetup, I proposed this topic. The general feeling was that people do have a tendency to revert to the tool as a way of communicating, rather than talking face to face. Each tool will offer its own way of facilitating that communication, usually via comments in tickets, bloated ticket descriptions and email notifications.  All of which is written word; prone to error, a lack of information, or even worse, specification.

Is the tool itself really the root cause of this waste?

Environment is ‘the’ Factor

The root cause appears to be our working environment. The use of ALM tools for communication is just a symptom of a deeper issue, namely the way in which our working environments are set up. Are you able to simply turn around to talk to the rest of your development team? Are you co-located with your stakeholders and any other teams you may be dependent on?

If the working environment is not right, then people will start to use the tools available to them to communicate. Reference email as an example. A consequence of this behaviour will be creation of waste in your system. Ultimately, if you can be co-located, with a whiteboard and some post-it notes, you’ve got all you need for successful (waste free) communication.