Debunking the Agile myths, Part 2

In the first blog, I discussed Scrum & its process. In this blog, I'm going to look at the bigger picture of "Why Agile?' Why does Agile exist? What evolutionary steps forced the creation of Agile? In my view, it is a reaction to traditional industry decision-making. In traditional industry, the accepted approach is top-down management; there is an assumption that people will not choose to work willingly, so need incentivised and controlled. The software industry standard method of delivering software for the last 30 years, Waterfall, is built around upfront decisions, tightly managed stages, and knowledge silos - the information of how to do specific things is kept within the theoretical walls of analysis, design, build, test, deploy. When work at any stage is complete, it's 'thrown over the wall' to the next stage. It is a dehumanising process, in that it does not recognise the human desire to communicate and learn from others, and can be attributed to the failure of so many IT projects. See if this feels familiar; this is an example of a Waterfall project in action:

• Users of a service have identified a specific problem with a service; a business case is made to initiate a project to solve it.
• The project is initiated; the project manager sets a timeframe, picks the personnel to do the work, immediately starts referring to them as 'resources', & dictates when and how the work should be done, standing over the whole project.
• Business analysts & architects start the analysis phase, gather & write requirements for a solution, create the designs, then throw them over the wall to developers once they're passed review and deemed ready. They then walk away to the next project; their work here is done.
• Developers develop the full requirement set. Inevitably, there are issues; they need to consult the architect/BA, who is working on another project at this time, so it takes longer than expected to get answers. Build time is extended to make sure all requirements are developed. Code is finally compiled and deployed into a test environment, and the developers prepare to work on another project; they've done their bit.
• Testers are brought in at this stage to test the requirements, albeit in a much shorter timeframe than was originally estimated. They inevitably find issues; their perception of the requirements aren't the same as the developer who created them, whose perception differs from the architect/BA who wrote them. Defects are logged and thrown back over the wall for to the developers to figure out where they went wrong.
• What's left of the development team either reject the issues outright, or try to contact the architect/BA who knew what exactly that requirement was supposed to do, then finally fix the issues. They then throw them back over the wall for the testers to have another go at getting this right; stupid testers.
• The project manager sees that the deadline is coming close, so applies pressure to the remainder of the team to work overtime to get the solution through the many acronymic test phases; SAT, NFT, FAT, UAT, OAT, BRT. Each phase tests a different aspect of the solution, but ultimately, is meant to ensure the solution is fit for the end user. In reality, all that is tested is whether or not the initial designs were followed.
• Eventually, the project manager deems that the completed solution meets the requirements set out initially. They ask for time from the architect (who's on other projects) to compile and deploy the end solution, which is then thrown over the wall to the customer.
• The PM disbands the remainder of the project team - job done.
• The end user, who wasn't engaged during the timeframe of this project as it was assumed that the problem that was captured at the start of the project will be the same by the time the project is delivered, gets to use the solution. However, the solution doesn't meet their current needs and expectations, and they now have a different problem.
• A change control is then initiated, usually at great cost, to try and solve this new problem

Sounds crazy, right? Unfortunately this is the reality for a lot of people working on IT projects. As the onus to collaborate is removed, a lot of the motivation for people to do things well is removed as well. No communication, no sharing of knowledge, no empathy. So, how does Agile come in to all of this? The key agile principle is, 'People over Processes'. What does this mean? It means that Agile recognises that software is created by people for people and humanises the software development process through:

• Cross-functional teams; a team will be multi-skilled, and can deliver all aspects of the project; from analysis, design, build, test, through to deployment.
• Continuous integration; the mechanism that makes Agile IT projects successful. This is the continuous deployment of code into a live-like environment. Automated testing is a huge part of this; many developers practice Test Driven Development, testers write automated tests to test the basic functions of a system, the test pack runs every time new code is deployed. This reduces manual test time considerably, and assures the solution under development.
• Collaboration; testers and developers need to learn each others skills to do development well. BAs and designers need to collaborate with Product Owners, subject matter experts, and end users, to ensure that what is being built is fit for purpose. The whole team (business & development) work together to achieve the goals.
• Communication: the team collaborate to ensure they understand what exactly each piece of work does, what they need to do to complete it, and maintain constant communication throughout all phases until it is deemed ready to be delivered to customers. The daily standup is a great mechanism for this, and to highlight any issues.
• Self management; teams are allowed to make their own decisions, and crucially, learn from their mistakes. There is an acceptance that they will grow and improve.
• Customer engagement: the end customer is key to the success of the project. By releasing working software early & often, we can engage with the customer, observe how they interact with the solution, record their feedback and ultimately, tailor the solution to their needs.
• Acceptance of change: it is taken as given that initial requirements are not set in stone, and are subject to change. This is addressed by adding any changes to the product backlog (the backlog of project work still outstanding) regularly reviewing & prioritising the backlog, and ensuring that in each sprint, only the highest priority/highest value work is considered.
• Short iterations: Work is completed in 1-4 week 'sprints' of work. The aim of a sprint is to have a piece of software (or product) that can be handed over to an end user: a potentially shippable product. This means that analysis, development, testing & deployment is done as part of a sprint of work, every sprint (The shorter the sprint the better, to gain rapid feedback).
• Learning lessons: retrospective sessions are held at the end of every sprint; looking at what went well, what didn't go so well, and what actions should be taken to improve. This is also a great time to give praise to team members for doing good work, individually and collectively.

By nature, humans are communal animals. We gather in groups we share common traits with. We crave autonomy and mastery over our own destination. We take pleasure in learning and solving complex tasks, and take reward in recognition of a job well done. This is recognised as intrinsic motivation, and as evidenced above, Agile is the application of this in software development.