Last update: 02/06/2016 13:53

You want to give Agility a try? What are the difficulties ahead of you?

Difficulty #1: Management Support

The first and foremost difficulty is … Management. Without the proper Management, the Agile journey is doomed to failure. Management must be in FULL support and must accept to face brutal facts. No taboo must be in the way, but no company has no constraints and has unlimited resources neither! Make sure the right people are on the bus, in the right seats. Train them, and train them again and again. Make them understand that in the economy of the 21st century, nothing counts more than happy customers and nothing is making them happier than outstanding products and services. Make them embracing the mantra that They are what they do!

Difficulty #2: Change the Organization

Full support of Management (with the right people) is mandatory but isn't enough. Management needs to accept that Agility must be "cocooned". Don't expect to change the organization, this won't happen. Instead, create cocoons of Agility that are protected from the rest of the organization, where new rules get formed, rules that come from the field, created out of necessity rather than coming from the top or simply because "we always did it this way". Examples? Question your governance, the security rules, the reporting procedures, the work conditions, … Changing all that is usually impossible or too burdening. You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete — Buckminster Fuller

Difficulty #3: Knowledge Work Still Treated as Semiskilled Work

Work has shifted from semiskilled to knowledge work — Stephen Denning in The Leader's Guide to Radical Management: Reinventing the Workplace for the 21st Century and this has changed forever relationship between those in charge and those doing the work.

And again, regarding the rules we said must come from the field, let's read Peter Drucker:

Workers throughout history could be “supervised.” They could be told what to do, how to do it, how fast to do it, and so on. Knowledge employees cannot, in effect, be supervised. Unless they know more than anybody else in the organization, they are to all intents and purposes useless.

The marketing manager may tell the market researcher what the company needs to know about the design of a new product and the market segment in which it should be positioned. But it is the market researcher’s job to tell the president of the company what market research is needed, how to set it up, and what the results mean. The commanding general of an air base decides how many planes and of what kind are needed for a certain mission. But it is the crew chief, though vastly inferior in rank (and usually not even a commissioned officer), who tells the general how many planes are airworthy and what repairs they need before they can be sent off on their mission. Only a very foolish commanding general overrules his crew chief, despite the difference in rank—and such a commanding general, by the way, will not last very long.

Peter F. Drucker in Post- Capitalist Society, (p. 65)

Isn't that crystal clear?

Difficulty #4: Starting in the Large

Often companies do start large programs with Agility at the core. This is wrong! Start small instead! Large transformation programs is a symptom of the Doom Loop (Good To GreatJim Collins). Little cocoons implemented one by one that will create be awe-inspiring for others to join is key. You can't force people to embrace the culture of Agility!

Difficulty #5: Getting the Business Involved

It's not only the Business that must be involved! It's all your stakeholders! Often we have come across organizations in which the users are NOT represented in any form … still the Business is!

Don't get us wrong! We are NOT saying that Business must be kept away! We have said that you need proxies for all of the stakeholders or even better … your stakeholders themselves (which is far more preferable, but much more difficult).

Don't elect fake Product Owners, people that have no vision, that do not know the services and/or products. You must have engaged people, people with opinions, people who are open-minded, real representatives.

Difficulty #6: Forming Teams with Fully Engaged People

Form small teams not exceeding 9 people. Let them come to you! Remember: To change something, build a new model that makes the existing model obsolete. Don't force them to join. Should you decide that you know better, and then you put your Agility journey at stake forever.

Difficulty #7: The manual Says So

Manuals and books are inspiring. They must remain at that level: inspiration! No prescription! Scrum says that you must have standup meetings. Otherwise, you are not scrumming. What the heck? scrumming! What is that? Agility says that you must communicate continuously (well, it says it differently: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation and Business people and developers must work together daily throughout the project.) Daily Scrum Meetings help communicate. That's it. If that works for you, fine! If something else works for you, that's fine too!

Principles and values trump practices! Remember that! Don't apply things just because the manual says so! Use your head. Nothing prevents you from thinking, trying, failing, adapting, …

Difficulty #8: The Powerpoint Consultant

Organizations that have embarked the Agile journey must be trained! This is a necessity. Then come dozens of consulting companies all promising the Holy Grail, all with the best of breed consultants that have run myriads of projects. You must winnow the truth from falsehood.

