I have been implementing project management systems for some time. In my experience, at the majority of companies that have declared agile project management as their methodology of choice, the reality was that there were no processes in place, no controls, no structure... nothing!
The widely used Waterfall Methodology works well if the customer knows what he or she wants, but what happens if that is not the case? What happens if the project management team thinks they understand what the customer wants, but when they have developed the system for months and finally get to a stage where they can demo something, it is not at all what the customer had in mind?
Everyone knows how long it takes to gather requirements. And everyone knows how long gathering requirements and getting client sign-off can delay the start of development.
What happens when the team is halfway through the project and the client wants one specific portion of the system to function differently? One can argue that the team can raise a scope change at this point and include it in the project scope - but what if the underlying architecture was not designed to cope with it?
Have a look at what Wikipedia says about Agile:
"Agile management or agile project management is an iterative method of determining requirements for engineering and information technology development projects in a highly flexible and interactive manner."
Use wisely
In my opinion, if used correctly, the iterative nature of agile suits the methodology required for managing software development projects. There still has to be proper and continuous planning, though.
Does the team just carry on, hoping they'll get it right at the end?
The project management team can still have its process/requirements analysis workshop with the client - but not down to the detailed level. It can plan for a release and the first iteration, but from there, the team needs to continuously plan iteration by iteration in order to refine the scope of the next release in line with changing requirements.
Instead of the project manager being the interface between client and service provider, the team needs to get involved in these interactions, because it is ultimately their responsibility to deliver what the client wants. Making the client part of the team will enhance the probability of delivering a desired product, but undocumented and rushed decisions should be looked out for, as it will contribute to scope creep that all project managers love so much.
So, if teams keep on planning these iterations, should anything be documented and signed off by the client, or does the team just carry on, hoping they'll get it right at the end?
Ducks in a row
In my opinion, the following documents should, at a minimum, be created to have some form of control in place:
1. Important design and architectural elements
2. User stories
3. Acceptance tests
4. Project schedule
In order to get a project schedule out, the functionality needs to be broken up into chunks, and for each of these chunks, the team should still:
1. Analyse and workshop the requirements
2. Design
3. Develop
4. Test
5. Deploy
The result is that the client will be able to see chunks being delivered on a regular basis instead of hoping the service provider understood what they meant. Interdependencies between the different chunks should be planned for as well, otherwise it will seem like the systems were just slapped together.
Control freaks will not like this way of working, and if they are traditional project managers, they will need to let go of the reins. They can plan the high-level details of the system, but they will need to have a tool in place, like Team Foundation Server, which can integrate into Project Server where the schedule resides. This will allow the team to break down the high-level tasks in its schedule into the chunks they require to deliver in an agile way.
Daily scrums will alleviate the feeling of chaos and will enhance team communication, but someone still needs to follow up and dish out tasks to team members that don't have anything planned for the day - otherwise the team will proverbially be failing to plan and inevitably planning to fail. Part of the daily scrums should be risk reviews, which theoretically should improve risk identification, as opposed to traditional project management, where risks might only be identified upfront and during progress meetings.
It also calls for an improvising and problem-solving approach to managing the team, as well as the project, and if the team is too set in its ways, this might not be something it should get involved in.
All in all, the sweet spot - in my opinion here - is planning accurately down to a level that is necessary for the current iteration, controlling and monitoring it tightly and closing it out when ready.
How is that for controlling the chaos?
Share