As project managers we are bombarded every day with challenges – changes in scope, difficult sponsors, distracted customers, confused team members, cuts in agreed budgets, legislative updates and other changes in our environment. Some of these are under our control, and others that we just have to grin and bear.
In response to this constant hum of activity, agile project management has become very popular. If you ask a project manager whether they are agile, the answer is invariably ‘yes’. But many find it difficult to apply many of the principles from agile software development to the world of project management. How does continuous deployment work for non-software projects? How can we apply practices such as pair programming to the challenges of managing projects?
Like many other methods and standards, the underlying principles will work, no matter the industry or domain. We just need to be careful when interpreting the principles to establish day to day activities.
To help, here are 8 key questions you should ask yourself regularly.
1. How is the customer involved?
Though we often say customers are our number one priority, they are often quarantined after an initial scoping workshop and review. In an agile world they need to be constantly involved. Having a customer (be they internal or external) co-located can bring about a much greater understanding for them as well as the development team. Wherever possible they should be a key member in the team. Depending on the business culture this is not always possible; sometimes developers don’t want a product owner breathing over their shoulder. Other times product owners simply have other priorities and ‘just want it built’. In both cases this is more about education and managing expectations and outcomes than it is about people ‘not getting along’.
Assessing customer satisfaction is often a good proxy for intentions, involvement and ultimately the success (or failure) of the project. This shouldn’t be a six monthly survey – it should be face to face on a regular basis. I’ve seen this done daily and at weekly workshops and meetings. This is extremely effective as misunderstandings can be addressed quickly and expectations reset if needed.
2. What are you and your team doing to build trust and collaboration?
As the success of a project moves away from enforced compliance to standards and complex processes and more towards collaboration you must be constantly driving attitudes and behaviors of trust and teamwork. You need everyone on the team to understand their value and how they need to work together in the true (and unforced) sense of the word.
You should use whatever means available to build teamwork and collaboration. This means finding a way of co-locating the project team (or using virtual tools if geographically distributed). You could also challenge the team to self-organize and prioritize themselves – if you do this make sure you establish boundaries and decision-making scope.
In achieving co-location and people-related changes, make sure that you have the support of the project sponsor or an executive/senior manager. Not having this is often a BIG demotivator for staff.
3. What does your critical deliverable look like?
Whether you are developing a physical product, a piece of software, a service, or some combination you need to know the critical few functions/elements that the customer absolutely must have. By understanding the Minimum Viable Product you can ensure something usable can be delivered straight out of the gate.
Remember though that the product/service must be valuable to the customer. So controlling the quality of deliverables is critical. So make sure you understand what quality means to the customer on a practical level.
4. How do you ensure the intended activities and critical processes are being followed?
Many new agile PMs frequently hear in the press about dropping processes in favor of interactions between customers and project team members. They see the heavy process frameworks like CMMI and how poorly many of these initiatives have performed. They think ‘Aha! I don’t need to use process now!’
But it is VERY important to understand that the original Agile Manifesto emphasises ‘Individuals and interactions over process and tools’. It DOESN’T say ‘Individuals instead of process’. Be selective and focus your efforts on the critical processes. You are working with thinking human beings, not robots – so we shouldn’t treat them that way. It’s your responsibility to ensure that everyone understands the critical processes – such as iterations, dealing with problems and how to turn requirements into top quality deliverables that the customer is willing to pay for.
In agile projects it is important that someone is responsible for assessing and monitoring how the processes are performing. This may seem obvious but it is often overlooked when people are down in the weeds trying to get a working product ready.
A term that is being used more widely and frequently is that of Technical Debt. It is the “short cuts” that result in work that will need to be done some time in the future – mostly after a project is finished. What technical debt are you (or your company) being asked to take on by taking shortcuts and making over-expedient decisions?
5. How often in your ‘information radiator’ updated?
Many project teams have a Gantt chart pinned on the wall. While this might be a good start you can do so much better. An Information Radiator (coined around 2000 by Alistair Cockburn) is a large and highly visible board to show planning and progress of the team. It can be handwritten, drawn, printed – I’ve seen some very effective electronic information boards linked dynamically to defect databases, integration stats and many other sources.
Positioning this information radiator centrally – often where Daily Standup meetings are held (you do have regular meetings, don’t you?) ensures everyone has a good understanding of progress.
6. How do you manage changes in product requirements?
Having a lengthy requirements specification or similar document is a big red flag from an agile point of view.
Keep the requirements to bite-sized chunks in a tool that allows for easy prioritizing, review and updating. User stories provides an effective method for business and operational staff to express themselves in a manner familiar to them. That way you won’t get caught in interpretation conflicts and other misunderstandings. It’s better to have a set of effective requirements that aren’t pretty than to have a beautifully presented System Requirements Specification with 10 signatures that is outdated before the ink dries.
7. How are your 5 key metrics trending?
Make sure that you have a clear understanding of how each metric (and hence the team) is performing over time. Simply having a snapshot is not effective and can lead to wrong short term, knee-jerk decisions being made.
As a PM running an agile project you need to manage estimates and continually monitor the effort and duration of tasks. As many team members are themselves still improving their knowledge of agile practices they often do not have adequate estimating skills. They may have not recorded the time they have spend previously nor the magnitude of their development deliverables.
8. What improvements did you complete last week?
Add a question to your weekly review or staff meeting – what have we improved? Even though everyone understands that we need to constantly improve, they are often too busy with the project and simply assume someone else will improve.
With the plethora of improvement methods and techniques available these days, it is easy to be overwhelmed and try to tackle a number of them at once. The best advice I can give is to “Keep It Simple”. Streamline activities, meetings, processes, reports – pretty much everything you can whenever you can.
Tomorrow, take 15 minutes to sit down and ask yourself some of these questions. Are you happy with your answers? How would your team respond?