Misunderstanding Agile

It's Saturday morning and it's cold. As I listen to the screams of my children blocking my ability enjoy my coffee I thought I would read some LinkedIn articles, with this I came across yet another misunderstanding and a promotional article against Agile.

Unsurprisingly this always seems to come from executives. (https://www.dhirubhai.net/pulse/agile-does-work-oleg-vishnepolsky)

I ran out of my words allowed on a comment and therefore thought I should write an article of my own for those that are interested.

This misunderstanding of what Agile is is getting worse. First and foremost, what is Agile?

Agile is Not a methodology, a framework or a process to follow. It is not something you push onto your employees with a stick hoping they will pump out more productivity. It is not something that will ensure you will always deliver your end work package faster.

It is a mindset. The agile mindset is about empowering those with the knowledge to perform with a customer focussed intrinsically motivated set of values which can lead to new processes and ways of doing things in your bespoke organisation.

With the mindset in 'mind' can you understand why people who truly care about their products and customers would want to adopt? you could also theorize why executives do not.... there is no large plan to execute and show a set of benefits to shareholders to get an extrinsic reward.

"In the business world we often apply cures that are worse than the disease. The disease was the waterfall where everything took forever. Then consultants came along, saw a great opportunity to make money and write books, and now we have a different problem. Things still take forever. We essentially gained flexibility in the requirements stage at expense of quality and predictability." - Oleg

I hear this statement a lot, that we throw away the quality and a just do it mentality is born. This really is only when we don't build quality into our exit criteria or you push teams to deliver inferior work due to time constraints and as for predictability, agile teams have led to cycle time and or work package style sprints which have been an excellent way of predicting objectively with re planning instead of a subjective rough guess by a project manager a year ago.

"We simply try to hire the best developers, and project managers, and instead of following any kind of religion, we follow our common sense." - Oleg

The mere fact that Oleg believes in hiring project managers shows me the global problem with Agile. Do we not need PMs? The outcomes we do need but the management role? No.

However to answer your questions (although I see this article is now a year old and I hope you have found these)

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

• Constant re-planning and prioritising the customer's needs leads to faster to market and a more objective priority (instead of who shouts the loudest)
• Agile does not push sprints and daily stand-ups
• Responding to change over following a planned value not demand

2) Architecture that often times can not be deployed piecemeal

• Large structures tend to require enabler epics that enable future development and as such may not be able to be deployed to a live environment at the end of a sprint
• The end of the sprint is about being accountable for your work and allowing feedback from appropriate stakeholders. Do you need to do it? No. Should you utilise it? I've never met a project that wouldn't benefit from it. However, this doesn't mean you have to deploy; just be accountable and keep it visible

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

• Testing automation is growing and I see this sort of work being capitalised in a project as a great way to future-proof yourself; however, it is not a must. Just something that is seeing obvious rewards over investment
• Individuals over tools, imagine your application constantly looking for live bugs and using customer data to drive requirements? it may be costly to set up but your executives should be empowering you with an ROI and a strategic goal for the future. However, if your individual teams do not think it's great? then don't do it!

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

• Customer collaboration over contract negotiation; If your business wants to change their mind they can. They are empowered to understand the results of their actions and the team is not held responsible. Imagine if a 10-year plan for paper media hadn't changed their plan quickly enough.... we may not have Daily Mail Online.
• When I am doing the analysis for any user story, I always link the proposed requirement back to an epic/feature and then ensure the benefits are all in line. If they are not then I will log the requirement separate on the benefits matrix and the product owner surely will not rank a user story that does not have a benefit attached?

"Instead of agile or waterfall, I propose we use common-sense methodology." - Oleg

I would prefer if our executives lead us into self-organising, self-motivating teams that focus on delivering product improvement over projects; if this is Scrum or XP or Lean or waterfall....it does not matter.