There’s 100s of articles about Agile Development and it’s history so I’m not going to bore you with those details. A quick Google search can do that. What I’m going to do is really dive into why it’s such a buzzword, the supposed answer to every problem, and what it really means.
Waterfall is soooo 1970s.
Everyone says their team is Agile or trying to be Agile, but why? They bash the Waterfall process as being old, outdated, and problematic, and think by saying they are Agile, they are solving real problems. The computer and/or phone you’re reading this article on wasn’t built using Agile. You don’t send it back every week for an upgrade. Neither is the car you are driving. So how bad can Waterfall be when many products and services we use daily get built or processed once and only once?
The biggest complaint with Waterfall is the upfront requirements which leads to the potential – most probably the inevitability – that by the time development is done, the product is obsolete. If a requirement is missed, we have to start at the very beginning again with much higher costs than the iterative development model used with Agile Development (supposedly).
We are moving to Agile. Everyone should celebrate!
So Agile Development comes along as this magical answer, and we introduce things such as Scrum meetings, stand ups, and Kanban. We read books on Extreme Programming and research Toyota. We get excited that by just changing the process, we think we will solve all of our development headaches, we will deliver faster, and we will have happier customers.
We will see some incremental improvements in inertia over the course of the new few months just due to the excitement and the feeling that everyone is able to do more. Is more actually getting done? That will be up for debate, but it will feel like it. We will take a retrospective with the team periodically say we need more time to adjust to the processes and we need everyone to buy in.
Then nothing changes!
The code still comes out buggy. The team is still working late nights. Tempo looks good on the Kanban board, but nothing seems to be really moving forward. What happened? Maybe we need to believe harder in Agile? Maybe we need more training?
How does A talk to B?
We can change the processes as much as we want, but what we have not changed is the underlying architecture – the underlying communication that governs the product. Interfaces – how two pieces interact with each other, do not inherently get resolved. We tend to iteratively improve implementation – we will make that algorithm more efficient or easier to maintain; but we rarely ever take the time to improve the interface, increasing the efficiency of communication between two parts.
When we look at the car, our computer, or our phones, the interfaces are highly optimized. A car has four wheels and one steering wheel. Your computer has a keyboard and a touchpad/mouse. Your phone has a touchscreen most likely. The biggest innovations we look at deal with interfaces. The mouse changed how we interacted with computers forever, a touchscreen put Blackberry’s phone keyboard out of business. We’re looking at removing the steering wheel with self driving cars. Changes to interfaces drive disruption.
So how did an article about Agile Development become an article about Architecture?
When we talk about Agile Development we’re talking about the iterative improvement of a product. When we talk about the best teams out there, we are not just looking at the product implementation, but also the interfaces. When we succeed at Agile, we succeed not just by incremental feature updates, but by incrementally improving the architecture. This is a much harder ask and much harder task for teams. The idea of refactoring is not to only re-implement functionality to optimize a process but to re-architect and optimize the communication. The ability to recreate who two or more parts interact with each other.
When we look at Pair Programming, Parallel Programming, Scrums, Stand-ups, and Retrospectives, we focus heavily on communication between people. We forget that parts of our product need to talk to one another as well. The spirit of communication gets lost inside of the product. We tend to just tack on another parameter to an existing function and pass it on through. We don’t take time to figure out how the parts are actually communicating.
When we refactor we need to think about “Is this the most effective and efficient way for these parts to communicate?” With that answer we can finally go about and make significant improvement to our products, processes, and services.