While Agile has made a definite improvement in the world since it started 2 decades ago, it is hard to argue that it hasn’t stagnated. We hear about dark Scrum and fake Agile almost as much as the real thing.
4 or 5 organizations dominate a focus on frameworks and certification and not on true learning. These companies are proud that they can release new versions every 1 or 2 years while espousing their clients to do it continuously.
Continue reading “If you’re wondering what’s next after Agile or are tired of limited offerings, here’s a place to go”
Agile has moved from the team to the enterprise with the goal being business agility. We need a system that takes us from strategies to realization. This has two tightly connected phases – the discovery of what to work on and developing it.
Business has the responsibility of discovering what these small pieces are – both who is being targeted and what value is to be delivered. These are presented to the development group in the product backlog.
What these pieces are is the missing concept I am referring to. Many people are using the term MVP for this, but an MVP is about discovering if a new product is viable. It starts small and grows.
Most large organizations have strategies and initiatives for extending existing products and services. This requires going from big (an initiative) and making it small. This is accomplished by ‘asking what part of an initiative can we deliver sooner?’ This is not just about being small, however. It must also contain all of what’s needed. That is, what shared services, ops, marketing, support is required to achieve value? So it can be thought of as the smallest container of what is needed to provide the quickest realization of value.
We call this the ‘minimum business increment.’
For more on MBIs and how they relate to MVPs, go here.
Originally posts August 2013.
Disclaimer: I could have named this framework/method/process tunnel vision, but that seems a bit redundant. So don’t infer I mean to pick on any Agile approach that is a framework over one that is called a method or a process. I am just using the word framework generically. For the purposes of shortness, whenever I use “framework” in this blog, pretend I’ve said “framework/method/process/…”.
Continue reading “Framework Tunnel Vision”
Creates a customized roadmap that attends to the needs and culture of the organization adopting it. This includes a customized starting point. Together these avoid a “one-size fits-all” mentality
Provides a support system used by practitioners to help them solve their challenges
Is geared towards practitioners becoming self-sufficient.
Is based around the value stream, making it easier to see how well the organization is doing and what they have to do to improve.
Provides a measure of improvement not based on how well the framework is being followed.
Doesn’t require a change in values in order to start. While the framework should help improve the culture of the organization, values change slowly. Remember, it’s easier to work your way into a new way of thinking than think your way into a new way of working.
Makes explicit how its practices manifest Flow and Lean principles
Has meaningful certification. Merely taking a class and passing a test just means they learned some information. Courses should include how to train and enroll people in new ideas. 0->60 in 3.5 days is meaningless.
Does not get more complicated as it evolves. It must be organized in a way that both scope and depth can be added without adding complexity.
Ref: Understanding Fake Agile by Steve Denning
There has been a lot of buzz around Mr. Denning’s comments in this article as SAFe being “the epitome of fake Agile”
But the real message is earlier, when he postulates the “3 laws of Agile”
- Law of the Customer—an obsession with delivering value to customers as the be-all and end-all of the organization
- Law of the Small Team—all work is carried out by small self -organizing teams, working in short cycles and focused on delivering value to customers
- Law of the Network—the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers
In summary, focus on the customer with small teams working as a network
What does this require?
Clear vision of who your customer is and what value you are going for. Work on delivering value in small increments so small teams can do the job. Create the alignment and proper communication channels networks require. These don’t just don’t happen on their own
I suggest that these three ‘laws’ can be used by those selecting an approach to take by considering how the approaches manifest them (or not). Designers of frameworks need to consider them as well.
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.
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.
FLEX leaps beyond the normal frameworks of today that are somewhat preset in how they work.
There are three mindshifts in FLEX:
1) our goal is business agility – the quick realization of value predictably, sustainably and with high quality
2) people do need a set place to start but it can be based on their needs, not a preset approach that makes selling courses easier
3) we must focus on the work by attending to flow using Flow and Lean thinking
FLEX’s approach is simple:
1) see where you want to go
2) see what’s in your way
3) create a roadmap to help alleviate these challenges
4) start working
5) improve your explicit workflow, policies, practices as you go
It’s a myth that you need a one-size fits all approach that preset frameworks provide for consistency. FLEX is as well documented as SAFe but is documented as a live document which is literally updated by the consultant using it to guide you.
Check it out at www.netobjectives.com/events
Quick recap (see earlier posts):
- How did Agile get to be so unagile
- take a systems thinking point of view. Use Lean to create a great environment
- Focus on business agility – the quick realization of value predictably, sustainably and with high quality.
Flow thinking is looking to see how to take an idea to realized value as quickly as possible by working on what will achieve the greatest value, educing delays in workflow, by getting quick feedback, and not creating rework. Lean’s mantra of “just in time” guides us in how to make decisions on when to start work. Its “build quality in” has us stop creating unplanned work due to errors.
But Flow thinking also means we have to attend to the work – not a framework. All too many times people adopt Agile by spending most (all?) of their budget on the framework or relegate how to do the real work to 2nd tier training. Einstein would say this is insane given the patterns of challenge this causes.
Ask yourself when you’re considering an adoption – which is more important to know – the framework or how to do the work? A framework sets the stage for the work, but won’t teach you how to do it directly.
if you find this blog interesting you might want to check our upcoming webinars. See NetObjectives.com/events.
It is difficult to get a man to understand something, when his salary depends upon his not understanding it. Sinclair
The task is, not so much to see what no one has seen yet; but to think what nobody has thought yet, about what everybody sees.
All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. Schopenhauer
Those who do not learn history are doomed to repeat it. George Santayana
I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem. Buckminster Fuller