So you were promoted as a project manager some years ago. You have also educated yourself on (PMI’s) golden triangle (scope-time-cost) of project management, and you have “successfully closed” your projects over the years. Now you hear a lot about Agile (project management) as a new way of managing projects! Some claim that Agile doesn’t care much about documentation, hence maybe no documentation! Others claim that the team manages everything, hence no need for managers to “monitor and control” scope or time commitments! Ah – why so many variations in understanding of agility in managing projects?
You know that you had kept your project schedules based on your team’s availability, and you have aligned your schedules with your planned projects to meet your stated scopes. You have managed your projects to meet milestones by “monitoring and controlling” your planned project tasks and deliverables. Then you took training courses about Agile (or Scrum for that matter) where you were challenged with much conflicting information about Agile project management. Add to the complexity if you are a hardware engineering manager where (by experience), you “know” that “time boxing” and short iteration of developing hardware projects will not work!
I have heard many surprising statements from a few hardware (and software) engineering managers. They even persisted on their claims until we further discussed on how Agile (as mindset) would offer many desired results if we apply its principles and values “correctly”.
You see, it’s really easy to learn about Agile in a short training course or workshop. Our experienced managers have had their success in leading their teams using proven structured PM methodologies. There is a reason for the success of PMI Body Of Knowledge (PMBOK), or ITIL, PRINCE2, and the others. Statistically, however, structured (or waterfall) project management yields fewer success rates as tight “command and control” creates slippage in time, or scope, or budget (refer to many online reports by simply searching online for statistics about the success rate of waterfall projects).
When examining change management in any organization, leadership tends to evaluate all possible Agile frameworks that are adaptable in the organization. In one of my (introduction to Agile) workshops I briefly outline the characteristics of over 16 different Agile frameworks and practices. I have always said that there is no magic wand and one-fits-all framework to agility at work. Agile change management is to produce values based on customers most desired needs. I think Agile team building is much like building a community of cross functional members, much like a village where community members roll up their sleeves to build their village. A coach is holding the lantern to brighten possible ways of doing things and helping others when needed.
Couldn’t agree more with both David and Donald. The ability to distinguish framework from philosophy comes after being into a few sprints. Even though I read about Agile & Scrum, the concepts were foggy. Once you see it in action, that’s when clarity seeps in, and does not become confusing at all!
I agree that a short training course or workshop on agile isn’t enough. I would also add that the key to success in applying any Agile approach increases with practice. Take Scrum for example. Where Agile is a philosophy, Scrum is a framework that functions within the agile philosophy. If you don’t have any familiarity with how Scrum works within the Agile philosophy, you can easily fall into the typical traps that renders the application of Scrum ineffective.
Experts say that in most cases you usually begin to realize how the dynamics of Scrum works after you have had a chance to experience your third sprint. This makes sense, because in most cases one needs to experience the subtleties within this practice in order to understand it and avoid many common traps and misconceptions. Only until then does one start to realize how powerful it can be when applied correctly. After a few sprint cycles one usually realizes its results and starts to trust its application. Having an experienced Scrum Master or Scrum Coach on your team at the beginning of the Scrum transformation can help get the team to this point quickly.
Once a team becomes competent with Scrum, it should consider combining it with other Agile frameworks, tools and techniques to further increase project outcomes. Incorporating other Agile practices such as SAFe, Kanban, or tools such as JIRA, Trello, Asana, or techniques such as Sequence Backlog Roadmap, User Design (UX), Extreme Programming (XP), Test-Driven Design (TDD), Continuous Deployment (CD), Continuous Integration (CI), just to name a few, can help improve the team’s performance.
An interesting aspect about Scrum is that if this discipline is applied correctly as a project’s first approach, many of the aspects within its framework such as “transparency, reflect and adapt” and “fail fast” will help the project team understand and successfully explore if other frameworks, tools and techniques can and/or should be applied to realize better results.
Scrum serves as a great starting point for Agile transformation. That’s why one of the key objectives of the SVPM Scrum Team volunteer program is to offer the opportunity for all volunteers to learn Scrum first and experience at least three sprint cycles so they can obtain confidence in its application and witness its results. This also sets a good foundation for them to be able to compare and explore other Agile frameworks, tools and techniques to further increase project outcomes.