This fourth article considers the communication approach necessary for successfully combining Agile and Waterfall methods in the same project or programme. Both methods have similar steps, but their natural cycles are different and out of step with each other. This can lead to confusion and misunderstanding at best, and at worst, a complete breakdown!
4. Communication - managing expectations and uncertainties on Agile and Waterfall projects
Waterfall is based on the theory that you decide what you want, document it, design and build, and then test what has been delivered against the documented requirements (see my earlier article on requirement). These steps can then be mapped out and a timescale estimated for completing the project.
However, as soon as you have captured what stakeholders think they want - at a point in time - new ideas and feedback results in changes to the scope and requirements. Changes also arise from the external market, from new technology, from previously unknown requirements and constraints. This leads to adjustments during the project life cycle and most of the content of project communication becomes centred on dealing with the impacts on these changes in scope, cost and time.
In Agile, is recognized that we don't know upfront what all your requirements will be and that part of the project process is to assist the stakeholders to find out what the real requirements are through iterative refinement. The scope and requirements are expected to change, so the project is designe to manage these iterations (sprints). The communication here becomes focused on deciding which user features to include in each iteration. However, you don't know how many iterations you need or which features will be left out after the scope is drawn for the final iteration.
So with Waterfall the assumptions are that all requirements are known, all features will be delivered and the project timescale is predictable. With Agile the assumptions are that stakeholders will agree on which features go into each iteration and that stakeholders will commit to the project without knowing the scope, cost and timescale upfront. In this scenario the project communication can quickly be consumed with discussions of relative feature priorities, demand for the project to give assurances of scope and timescale, and dissatisfaction with the limited functionality in a sprint.
As you can see from the above, the communication needs boil down to managing stakeholder expectations and the inherent uncertainties. My recommendation for managing expectations is to ensure the stakeholders are informed of the journey that they will be part of, what key assumptions are underpinning the project strategy, and what expectations are placed on different stakeholders. This will enable questions and concerns to be addressed early early. It will also highlight areas requiring further clarification or ongoing communication later in the project.
For managing uncertainties (this also applies to risks), the communication process and communication plan should capitalize on uncertainties by demonstrating how the project methodically and deliberately resolves uncertainties. That way, stakeholder trust in the project team and processes is earned from day one, from where the initial expectations are set.
Communication is more of an art than a science, so cannot easily be prescribed. This means that you should plan for more communication than seems necessary (people can interpret the same communication differently), repeat information (using different modes of communication), and allow for feedback (with short feedback loops). Communication is as much about listening and observing as it is about presenting and publishing. It is also about being, about leading by example (you cannot not communicate!).
Effective communication is the outcome you get (i.e. successful project), not the design of your messages and presentations. The single most powerful tip for effective communication is to be clear on your intent before considering the how, what, where, when and who.
Waterfall is based on the theory that you decide what you want, document it, design and build, and then test what has been delivered against the documented requirements (see my earlier article on requirement). These steps can then be mapped out and a timescale estimated for completing the project.
However, as soon as you have captured what stakeholders think they want - at a point in time - new ideas and feedback results in changes to the scope and requirements. Changes also arise from the external market, from new technology, from previously unknown requirements and constraints. This leads to adjustments during the project life cycle and most of the content of project communication becomes centred on dealing with the impacts on these changes in scope, cost and time.
In Agile, is recognized that we don't know upfront what all your requirements will be and that part of the project process is to assist the stakeholders to find out what the real requirements are through iterative refinement. The scope and requirements are expected to change, so the project is designe to manage these iterations (sprints). The communication here becomes focused on deciding which user features to include in each iteration. However, you don't know how many iterations you need or which features will be left out after the scope is drawn for the final iteration.
So with Waterfall the assumptions are that all requirements are known, all features will be delivered and the project timescale is predictable. With Agile the assumptions are that stakeholders will agree on which features go into each iteration and that stakeholders will commit to the project without knowing the scope, cost and timescale upfront. In this scenario the project communication can quickly be consumed with discussions of relative feature priorities, demand for the project to give assurances of scope and timescale, and dissatisfaction with the limited functionality in a sprint.
As you can see from the above, the communication needs boil down to managing stakeholder expectations and the inherent uncertainties. My recommendation for managing expectations is to ensure the stakeholders are informed of the journey that they will be part of, what key assumptions are underpinning the project strategy, and what expectations are placed on different stakeholders. This will enable questions and concerns to be addressed early early. It will also highlight areas requiring further clarification or ongoing communication later in the project.
For managing uncertainties (this also applies to risks), the communication process and communication plan should capitalize on uncertainties by demonstrating how the project methodically and deliberately resolves uncertainties. That way, stakeholder trust in the project team and processes is earned from day one, from where the initial expectations are set.
Communication is more of an art than a science, so cannot easily be prescribed. This means that you should plan for more communication than seems necessary (people can interpret the same communication differently), repeat information (using different modes of communication), and allow for feedback (with short feedback loops). Communication is as much about listening and observing as it is about presenting and publishing. It is also about being, about leading by example (you cannot not communicate!).
Effective communication is the outcome you get (i.e. successful project), not the design of your messages and presentations. The single most powerful tip for effective communication is to be clear on your intent before considering the how, what, where, when and who.
Enjoy this Dilbert cartoon and think of ways the project manager could use communication skills to effect different outcomes. http://youtu.be/52yjQEEdnso
RSS Feed
