28 April 2019 - Is Agile affecting deep thinking?

Some years ago I wrote a blog titled, Agile is a dirty word. I talked about how businesses approached project delivery, where clients feared Agile as a slap dashed route. I mentioned how marrying the governing powers of Prince 2 can help clients improve Agile delivery method. As long as they remember the business case of the project and the success criteria, then iterative delivery of the product, in the style of Agile can benefit everyone. Since that post, the term Agile has become more prolific within the realms of business transformation. What I wonder about is if businesses have really progressed to really understand the term and how it can impact on them. 

The term Agile is banded about by companies almost to show that they are on trend, so they may attract the talent they desperately need. Agile delivery suggests that teams can produce technical outputs to end users quicker than traditional waterfall methodology. This is factually correct. The beauty of Agile is that you can gather small set of requirements, build against that item, show to the end user for their feedback, tweak as needed and then look to put into production. All good you say and exactly what technical teams want to work to. But, there is a but...

I’ve seen at work too many times when people are given a task to build something. They start investigating the solution only to find it unraveling into something more complex. Instead of tackling the wider issues from the discovered complexity they are told to park these elements and plough on with their narrow remit. 

Now you could say that this was as per the request, the team were focussing in the immediate task. But what if the items identified along the journey could have a negative impact on the larger solution? What then?

It’s at this point that a response can sometimes be, "we’re only looking at this bit, we can address the other thing at a later iteration. We’re being agile".

Really? Are you really? Or are you creating a whole load of risk for the project at a point in the future that could become very costly to put right?

In other cases I am asked to estimate on what a solution might be, what resources are needed and how long something will take but I find it difficult to give a diligent answer. Again, their remit is so narrow that I am not given enough information on what happens before or after a certain point in the chain. I am at risk of giving an answer that is too thin. I want to know more about the subject area that I'm being asked to advise on. 

Is it just me that wants to know more about something? Is it wrong to want to understand the potential flow of a process from the start to end so I can see where my piece might fit into the puzzle? I am beginning to feel there are too many development teams out there who have lost their curiosity, who are happy to accept the piecemeal tasks set before them. I do not see the questioning minds, nor any challenges to what leadership tells them to focus upon. What scares me most is that I do not see the thirst to understand the holistic view of what the end result should be from all the technical tweaking. People seem to be content (or pushed into their place) to just concentrate on their piece of tech and not look at the wider picture. 

Is Agile changing our ability to think deeper and longer on a problem? Is the so-called quicker delivery method of adopting Agile stopping technical minds from thinking about all the 'what if's' and 'maybe's' and instead being pushed to complete as many stories as quickly as possible to get the next feature out? Constant iteration delivers small tweaks to a product, but what if the product needs a serious overall? Who in an organisation gets to think about that? 

Maybe this is left to the Architect in a business, at least someone should be thinking about this stuff but what I find frustrating is the the often disconnect between Architect, technical delivery and stakeholder. Somewhere along the line the communication drops. A high level vision maybe created but the method to deliver the change is often neglected. Or worse, each team is only communicated a small piece of the puzzle and not told how it fits with the next, and with the larger picture. This is where Agile breaks. 

So businesses out there, wanting to make transformational change, by all means adopt Agile. It really can help you to deliver chunks of product change in an iterative way. But please share the big picture to the masses so they can understand what the end goal looks like. Also, be brave to think wider and allow your people to do so too. This will help your teams to think about work packages more effectively and provide more future proof and scalable connections with other technologies/systems that could give the business a fighting chance of sustainable technical enhancements.