Last December, we introduced you to Tom Gilb, the Grandfather of Agile.
This month, Tom will be sharing his insights on Why Agile Needs Engineering to Scale. As the “Grandfather of Agile” Mr. Gilb has contributed countless talks, articles, and books on both engineering and project management practices.
Notably, Evolutionary Project Management or “Evo” is one of his many contributions to the agile field. Like other agile frameworks, Evo is well-suited to dealing with large, complex, innovative systems. It accomplishes this with a laser focus on delivering tangible value to the customer, early and often in small steps.
The ten principles of Evo (as outlined in Fundamental Principles of Evolutionary Project Management ) are:
E1: Decompose by performance results and stakeholders.
E2: Do high-risk steps early, learn how ‘unknowns’ really perform.
E3: Focus on improving your most valuable performance objectives first.
E4: Base your early evolution on existing frameworks and stakeholders.
E5: Design to cost dynamically.
E6: Design to performance dynamically.
E7: Invest in an open-ended architecture early on.
E8: Motivate your team by rewarding results.
E9: Prioritize changes by value, not place in queue.
E10: Learn fast, change fast, adapt to reality fast.
Evo is noticeably distinguishable from other agile methods in that it incorporates project management techniques and philosophies with true consideration of the technical implementation needs and mindset.
For example, principle E2 encourages the team to “Do high-risk steps early, learn how ‘unknowns’ really perform”. Mr. Gilb likens this approach to that of a chess player, where there are a large number of possibilities, and the player must pick one and proceed focusing on the highest value first. The risk calculus changes as the game unfolds, what is important one turn may have little impact in the next.
Principles E5 – E7 provide technical pathways that build in an expectation of changing systems allowing the team to proceed into the unknown in a structured and systematic way. By doing this, teams are forced to accept that they can’t know all of the answers upfront to mitigate the risk inherent in that reality, they must create an open architecture that can adapt as their understanding of the problem and solution evolves.
To learn more about Tom’s framework, please watch the video recording of Tom’s Agile Engineering presentation at our DC Lean + Agile Meetup.
