An Agilist's Tale - A Tale of Two Cities

PART 2

We join our protagonist for Part 2 in this three part series. Part 1 is here

Melbourne, beautiful city of my birth

DSDM wasn’t the answer to every dysfunctional software related problem… but my interest was piqued by this much improved experience of being on a software delivery team and I spent the next few years at that company looking around at other methods, attending London Meet-ups about different approaches to agility, reading XP books and talking to people about what they had discovered about other ways of working. I helped to start internal interest groups to try and foster the use of these ideas, and, unified in our pursuit of logic, we earnestly looked for opportunities to talk to colleagues and try out different practices and techniques. Some might say we were spreading ‘the word’.

I naively expected that these would be ‘the new ways’ and all other dysfunctional approaches would fade away. But at this time, other methods were also on the rise. 

Prince became a popular way to manage projects. IBM bought Rational and their RUP: the Rational Unified Process was a thing. CASE  - Computer Aided Software Engineering tools sprang up for us to wrestle with, and CMMi the Capability Maturity Model gained traction too. There was always a morass of options when it came to methods and approaches. Some were very ‘Open’ free and community driven, and some came from vendors. Different people aligned themselves to different ideas. Often allegiance was formed because of the training course that your company was willing to send you on. Has anything really changed here? Amongst all of these methods, approaches and options, there remained one: the mad scramble. The unorganised, make-the-best-of-things, leave it up to the experienced team members, cut scope at the end, extend the project by two weeks, ignore what the team is saying, 11th hour power, hit-a-date mad scramble. It was still an approach being applied on a regular basis on many software projects. 

“Amongst all of these methods, approaches and options, there remained one: the mad scramble. The unorganised, make-the-best-of-things, leave it up to the experienced team members, cut scope at the end, extend the project by two weeks, ignore what the team is saying, 11th hour power, hit-a-date mad scramble. ”

After 2001 some of the proponents of the more open and alternative approaches to licensed methodologies, noticed they had more commonalities than differences, thus the Manifesto for Agile Software Development was created. Sometimes it seems that from that point you either aligned yourself and your approach as Agile, or Not Agile.

Was this a good thing or not?

Well many great things have come from those days. I still find myself leaning heavily on the principles and values of the Agile Manifesto when I’m coaching people new to ‘the ways’. It's imminently more sensible for a team to use them to produce a block of integrated working software to achieve an outcome for a business. 

It was also a joyful thing to find a community outside of your workplace who shared your opinions.  These approaches were open, the communities were inclusive, and we had an umbrella term to unify us all. We were the Agile people, and you could sit down for a chat with us and hear all about it. It felt good to be with your people. It still does. 

But it wasn’t all good as the umbrella term of Agile allowed for confusion and division. We sometimes found ourselves in the position of being the defenders of the concept of agility. Lining up everything great with a process as an Agile thing, and everything else as the realm of the ignorant, and that every element of failure could be attributed to a lack of agility and stubborn belief in old traditional ways.  

Time passed, approaches matured. I landed a job at ThoughtWorks in the UK and returned to Australia with ThoughtWorks. I was drawn to this young company of big thinkers, solving complex problems without leaning on status and authority. It was the nearest I had seen to a meritocracy in a workplace. At the time their cutting edge approach to exploring these new agile ways was inspiring, they had a strong presence at every flavour of Agile and software meet up and their engineers were impressive. Surprisingly though they were some of the most anxiety ridden people I had worked with, because they had high standards and weren't keen to compromise. A good deal of team time was given over to ranting about the suboptimal state of things. Was this the nature of people with a predisposition to problem solving or something more like intellectual arrogance? I still don't know, and I still see it in certain engineering cultures.  

And what was The Agile stuff anyway? Was it just for software? Did it include Lean or was that something else? Was it the stories or the goddamn post-it’s on the wall? XP (extreme programming) fans became annoyed that you could claim to 'Be Agile’ or be ‘Delivering Agile' and yet skate past all concepts of good software engineering practices. Scrum purists were not happy that so called 'Agile Teams' had role definitions that were plainly not in the Scrum guide, Iteration Manager for one. Where did that term come from? From my best recollection it was a way of not having to have an old school Project Manager foist upon your team; give me one of those Agile Iteration Managers instead - at least they don’t use Gantt charts.  

And don’t get me started on scaling frameworks (this blog series can actually only be limited to three posts if you don’t get me started on scaling frameworks). I think we hit peak 'Divided Agile' when this Agile landscape model appeared late in 2016 and the haters within the community came out in force. 

Stop the train I want to get off

Here’s a more considered treatment by Craig Brown that included some of the harsher and more entertaining tweets in response. The saddest thing I feel about the navigating the Deloitte Agile Landscape Model is the way the article begins "Being Agile isn’t as simple as following one single methodology".  It used to be. You used to be able to buy a book about a chosen methodology and read it, attend a meet up and apply what you learnt to your project. I had picked up a phrase from a colleague Dan North "The simplest thing that could possibly work" and we bought that thinking to everything. The way we approached an architecture, the way we captured a requirement, the way we solved a problem. But Agile has now moved a long way away from simple.

It wasn’t surprising to me that Agile became a divider of even Agile people. At some point on every ‘transformation’ that I’ve been privy to, the word itself becomes corrupted. Through alienation of  'Non Agile people' by 'Agile people' we create suspicion and allegiance that becomes off putting, we start referring to it as the 'A word', avoiding it and substituting it with terms like ‘The New Ways of Working’ instead, it’s just too loaded and confusing. You’re either considered too dogmatic to deviate from a process, or too pragmatic and are glossing over necessary basics. Much like a holy war, everyone winds up a loser. 

I think back to those early days of great curiosity and trial and error and wonder how, when we were uncovering better ways of developing software, did we end up here? 

 ***

We’ll find out how! Or at least where our protagonist's journey has taken her in our concluding episode of An Agilist’s Tale.