Managed Agile Development Framework

I’ve seen many people ask a question like “should I use Agile or Waterfall for a project? That presumes that this is a binary, all-or-nothing choice that you have to choose one or the other and not both. It excludes the possibility that there is a hybrid approach that provides the benefits of both approaches.

A few years ago I was responsible for managing a large government project that required meeting some defined cost and schedule milestones but the customer wanted to take an Agile approach to defining the requirements. In response to that project, I developed an approach which I call “The Managed Agile Development” framework that would satisfy those two seemingly inconsistent goals.

  • We were able to successfully build a partnership with the government client in which we did a very professional job of managing overall contractual requirements at the “macro-level”, and
  • Within that “macro level” envelope, we were still able to implement a fairly Agile development approach at the “micro-level”

Managed Agile Development Framework

I’m providing a brief description of how it works here (refer to my book for more details). There are two layers in the framework as shown in the diagram above. The “Macro” layer is plan-driven; but it can be as “thick” or “thin” as you want it to be. The “Micro” layer can be any Agile development approach such as Scrum.

  • The macro-level framework is a plan-driven approach, designed to provide a sufficient level of control and predictability for the overall project. It defines the outer envelope (scope and high-level requirements) that the project operates within
  • Within that outer envelope, the micro-level framework utilizes a more flexible and iterative approach based on an Agile Scrum approach that is designed to be adaptive to user needs

Naturally, there are tradeoffs between the level of agility and flexibility to adapt to change at the “micro-level” and the level of predictability and control at the “macro-level”. It is important that both the client or business sponsor and the development team need to agree on those tradeoffs. The framework provides a mechanism for making those tradeoffs by making the “macro-level” as “thick” or “thin” as you want to fit a given situation.

  • Increasing the level of predictability and control requires beefing up the macro-level and providing more detailed requirements at that level and implementing at least a limited amount of change control
  • To increase the level of agility, you can simply eliminate the macro-level altogether or limit it to only very high-level requirements
  • Other elements of the framework can be easily customized or eliminated depending on the scope and complexity of the project and other factors

A question that often comes up is “How do you handle change control?”. The answer to that question is that you have to design enough slack into the milestones at the “macro” level to allow detailed elaboration of requirements to take place in the “micro” level. However, when there is a significant enough change in the “micro” level that would impact achievement of the requirements in the “macro” level, that should trigger a change to the “macro” level milestones. This general approach can be used on almost any project.

Check out my online training course, “Mastering Agile Project Management” to learn more about developing a hybrid Agile approach and some case studies that show how it has been used successfully.

A Hybrid Agile Development Framework

I’ve seen many people ask a question like “should I use Agile or Waterfall for a project? That presumes that this is a binary, all-or-nothing choice that you have to choose one or the other and not both. It excludes the possibility that there is a hybrid approach that provides the benefits of both approaches.

A few years ago I was responsible for managing a large government project that required meeting some defined cost and schedule milestones but the customer wanted to take an Agile approach to defining the requirements. In response to that project, I developed an approach which I call “The Managed Agile Development” framework that would satisfy those two seemingly inconsistent goals.

  • We were able to successfully build a partnership with the government client in which we did a very professional job of managing overall contractual requirements at the “macro-level”, and
  • Within that “macro level” envelope, we were still able to implement a fairly Agile development approach at the “micro-level”

Managed Agile Development Framework

I’m providing a brief description of how it works here (refer to my book for more details). There are two layers in the framework as shown in the diagram above. The “Macro” layer is plan-driven; but it can be as “thick” or “thin” as you want it to be. The “Micro” layer can be any Agile development approach such as Scrum.

  • The macro-level framework is a plan-driven approach, designed to provide a sufficient level of control and predictability for the overall project. It defines the outer envelope (scope and high-level requirements) that the project operates within
  • Within that outer envelope, the micro-level framework utilizes a more flexible and iterative approach based on an Agile Scrum approach that is designed to be adaptive to user needs

Naturally, there are tradeoffs between the level of agility and flexibility to adapt to change at the “micro-level” and the level of predictability and control at the “macro-level”. It is important that both the client or business sponsor and the development team need to agree on those tradeoffs. The framework provides a mechanism for making those tradeoffs by making the “macro-level” as “thick” or “thin” as you want to fit a given situation.

  • Increasing the level of predictability and control requires beefing up the macro-level and providing more detailed requirements at that level and implementing at least a limited amount of change control
  • To increase the level of agility, you can simply eliminate the macro-level altogether or limit it to only very high-level requirements
  • Other elements of the framework can be easily customized or eliminated depending on the scope and complexity of the project and other factors

