Debunking the Agile myths, Part 1

Date posted
13 October 2014
Reading time
7 Minutes
Steven Limmer

Debunking the Agile myths, Part 1

Assuming that you either work (or want to work) in the IT Industry, you could not have failed to notice that a paradigm shift has happened in software development. Processes and tools have evolved rapidly, the thought processes towards product/service delivery have changed, and roles have become blurred. Developers, did you write that test first? Testers, have you checked in your code? Systems Engineers; is that automated build process running smoothly? Project Managers - do you have a role in this new world? Agile is no longer a buzzword, it is considered the industry standard way of delivering high quality solutions, but it can also be confusing, and, being honest, daunting, for the uninitiated. Part of the problem is that it surrounds itself with slogans and euphemisms, and you could be forgiven for thinking that it's more style than substance. My aim is to address this, share a bit of knowledge, empathy, and cut through a lot of the hyperbole that surrounds Agile in a series of short blogs.

'Scrum, simple but not easy"

scrum1 This is one of those slogans that is both annoying and patronising. Scrum is one of the most popular delivery frameworks that comes under the Agile umbrella, however, it takes a lot of practice to get it right. It also takes a huge amount of buy-in to set it in motion:
  • There is an expectation that people will fulfil newly defined roles; customers have to provide a Product Owner (or Owners, depending on the scale of the project), and development teams have to provide a Scrum Master for each team.
  • When a project is initiated, the full team (customer & supplier) has to be dedicated to the project full-time, and ideally co-located
  • There is a requirement for the physical environment to be set up to support this co-located team. It needs to ensure the team can work unhindered, and have access to the right people (stakeholders and subject matter experts, for example) as required.
  • Continuous Integration is one of the keys to ensuring the success of a Scrum project - this comes with a significant upfront overhead of time, training & materials. You need environments to support the frequent deployment of code, the code itself needs to be robust enough to ensure that it won't break previous deployments, and it takes discipline to ensure that quality is built in to the software. By working software, we mean software that has passed all tests and is fit-for-purpose for end-users.
This is not simple. When presented with this, customers without any previous Agile experience are taken aback, and can be forgiven for reverting to familiar habits. It makes more sense to just buy the services, provide a specification for a solution, then take delivery of that solution after a period of time, doesn't it? Well, no. If, as a customer, you are willing to take on the challenges that Scrum presents initially, you can reap significant rewards:
  • You get direct input into the solution being developed at all stages, shaping it to your business vision and goals.
  • By deploying working software regularly, you get early feedback from customers & end-users, that can shape development of future, useable features.
  • Change Controls, one of the bugbears of large traditional projects, become less problematic. If critical features come to light during development, they can be added to the Product Backlog (a list of outstanding work that is prioritised on a regular basis with the input of business and development teams).
  • Large test events with every acronym imaginable are no longer required, as functional testing is inbuilt, mainly automated, and runs every time code is checked in and deployed into a working environment. Non-functional testing events become work items that are prioritised in the Product Backlog, and is prioritised like all other work.
  • Worst case scenario, if funding is pulled during the project, you still have a working product or service, as prioritised, iterative development is key to Agile's success.
This is not simple, definitely not easy, but ultimately, this is a very powerful method of delivering software that is tailored to getting the right solution to end-users.

About the author

Steven Limmer