There are six major actions that need to be in place in order to achieve significant improvement in an organization’s capability to deliver value quickly. These can be implemented in different ways depending upon the needs and culture of the company. These are:
- Identify and prioritize the work to be done
- Have an effective intake process to avoid pushing too much work onto the development group while ensuring the most important work gets done
- Create clear requirements
- Coordinate the work of the teams
- Teams work together with a common cadence and frequent synchronization
- Core DevOps
Here are the best solutions we’ve found in 20 years: Continue reading “What work we need to focus on”
Many consultants repeat the refrain that Agile is hard because change is hard, people resist Agile, and systems are complex. These are over-simplifications of what’s really going on.
While changing our personality is hard, changing the way we work is only hard when we don’t see what’s in it for us. Preconceived solutions imposed on us often appear as extra work and we resist it. When a solution is based on solving our challenges we are likely to embrace it.
Understanding Flow and Lean enables making reasonably good predictions on whether something will be an improvement. But the way people work together is complex, meaning there are unknown relationships and personal behaviors. These often block our intentions but expose themselves when they do. We can incorporate these insights into future improvements making them more likely to succeed.
I do believe the most coaches are well intended. But the above reasons given for dark Agile are self-serving and hide major flaws in Agile adoption – focusing on the wrong thing and teaching in the wrong way.
People can understand Flow and Lean principles when they are related to their past experience. The focus needs to be directly on our challenges and how to overcome them. Not a framework that on average may be an improvement.
I will quickly follow up this post with what we need to focus on.
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.
Refactoring is defined by Martin Fowler as “improving the design of existing code.” Refactoring stipulates two things: that behavior does not change, and that the design has been improved. While developers have been “cleaning up” their code from the very early days, Fowler made this a discipline that developers can collaborate within. He defined a shared way to do it. Continue reading “The Value of Refactoring Skills”
I believe the next mindshift in software development will be as big as the one from waterfall to agile has been. Agile is now over 20 years old– a lifetime for the information age. This is evidenced by rise of new methods like Flow and Lean and new technologies like the cloud and AI.
Agile’s growth has been fueled by the successful marketing of a few companies that somehow created the belief that certification in a framework is more meaningful than learning the principles underneath them and the work required to be effective (e.g., ATDD, automated testing). Most certification courses are not taking full advantage of the latest insights now available. And most use old-school training methods that are expensive, inefficient and in some cases preclude customizing the materials promoted
We’re told complexity prevents those new to Agile from understanding principles from the beginning and that there aren’t best practices that can be readily tailored to the needs learning them. Many of us have demonstrated otherwise.
I’m up to changing this along with many other thought leaders.
If it seems that I’m tearing down something, it’s only so I can help build something better.
Once upon a time 2 really smart guys came up with a simple framework for teams who knew what they were doing to build products. It worked well. Other people who knew what they were doing started doing it. Then those that didn’t know what they were doing started doing it figuring they’d now know what they were doing as well.
It became popular because for the cost of a 2 day course you could get certified in that you knew what you were doing.
The framework was promoted as being the same as Agile, when it wasn’t. Companies that wanted to go Agile wanted folks who knew what they were doing so started hiring these master. This had the framework start to be used everywhere, even where it was not designed for. And, with its success, it became closed to new ideas by allowing new things to be put into the framework, but never allowing a challenge to the foundations of the framework
Then another group decided that they could take this framework and wrap it with their own. Now they had a big framework for all companies. And they put Agile in its name because no one knows what Agile is anyway
So now we have all of these people doing something called Agile that isn’t.
The moral of the story? A framework won’t help you become Agile. Focusing on your work may.
Systems thinking tells us to attend to the relationships between the components of a system more than the components themselves. The challenge is as the number of components increase the number of relationships between them increases exponentially. And, when these relationships have to do with human behavior they are only somewhat predictable. But this complexity does not mean that we cannot make reasonably accurate predictions about the affects of change in a system. Nor that we can’t learn how to make better predictions when we are wrong. While it is true that one cannot have certainty on what affects a change will make, there is a fair amount of predictably available.
The approach to take is to make predictions based on the laws of development present and on the known relationships and current state of the organization. We can make a change, but know we may be missing some relationships and possibly be misinterpreting others. We therefore consider the change an experiment. One that we think will work. If we don’t get an improvement we have likely found out about a relationship we weren’t aware of or a relationship that we have to be careful of. In either event we’ve learned something and our next “experiments” should be better.
Most frameworks are adopted in one way. Scrum has immutable roles, rules, events and artifacts so any start will attempt to have those. While you may vary things inside of it, this makes it somewhat of a static framework. SAFe’s implementation roadmap is the same regardless of the organization using it, taking a bottom level up approach since that is supposedly simpler. Neither take a look at where the organization is with the exception of some minor adjustments within the framework.
Taking this approach has the following disadvantages I’ve mentioned before:
- there is a tendency to focus too much on the framework at initial training – leaving less time on what the organization really needs to learn.
- when challenges arise people tend to look at the framework for answers, when a basic understanding of Flow and Lean would suffice
- the framework often doesn’t fit the organization adopting it well for any number of reasons and often does not fit the company’s culture
The result is that they only fit a certain number of organizations and those are typically the ones where teams are easy to form. A framework that adapts to the organization adopting it is critical. This increases adoption speed and value achieved while avoiding resistance.
MVPs were defined by Eric Ries to mean “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
If you are an established company, especially if you are using SAFe, the chances are excellent that you area not creating a new product but enhancing an existing one. You already have a customer base, know a considerable amount about your product and you have competitors you are trying to either keep ahead of or catch up to. This is a considerably different situation than creating a new product that you hope will create a new market.
In this situation, product development starts with initiatives to build. he question isn’t so much how do you discover if there is a product, as is it “what is of the most value that we can deliver sooner.” This requires a different tact. This is what a Minimum Business Increment is for. MBIs are that smallest part of an initiative that will realize the most value when delivered. This is a far cry from the MVP where we start small and extend.
While both MVPs and MBIs are conceptually about value sooner, they are considerably different in implementation. If you’ve been having trouble using MVPs, now you know why.
This is to people buying Agile training and/or coaching
A key aspect of Agile is respecting people. Yet, this is often lost when we get to Agile transitions, particularly Scrum. This is not a knock on Scrum, but rather how it is commonly trained & adopted. We often hear devs say:
- daily stand ups are a waste of time
- we’re not getting any value out of our retrospectives
- why do we have to <fill in the blank>?
A common reaction to this is that devs are not motivated or don’t see the value. But think about for a minute-hat if your customers said something like the following about your services?
- <something customers have to do to use your service> are a waste of time
- we’re not getting any value out of <this aspect of your service>
- why do we have to <fill in the blank>?
Would you pay attention? Would you ask why they have that problem? Would you force training down their throats and make them pay for a coach to help them use your product?
So why don’y you do that with your staff? You are the Agile consultancy’s client. You don’t have to buy in to a service that your users (devs, …) are having troubles with. There are many ways to adopt Agile. Use one your people will find effective.