Business Agility Basics
Having teams run agile will quickly expose the organizational issues slowing teams down:
Differing priorities throughout the organization causing in fighting and delaying work between teams
Focus on projects splits people up into percentages and causes heroic success in one project while others are left vulnerable and understaffed
Trying to ensure everyone in the organization is 100% utilized creates massive exhaustion and causes misunderstandings between overworked groups
Product leaders do not truly understand the customer and have not validated their product ideas will work
This causes issues like slowed delivery pace, unpredictable outcomes, lack of leadership availability for team questions, people being “stolen” and a fatigued workforce that is tired and burned out.
Business Agility refers to the process of the whole organization being able to adapt quickly, experiment, and deliver solutions that meet customer needs. All while being sustainable, and focused on top prioritizes and deferring or deleting non-high priority items.
How Not to boil the ocean
Design Thinking. Jobs To Be Done. OKRs. Agile. Minimal Viable Products. DevOps. DevSecOps. TDD. BDD. Value Stream Mapping. Privacy. Move Faster. Get Bigger. Scale. Eliminate Waste. Diversity and Inclusion. Scrum. Kanban. Scrumban. Project to Product.
There’s a lot coming at your organization. New things to do, to change, to implement. How do you keep your organization from change fatigue? How do you maintain your focus?
You experiment.
Start with a vision of what you want - an idea of where you want to be six months to a year from now. Then, follow the scientific method. Remember your grade school science experiments?
Start with a vision: you want to be a responsive organization that delivers to your customers twice as frequently
Ask a Question - Use the obstacles blocking your organization from achieving the vision as an inspiration. For instance, why aren’t the teams aren’t delivering fast right now?
Research - Look at what other organizations are doing to address the issue you face.
Form a Hypothesis - Create your hypothesis in an If…Then format. So you might think that waterfall is slowing teams down, so the hypothesis may be: If we implement agile on teams, then the teams will deliver faster.
Test the Hypothesis - Run the experiment and create checks to validate your hypothesis. If in a quarter, one team delivers faster, then my hypthesis is supported and I can expand the experiment. If in a quarter, the team delivers the same, or slower, then my hypothesis is not supported and I can abandon the experiment or must modify it.
Analyze the Data - This is where companies often fail. They implement the latest and greatest, then implement more of the latest and greatest, and they do not take time to analyze the data from any of their experiments. What did the organizations find in their experiment? If the teams didn’t go faster why? Are there new obstacles that need to be addressed? Do product leaders need better ways of communicating with the team? How did the teams inspect and adapt during their agile process?
Conclusion - Let’s bring closure to the experiments alive in our organizations. If the experiment was to test agile, but then dependencies kept teams from delivering, then that discovery opens the door to the next experiment. Share those discoveries with your organization, especially with the teams doing the experiment!
Have a backlog of experiments, just like there is a backlog of work. Make those experiments time bound (no more than a quarter if possible), and keep the organization focused on the experiment at hand. Even if the leadership group feels itchy to start something new. Keeping experiments to a quarter will help with the itchiness, but so will having the leadership group go out and interview team members running the experiment (gathering data).
Visions take time to implement. Making an organization run optimally is hard work. Each experiment will bring you closer to your vision, even if the hypothesis is not correct. Running in this way will keep you from wanting to boil the ocean in your transformation to business agility.
SAFe vs Scrum @ Scale
Scrum @ Scale (S@S)
Overview: Defined as: A framework in which a network of Scrum teams operating consistently with the Scrum Guide can address complex adaptive problems, while creatively delivering products of the highest possible value. Scrum@Scale will be the lightest weight of the approaches.
Framework: Scrum @ Scale gives structures for two cycles in your organization. The Scrum Master Cycle ensures teams are enabled to deliver and improve The Product Owner Cycle ensures your product vision continues to be refined based on new data from your enterprise, customers, or the market.
Limitations: Scrum @ Scale offers no guidelines on how to set up your executive product backlog, who to have in your executive action team or executive metascrum. They also remain silent on how to handle governance, risk and controls. Nor does it share how to breakdown large features across teams. JJ Sutherland did tell me once that you can use your first sprint as a work breakdown and dependency identification sprint, but organizations rarely want to dedicate two weeks for that work.
Scaled Agile Framework (SAFe)
Overview: Scaled Agile Framework (SAFe) came onto the agile scene in 2011 to cover the issues from having agile teams and a waterfall enterprise. It has iterated its model eight times, and now you see SAFe 5.0.
Products are released in phases called Product Increments (PIs), and are delivered by groups of teams dedicated to one value stream (or Agile Release Train - ART). Where Scrum @ Scale creates meetings to scale agility, SAFe offers meetings (PI Plannings) AND specific people who are solely focused on scaling.
Framework: SAFe offers various configurations to adapt to business needs. Each configuration offers different levels of specialized roles, strategy and investment funding, so that you can ensure the enterprise meets controls necessary for your institution.
Limitations: Scaled Agile Framework is robust with several elements to help busy executives transform their organization into an agile enterprise. However, it is more costly upfront - you must train teams together before starting the release train. The roles described above are full time roles, and require either new hires or transferring responsibilities away from an individual. This focus is critical for success.