MoreAgile, shock or goal?
Just like the Agile Manifesto was a shock 10 years ago, the MoreAgile Manifesto creates some shock effects now.
Responsibility is scary, Business value is undefined, partnership feels impossible and change is kind of accepted but not loved.
- Over the next coming years expert professionals will become very rare, so employers will have to make the difference by creating the best possible workplace. Part of this will be that responsibility embraces empowerment and that the freedom that comes with this will be the only thing wanted by this professionals.
- Business Value is already important today, however difficult to measure. The Lean and SixSigma movements are creating a setting where not measuring value is not done. This expertise will be the a good basis to use as a logical measurement tool for success in software delivery.
- Endusers are rapidly maturing into strong groups with an opinion that matters. Social media will help them to raise their voice. Service companies and software suppliers will have no other option but to deliver services in partnership to catch up with the high demands from the market.
- The speed of change will go up for another couple of decades. Sprints of 2 weeks are far to long, waiting to see something in production that is already finished will no longer be accepted. Just responding to change will simply not be enough. We have to love change.
It took us 10 years to create a world where the ideas of the Agile Manifesto are accepted and commonly used. Likewise, MoreAgile is not something we will easily achieve. The ideas are bolt and a lot of things need to change before we can really work MoreAgile.
I can imagine reactions on the original manifesto like this :
If interaction is your goal, good luck ! There will be a lot of interaction and it will leed to nothing because the process isn't followed. I don't hire people to talk to each other but to do their job.
Working software over comprehensive documentation ? Good luck ! Working software is of no value whatsoever if nobody knows what it does. The documentation makes the software usable. So if you really want to focus on software, you'll find hard times, because nobody will know what to build, and once build, nobody will know how to use it nor how to maintain it.
And then, do you really think that any supplier will be willing to collaborate without a contract to cover his ass ?
The last one is the most ridiculous one .... In serious projects
whole divisions can depend on the milestones of the project. If the
plan is not followed, the entire company can be into stress. Make a
plan and do whatever is needed to stick to that plan.
Even now, this kind of reactions are still heard but more and more (big) organizations are convinced that Agile working can help them to become more competitive. It's no longer weird to start a change that will lead to a general focus on interaction between people to deliver working software and useful feedback in close collaboration with the customer.
Looking back at all the fights fought, it's impossible to predict what battles we'll all have to win to find ourselves in a MoreAgile world, but I can draw a sketch of what ideas we need to embrace to start to journey :
Teamwork & responsibility over Individuals and Interaction
Teamwork is highly underestimated. Pair programming is a form of teamwork that has proven to be very effective, but still’s not generally accepted. Kanban embraces the idea of stopping the team if part of the team is in trouble. But it feels not efficient, and that hurts. You’re paid and assessed as an individual, so you want to be the best as a person.
Responsiblity is another great challenge. “Make sure things happen” is one of the best explanations I ever saw for the word ‘responsiblity’. It’s not about getting your head chopped off if you fail, it’s about making decisions that lead to delivering the promised. It’s about empowerment and creativity and it’s about mindset and passion.
Business Value over Working software
‘Business value’ has become a hollow phrase, but in fact, it really means something. It is about real value for the customers ! To value business value over working software could cause a problem to be solved without software change, but more important it’s about measuring and realizing. ‘What you measure is what you get’ is a known statement. So let’s measure earned business value per story instead of estimated hours, let’s have burndowns on earned dollars and plan sprints based on business value. Each Sprint must deliver more value then the cost of the Sprint.
Partnership elaboration over Customer collaboration
Nothing wrong with collaboration. Partnership is stronger. It implies shared ownership of the problem, true comprehension of the problem and shared willingness to resolve the customers issues. ( Note: The customer here is the enduser, not necessary the one who pays the bill).
Embrace change over Respond to Change
There will be change ! A lot of it. The world is changing every minute. In a month time this adds up to fairly big changes. It’s good to worry if you’re still doing what you planned last month, because the chances of it being still the best thing to do are pretty small since the world has changed.
MoreAgile, shock or goal ?
In our current way of working and thinking I beleive it is impossible to work in a true MoreAgile mindset. Responsibility is scary, Business value is undefined, partnership feels impossible and change is kind of accepted but not loved. The need to change this will inevitably come, with a new norming system coming from that:
- responsibility embraces empowerment and the freedom that comes with this will be the only thing wanted by professionals.
- not measuring value is not done. Insight in delivered business value is a logical instrument for measuring success in software delivery.
- partnership is the only option to answer the the high demands of endusers with an opinion that matters.
- change is normal, and we love it!
MoreAgile is our goal ! And if it's not, something else will come up, but it will hold the same ideas.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)