There are a bunch of different frameworks, tools, and processes that serve different needs, and we have included a bit of a summary below. This is by no means complete and is meant to serve as a starting point and guide for discussion.
Scrum works very well in problem spaces that are building a deliverable that is complex. The framework optimizes around time boxes for activity as a technique for decomposing work into accomplishable pieces for inspection. If the work can be planned in short iterations, it helps significantly in the adoption of Scrum. Scrum is often heavy on overhead if the deliverable is well-known and/or simple.
Kanban works well in interrupt driven work, or a mixture of plannable and interrupt drive work. The focal point of Kanban is the flow of the team and optimizing the system for throughput measured regularly. Typically, the work is complicated but not overly complex. A multi-discipline team is expected for Kanban, but not required.
Lean works well with systems that serve the business well but want to continue to improve over time. Lean focuses on waste reduction and incremental improvement. This is often used well to locally optimize but can struggle when applied to multiple level and multiple dimension problems due to the definition of “waste” changing based on perspective. This can be combined with multiple other frameworks and approaches.
Traditional (Waterfall) processes work well in known project spaces, or high-risk problem spaces where safety risks are prevalent. Contrary to common belief you can combine these practices with more incremental delivery to gain some of the advantages of agility without the procedural oversight needed for some work areas.
You may be reading this and wondering where all your favorite scaling agile buzz words are. We haven’t forgotten about the scaling area. We have done a lot of work with Nexus, LeSS, SAFe, DAD, Scrum of Scrums, and many other scaling systems. We will explore those frameworks in a future article because of complexity of the conversation.
Key 11: Not an agilest factory
The roots of lean manufacturing have helped to shape the business agility space for decades, and we see often how that can create great outcomes. Unfortunately, it can also create some base level assumptions that stunt growth and stall adoption. The ideas we mean are those that compare agile mindset growth to factory work. The ideas show up in presentations that sound great, but often fail to provide the promised value. Things like “Agile Coaching bootcamp” that promise coaches in 12 weeks without any previous experience in agile, or an “Agile Dojo/Agile factory” that teams come to and do agile “right” for 2-3 sprints and then go back to their normal work location to continue on. Please don’t misunderstand, there is value in immersion programs like these. Each of them tries to push on speed to value because of a history of slow change. Quick results can create momentum and support for an agile adoption and justify budget for continued investment. Unfortunately, we have seen that each team’s journey to maturity is going to be different. They will share some common experiences and trying to force the learnings to fit a mold can limit how effective the change is.
As we shape the next variation of our business, the dynamic tension between speed to results and long-term foundations is something to foster as it keeps the balance without creating too many rigid systems. The tension is uncomfortable, and that helps to create the right conversations. We talk about this as the balance of wide boulevards and high curbs. We want teams to have a lot of space to maneuver and autonomy in those areas, while also drawing lines around that space for areas that the team is not allowed to change. Things like remote work policies for a company may be something a team is not allowed to change in isolation, but the update format and work distribution is likely in the defined autonomy for the team.
This doesn’t have to be a laundry list of areas, and often starts as a couple bullet points. Once the transformation starts to grow beyond the initial group of change, we will see guidance and decision trees evolve. Exceptions will happen, and we aim to cover the 80% case and give a path for the other 20% to differ. We want this to be over seen because of the pain of change that we discussed in Key 3: Follow the recipe.
Key 12: Just keep changing, just keep changing, just keep...
Business agility is not a destination, and it will never be done. … Ok, breathe. That is hard to read. When we look back 20 years, the business environment, technology, and practices look very different than today. In the next 20 years, we expect that more change will continue and probably be faster than it is today. In that light, a successful adoption is one that gets the organization comfortable and good at change. That doesn’t mean that all changes will be successful, and even the successful ones may not become pervasive in the organization.
We found that implementing a recurring process for teams to get outsider feedback and perspective a couple times a year helps to maintain the focus on continual improvement. This can take the form of an internal coach rotating amongst mature teams, or potentially a TNT event. A TNT event is a 1 to 5 day workshop for a team to tear apart their processes and define experiments that they will try over the next three to six sprints. We call it a TNT event because the intent is to blow up our assumptions and pre-conceived ideas and try something new.
If you would like some help to define flexible guidance for your team, or in planning of a TNT event please reach out and we will strive to help without cost.
If you are looking to connect on a broader set of topics and connect with other community members and leaders, as well as hearing from industry leading experts, take a look at Improving Edge and register for a great set of thought leaders in many areas.