Back to The Future of Agile Software Development

This content is syndicated from Edge of Chaos | Agile Development Blog by Olga Kouzina. To view the original post in full, click here.

This essay is inspired by Ken Schwaber’s unSAFe at any speed blog. In brief, Ken cautions against returning to the RUP practices disguised as agile framework, and urges his readers to keep their commitment to the Agile Manifesto.

While I’m very much with Ken on the subject of heuristics, thinking for yourself and sticking to the principles of agile, there’re some more deeper things to that than management vs. software developers, or RUP vs. agile oppositions. Make yourself comfortable, as it’s going to be an interesting  7+ min read, or whatever more time you might need to contemplate it.

The Origins of RUP and waterfall (’80s–’90s)

Let’s look back at RUP, waterfall and other such unified processes, you name them.  Where are their roots , and when did they actually make sense? It’s in the ’80s-90s of the last century, maybe even in the ’70s. The unified processes are the legacy of industrial and agricultural age production methods from the earlier times of the 20th century. Back then, in the ’80s-90s, it was very natural to think of software development as yet another field of production, not any different from hardware or commodities. Besides — and it’s an important thing to note — the pace of changes in the industrial and agricultural environment has always been slow. No changes for 50+, or even 100+ years in some cases.

First, everyone thought that software production is going to be like that as well. No changes, hence no changes in the market/production environment, hence no problem-solving skills required. Well, if the problems related to an unchanged routine activity have been solved once and for all, all you need to do is follow some rules and commandments. No new problems -> no changes -> rigid processes.  With software development, it all went along in the same fashion with the boom of outsourcing in the late 90′s – the early 00′s.  I used to work in an outsourcing company, by the way, and I remember how we’ve been luring the prospective clients back then by neat RUP diagrams, as we tried to convince them that their project will be done on time and within budget.

Next, with no changes in the environment, rigid processes are supposed to work fine. Well, fine it was until some moment. It appears that by 2001 (maybe it was related to the notorious Y2K problem, along with the others), but there came an understanding to thinking people in the software industry that something is wrong. Rigid boilerplate processes did not seem to be working to create  viable software in the changing environment. This critical mass of changes found a small outlet, as the lava first appears only as a tiny stream, in the 2001 agile manifesto, and Ken Schwaber was one of those who signed it.

I see the Agile Manifesto as the soul’s cry of creative  software engineers who wanted to say it out loud, that they are aware of this problem, they claim this awareness to the whole world, and say that they’re not “code monkeys” but thinking people who have their solution to this problem in mind. They wanted to stand out and share their beliefs about better ways of developing software. They just couldn’t live with that awareness and not sharing it anymore. I haven’t studied the biographies of the agile manifesto founding fathers but for some reason I’m sure they’ve had enough of  enterprise softdev companies running in the Procrustean bed of the 20th century industrial ways.

The Agile Manifesto and what came next (2001 — ?)

After 2001, the whole decade up till now, has been filled with the buzz about agile adoption, fading or getting louder at times. Most likely, the agile manifesto has had its first ardent followers among bootstrapped softdev start-ups and some small web service shops. Or, among the software engineers who simply felt they can’t do their work well within the old paradigm.  Just anyone who was not a mere “human resource”, not a cog in the rigid process but a thinking person who faced the real problems in their biz/softdev life-style, and naturally had no other way to go on as to be able to solve those real problems. That’s what the essence of agile is. Agile problem-solving in the fast changing environment.

Let’s flip the phenomenon called “agile” and look at the other side of the coin. As agile methodology got its entourage of followers, agile coaches, trainers, various certification programs, it started showing some signs of rust. Like an idol worshiped just out of tradition, because everyone seems to have forgotten how it appeared originally, in the first place. Now, consider this. The industrial-style companies of the late 90′s are still there. They still have their problems. They’re still the same as in the late 90′s, or even late 80′s. They have budgets to spend and  outsourcing teams to run. But since RUP and waterfall have publicly been coined as malpractices, these enterprise companies must have jumped for joy as they saw someone approaching them with the stuff called SAF (Scaled Agile Framework).  As far as I can see, SAF has the same essence as RUP (correct me, if I’m wrong) but now it wears a nice glittering gift wrap with the big word “AGILE” on it.  The terms are different from RUP, though. It’s called SAF, but the essence is the same: it’s a prescriptive framework for industrial/agricultural style production in software development.

