Close

October 28, 2014

#NoProjects Please, We’re Developers

Thanks to Allan Kelly (@allankellynet) for articulating much of this in his recent talks on the subject.

I was approached recently to apply for a position as a “Software Project Manager “. The job ad mentioned Agile a lot but also made a great emphasis on estimating, planning and traditional style project management. It has always seemed to me that Agile and Project Management are incongruent and jobs like this seem to be crowbarring Agile into a typical project management role. You can guarantee that the outcome won’t be an Agile Project Manager; either the successful candidate will be able to subvert the project paradigm and be mainly Agile; or more likely the projects and traditional command and control management model will dominate with superficial aspects of Agile (otherwise known as Scrum) being employed.

The Project Model

There are three assumptions of the project model – that a successful project is:

  • On schedule
  • On budget
  • On quality

Implicit are assumptions that the value of the work/project is known; and that other options or possibilities that may arise during the work are valueless . Hit those three targets and you’ll be considered a success.

The focus in managing the project is on ensuring that these objectives are met. The project manager has no interest in evaluating intended benefits or retrospectively assessing the value and impact – the project in itself is the important thing. Partly this is due to the way their performance is managed and rewarded.

Projects have an end date. But software doesn’t stop. Used software changes all the time. Especially in the web application world, where hundreds of commits can be released every single day if need be. Only dead software stops being developed (certainly in the web space).

Teams

Consider how projects are defined: classically as temporary organisations that take a long time to get the team together (remember forming, storming, norming and all that?) and then it’s destroyed at the end as team members are sent to join other projects.

Why destroy it? Why spend all that effort in getting a great team together only to let it disband? In Agile, fluency and coherence can only come through time, which shouldn’t be wasted if it’s working.

Projects are usually planned with the assumption of pre-determined resources. You know certain constraints around people, money and time; quite often the key resource is the number of people you have on the project.

However, people end up working on multiple projects or older things they were already on. Resource allocation within an organisation is always a political activity. Instead of getting what you need, you get what you can depending on a whole range of factors, not least your personal persuasive abilities. Do you always get what you need in terms of resources? If so, does anyone else (you might be the boss and other people don’t get what they need even if you do).

Requirements

A damaging assumption when applied to software products is that of predefined requirements. Requirements change, and have value. Why would you not want to consider new information, thinking and technology? Why would you disregard reflection on what was initially agreed?

When working with customers (internal and external) and determining their needs, remember they are not expert at articulating those needs in a form most beneficial to the development of software. That is the job of analysts, product managers etc, to elicit the underlying needs of the customer. Those needs are rarely fully understood at the start of the process and emerge through time as the implications of what is being developed become more fully understood. This is one of the principles behind Agile, that change is not only inevitable but welcome.

Capers Jones, the renowned computer science methodologist, made the observation back in 1975 that the rate of change in requirements was 2% per month. Compound this figure annually and you get an annual rate of change in software requirements of 27%. Therefore the longer the period between writing initial requirements and software deployment then the greater the variance between what is needed and what is delivered. Again, this is why Agile has a focus on incremental iterative delivery of value – the cycle time between becoming aware of requirements and their delivery is much shorter and more likely to meet those specific needs, as opposed to scooping up all needs at the start and then planning the work over an extended period.

Project thinking sees late requirements as inferior; yet it is the requirements that come after a period of reflection and consideration in response to what has been proposed or built that may have the most value. To the project model though, these are very likely to make the project late and over budget and are therefore negative.

Deadlines

Projects typically have a big end date in mind, by which the work must Go Live. Quite often these dates are the result of an arbitrary decree from a senior person and not rooted in analysis or real need (except perhaps their own performance targets).

Now humans are good at deadlines and last minute work; however we are very bad at estimating. We’re particularly bad at estimating larger pieces of work and longer timeframes.

Having drop dead end dates are harmful, but a series of short term deadlines are actually beneficial; taking advantage of psychology without compromising quality.

With hard deadlines,quality gets cut to make the date, making it harder to change in the future. In coding terms, technical debt is generated for the short term benefit of the project timescales.

For many of us in software development, projects should really only be considered as accounting codes, not the framework involved in delivery

Language of projects

You may have run into “False Projects” – using the language of projects to discuss work which is not a project. It’s common to find that people see projects as the default paradigm for work and so view everything through that prism. When they rub up against work which is not being delivered as a project, friction arises (as I found when discussing a complex set of development that would take months with a project manager). You may experience an episode of cognitive dissonance as you try to find a common language to describe the work.

If you’re trying to move your software development mindset away from projects to products, what should you do? First of all, keep functioning teams together. Colleagues who know each other and how to get the best out of each other improve over time, messing with the lineup introduces new learning curves. It’s useful sometimes to rotate people around to learn new things and not become stale, but consistent team membership drives productivity.

Products not projects

If you are in a position to deliver work to the team, make it a consistent flow of work rather than fits and starts, or periodic massive piles with a long deadline. Work “in the small”, continually and to short deadlines. Ensure you are able to demonstrate value to stakeholders. Focus on that value not on the end date or final set of deliverables.

In this environment, your customers will be asking what will the software deliver next, rather than when will my features be delivered. They will appreciate the stream of value.

Software development has diseconomies of scale. The price goes up per unit of work as the work gets bigger, and you need to involve more and more people in QA, analysis and all the other things that come with large scale software development. Risk is reduced in smaller packages of work, in small coherent and knowledgeable teams. All the software cannot be tested all at once beyond small systems, so prioritization of what is necessary to test is easier when the amount of change per release is small.

Projects put great emphasis on milestones and reviews; in order to maintain good governance have regular fixed review points where everyone can see where the product is up to; and can make changes in direction and priorities for the next period.

Projects negotiate features at start and at end. Agile product development does negotiation all the time. Priorities are constantly being updated because the world changes and the opinions of those wanting the software also changes.

Conclusion

Similar to the #NoEstimates conversation on Twitter; as IT professionals we need to challenge assumptions about how we do our work and what the benefits are of what we do. There will be circumstances when a tightly controlled project approach is best for a given task; but my point is that not all software is projects and different domains require consideration as to the best way to manage them. Agile does not have all the answers but it allows for introspection and questioning with tighter feedback loops to ensure that the right thing is being done and done well, and not just the wrong thing righter (as John Seddon warned of).

Leave a Reply

Your email address will not be published. Required fields are marked *