- An explicit starting point tailored for your organization.
- A statement of objectives for each part of the organization that allows for making local decisions in the global context.
- A support system to help you with challenges that arise so you need not reinvent the wheel
- A method of improving over time so you need not transcend the framework.
- A systems approach in guiding the adoption of the framework. This includes how to talk to the different roles in the organization.
- An increasing number of practices from which to choose without adding complexity to the framework
- Take a scientific approach and make the hypothesis that they are the best way to do what they are attempting to do. This encourages frameworks to evolve and improve and avoids dogma
- Provide a way to make reasonably accurate predictions whether a change will be beneficial.
- Be architected so they can accommodate the next three points
- Create a well-defined, customized starting point since no one size fits all.
Most of the behavior we get comes from the system in place. This means how the people are organized and the agreements (or not) they make with each other. When adopting frameworks, you are creating a new system. There are particular patterns of behavior driven by frameworks that focus on their practices more than on the flow thinking that is needed: Continue reading “Side affects of frameworks that focus on their practices and not your flow”
I’m not saying that how a coach “be’s” is not important. But it’s also not the only critical aspect of things. Good energy, knowing what to explain and explaining them well are critical. A great coach can explain the right things to people so that they can learn on their own.
The Agile community is currently focusing on certification and frameworks that make it easy to start. I believe this is much of the reason for Dark Scrum and Fake Agile.
We need to shift our focus to the laws of effective software development embodied in Flow and Lean thinking. These are usually touched on in framework training but then used to justify practices that are only partially consistent with them.
It’s amazing to me how this is as effective as it is. It is better when you integrate true Flow and Lean thinking with your practices. Go for smaller pieces, shorter timeframes and greater visibility. How to do this is easier with a framework designed around the value stream.
Don’t rely on framework thinking, rely on real thinking-yours. Don’t buy the quick excuses I hear many consultants espouse- “if only they’d do what’s in the guide”, “management wasn’t involved”, …
The job of the consultant is to guide the way, not blame their clients. That’s true being.
A pattern is a solution to a recurring problem in a context. Christopher Alexander, who created the concept, says :
“Each pattern describes a problem which occurs over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”
In FLEX’s case, the context is achieving business agility – the quick realization of value predictably, sustainably and with high quality. This, of course, requires solving several problems with each of these problems being solved in a different manner. FLEX groups these patterns those patterns that solve the same conceptual problem. Hence it consists of pattern groups with each group consisting of a set of patterns that solve the problem associated with the group. The primary groups are:
- Value stream management
- Strategies, & initiatives
- Portfolio management
- Product management
- Intake process
Patterns must include their purpose, the forces they deal with and their proposed solution(s). Patterns are also named in order to be able to identify them. This has the added value of improved communication.
Good frameworks are based on the value stream. This makes it easier for people to see their challenges and how they relate to each other. Roles are defined as responsibilities in the value stream and not as separate people. Roles can be expanded as required by the organization’s size.
Good frameworks adapt to fit the organization’s culture and situation. Resistance to adoption is lowered since the framework is presented as a solution to people’s challenges and not as something that may or may not help them.
Any practice or event in the framework should be presented as an example of what can be done. Alternatives, for different situations should also be presented.
The explanation of the framework is presented as an example of what a good organization does. More options can be provided as needed. This allows for adding options without adding complexity and still providing an holistic view.
When an adoption requires only part of the value stream to be worked on, how to influence the rest of the value stream is included.
It includes a support system to help people solve their challenges adopting it.
If licensing framework materials, how to adapt and teach the framework is also be provided.
The reason I am not a fan of frameworks is that they mostly have us focus on activities that are proxies to what we need to do to achieve what we really want to do – realize value quickly, predictably, sustainably and with high quality. Lean provides us insights on what to directly work on. Consider these 5 aspects of product development:
Focus on what’s of value to the company. Much of this will be providing better value to the customer some will be on how the organization builds them. This must be quantified for it to be relevant since everyone in the organization must see these driving factors. Use OKRs (objectives and key results) as a basis with strategies and initiatives being spawned by them.
Understand your value stream network details the steps and who does them that it takes to actually create the value.
Focus on lowering the cost of delay which is the time lost to delays in value realization. Organizational structure, development method, size of the work to be done and how people collaborate are significant factors.
Manage the flow of work and the ecosystem through which all of this flows. This includes when work is started and how decisions are made for how people work together.
Continuously improve the above.
Part 1: Frameworks are taking our eye off the ball
We cannot solve our problems with the same thinking we used when we created them. – Albert Einstein
How Frameworks Are Now Impeding Agile: Part 1
We cannot solve our problems with the same thinking we used when we created them.
There is no question that Scrum & SAFe have transformed how we work. Both have created a new mindset around work- Scrum focusing on the importance of team & SAFe focusing on the necessity to coordinate teams.
And both have now created new challenges in somewhat the same manner. Each has taken our eye off the real task- working in an Agile manner. This is finding what’s of greatest value, allocating our capacity to work on it, properly decomposing it so it can be built in increments and being able to deploy frequently/continuously. Scrum’s focus on ceremonies has takes peoples’ eyes off of how they do their work – leaving it to the team with the unquestioned assumption that they’ll figure it out (& then blaming them for not doing Scrum if they can’t or change anything in their attempt).
SAFe has gotten management involved but mostly to demand that SAFe be done. SAFe is often led internally by agents who demand that SAFe be followed. Again, the focus is on the framework.
Frameworks were an excellent way to go when we didn’t understand the mechanics of Agile. We do now. We should attend to them or at least drive our frameworks with them.
How Frameworks Are Now Impeding Agile. Part 2 – Scrum
Take a look at the common challenges teams have when adopting Scrum:
- not being able to write small stories
- essentially doing waterfall in 2 week cycles-Scrumerfall
- having many open stories at the end of the sprint
- difficulties poised by being interrupted in a sprint
- not being able to coordinate well with other teams
The similarities across widely variant dev groups is striking. Not a surprise since systems-thinking would predict this. While Scrum proponents claim “if you did Scrum these things wouldn’t happen” is likely true, what does that matter? People are doing their best.
We need to attend more to what insights & skills would help us avoid these challenges directly.
The above challenges are due to not attending to:
- managing work in process inside the sprint
- the team’s part in the bigger picture
Yes, I know Scrum doesn’t say not to do these, but that’s not the same as saying to do them.
In the early days just getting teams co-located, cross-functional & working in small chunks was a major improvement. To go to the next level we need to shift our focus to the work & how to do it.
How Frameworks Are Now Impeding Agile. Part 3 – SAFe
Many people complain that SAFe is too complicated and doesn’t truly get management involvement. I would agree. But why is that?
Take a look at the common challenges organizations have with adopting SAFe:
- little improvement beyond the program
- little improvement in the area of portfolio management
- difficulty resolving conflicting requirements given to platforms and shared services
- a continuation of top-down management
- too much work in play overall
- not being able to get deliveries within a program increment
The similarities across widely variant organizations is striking. This validates systems-thinking’s assertion that the system people are in causes behavior. SAFe proponents claim it addresses the main issues & people just need to fill things in. I would suggest that the way SAFe addresses these issues prevents people from filling things in.
Pre-defining roles & artifacts takes our eyes off of the value stream and the work that is taking place in it. This is exacerbated by SAFe overloading and redefining terms.
In the early days getting a plan for a program & having teams work together towards that a major improvement. To go to the next level we need to shift our focus to the work itself.
How Frameworks Are Now Impeding Agile. Part 4 – The Solution
Actually, if you’ve been following my train of thought here, you’d know there is no solution. But there is an approach that will lead to a solution. It’s using Lean as an overall context for your work because Lean focuses directly on the work. Lean can help achieve business agility – the quick realization of value predictably, sustainably and with high quality.
Lean provides insights to shorten the time from beginning work until value is realized. It does this by starting with the question of what’s value to the customer? Then attending to the value stream so that we can improve it to eliminate delays in workflow and feedback. By attending to queues of work we can see where our bottlenecks are and improve them. Instead of overloading teams we have them manage their work by implementing pull systems. And, because we’re looking at improving our work directly we can continuously improve.
Fortunately, this doesn’t mean we have to re-invent the wheel. All we need to do is look at the outcomes we need at each step of the way and select the best method for us to get there. This is true agility – figuring out how to solve our problems instead of taking canned solutions.
I am close to finishing “Adopting SAFe® for Your Organization: Achieving Business Agility from Small to Mid-Scale.” We take our own FLEX approach (FLow for Enterprise Transformation) and apply it to SAFe to help solve virtually all of the challenges we’ve seen small to mid-scale organizations have when trying to adopt SAFe. The result is using the core of SAFe while fleshing it out with Lean-Agile principles and patterns of adoption to create a simpler framework, albeit perhaps no longer SAFe, to use.
The list of these challenges is at https://goo.gl/Zcx7cu
Please take a look at let me know about any others.
Framework proponents suggest starting with framework training & later adding what else is needed (e.g., prod management, test-first). We believe this leads to a significantly higher cost of training
Companies with more than a few teams need a blend of Scrum & Kanban. Few companies need all of SAFe. The most important aspect of a workshop should be how to work together with your associates
Training should be oriented around
- the context of the people being trained
- increasing collaboration
- learning by doing actual work
- needed essential skills
Training in frameworks is important. But when people are given the skills they need from the start, less knowledge of the framework is needed to move forward. This is especially true when these essential skills are learned together. Not having these essential skills leaves them unprepared & often causes resistance to the framework, which, by itself, is not helping.
Unfortunately, this type of training cannot be done with certification, since certification requires a focus on the framework. Less framework, more how to do is required. Fortunately, there are many qualified, non-certified trainers out there who are more concerned with you getting what you need