Agile Project Management Values

Back in November I looked at some ideas from Agile approaches to project, in particular Extreme Programming (XP). I said then that this approach for managing software projects had many useful ideas for all types of projects. In this article I’ll look at what Kent Beck, the author of Extreme Programming Explained considers to be essential values for everyone to share on a successful project.

Beck distinguishes between practices, telling people how things could be done and values that justify why things should be done that way. For example a stand up meeting is a practice that demonstrates the value of quick, simple communication. Not having an understanding and commitment to these values risks applying the practices incorrectly. Either people follow practices when they are not justified, for example writing out long reports when verbal communication would have sufficed, or miss them out completely, such as diving into projects without proper planning. The first leads to bureaucracy the second to chaos!

Values as Beck says, “bring purpose to practices”. However it is difficult to perceive if someone has a value. The only way of doing so is to observe their behaviour to see if they are following any practices. So practices bring accountability to values.

Beck sets out five core values that every project team should have in order to deliver a successful project.

Simplicity

The simple approach, design or product is always the best. I remember working for a broadcast company in London several years ago. It was common practice there for all project manager to maintain a project plan down to an hourly level. The plans became so complex, that they took ages to maintain each week. The project managers didn’t have time to do much else! The level of detail wasn’t necessary to track and control the project.

Communication

For a project to be successful everyone must see the value of clear and concise communication. I worked with a company recently who insisted they use a large project RACI (Responsible, Accountable, Consulted, Informed) spreadsheet to show who was responsible for what. It was difficult to read and as a result people were confused as to their role, causing all sorts of problems. We circulated a one slide Powerpoint organisation chart as an addendum to their spreadsheet. It quickly communicated everyone’s roles. It certainly wasn’t perfect but it greatly improved everyone’s understanding of how to work within the project team.

Feedback

Working without regular feedback is asking for trouble. After a few months of hard work you could discover that you misunderstood what was required originally, or that things have changed so much leaving your solution redundant.

I did some consultancy work a few years ago for a company’s IT department who were developing a support system for their business. They were about five months in to the build when we met them. They hadn’t talked to their internal clients since putting together the requirements document and weren’t planning to do so again until it was time to test the finished system. We encouraged them to go and get feedback straight away. They discovered that their contacts had left the department and the replacements had no idea IT were building something for them! The result was a disastrous system that met no-ones needs.

Courage

Tackling problems early, telling people what they might not want to hear, standing up for the team, all these things take courage. Avoiding problems till later on nearly always makes them worse. The best example I can think of is unrealistic deadlines. It’s always better to discuss these early on with the client even if the conversation is difficult. Then you can start negotiating what can be delivered and what can’t, rather than leaving it as a nasty surprise at the end when the project overruns.

Respect

Respecting the project and the people within it enables the team to work together effectively. Quite early on in a project it usually becomes obvious who is for and against the change the project will bring. If there are key personnel with no respect for what is to be done, it becomes difficult to move the project forward.

We worked on the build of a big web project for a UK government department. At first the head of IT had little time for what we were trying to achieve. His new chef executive had forced the project on him, and he had seen several similar projects fail. As time progressed we worked hard to develop a relationship with him. This along with some early successes helped to win him over and he eventually became very useful in helping us deal with some difficult technical problems. Respect sometimes has to be earned.

What other values do you consider important? Let us know by commenting below.