Enough of these silly “Agile Games“! Enough of all these presentations and marketing material! This is crap and needs to be treated as such.

If you really want to get results, you need to head to these fellows who have kept a (very) tight connection with the technicality [1] of Software Development and who have been immersed in Agility for many years. Only these people have the true capability to try, check, adapt for your organization.

Stop the Powerpoint Consultants at the entrance door! Really! There is really more to DSM, Demo and Retro!

Difficulty #9: Uncertainty Acceptation

You must abandon certainty and accept adaptability. One must accept that predictive processes are not appropriate to Software Development. You must favor adaptive processes instead.

Any reporting, any measure that is based on items from a predictive process is nonsense. Any thought that requirements can get fully elaborated is junk. Accept it so that you can take the next step.

Difficulty #10: Feedback Loops

Most companies tend to believe that Agility comes with predefined feedback loops. This is only partially true. Yep, Scrum has retrospectives. Sure, SAFe has Inspect & Adapt. But this is only the tip of the iceberg. It's the whole functioning that must be all inscribed in a feedback loop. Feedback Loops must be fractal in Agility — Pat Boens.

Feedback loops must be possible for all your stakeholders, not only for the members of the Development Team.

The best way to see how feedback loops might be implemented is extend the shadow of the future (aka "You build it; you run it" of Amazon, or "The Kharma Factor of Facebook"). And yes, DevOps is a very groovy way of doing just that!

Difficulty #11: Standardization, Generalization

Companies have a sad tendency to standardize and to generalize.

It's not to say that you should not standardize! It's about saying that standardization comes AFTER you have something to standardize, something out the door!

Have the damn thing up and running, and then standardize! But wait a minute! Do not go ahead unless you know that standardization is not about the how, at least in contexts of agility! It's about the what, about inputs and outputs! Focus on what must be produced and consumed. Let the people make the eating! Otherwise, you will never be able to adapt your processes to the current context.

Difficulty #12: Beware the Silverbacks

It's not unusual to see people in the organization who step forward when starting an Agile initiative.

Make sure you can distinguish the ones who simply see the Agile initiative as an opportunity to boost their career from the ones who are really willing to help (and work) towards the Hedgehog Concept of the company.

Often the first category is epitomized as people to start big sub-initiatives. Examples? People that will revolutionize testing (and Agile testing), that will start fully automated deployments (even zero-touch deployments) before the Agile Teams are in place, people willing to reduce your doc set by 80% from day 1, …

We call them silverbacks, people acting more by bravado than by real understanding and deep knowledge. Run away as they are really dangerous animals.

Difficulty #13: Implement from the bottom

The longest march starts with a first step and this first step, in Agile, is to start from the bottom! It's OK not to be fully agile in a first phase.

Like in rugby where a team fixes objectives 20m by 20m, progress towards an end goal, little by little. Try, analyze, fix. Loop!

Taking all the challenges at once is a terrible mistake, still we have seen this pattern many times.

Difficulty #14: The Offshore and Nearshore Temptation

There is a heavy temptation for large organizations to go offshore to get a (much) cheaper workforce. This is fed as a vicious circle: projects are late, over budget … we need to remain within our envelope, we need to get more people, cheaper! This combined with the will to lower development costs … at all cost (sadly enough).

Then the company feels it needs to try something different: Management wants to try Agility!

Only the journey to Agility is already a difficult one at its core, on which we add offshore or nearshore of course. Crudely said, this is going to make things even more difficult, possibly impossible: communication will be harder (and the farthest you go, the more painful), contracts are not appropriate (most of the time), performance measurement is not suited, SLAs are unenforceable, security constraints need to be adapted, …

With L(i)VID we have set a quick (and somewhat cramped) categorization of offshore and we rapidly came to the conclusion that offshore (even nearshore) is not for the ones starting an Agile initiative: you must have attained a performed or even managed maturity level in Agility before trying to go this path.

Footnotes

[1] … Technical expertise is key as the Agile Manifesto reminds us: Continuous attention to technical excellence and good design enhances agility

Our website uses cookies to save your preferences. We kindly ask you to consent to our use of cookies when you first visit our website. If you do not consent, the sole recourse is to stop visiting our website. X