I've seen a lot about Agile over 20 yrs. I remember 15 yrs ago people moaning about lack of trust & respect. Now it seems that we just say that's what you need.
Paraphrased from the Scrum Guide - "Successful use of Scrum depends on people becoming more proficient in living the values of commitment, courage, focus, openness & respect. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team & its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members
respect each other to be capable, independent people."
Wouldn't that be nice. But change doesn't happen like that- note Richard Pascale's “People are much more likely to act their way into a new way of thinking than think their way into a new way of acting.”
Now we're pretending we can just be like Lean Startups. Even though we can learn from the Lean Startup we must remember existing companies have a different problem- how to align people, not how to use aligned people to discover what's important.
Systems-thinking tells us to look at the entire system. It's more about the relationships between the pieces than the pieces themselves. When we focus on components we will get unpredictable results. But seeing all of the potential interactions in large organizations is also not possible.
Nevertheless, as Edwards Deming said “A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centers, and thus destroy the system … The secret is cooperation between components toward the aim of the organization.”
The trick is to understand patterns of behavior & get quick feedback. on how the system is working. It also requires leadership in both how the organization is run and what it is working on. This also requires management because although the best organizational structures will emerge, this emergence must also be fostered.
An environment in which teams can self-organize to work effectively towards the business' goal must be created. Product management is required so that everyone is clear about what they should be working on. The last piece is how to allocate capacity to the most important investments being made.
The Minimum Business Increment (MBI) is the most significant concept I’ve seen in 20 years. It originates with Denne and Cleland Huang’s Software By Numbers. An MBI:
Is the smallest chunk of value that can be realized
Is all of what is needed to realize the value
has value associated with it so we should be able to sequence our MBIs
This looks similar to the Lean Startup’s MVP but is considerably different. An MVP is about discovering if something has value and is being built around an already aligned team. MBIs are more about extending existing products where teams may or may not be aligned.
While MVPs can be conceptually used as MBIs, they become an overloaded term that causes confusion. MMFs have this same problem (note, the book Lean UX never mentions MMFs). In any event, we should be finding only those parts of a feature that are in the MBI we’re working on. These may or may not be marketable.
By starting with MBIs, at the top, we can use an MBI mindset to first sequence our MBIs to know what order we’ll work on things and where to allocate our capacity. Then, as we decompose them, we know not to build anything that is not needed by the MBI. This provides us alignment, focus and fast realization of value.
For the last 2 decades I've been trying to help companies be more effective when software's involved. Knowing how to write small stories based on testable specifications, being able to write quality code, having good Scrum Masters & management who understands Agile are required. Missing any of these pieces causes most teams to bog down.
A few months ago we figured out how to integrate Scrum & ATDD in a more cost effective way than just Scrum Master training. The key is to have much of the course be hands on with people's own stories.
I'm proud of this course - I believe it is one of the most significant breakthroughs we've had in 20 years. But this still leaves the other 3 needs out. Not coincidentally, we've recently completed online courses for just these 3 things. As much as for helping ease my frustration with so many people spending their budgets on the wrong things as it is to help sell our course, we're now bundling these into team-level courses.
As Ken says, "Scrum is simple." I'll add you don't need to spend 2 days on it. Spend your budget on harder things to learn. Doing Scrum is a lot easier to do if you know what to do inside of it. But the insides are what you should learn with it, not later.
An MBI is the smallest chunk of work that realizes value for its intended target- customers, an internal provider of services, or the company's people creating new services. The key word is realizes as the focus of business agility is to realize value quickly, predictably, sustainably and with high quality.
Agile methods too often focus on software's release. Release is just a step towards realization of value. The difference is that most often there are things beyond technology's release of software that are needed to realize value.
But why the focus on business? Great companies have a great focus on serving particular customers. They do not go after everyone. So who is the customer is an important business question. The first step in portfolio management needs to understand what a business is going to invest in. Of course, most of this will be for selected customer, but not all of it. These are business decisions. Hence what is built are business increments. In order to be able to compare the value of MBIs they must be about business value since some may not involve the customer
Everyone agrees that to understand a new concept you must use it on your own problem. Somehow this has been overlooked in both Scrum and SAFe for the Team training. Not having hands on their own problems requires teams to either figure this out on their own or bringing in additional training &/or coaches. The focus on the framework also ignores that people can only absorb so much at any one time, so going into depth on the framework does little good. Only a core is needed with the rest being best deferred until after people have tried the basic concepts.
How initial training fits into the bigger picture of Scrum or SAFe adoption is also critical. By taking advantage of different learning modalities, it is possible to get initial training that covers the core of the framework as well as what’s needed to do Agile. Initial team training should focus on the actual Agile work teams need to do such as writing small, clear stories that will realize value. This does require follow up training for the Scrum Masters, some basic technical Agile training and some management training as well. These, however, can be done over time and online with coaches supporting them.
This is the basis for Net Objectives Team-Agility Training
This is to people buying Agile training &/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 standups are a waste of time
we're not getting any value out of our retrospections
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 imagine this for a minute. What 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 &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. Find one your people will find effective.
Recognize that changing how someone "be's" is a lot harder than changing what someone does.
Agile best starts by doing.
Take advantage that devs want to produce good results
Provide them with some principles they can relate to from their past experience
Small batches are good
Focus on finishing is important
Clarity of requirements is needed
Focus on value delivered not rules to follow
There is a big difference between describing what a story should look like & actualy writing good stories. They must learn to write quality stories from their own backlog in the initial training. This requires ATDD to some degree
Provide them with a starting point ranging from Scrum to Kanban, or something in between, that includes a support system to get questions answered
Find some people in your organization that would be good Scrum Masters/Team Coaches and enroll them in a program where they learn on-the-job for several months to both do their job and to provide an environment to help the team get their job done
If you have budget for it, bring in an outside team coach who knows Scrum & Kanban
Always focus on the work, not the framework
Always remember your people are doing the best they can
The above works
Read Full Article
Read for later
Articles marked as Favorite are saved for later viewing.
Scroll to Top
Separate tags by commas
To access this feature, please upgrade your account.