Estimated Reading Time: 2 minutes
I’m excited to be heading to Agile 2016. I’ll be in Atlanta all week and will talk about SAFER SAFe implementations on Wednesday (See the full session description below)
This will be my first time attending/speaking at the Agile Alliance annual conference. In the past it was a tough time to travel to the US smack in the middle of the summer vacation in Israel. But now it is both an easier travel coming from Boston and I also get the opportunity to take the family along and visit friends and family in the area.
I’m looking forward to the big agile conference experience. Looking forward to meet long-time friends and make new ones as well as have some interesting bizdev discussions.
Are you coming to Atlanta? If you want to meet/catchup contact me on twitter or leave me a comment here or on the conference scheduling/social app where you can also see the sessions I’m thinking of attending.
Hope to see you there!
The Scaled Agile Framework (SAFe(tm)) is a powerful and popular framework for implementing agile at large scale across the enterprise.
In this talk we will examine some dangerous Agile at Scale implementation anti-patterns from real-world cases I’ve been involved in such as:
- Planned/Mandate-based implementation across the enterprise – Pushing implementations onto people regardless of their interest/motivation to change.
- Prescribed-based implementation – Either by the book or as designed by a central committee or an external consultant.
- Total focus on practices starting from training all the way through assessment/metrics and lack of attention to spirit/principles.
- Expecting every group in the organization to work the same way and implement change the same way.
We will then look at some healthier alternatives I used to drive more successful & sustainable change in several organizations. You will learn some concrete techniques that help live up to the Lean/Agile principles of respecting and engaging people.
Using SAFe as the specific backdrop for discussion, we will review field-proven ideas such as pull-based crossing the chasm approach to implementation, use of open space as part of the different SAFe ceremonies, and how Open Space Agility can combine with SAFe.
Note that the ideas and practices have also been tried with other Scaled Agile approaches such as Enterprise Kanban, LeSS.
- Get familiar with some scaled agile implementation anti-patterns related to push/mandate.
- Understand when to choose pull/invitation as a healthier more sustainable and successful alternative.
- Get some concrete techniques to bring pull/invitation into a scaled agile implementation approach – focusing on SAFe 1-2-3 implementation approach specifically.
- Have a high-level understanding of how to implement SAFe using “Open Space Technology”.
- Understand how to apply these ideas to any Scaled Agile approach (not just SAFe)
Estimated Reading Time: 1 minute
Two of the questions I’m frequently asked these days “Do we need the Scaled Agile Framework (SAFe)?” as well as “CAN we (safely) implement SAFe?”. I recently published a self-assessment based on the questions I typically help organizations answer when they’re looking at this. Continue reading “Assessing your need and readiness for the Scaled Agile Framework”
Estimated Reading Time: 1 minute
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:
Continue reading “Spark engagement and participation in a SAFe Scaled Agile Implementation using Online Games – My workshop at Agile Games New England”
Estimated Reading Time: 3 minutes
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.
Continue reading “SAFe With No Estimates”
Estimated Reading Time: 3 minutes
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/Technology uncertainties impact our economic costs in product development – especially the potential impact of risk. The first principle of SAFe™ is “Take an economic view”. I frequently use my “uncertainty filter glasses” to take an alternative economic view. I find it helps Scaled Agile/SAFe™ practitioners/leaders understand both the need for Agility as well as examine various work system design considerations. In this article I introduce the Stacey Matrix which is one of my favorite models for understanding the uncertainty landscape as well as implications of uncertainty on various specific SAFe™ design decisions.
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.