Introducing Agile in the Workplace

So you’ve heard about agile development, you’ve read some literature, maybe even memorized the manifesto and you want to convince your boss to try it out. What’s the best way to present agile without getting blown off as just another fad? Here are some tips that will help you make a compelling argument in favor of agile.

 

Faster Time to Market

Unless you work in a utopian non-profit company, the sole reason that you are writing software is to sell it and make money. Developing software using an agile methodology allows you to write valuable software quicker than using a traditional design first waterfall method. This in turn gives you the potential to beat your competitors to market.

How does this work? Glad you asked, first of all agile lets you start working on a project with a minimum amount of upfront design. The entire project does not need to be scoped out, architected and estimated before writing a single line of code. The design evolves as the project progresses, based on stakeholder requirements.

Secondly, agile done right actually results in a minimum viable product faster because after every iteration of writing code you have a product that you can potentially release. All agile methodologies have minimum cycle time baked in, meaning they value small changes that leave the project in a state that can be released after every iteration. It’s up to management at that point to decide if the available feature set is good enough to sell.

 

More Responsive to Stakeholders

How many times have you worked on a software project, presented it to the client and they said “That’s not what I wanted!” Then several arguments follow about the scope and requirements and it can become a real nightmare.

Using agile, stakeholders are involved in the development process from the beginning through the lifetime of the project. Providing this type of transparency and input gives the customer a much finer grained level of control over the final outcome of their project. Changes are rolled out and reviewed by the customer in much smaller increments over the course of the project.

So now instead of “That’s not what I wanted!” at the end of the project, the customer can see a new feature and say “that’s not what I wanted, lets fix it in the next iteration”

 

The Big Boys Are Doing It

Google, Apple, and Microsoft all use agile methods to one degree or another. If you have some time check out how Spotify does agile and you’ll be amazed at how quickly they can get software out. Though the videos linked are already out of date, they exemplify how a good agile software practice can produce a superior product in a short period of time.

Though the bigger companies might have hundreds of people working on a project, those people will be broken up into multiple teams that are each using some form of agile based on their preferences and skill sets.

 

Higher Quality Product

A typical waterfall project goes something like this: requirements -> specification -> design -> code -> test. When it gets down to crunch time and the boss is breathing down your neck to finish and ship software which step is going to get sacrificed? That’s right testing is the step that always seems to have the lowest priority even though it will have the greatest impact on the perception of your product.

Agile forces developers to test early and often, finding defects earlier in the development process saves time and money. Testing in agile also happens at the end of the development cycle, but depending on the style you use that could be every month or every new feature. Either way since there are multiple development cycles there are multiple chances to get testing right, it’s not all saved until the end when there’s no time left to do it. In agile you would sacrifice scope instead of quality if there was a deadline looming.

 

Happier Developers

Circling back to the testing crunch at the end of a waterfall project, no one wants to put out a shoddy product. Developers hate deploying broken code, it’s a real moral killer. Though when developers put out quality code they get a sense of pride in their work, which tends to make them happier.

Agile also gives developers more control over the process they are using to build a product. They are not mindless drones that are happy to read from a script and do as they are told over and over again. They are people, and they probably know best how they can improve their own efficiency. So just let them, let them use agile to improve the processes they use to develop code. Give some autonomy and get some happier coders that will be more willing to work harder when it comes to crunch time.

 

Conclusion (TL;DR)

Selling your boss on agile may be a difficult proposition, organizations are like glaciers, they take an incredible effort to move. But show them these business benefits to make them a little more pliable.

Faster time to market – shorter development cycles and an increasingly functional product means potentially getting to market before your competitors.

More responsive to stakeholders – continuous input from stakeholders means they are never surprised and will get exactly what they asked for

The big boys are doing it – if agile works for small teams at large companies then it will certainly work for your small team

Higher quality product – testing after every iteration means bugs are found sooner and testing is never sacrificed

Happier developers – give them more control over the development process and they will happily make themselves more efficient

I hope this helps you convince your company to look into switching to agile. I’d like to hear some of your experiences trying to implement agile, please leave a comment below.