Be lean and stop wasting your time doing agile

In the software world the term process has a picked up a distinctly negative connotation. So many tedious, bureaucratic and useless activities have been associated with software processes that it has almost become a four letter word. 

In other industries the opposite is true. Manufacturing organisations swear by processes as do those involved in large scale service delivery. 

The fundamental goal of having a process is to make outcomes of some system consistent and predictable

Now think about the software process you're using. How is it helping you to get predictable results? Which activities are useful, from this perspective? Which are useless? Are there some things that are just plain counter-productive?  

What if you could get more consistent and predictable results by having less, not more, "process"? 

Project management is dead (long live task management)

The software engineering practises of today are quite different than those used just 15 years ago. Most of the credit goes to the agile movement. The focus on continuous improvement, sustainable development practises and embracing change have made the software industry better in many ways. 

The debates still rage on how to properly "do" and "be" agile, but there is one underlying idea that almost everyone, agile or not, has absorbed from the agile practices tool set. Task management has replaced project management as the primary method for managing software production. 

Academics and practitioners have been dreaming of "software factories" that produce well-engineered systems, on-budget and on-schedule for decades. 

Smart managers knew that to predict outcomes of (industrial) processes you needed a system that is both stable and measurable. So they started measuring projects and applied learnings from the manufacturing world. Tools were built to monitor time budgets, manage requirements, draw gantt-charts and track bugs.

Unfortunately project is not a good unit of measure in software production. It's too big, as there are not enough projects in most organisations to create a measurable flow. It implies a plan, and casts change as failure. It creates inconvenient discontinuities. Projects have start and end dates, but just when is a software product supposed to be finished?

With the emergence of agile methods (scrum in particular) the unit was drastically changed. Enter user stories. Pieces of functionality that could be completed in a few days. A steady flow of work, with clear criteria of completion. Something that you could actually measure. Factory became team and velocity measured its throughput. Tool innovation shifted to task management systems, kanban boards and the like. A huge improvement.

But teams still struggled to estimate stories and took hours to plan how many could be fit in to arbitrary time boxes. Arguments flared over the number and format of meetings teams should have. A whole profession sprang around conducting agile ceremonies. (Full disclosure: The author is a Certified Scrum Master) 

By now many have realised that these activities bring little value to their work and have abandoned them. 

The funny thing is that you can actually ignore most of the agile ceremony, yet take full advantage of its major benefit, the ability to measure your workflow in a meaningful way.    

The key ingredients to take home from agile are: 

1. Break your work into small enough tasks.

2. Have a system in place for managing your tasks.

You don't need to call tasks user stories if you don't want. You can have as many or few meetings as you like. Estimate effort if helps you. Sprint, or don't. Doesn't matter. Just slice your work to small tasks and manage them in a systematic way.

Control your software development process and predict the future 

When talking to customers, or reflecting on my own experiences as software team lead, it's clear that the most common problems, from the software production point of view, are usually related to scope/schedule questions. 

When is this feature going to be ready? When can we release the new version? If I drop that feature can I deliver this one on schedule? How long does it take to fix bug? And on so. 

So that's the first thing you need to measure and control. Scope and schedule. If you're using any agile process, you already have the building blocks in place:

1. Monitor your team's throughput (velocity)

2. Keep an ordered list of tasks (backlog)

If your process is stable, you should be able to answer any scope/schedule question based on those two pieces of data, right? And you can, with some limitations. Check out our earlier posting on release forecasting for an example on how to answer the "Are we going to release on time?" question.

Another example is the Pivotal Tracker tool. Based on your team's velocity and backlog order, it automatically shows which tasks are likely to be completed in which sprint. Very convenient if you find yourself answering the "When is my feature going to ship?" question  often. 

With this kind of simple methods, you can measure your workflow and make useful predictions based on the data. This is the the essential process you need to have. No ceremonies needed.

Of course measuring is cool, but control is even better.  

That's what you can do after measuring and mastering your process. Now is the time to take a good look at all the agile tools and methods that help improve your team. But do it in this order. Blindly applying the whole agile toolset before understanding your core process leads to confusion, bureaucracy and waste.