The Big Agile Learning Framework
If we accomplish one thing in Big Agile, we hope it will be to provide a way for people to think about what they are doing and create a learning framework for being able to do it well and take it to scale.
We don’t want to try to present the one right path you have to follow – because we think each situation will require distinct strategies. But we also want to get beyond the intuitive approach. Just saying, “Eliminate waste, identify and remove impediments, and write code better” is not enough guidance to create a reliable and sustainable approach that can be scaled . So, what is a structured way to think about being good at Agile that supports getting big? Part of the answer is to focus on outcomes and purposes using capabilities. But how do we apply these and where do we start?
First off, teams are the organizational units that actually produce value. So getting small teams highly productive is the right place to start. Then, as we scale, the principles that make the small team function well scale into different instances of the same principles. The objective is to add the least amount of overhead possible at each order while maintaining the productivity of the small teams.
Today, I present the (draft) Big Agile Learning Framework. This reflects the approach I have intuitively used when approaching this problem. The three dimensions are Value, Velocity, and Context. The capabilities of the organization operate together in an interdependent way. Understanding how each one plays in this model, and how they impact each other, is a key to developing situation specific strategies for taking Agile to the Enterprise.
The Big Agile Learning Framework
Value, Velocity, and Context
Value: What the product development team provides back to the business that the business might sell to an actual customer.
When we look at value, we want to identify what Jack Welch called the value nub – the intersection where low-cost and just-the-right-features intersect. Moving up on the value axis means moving towards the nub. In Agile, we leverage the ability to get a working product to the customer frequently to continue to narrow in on the value hub. This helps us reduce the costs and risks associated with a granular up front requirements effort.
Velocity: The rate that work is moving toward its objective.
Confusion over the distinction between speed, utilization and velocity is a common problem. Velocity is speed in one direction. The car driving 60 mph on a straight road has much higher velocity than the one going 60 mpg on a winding road.In Agile we increase velocity through finishing what we start, coordinating hand-offs to remove delay, improving quality, and continually removing waste from our processes.
Context: The environment that the team operates it. It is shaped by the team, the organization, the goal of the effort, and the sphere of influence of leadership.
Software development is a knowledge-based endeavor. People need room to think and innovate. Difficulties in the context can compromise efforts to improve Value and Velocity. In Agile we improve context through commitment to a productive environment, empowered teams, disciplined compliance with the team standards, working toward individual mastery, bringing in external knowledge, and managing expectations.
Each of the dimensions in the learning framework are interdependent. Let’s take the capabilities around requirements as an example. In once case, we put in an up front focus on detailed requirements. We think they are perfect and they take a long time. So the capability is high on value but low velocity. As we move along on the project, errors in the original assumptions and evolving customer preference degrades the actual value, moving the capability down on the value axis. If we take an Agile approach, Agile recommends a lightweight, progressive elaboration approach to requirements. This would be farther right on the Velocity axis but potentially not as high on the Value axis. Over time, as we uncover specifics and move towards the value nub, the capability raises on the value axis. We also know when to stop adding things not valued by the customer – so we don’t begin to slide down the value axis again. Experience in software development shows this is effective, but the organizational context has to allow for this approach.
The Thinking Framework is a way to frame the development of strategies as we scale. As we develop situation specific strategies to scale Agile the way that we can impact Value and Velocity become more complex But keep in mind that we must not sub-optimize small team productivity. Top down approaches have not been consistently successful in scaling agile up into the enterprise. Just replicating the same practices up through the organization hasn’t worked either. Basing our work on capabilities and leveraging the thinking framework, we are able to develop appropriate strategies.
Tags: Agile, Big Agile, Business Capability, Requirements, Software Development
This is a great post and a great idea.
A couple of suggestions on where to expand this.
1) I would suggest that you can come up with a way to quantify context, and you might even want to put it on a scale of 1 to 10, but it might also be a blend of a few factors that don’t roll up elegantly into a single score, but you could then use that to explicitly plot on the axis the different levels of value you will get with varying degrees of velocity.
2) Somewhat related to that, I wonder how much consistency there is in the relationship between Context and Value. Is the relationship linear? I highly doubt that, but it’s probably also not logarithmic.
And of course this overlays very elegantly on the business capabilities work you have talked about in the past.
That’s my $.02 on where to go next with this idea. Great stuff.
-Ric
Thanks for the positive comment, Ric.
I have some thoughts at this point to use the heat map construct: Border is Value, Fill is Velocity, the stop light is context. Special cases (constraint, type of deficiency) will be icons.
The scale or ranking needs a bit of thought.
The output needs to be an actionable and situation specific strategy that identifies which capability to create/act on next to improve performance and/or support scale.
Dennis
Dennis:
Interesting idea. However, you are approaching this with a bottom-up perspective and thus will make IT assume responsibilities of other functions. Yes, you will be able to effectively prioritize what is available, but only from the ones you have. There should be an alternate process to bring the best ideas together before you can prioritize and the software developer has only very little to contribute. I think this system maybe efficient, but not easily replicated and sustained because of the unique quality of manpower required.
Here is an Top-down approach to Business Agility:
http://www.businesschange.com/agility.htm. Please let me know your thoughts.
Deepu,
That is correct. I don’t understand the conclusion that IT will assume responsibilities of other functions or that there is some unique quality of manpower. It would be helpful to tell me how your reached that conclusion.
We are explicitly taking a bottom-up approach in presenting the model. Let me make three points:
1. Most organizations can’t effectively plan top down. This is the problem with many CMMI and OPM3 implementations. Just wanting to be agile doesn’t make you agile. In top down methods, we may think we are making the strategic choices – but most the strategic options and choices exist where the rubber meets the road. With appropriate capability at the bottom, the top down planning is not productive.
2. Our model doesn’t ask for a manager to operate outside of their sphere of influence. The small teams aren’t deciding what markets to go after, what the product parameters are, how support operates, how sales operates, what message marketing is selling. These will be determined at the right level as the model moves up. As new capabilities exist, there are new bargains at the next level.
3. The entire point is to make a sustainable model that can be replicated. Sustainability occurs when the you can reliably deliver at the small team level – this is missing in the implementation of many approaches. We don’t talk about how to identify and implement the next most important capabilities. But, we don’t expect this to be implemented in a linear fashion. We expect it to be implemented in the fashion that makes sense and is adoptable within each organization.
Thanks for the feedback. This is a great discussion.