Such companies will indeed be glad to open their checkbooks to something like that, as Ken says in his blog. That’s what they need, and they will run fine with it, as long as the global market and business environment lets them live this way, keeping the patterns of production where they don’t need problem-solving skills in software development as the ultimate prerequisite for running their businesses.

Now, speaking of the global market environment. Of course, the distinction is not black-and-white. There can be companies who are enterprise, who are changing, transitioning, transforming their businesses, etc. Everyone is human, and everyone has their own problems. SAFe indeed might be able to solve the problems of some companies. Of course, there can be a hybrid of enterprise thinking and creative thinking (the Japanese look like the most obvious example of that to me).

 ”Agile” as buzzword and “agile” as continuous problem-solving

I want to emphasize that there’s agile as “agile, the buzzword”, the silver bullet that many heard of, the idol that is supposed to heal all the ulcers if you worship it. Usually, people resort to this kind of agile if they:

a) don’t have time, or guts (sorry), to dig deep, study and learn from their own experience and move on. Well, it’s one of the most common misconceptions of the humankind: a belief that your particular problem, in your particular business/market context has a ready made solution out-of-the-box, coming from some 3d party. The ready-made answers can only come to a purely technical problem, like the sequence of steps to assemble a wardrobe purchased from IKEA.  I’m continuously amazed at the questions  people ask on some forums, as they believe that the  problem in collaboration, or production, or in a process peculiar to their organization can be resolved by someone’s quick online answer. There’s no prescription for such problems, period. Only the experience-based flow and thinking, iterations and corrections in response to the feedback from your particular business/production/market environment are viable.

b) if they’re the folks who muss RUP. They still need something like it. Budgets to spend, reports to write as they operate in their narrow neat silos,  untouched for one reason or another (so far)  by changes since the late 90′s or maybe even earlier.

The 2nd kind of agile — and I don’t want it to be a rusty buzzword — is about problem-solving out-in-the-trenches. Take a living organization that operates in a very fast-changing business/market/production environment.  Well, I don’t think that such organizations can afford thoughtless copy-pasting of abstract prescriptions. By the way, here’s an interesting brief  summary of Agile 2013 conference. In short, the best thing about this conference, according to the author, was mingling with the folks who have the same problems, but the conference gave no actual answers to those problems.  I published a post called Agile Conferences: Look To No Epiphany on a similar subject about 4 years ago as well.

The logical conclusion? People. People. People.

If you can’t afford blind copy-pasting of prescriptions to solve the real problems in your organization, then PEOPLE are your biggest asset. That’s the real agility. Only people can be agile. Not a process, in the very true sense. Agile people can tweak the process as they need to solve their problems that appear in the fast-paced environment where they operate. The people who make one team together and are able to solve problems continuously, because a changing environment always entails new and new problems. If in a more narrow software development terminology we have the term called “continuous delivery”, then my version of the buzzword definition would be:

Agile is continuous problem-solving.

Now, what do you think the future will bring?  More of those 20th century industrial/agricultural softdev corporations? Or more of those indie companies with their universally knowledgeable people, who are, well, agile and alert because otherwise they won’t survive in the changing environment? This is an interesting subject in itself, and it goes far beyond this essay.

People are people. They have their problems. They live. Life changes. Agility is a way to survive, live, enjoy those moments, and create some nice software stuff that will make the lives of other peoples easier, maybe even nicer, and will help  people solve their problems, eventually.

So, that’s where the answer to the question ” What will become of agile in the next few years?” is. It’s a global economic/business market, and what this market needs more: agility as real agility, or enterprise-industrial style enterprises with their rigid homeostasis untouched by the changes. Why and how the rigid homeostasis can be untouched is not to be discussed in a blog on agile software development :) Maybe I’ll write about it elsewhere, some other time.

Leave a Reply

Your email address will not be published. Required fields are marked *

ten − ten =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”



To explore how we can help you, please get in touch