I remember my first SAFe implementation – Northwestern Mutual (you can see a case study of it on the SAFe website). I remember that my main focus was on training the managers, product managers and shared service managers. While I did do a SAFe/Scrum course for the train, I wasn’t particularly worried about them. Continue reading “Why teams starting out with SAFe need little SAFe training but do need ATDD up front – 6 days to #SAFeSummit”
When people adopt SAFe they often believe that the way to do work with each other is by having everyone adopt SAFe’s roles and act accordingly. But this is a componentized view. That is, it looks at the organization as a collection of pieces and won’t result in a true system. A system is not the sum of it’s parts but rather the synergy that its parts create when working towards a common goal.
We have found that all roles need to agree to work with each other in order to achieve the following: Continue reading “How do we work together at Scale? – 7 days to #SAFeSummit”
A question often arises of how to connect strategies, which are long term thinking, with the shorter event horizon of small increments of delivery. The first part of the answer is to shift our thinking from project thinking to product/service thinking. This means that we think of the offerings we provide and consider how we consistently improve them instead of doing a series of one-off projects.
We manage these improvements by creating initiatives based on our strategies and then consider the business increments we want to release on a regular basis. Continue reading “Implementing Strategies with Small Pieces of Work- 8 days to #SAFeSummit”
Frameworks in and of themselves are not the goal. This is sometimes forgotten when Scrum is conflated with Agile. Scrum is a means to Agile, but it is not Agile in the same way a recipe is not the meal. Recipes have ingredients, an order to cook, how to cook, etc. Frameworks provide us with roles, rules, events, structure (of the people) and events. These are all required for effective work. Continue reading “What is the purpose of a framework? 9 days to #SAFeSummit”
Essential SAFe is intended for when a group of teams working together using SAFe. It presumes that a backlog has been created for the train(s) to work on. Most groups starting SAFe at the program level have done so, however, because they can’t get product management involved or believe the higher levels of SAFe are too complicated. Continue reading “What to do when prod management won’t provide MBIs to a program – SAFe countdown #10”
Many dev groups in large companies start with Essential SAFe because they are the only group starting SAFe. This is not a bad way to start. However, many of the concepts needed for such groups are described at levels above the Essential SAFe level. This can be confusing.
We suggest adding the MBI concept as we discussed in the earlier post. In this situation, as epics comes in, the dev group can break them into MBIs by collaborating with product managers & asking them the following questions: Continue reading “Essential SAFe for Large-Scale Companies – Countdown #11”
Essential SAFe was intended for large orgs adopting SAFe at the program level. But many mid-scale companies have adopted it as well.
Mostly they’ve done this because of: Continue reading “Essential SAFe for Mid-Scale Companies – #SAFeSummit 12”
Many mid-scale companies feel they are in the dilemma that LeSS is insufficient while SAFe feels like too much. Many decide to use the SAFe program increment planning event but are left with little guidance on product management. SAFe”s intriguing because it provides many good insights – MVPs, MMFs, Solutions, and more. But many of these are discussed mostly at the portfolio level or above. Continue reading “How Midscale Companies Can Use a Lightweight Version of SAFe – #SAFeSummit 13”
The purpose of Agile@scale is business agility- the quick realization of value predictably, sustainably & with high quality. We know we want to realize value in increments, but what do we call these increments? I say “realize” not “deliver” because the mere delivery of software often has no value- it usually requires non-software aspects to be useful. Continue reading “Focus on Realization of Value, Not Delivery of Software – #SAFeSummit 14”
We suggest our clients focus on:
- Systems thinking
- Quarterly business planning or shorter
- Small business chunks so you can release quickly
- Creating the right environment for teams to work in
- Acceptance Test-Driven Development
- A flow-based mindset
In over a decade of doing Agile at scale, we’ve found the most important concept to be that of the smallest realizable chunk of business value (hashtag14’s topic). But why small? Continue reading “The Case for Small When You Are @Scale – #SAFeSummit 15”