Agile is one of those buzzwords you can’t really avoid in any modern conversation about management. With agile, you can create products quickly and put them in front of your customers. If they don’t work out immediately, you can reiterate as many times as necessary until you’re able to satisfy your market’s needs. At least, that’s a common way to view things for executives, with agile becoming like a secret sauce that makes the company’s burger delicious.
There’s more than a secret sauce to a great burger, though, and there’s also more than agile to making good software. In fact, what does agile even mean?
For some people, the first picture that comes to mind when thinking about agile is a bunch of people standing around in a room, talking to each other for 15 minutes each morning. Others probably think of a whiteboard full of sticky notes, arranged in different columns, tracking a project from inception to completion. These images are in contrast with the old school way of doing things: piles and piles of documents requiring management approval and endless revision.
The reality is a bit more complex than that, of course. A whole set of activities must happen in order to release a product. For one thing, the team must decide what features need to go into the software. Then, these features need to be written. Finally, the resulting software needs to be verified for stability and performance. Whether a team is running agile or not, these things can’t be escaped.
Before we get too far ahead of ourselves, let’s take a step back and look at what agile actually is and how it helps in building products faster.
Agile: Behind The Hype
First of all, we need to address the most common misconception about agile: It is not a rulebook or a set of rules. It’s not even a process or a single methodology, per se. Rather, agile is an umbrella term that encompasses a group of similar methodologies which all share the same goal, which is to reduce paperwork, documentation, and bureaucracy in favor of producing software that works, built through collaboration between all stakeholders, including customers. In order words, the team collaborates to build something, gathers feedback, and then acts upon it. Even more succinctly, the process is less meta and more meat.
Teams can use multiple strategies to implement this new way of working, and that’s why there are a number of methodologies that all adhere to the agile manifesto. Some, like scrum, look at how to organize a project so that work progresses in an iterative manner. Others, like extreme programming, focus more on the engineering practice for building high-quality software.
The real problem arises when somebody takes a precursory and superficial look at agile, and demands that it’s implemented immediately in their organization.
One of two things generally happens in this scenario. Either an official framework is chosen, such as scrum, with the intention of following it blindly, or random bits and pieces of different frameworks are selected and put in place, often including a Kanban board, without a real understanding of how these pieces are supposed to fit together.
Both options exasperate the team, which then tries to shoehorn the changes around their current process. This results in what I call a FrankenScrum: a monster that is better suited to star in horror tales than a proper software development methodology.
This leads to the first key takeaway: If you want to implement an agile framework, you first need to shift your team’s culture. The team needs to understand and adopt the spirit of agile.
I can’t emphasize this point enough. The frameworks are just a guideline, and they aren’t expected to be one-size-fits-all. What’s important is the spirit behind them. The final implementation is highly dependent on each team’s specific environment, but the agile spirit is what makes it all work.
Managing Behind The Curtains
Adopting the spirit of agile alone isn’t enough, though. Again, there’s more to a burger than a secret sauce, and there’s more to a process than just its spirit.
The team still needs to be managed properly if they’re to deliver a completed, working software product. Without a proper management layer, all the team can really produce is a bunch of prototypes. The basic principles of writing maintainable software are ignored in favor of sheer production speed, resulting in software that kind of works, but it’s ultimately spaghetti code, a collection of workarounds that are bound to break as complexity rises. That might be enough in the early stages of a startup, when quick pivots might be necessary to get to a good MVP, but it isn’t sustainable in the long run. Eventually, the prototype needs to evolve into a concrete, salable product.
On the flipside, management as it’s commonly practiced has a penchant for bureaucracy, process and documentation, which seems to go exactly against the spirit of agile that we just talked about. The truth, though, is that management doesn’t need to be bureaucratic in order to succeed.
Ultimately, the manager needs to adopt the spirit of agile as much as each person on her team. Managers using agile as an excuse to justify poor practices are missing the whole point.
What does that mean in practice? Let’s look at the core business functions of producing software, product design and software engineering, and how they should be managed in an agile context.
Agile and Product Design
On the product design side, the key activity to manage is the creation of actionable stories. These stories are born out of both new ideas from within the organization and the feedback received from customers on prior iterations. Actionable stories are the driving force behind product creation.
The key word here is actionable: The stories need to be concrete enough to be turned into lines of code. Therefore, it’s important that this process doesn’t involve just product designers, but software engineers as well. The aim here is to understand the impact of the story on the system as a whole, and to avoid surprises during the implementation phase that might derail the release plan.
What we’re trying to avoid is having the story turning into a mini-functional spec. We don’t want to go back to a spec-heavy, waterfall-like approach that grinds the development speed to a halt, but we also don’t want to leave the story so vague that the team won’t know what they need to implement. Open-endedness and overzealousness are equally dangerous, and the right balance is somewhere in the middle.
Therefore, when choosing metrics by which to measure team performance, it’s important to emphasize the timely implementation of stories over the production of beautiful accompanying cards or mockups and, above all, measure customer satisfaction on each iteration of the software. Useful metrics that can be employed on the stories revolve around the amount of items completed versus those pushed back to another sprint and the average complexity/difficulty of those completed. Customer satisfaction can be assessed using standard systems like a net promoter score (NPS), gathered on the same user demographic across different iterations.
Agile and Software Engineering
While the product design team is busy making sense of the functionality of the product, engineering should be concerned about how to release software that is stable, scalable, performant, and secure. There’s no magic trick here. The best way to achieve this is to follow the usual spec, implement and verify approach. But that doesn’t mean we can’t be agile.
In the spec phase, it is crucial to ensure that there’s a structure to the software being written and that any changes are properly assessed in the context of the overall system architecture. As a result, you can’t escape producing certain documents, but they gain a new meaning under agile. Architecture diagrams, API references, and technical specs are now more akin to a map of a meandering dungeon, given to the hero (in this case, the developer) who’s trying to slay all the monsters (bugs and maybe even features) in it. These aren’t dead documents, once written and then forever forgotten. Instead, they become live materials that are constantly updated from iteration to iteration.
Ensuring the documents are up-to-date necessitates two criteria in their upkeep. First, the need to be lean, avoiding unnecessary verbosity or decoration. Secondly, whenever possible, document creation and maintenance needs to be automated to expedite the process.
The implementation phase under agile looks slightly different than its traditional counterpart. That’s mainly because the functionality as it’s described in the actionable stories is less detailed than in old-style functional specs, as we saw earlier.
The expectation should be that engineers and designers work together in this phase to figure out the fine details of each story being implemented. The involvement of product designers is especially important as these decisions need to be assessed in the context of all the other work pending in the backlog, not just for the current sprint but also for those coming further down the line.
If significant changes to the work that was set out in the spec phase arise, they need to be assessed and a decision needs to be made on whether to descope the story or to proceed incorporating the changes. This decision is better made at the management level between the respective leads of the product and the engineering functions, as delays or scope changes could impact prior customer commitment or future roadmap expectations. The good news is that, if agile is done right, this should happen infrequently enough to seldom present a real problem. After all, the whole point of agile is to work on smaller chunks and release often, and that means breaking down bigger problems into more manageable stories that are unlikely to have a massive scope change during implementation.
Traditionally, the purpose of the verification phase is to verify the conformance of the software to technical and functional specification. In an agile context, that’s still true, but it doesn’t happen only at the end of each cycle. Code reviews can uncover potential problems as development is being carried out, and so can early testing and continuous integration backed by automated testing. In order to accelerate development while maintaining quality, these are concepts that a leader needs to understand and integrate into her team’s practice.
Parting Thoughts
It’s easy to herald agile as the savior of a dwindling team that’s running out of wind in their sails. With agile, the team can release products at regular intervals and show the fruit of their work to the rest of the organization and to customers too.
Using agile alone, however, can lead to the creation of flimsy software, including prototypes that are nothing more than a facade for the latest functionality, built on an unstable base that will eventually collapse. Teams must avoid this at all costs.
Managing an organization that runs on an agile framework isn’t difficult as long as both the team and its manager embrace the underlying spirit and work together to deploy the chosen methodology. This primarily means understanding that agile isn’t a substitute for good engineering practices, but a tool to make progress more visible. It’s not about getting to a final product faster as much as it is about offering earlier course correction. Perhaps that’s really why it’s so successful in the bootstrapped startup: It’s not as focused on squeezing 10 times more performance out of an understaffed team as it is about creating good software without secrecy and segregation of roles. This results in software that isn’t so rigid as to need rewriting any time a new feature comes up, but at the same time remains stable and robust enough to grant its continued commercialization.
To go back to our opening analogy: If agile is the secret sauce of our great burger, then management is the sesame bun. It might be boring, but without it you don’t have a burger at all.
