Last week I gave a deep dive workshop in the Agile Games New England conference about the NEED for engagement and participation when implementing agile at scale using an approach like SAFe as well as how I use online games like Kahoot and Socrative and various points throughout the implementation to increase engagement and participation especially when working with big groups beyond the team. Here’s my slide deck from the talk:
SAFe (The Scaled Agile Framework) uses Story Points throughout the various levels as its estimation currency. This is covered in the “Story” article on the SAFe site. This is a pretty standard practice in organizations scaling agile these days. If you dive a bit deeper into how this is done in SAFe you will see that actually the story points used in SAFe are quite similar to “Ideal Developer Day” as this helps the teams align to a common baseline and support a rational economic ROI discussion at the level of Features/Capabilities that require effort from more than one team or haven’t even been mapped to a specific team yet.
An alternative to using Story Points at the team level that is interesting to look at especially as Kanban is becoming a first-class citizen of the SAFe world is to use NoEstimates.
What is the connection between Uncertainty and the Scaled Agile Framework?
Uncertainty is one of the core reasons we need to be agile. Different modes of Business/Requirements/
Making it Concrete – The Stacey Uncertainty Matrix and its relation to the Scaled Agile Framework
As I wrote about at some length in Risk-Aware Product Development (a.k.a Agile) explaining the concept of Requirement/Business/Technology uncertainty is one of the first things I do with most audiences I meet for the first time. On a Leading SAFe/SPC class this typically takes place in the first module when we go over the need for SAFe. This is not a core part of the materials but I take the time to explain it anyhow and then find myself referring back to it throughout the workshop.
The first layer of realization is that our problem with the classic approaches to product development is that they were built for complicated endeavors but not complex ones.
Then we layer on more interesting realizations like the fact that for some endeavors like those approaching the “Anarchy”/”Chaos” domains probably the best approach would be a “Skunkworks” style cross-functional co-located fully empowered small team. As you grow a bit farther from Anarchy you can scale agility using an approach like the Scaled Agile Framework. At these levels of uncertainty/risk the trade-off of distributed teams, distributed PI Planning, system team, component teams, shared architects/UX MIGHT make sense and are worth considering.
As you approach the simpler domain sometimes even the alignment rationale for “whole train” PI Planning can be reconsidered. Is that SAFe™ heresy? maybe. But I find that telling people “Whole ART PI Planning” is mandatory is less effective than showing them WHEN it has a better economic impact. (BTW as you grow in complexity/uncertainty you also need better people that are more engaged – which the Whole ART PI Planning helps with as well)
In general, this thinking helps leaders at these workshops grasp the various economic levers that go into tailoring a SAFe™ implementation. I find this disarms some of the resistance you get when people feel something is “a must”. Using this approach they typically go out with a stronger conviction to avoid some compromises and a better feeling about the compromises that do make sense.
To take another example of how I use the uncertainty matrix during SAFe™ training/implementation discussions – SAFe™ talks about a hierarchy between ART Product Management and the Product Owners working with the teams. A typical and sensible question people have is “Who should wear the Product Owner hat?”. Using the uncertainty matrix, we realize that in some cases the Product Owner should be a Product Manager (probably the top two quadrants of the matrix) and in some other cases he can also be a more technical leader (Especially on the far right side of the matrix). As the typical organization I work with is struggling to fill those Product Owner roles, this realization helps them deploy their people more effectively in a way that minimizes the risk of ineffective feedback loops due to the wrong individuals being in the tight Product Owner loop.
Understanding uncertainty and its attributes and implications is in my view and experience a critical step of buying into the need for agile as well as gaining the ability to design an effective agile approach for your context. Presenting the Stacey Matrix and trying to map it to your reality is one technique I used to help people gain this understanding. Using it as a decision filter/design criteria for further SAFe™ tailoring questions complements this initial presentation/exposure and grounds it. If you are teaching Leading SAFe™/SPC classes, explaining the need for agile to leaders/executives, or working with an organization to implement a scaled agile approach, I believe you will see improved results if you add this technique to your toolbox. I know I have.
(This post is based on content which originally appeared in an interview I gave InfoQ for Lean Kanban France 2014)
A pattern I recognized on enterprise agile transformations is the difference between the guided tour and guide book approaches to change management.
This pattern basically talks about this choice that people have to make between following big, organized, prescriptive framework or basing their decisions on principles and then choosing the different practices that make sense along the way. Continue reading “Just because you hate guided tours doesn’t mean you need to hate SAFe!”
In parts 1 and 2 of this series about bringing Invitations into the Scaled Agile Framework implementation approach I talked about various ways to switch from Mandates to Invitations when choosing the timing and the how-to. In this post I describe an even more Invitational style using an approach called Open Space Agility. Consider this an experimental suggestion that combines two field-proven practices into one mashup that is just looking for the first opportunity to get its field test (If you’re interested to go for it, let me know…)
In this approach the leader would say something like “We decided to use SAFe in order to XXX insert Commander’s intent here XXX. We know this is the direction we want to take but we need your help figuring out how this would work here in our group. Scaling Agile is a complex thing and while we the leadership team believe SAFe is a good starting point we also believe there are many open questions and risks and we want your help figuring this out. We also want to do Continue reading “SAFe Invitations – Part 3/3 – Combining Open Space Agility and SAFe”