Let’s find out what’s wrong with agile

Raffaele Cigni
Byte-Code
Published in
4 min readSep 18, 2018

In the software industry, we often refer to agile methodologies as the foundation for modern software development. And it is.

The agile manifesto is going to turn 18 in a few months (13 Feb 2019) and its principles are still valid:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

In the early days of agile software development, I remember we felt like part of a secret movement against the evil waterfall status-quo.

We were against that six-months-long deadline, the impossible to match GANTT diagrams and the magical tome of requirements.

Today the situation is vastly different: every organization understands the importance of responding to change in a fast evolving market and agile principles have crossed the boundaries of software development to influence business and marketing.

While “everybody does agile”, many development teams are actually struggling in the adoption process of those principles and practices.

Implementing agile out of those simple specs, it’s still an ongoing process. Why? Let’s list some of the problems with agile today.

Agile practices cannot happen in the basement.

https://www.youtube.com/watch?v=p85xwZ_OLX0

The digital team cannot be the weirdo group, the one that does not wear a suit. To follow the agile manifesto effectively, organizations have to add those principles to their company values or the “extra adaptability” of the development team will be translated into extra stress on the component that makes less resistance.

We still look at the business like a black box

https://www.youtube.com/watch?v=iDbyYGrswtg

This hilarious sketch that pokes fun at the generally low level of understanding of technology by non-technical teams could just as easily work the other way around: “This, Devs, is THE BUSINESS”.

As technologists, we often forget that the code we write is in service of achieving business goals and delivering value to that business.

So how do we measure that value? Ideally, we could quantify it with a simple scalar value representing potential revenue that we could use to easily calculate the ROI of any story and prioritize accordingly.

Well, I’ve never seen this in the real world, and you probably haven’t either. Why? Because “value” is not a number! If it was this easy, would businesses need agile in the first place?

Contracts do not work

We’re about to turn 18 and we haven’t even learned how to make commitments in a sustainable way.

Fixed price projects need a waterfall process, and they can only work where we expect a high degree of predictability — otherwise it’s a gamble.

Time & Material contracts solve some problems, but have other issues:
- There is no incentive to do things better and smarter, quite the opposite.
- The partner goals become “how can we justify more people”.
- Framework contracts often have fixed prices that can push talent away.

True customer collaboration cannot be achieved without an effective agile contract that we still do not have. There are many new initiatives trying to overcome this, mostly using hybrid solutions, but still, there is little to no evidence of its applicability.

Some organizations and startups try to overcome the contracting problem with insourcing but this can be a false solution as many organizations work internally as client/supplier, with different divisions, budgets and goals.

One constant challenge is figuring out how you evaluate the health of the relationship. Most of the time, we use KPIs to try to measure the amount of sweat and tears (time and material), instead of the amount of value delivered.

A problem emerges when the KPIs themselves create incentives that run counter to the actual business goals. If you set a monetary reward by story point you are going to build another cobra factory (Cobra Effect).

Let’s figure out the root problems

“Having no problems is the biggest problem of all.” Taiichi Ohno.

We believe that the problems listed above are most likely symptoms of deeper root problems hiding underneath. So how do we discover the root problems affecting agile organizations today?

Call for volunteers: The Agile Problem Interview

We are going to be running a series of in-depth interviews across organizations to understand how agile both works and breaks down in practice.

We want to understand the perspectives of all stakeholders — not just us developers. Having these broad conversations is going to help us make sure we’re looking at the problem holistically.

We need your sword, your bow and your axe!

https://www.youtube.com/watch?v=hyquiA8RL1Q

We are going to borrow the interview method from continuous innovation — the problem interview — that startups use to discover unsolved problems.

The output of the interview process will depend a lot on the number of people we manage to get in contact with. The industry is wide and the functions/roles touched by the digital innovation are many.

I know — it’s going to be a long process.

We want to start from the business side because we think there are gaps and problems there. Great developers created the agile manifesto and as a result, the practices and tactics that emerged are mostly focused on their needs — not necessarily those of business teams.

Get in touch with us!

If you would like help us in this initiative 😘 get in touch with us, we are looking for your help!

We are looking for people in the software industry, from all possible angles to extend our research and find ways to fix the agile practice.

Leave your contact info here or reach me or comment this article.

--

--

Raffaele Cigni
Byte-Code

Passionate about problems and new ways to solve them with software. I'm focused on lean startup, agile software and self-organization. www.byte-code.com