I’m guessing most people are expecting me to talk about making a decision on whether to use Scrum or Kanban. But I don’t believe that’s the biggest decision to make. The first thing when starting Agile at the team is to ask “what’s in my way of creating and delivering value?”
Although Scrum proponents hail Scrum as a good way to figure this out there are other, faster methods available (mostly just look at your current situation and see where your blockages and large queues are – see Value Stream Impedance Scorecard for more).
Common challenges are:
- developers & testers don’t collaborate well together on stories
- people aren’t interacting well with each other
- the lack of cross-functional teams is causing delays
- work is not done in short cycles so feedback is hard to get
- teams are being overloaded with work
- teams don’t know how to write small stories
Clearly Scrum & Kanban both attempt to address this in their own way and it should be clear how each one addresses these. Your choice though is to learn a framework or method that helps you with these challenges or in your initial training work on them directly – and then adopt a Scrum/Kanban approach that best fits your situation.
Why You Must “Do” Agile Before “Being” Agile
I often hear that you can get people to do Scrum but it won’t last unless they learn to “be” Agile. I suggest Scrum often fails because teams never learned how to do Agile. Scrum is a framework, a potential path to Agile. Conflating these two has many companies adopt Agile by getting certified in Scrum and hiring a coach to help them fill it in with practices
The challenge with this is that teams were already busy with their work before their training and now they have even more to do because Scrum appears to be a set of practices & meetings. They haven’t learned the Agile “doing” yet.
You obviously can’t teach the doing of Agile in 2-3 days. Agile is a method of collaborating with the customer, defining small pieces of work to do, creating them & getting feedback to ensure you’re on the right course. Yes, a new way of being is needed, but it is easier to act your way into a new way of thinking than think your way into a new way of acting.
Getting started with Agile means to take a sustainable step of doing with just enough of a framework to keep it going and to encourage improvement. The focus should be on the doing. Working together effectively may create the being. But the doing alone will be an immediate improvement.
SAFe has many concepts across its levels-strategic themes, epics, solutions, value stream, MVPs, MMFs, capabilities, stories & several backlogs.
While SAFe nobly attempts to present all needed concepts it does not explicitly call out the most important one–the smallest chunk of work that will provide the most value for the time it takes to build it. We call this the Minimum Business Increment (MBI). It is very similar to Denne& Cleland-Huang’s Minimum Marketable Feature (MMF), which, unfortunately, SAFe changed original meaning of to represent “the minmimum functionality that the teams can build to learn whether the benefit hypothesis is valid or not.” This concept is already part of Agile which always suggest to build in vertical slices to test our hypothesis.
SAFe definitely intends to have the concept of the MBI, but its use of overloaded &redefined terms make it hard to see. MBIs encapsulate the intention of solutions, MVPs, capabilities & SAFe’s re-defined MMFs. Realizing this can simplify SAFe by starting with initiatives that are consistent with our strategic themes & defining a sequence of business increments for them. These business initiatives can then be refined into MBIs which create the context for everything needed to manifest value.
We hear so much about how adopting Agile is hard. It is worth looking at the exceptions in order to learn why it doesn’t have to be that way.
Let’s consider the case of a dev group of 75-300 people. This is a good example of a common situation. The organization was looking at improvements, focusing on product management, and organizing how people work together. Specifically, here was what they paid attention to. Continue reading “The Common Aspects of Almost-Instant Agile Success”
There are many lessons we can learn from the challenges incurred in adopting Scrum. I suggest the significant amount of bad Scrum in the world is due to the approach in teaching it.
The most popular method focuses on the framework itself. It usually consists of a CSM taught to a team. Some guidance is provided on how to write stories, but the attendees spend virtually no time writing their own stories past the ubiquitous “as a user…” method which is insufficient in the real world.
Another method focuses on Agile analysis by having teams create a backlog of their own stories using some aspects of ATDD. Only minimum training on Scrum is needed since it is now in support of what the team’s work & they already have an understanding of the why for feedback.
We have found the 2nd approach to be significantly more effective because people leave the workshops actually doing Scrum & don’t have to figure out parts later.
I see the same thing happening with SAFe with different ramifications. The SAFe framework alone often improves orgs’ agility because of the quarterly planning event. But working with product managers prior to the event & teaching teams more ATDD & less SAFe is critical.
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”
I’ve always been bothered by the dismissal of XP as just being “Scrum with tech practices.” But the differences between the two are much greater. First, while XP and Scrum both have related values, the practices of XP are mostly centered around sw development practices (such as paired programming), while Scrum is mostly about non-domain specific team practices. Second, XP includes Acceptance Test-Driven Development (ATDD). ATDD, which is a collaboration between the Product Owner, dev, and tester and which includes neither design nor coding and is therefore, not a technical practice. In other words, Continue reading “XP is not Scrum with tech practices & knowing why this is so is more important than ever before”
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”
I see a need for a new service and wonder how many people would be interested. As many people know, we’ve been on the front edge of XP, Scrum, Kanban, Lean, SAFe, technical Agile and more. We, of course, do assessments and Lean-Agile Transformations. In the course of these proposals I have noticed that many companies don’t have experience selecting who will work best for them Continue reading “Want an experienced person helping you with Lean and Agile proposals?”
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”