A question that often comes up is “How do you handle change control?”. The answer to that question is that you have to design enough slack into the milestones at the “macro” level to allow detailed elaboration of requirements to take place in the “micro” level. However, when there is a significant enough change in the “micro” level that would impact achievement of the requirements in the “macro” level, that should trigger a change to the “macro” level milestones. This general approach can be used on almost any project.

Agile and Lesssons Learned From Martial Arts

I was engaged in a discussion on LinkedIn that made me think about the relationship of Agile and Martial Arts like Karate – in theory, there should be a lot of similarity:

  • Techniques – There are a wide range of Martial Arts techniques that can be applied in different situations
  • Finesse and Skill – Most Martial Arts require finesse and skill; it’s not just a brute force approach
  • Levels of Skill – There are different levels of skill associated with Martial Arts and it is an ongoing journey to become a “master”

In actual practice; however, I think that Agile principles and practices are at a very low level of maturity compared to Martial Arts (that’s perfectly understandable given that Martial Arts have been around for thousands of years); however, there is a lot we can learn from martial arts that can be applied to Agile:

  • Techniques – Agile has become synonymous with Scrum as the primary methodology for implementing Agile and our knowledge of implementing Agile successfully is heavily defined by the “mechanics” of how to implement Scrum. Surely, there must be more to Agile than that. That’s equivalent to saying that Karate is the only Martial Arts practice when there are many, many others.
  • Finesse and Skill – I’ve seen many companies take a very superficial approach to Agile. They will do a few Agile practices like holding Daily Standups and putting up Kanban Boards and call it Agile. In many cases, if you look under the surface, it’s still just a brute force approach to get things done. They haven’t really fully implemented Agile principles and practices and they haven’t mastered the skill and finesse needed to do it well.
    • People may not be dedicated to Agile teams
    • The company may still rely on overtime, weekend work, and pressure to meet unrealistic deadlines
    • There may be no Product Owner role and the business side may not be well-integrated with the project
  • Levels of Skill – Many people don’t seem to realize that there are different levels of skill associated with Agile (some of those levels aren’t even fully understood yet).
    • There is a wealth of knowledge about how to do almost every aspect of Scrum at the team level but very little is understood about how to scale Agile to an enterprise level and how to integrate it with a business environment that isn’t necessarily well-suited to Agile.
    • There are also still very wide gaps in our understanding of how to blend Agile principles and practices with more traditional project management principles and practices which are often seen as competitive rather than complementary with Agile.

There’s a particular concept from Martial Arts that is helpful to understand the level of maturity we are at in Agile. The concept of “Shu-ha-ri” is a Japanese concept to define different levels of proficiency in Martial Arts:

  • “Shu” means to keep, protect, keep or maintain. During the “Shu” phase, the student builds the technical foundation of the art.

    In “Shu”, the student should be working to copy the techniques as taught without modification and without yet attempting to make any effort to understand the rationale of the techniques of the school/teacher. In this way, a lasting technical foundation is built on which the deeper understanding of the art can be based

  • “Ha” is the second stage of the process. “Ha” means to detach and means that the student breaks free from traditions to some extent.

    In the “Ha” stage, the student must reflect on the meaning and purpose of everything that s/he has learned and thus come to a deeper understanding of the art than pure repetitive practice can allow.

  • “Ri” means to go beyond or transcend. In this stage, the student is no longer a student in the normal sense, but a practitioner.

    The practitioner must think originally and develop from background knowledge original thoughts about the art and test them against the reality of his or her background knowledge and conclusions as well as the demands of everyday life. In the Ri stage, the art truly becomes the practitioner’s own and to some extent his or her own creation.

  • (Source: Shu-Ha-Ri http://www.aikidofaq.com/essays/tin/shuhari.html)

    If you think about our current level of knowledge of Agile as it exists today, I think many people are still struggling with the “Shu” level to understand the mechanics of how to do Scrum and have a long way to go to really get to higher levels of mastery. I’m not sure how many people realize how big this gap is between where we are now and where we need to get to. I think there are many people who seem to think that all there is to know is the mechanics of how to do Scrum at the team level and I think we have hardly scratched the surface of the knowledge that is needed to be known about how to successfully do Agile Project Management.

    Martial Arts have been around for thousands of years and there’s still a lot to be learned so its very understandable that our level of knowledge about Agile is at a fairly low level of maturity. For example, here is a very good article written by Patti Gilchrist on the innovations that Bruce Lee has brought to Martial Arts that has some similar thoughts to this article that I really liked: http://www.projectmanagement.com/articles/278838/Of-Martial-Arts-and-Methodology