I recently read a blog post on LinkedIn from Oleg Vishnepolsky from DailyMail Online and Metro.co.uk stating that ‘Agile does not work’ and ‘And never did’. The blog contains some interesting statements and asks for responses. Well, here is one:

1) Short-term thinking that results from following short iterations and daily stand-ups

Where does this short-term thinking take place? Who does it? What have you tried to change that?

I think you do want your development teams focusing more on the short term when it comes to what value they should deliver rather than on the long term. That doesn’t mean the long term isn’t important though, and being agile doesn’t mean you should forget the long term either. It means you should use the frameworks, tools, and methodologies that allow you to respond to an ever-changing world.

In fact, long-term is quite important in order to be agile. You need to focus on quality and prevent technical debt. You should invest in test automation. You should focus on creating the right amount of documentation (be it code documentation, infrastructure as code or something else). You should invest in gathering and sharing knowledge. Those are all examples of the long-term thinking required.

If someone doesn’t think about these things, I’d say they’re doing themselves and their company a disservice. You should help them understand why these things are so important, especially when you want to be agile, and help them keep focus on them as well.

2) Architecture that often times can not be deployed piecemeal

What kind of architecture are you talking about? What challenges are you facing when trying to deploy your architecture? What’s the relation of this to being agile?

One could argue that delivery and deployment aren’t the same thing. I’ve seen cases where entire work-flow systems were being replaced and in certain cases that wasn’t being done one piece at a time, simply because it was either too costly or too complex. That doesn’t mean those teams didn’t work iteratively and didn’t go get feedback as soon as possible. It just meant the final deployment to production was postponed to such time where the work-flow could be implemented as a whole.

I do believe that there’s only a certain number of situations in which piecemeal deployments, for software, are extremely hard or impossible. But in order to do piecemeal deployments your application or architecture does need to support it. In most cases I’ve seen, piecemeal deployment is hard because the architecture isn’t right in the first place.

3) Complex infrastructure in production that is supposedly continuously getting deployed over. If you are Facebook, you can afford automation. Can you ?

What kind of deployments are you talking about and what is blocking you from doing them continuously? What makes your infrastructure so complex you can’t deploy continuously? It could be your infrastructure isn’t ready for continuous deployments yet.

But yes, I believe every company can afford automation. Because every company that I’ve seen that doesn’t invest in it pays the price in the long term. They struggle rather than grow and have to invest in automation along the road anyway, but at an increased cost.

I would like to note that deployment should be a business decision. While you’d want your bug fixes out ASAP, I could imagine not wanting to change your functionality continuously. It’s perfectly legitimate to do some deployments every X weeks and introduce them properly to your users. I’ve had a company offer customers the option of either continuous deployments or one every 6 months. Those that chose the 6 months were still involved in the development effort and gave feedback frequently, but they only got the changes after they had prepared their staff for it.

4) Business expectations that they do not need to give you any requirements and that they can change their mind at any time.

I’m especially curious where this one comes from? How are development teams expected to deliver value without having any requirements? How are they expected to focus when they can change direction from second to second? How could the business be expected to be less involved when the development effort needs them to be more involved?

In my opinion the business has the responsibility to talk to development teams and explore the requirements together. Naturally they can change their mind at any time, but a proper preparation may prevent changes of mind down the road. Because changes of mind are often the result of questions being asked too late or too little, as new insights lead to new solutions. If you don’t have a transparent situation to begin with, how are you expected to inspect and adapt to that situation properly?

Closing

Yes, Agile is being used as a buzz-word and yes, there’s probably some Agile Coaches whom are in it for the money rather than to achieve true agility as meant by the Agile Manifesto. That doesn’t mean agile isn’t good or dead or whatever. Agile isn’t easy. Being agile isn’t easy. I do believe it’s the right option and the right way forward, but it takes time and continuous investment in order to be and remain agile.

A note to the author of the original blog post: my questions are genuine and I’d be more than happy to discuss these topics with you.