Agile

The first listed principle at agilemanifesto.org lists customer satisfaction via delivery of valuable software as the highest priority.

Some people interpret this to mean the more software that gets delivered the better. They even point to short iterations which include deliverable’s as a manifestation of that. More rapid delivery can even be a selling point to launch an Agile transition. Thing is, the goal isn’t more software, it’s valuable software.

When a team builds a house the project has a very defined end. Once built the original team no longer deals with the house instead handing maintenance and support over to the user. Software development is not like that. Once the initial release is done the original team generally does deal with maintenance and support. When the last release is done they generally still deal with maintenance and support.

This can be tough for some people tasked with managing agile software projects to reconcile. Projects are supposed to be temporary and have a defined end. Once a project is done it’s time to move on to the next one.

A good way to get around this mindset is to change the delivery. Don’t think about the software as a product to develop and deliver. Think about the software as a value delivery system. Your team is not creating this single product which will then be passed off and forgotten. Your team is creating value for the user. As long as there is more value in enhancing or fixing the software then there is in doing something else for that user then your team should focus on the software. That brings us to how we deliver more value on a product that is out the door. My answer, admittedly biased, is with an Agile mindset.

I like to point out that Agile is going to look different from one company to another. In fact, it often looks different from one team to another. To get the most from an Agile transformation there needs to be freedom for the teams to adapt. This isn’t the whole story though.

Just as humans must walk before they run teams must start along an Agile path before they can create their own trail. It’s a truth that has been known for ages among many specialties over time. The most common reference is to Shuhari. The basic premise is that you start by imitating what someone else does. You then progress to modifying it to better suit your situation. You end the end up as a master that can create new ways of doing on your own. This same logic applies to attempting an Agile transition in a company. Whether the pilot program or the last team on board the truth is the same.

There is a lot of work being done on scaling Agile. This makes sense. There are few people anymore that will argue against Agile methods on a small-scale. The problem is that many organizations are not small. Plugging these small-scale changes into the greater organization can be difficult and often has mixed results.

Any organization looking to scale needs to know why they want to scale. They need a plan to scale. They need a way to evaluate whether their transition is working.

A good way to think of what’s happening is by imagining a city skyline. Spreading Agile to all teams is equivalent to building more skyscrapers across the horizontal landscape. Scaling Agile in the organization is more like extending the existing skyscrapers higher in the vertical plane. The analogy isn’t perfect of course. Scaling will require more horizontal involvement and spreading will require a degree of vertical integration. The important part is the focus and most movement is in a different direction scaling than it is for spreading.

We’ve all been there. Here in the Northern US it happens like this. It’s the dead of winter. The days have been getting shorter and darker. The weather has been increasingly trapping us inside while simultaneously making our daily commute longer than ever. January first approaches and we make some resolutions, providing focus and hope. We work hard towards these new goals. We see some positive change. Progress is made and it makes us feel good. Then something happens.

Sometime in late February or early March is when we tend to first notice it. We’ve lost momentum. Progress has stalled, and we aren’t really sure when it happened. We might have lost the initial progress. In some cases things have slid even further back then when they started. Most of the time by May it’s as if nothing ever happened.

Many Agile transformations are the same way. They start strong. Everyone has really good intentions. A couple of process changes are made. Some benefit is seen. Some resistance is met with facets of change that are uncomfortable. Concessions get made. The result is little change, minimal benefit, and stalled change initiatives.