In my previous post, I looked at the most common causes of IT project failure. So how can me reduce the effects of these issues, and maximize our chances for success? Well, let us learn from others – especially those in the agile software development community – who have been dealing with these issues for decades.
We tend to think of this as the responsibility of Project Managers (PMs) – a reasonable assumption, but one that is flawed. It is the responsibility of everyone involved in a project – business representatives, developers, executives, everyone – to help manage the project. In this case, “manage” means “if I see something that needs doing, I own getting it done”. But it goes further than that, as it is everyone’s responsibility to support the entire development effort, to bring their expertise, skills, and background to empowering and enabling the development team in their work, allowing them to be creative and innovative in delivering high-value solutions quickly.
OK, that is very “rah rah”, but what should people – especially leaders – actually do? Well, here are three concrete examples of steps anybody can take or support:
Focus and finish – provide space, time, and tools to allow the development team to work on the most important things first, without distracting them be having them time-slice across multiple projects or multiple elements within a project. Having 1 thing completely finished an usable is much more valuable than having 10 things partly done.
Prioritize “value” – of course, everything in a project is important. But which items are most important, most valuable? These are the things the development team should focus on first, but without getting priorities from the business, how can they be expected to guess accurately what should be worked on first.
Don’t sub-optimize the development team – I always know when an organization is in trouble in adopting agile approaches to software development, simply by looking at an organization chart. If I see a VP of Business Analysis, a VP of Development, and a VP or Quality, I know we are in for a struggle. Why? Simply because each organization is focused on their own goals. The Analysts want to write the best requirements documentation ever, then hand these off the development. The developers want to write great code, and hand it off to QA. The QA organization is there to find – and stop – bugs, then send the code back to the developers. Each organization doing its specific job as well as it can, but with little or no focus on the entire goal of delivering value quickly.
The goal of an agile development team is to delivery high-value, high-quality software quickly and frequently, and this takes a new paradigm in communicating and collaborating across organizational boundaries.
Used to be we would spend months designing and planning projects, then months developing them prior to release. It is time for a new approach, one that is being very effectively used by many organizations, no matter what development methodology (agile, lean, spiral, etc.) they employ.
Projects now must continually be designing, innovating, and planning on what to do next. Obviously, it is important to have a good idea of the goals of the project before we start (something I find seems to be forgotten by many agile projects team), but this must be explained in business terms, and not just in terms of the technology solution. Technology projects exist to solve business problems – which is why business and technology can not afford to be separated in any way.
I use an approach I call “The 5 levels of agile planning”.
The first level of planning – Project / Vision
This is the highest-level requirement possible, and describes, in quite broad terms, what business problem the project is trying to solve. The project description or vision may be “Increase sales through our e-commerce platform”, “Re-platform our ERP solution”, or a vision I will use as an example throughout this paper “Sell airplane tickets through a new web site”.
Second level of planning – Release Planning
As we discuss the project, and each business objective within the project, we will discover more, especially if we look at the solution from the end-users perspective. As we discover more, we will discover more functionality is necessary, and we need to capture this functionality, even if we do not think we will develop it anytime soon.
Third level of planning – Iteration Planning
If we have done the rolling look-ahead planning well (see below), iteration planning should be a very short event. This is when the entire team has the opportunity to ensure they know what stories are planned to be in the next iteration, if they have enough understanding of them to complete them, and identify issues that may inhibit the team from completing all of the work.
Fourth level of planning – Rolling look-ahead planning
For each level of planning outlined above, it is vital that these efforts are not single events, but ongoing work that is as much a part of the project as coding and testing. We must keep looking ahead, building on the knowledge we have gained, and getting ready to maximize the value we want to deliver.
During each iteration, it is the responsibility of some team members (usually the analysts and scrummaster) to determine if the work to be done in the next iteration is sufficiently detailed, or if additional work needs to be done to prepare the stories for the iteration.
Similarly, during each release, someone (or group of people) must be looking ahead to the next release, discovering new requirements or changes in direction and technology, and prioritizing these discoveries to maximize value delivery.
And finally, while this project is evolving and being developed, we should consider what opportunities it opens up for the business (or deficiencies in our business it highlights). We should start planning the next project (or projects) while this project is in-flight.
Fifth level of planning – Daily Stand-up
The Daily Stand-up is an opportunity for the entire team to come together, and ensure everything is fine (or issues are identified). Rather than focusing on “what I did yesterday” (one of the 3-questions of a stand-up), I prefer team members to tell the team what they plan on doing today, and asking for help if they need it. This allows other team members to quickly identify if there is a potential for road-blocks of their work, and decide if they have something to add to another team members efforts.
Slow Project Release
I stated above that the goal of an agile development team is to delivery high-value, high-quality software quickly and frequently. In practice, this means that the team must get a requirement (user story, use case, or whatever) from an expression of intent to working software as fast as possible. This allows the business to inspect the growing solution at a very detailed level, as well as ensuring the entire software suite hangs together. The business should be able to examine working software at least every 2 weeks, and preferable more frequently.
But what do I do with this software once it is “right”? Many organizations have a periodic software release, often quarterly, perhaps monthly. This is simply not good enough – I have a pile of valuable, useful software, but cannot actually get it into production for up to 12 weeks – is that really delivering value?
It is only when we release our product to the real users that we find-out if THEY find it valuable – frankly, our opinions as to value are simply opinions. The real users give us data.
Moving to a releases cycle based around iterations, perhaps releasing at the end of each iteration, is a good solution to this. Better yet is moving to a Continuous Deployment approach, releasing software as soon as it is done.