Most of my life I have been involved with projects. Many of them large, complex and involving creating innovative software products; my career has not been for the fainthearted.
Over the course of these last 25 years a great deal of water has passed over the dam in the development of Project Management methodologies. Also process based technologies have made for a more systematized approach to creating successful products.
During this time many of these methods have become institutionalized, certified, authorized and pasteurized. We now have PMBOK, Prince2, Agile, Scrum, CMMI, ISO, ITIL and a whole lot more to choose from to prove our credentials in an industry discipline that had little to start. Times have changed.
Agile may be been a late comer to the Project Management ball, celebrating a ten year birthday, but it has made a huge impact. Because of the radical nature and departure from “other project management” methods then in vogue, it got noticed. It also focused heavily on software development, which seemed to be (and perhaps still is), more art than science.
The squabbling continues
Articles abound purporting the benefits and problems associated with one method or another. Agile has been no stranger to this criticism; however the search for innovation does not just lie in technology development, but also in the manufacturing process, itself. The difference being not just one way doing the work, there are many.
The tremendous improvements that are core to Agile development include; transparent and continuous communication within development teams and customers; willingness to listen and integrate changing requirements and total interdependence of team members. These are foundational principals that should be a part of any project; regardless whether the end product is a software system or a residential home.
However, believing that Agile alone will instantly create a Kumbaya atmosphere for your project is not a good assumption. Team members also need structure to work successfully, and much the elements from other Project Management methods can be integrated with Agile to get the best of both worlds.
Imagine having an argument for which drink is best … coffee or milk? They are different but both serve a purpose to satisfy a need for refreshment, and provide nourishment. The bottom line is many like to have both coffee and milk together. So goes it with Agile and Non-Agile Project Management methods; different but not incompatible.
Researcher and Project Managers agree on a blended approach
Many organizations are now taking a blended approach and organizations such as Forrester Research recommend including traditional and Agile skills, traits and methods.
|
Project Management’s PMBOK advantages |
|
Agile promotes |
|
· Clear guidance on project initiation and closure. · Communications management and project integration management. · Project cost management. · Risk management |
· Cross-functional, empowered teams. · Flexibility and adjustment throughout a project. · Encouragement of strong working relationships with customers. · Just enough rigor and documentation |
The table above illustrates the benefits of such a blended approach as recommended by Forrester Research
There are thousands of projects that individual Project Managers (Owners) where the benefits of such a blended approach have been espoused. So the combination of different methodologies is now becoming very commonplace in many industries, not just software development. When you see leading legal firms such as Seyfarth adopting lean and Six Sigma, you just know that things are changing.
Agile Stepping Stones Approach
As a part time ski instructor in the winter, I have come to learn that you need a lot of skills, lessons and techniques in your bag. The Professional Ski Association of America teaches these skills to instructors with a combination of observation, lesson planning and execution is required. If a student cannot learn a technique through one approach, then you can try three others that may resonate with them.
This approach is known as stepping stones. Where progress is made by selecting different skills, models and examples and then traversing up the learning curve from there.
We can learn much from this approach by applying those agile attributes and methods and creating “our own agile blend”. This will allow an organization to take the best of each approach as it relates to their particular problem or project.
As an example, much of my current software development work is carried out across different countries and time zones. By using a more “heavyweight” documentation approach, there is a reduction in corrective iterations of the software that could be very costly. So we put more emphasis on user interface designs and detailed use cases to remove ambiguity from the early stages of a project. Conversely we use all available communications tools in reviewing and problem solving during the development cycle. These include Web conferencing, Chat, Skype and revision controls.
By picking our spots to use Agile, it may well be that less is more. We only force the benefits of agile where they are adding value to the project, and avoid methodology wars amongst our colleagues and teams. Just was different materials are used in creating products, we can apply the same principles in techniques and perhaps make it to the other side with our team and goals intact.
[...] Agile methodology: The case for a blended Agile [...]