Slaying the Dragon: Oldies but Goodies in an Agile World
Attending the PMI Global Congress a couple of weeks ago reminded me that good ideas have staying power. There were several presentations on managing agile projects. As I listened, I was reminded of some of my past projects. Here are a few principles that have always worked for me and that can apply to agile projects.
Divide and Conquer
When I was first promoted to project manager, I was given a large new project to tackle. One of my colleagues told me that he was glad I was assigned the project. He said that he dreaded hearing of a new initiative, because he imagined a large dragon with its head peeking around the cubicle wall. I loved being a dragon slayer. I took that fire-breathing beast and cut it into several pieces, which we prioritized and completed more or less successfully. The “less” had more to do with not getting input from enough business subject matter experts, but the principle of breaking a large project into smaller chunks worked wonderfully.
The Project Management “what” vs. “how”
Deliverables have always counted more on my projects than activities and tasks. Deliverables focus on what needs to be done. Tasks provide actions – how each deliverable will be produced. In his Global Congress presentation, Why Agile Focuses on the Work-Breakdown-Structure and Frequent Communications, Clement J Goebel described the application of the Work Breakdown Structure (WBS) to the agile environment. I continue to believe that the deliverable WBS is one of the most useful concepts in the PMBOK, and I was delighted to hear how it applies to agile projects. As a project manager, I was the only one I knew who never used a Gantt chart. Sure I had activity lists, but each task was tied to a deliverable. A feature if you will.
Whose Project is it, anyhow?
I learned early in my project management career that trying to control scope was a losing battle – one I fought courageously, but never won. I learned that requirements, the basis of the project scope, needed to be prioritized by the business, not by me. On some agile projects features are prioritized by the role of the product owner, or business representative, not the acting project manager.
The Three “I’s.”
In the mid-90s I worked on a large project, one of the organization’s early “RAD” projects. RAD stood for Rapid Application Design/Development. We were trained by a consultant, who taught us the principle of the Three-I’s” – Iteration, Increment, and Involvement. We learned to do iterations, focusing on prototyping as a way to drive out requirements, although in all honesty, our iterations were more of a hybrid approach than is used today. The increments were time boxes. Again, our time boxes were longer and looser than those today, but they certainly helped.
Perhaps the most important of the “I’s” was Involvement. We were fortunate, indeed, to have a full-time business expert move from her office in the merchandising department, where she was one of hundreds of buyers, to our IS area where our team was co-located. Her presence was invaluable to the project. Today we would probably call her the product owner, but we called her a BUC– Business User Coordinator. She facilitated the requirements workshops, prototyping sessions, and user acceptance testing. As code was developed, she brought other client representatives into our area to show them prototypes and ensure they were on board with the new system. She participated in sponsor meetings, particularly when there was conflict between SMEs.
Our BUC worked in true partnership with the business analyst who ensured that the requirements were clear, that dependencies were taken into account, and that the design, code, and testing addressed the approved requirements. She also helped ensure that the interfacing systems and programs were completed, since there were many hundreds of programs that needed to be changed to accommodate the new system. There was virtually no conflict between these two roles. The term “collaborate” was not in our vernacular, but that’s exactly what they did.
Although the project was considered highly successful, one of the main missing ingredients had to do with me, the project manager. In retrospect, I should have spent more of my time removing obstacles (of which there were massive numbers) and let the team figure out how to get the project done. I should have worked for the team, instead of viewing the team as working for me.
Final thought. It seems to me that agile was built on some pretty solid principles, but these have been taken to a whole new level, vastly improving the software development process.
Don’t forget to leave your comments below