10 things a developer wishes his boss knows about being Agile


11 February 2015
Bryan Tan of Rally Software

What is Agile in the world of software and app development? In the traditional "waterfall" approach to software development, the software developer is often constrained by a barrage of incessant feature additions, frequent unmeasured requests of tweaks and changes, and uncontrolled work schedules. It is no wonder software and applications are often riddled with bugs and vulnerabilities, and ultimately frustrate corporate management, end-users, and paying clients.
If you are a software developer working for an in-house team, or part of a team developing external software, what would you hope your boss would know to make software development a profitable and controllable experience for all?
In a nutshell - Agile. The Agile revolution has turned the more traditional or "waterfall" development method upside-down, all for the better. Agile is the key to unlocking the full potential of an in-house or external software project, but to do it well there are 10 things a corporate manager should know:

1. Go Agile to realise revenue early

Profitability is mandatory. Developers understand and appreciate that. We strive to work towards that too. To help the company realise revenue sooner, an Agile approach is a key element. Using an Agile approach, companies release development projects early and often, delivering steady, small increments of value. This approach not only allows companies to realize revenue more quickly, but to also incorporate key learnings and customer feedback into subsequent releases – allowing dynamic steering of a product strategy and ensuring customer satisfaction. One of the main failings of traditional software development can be attributed to the missteps along the way that all accumulate towards delays and ultimately, loss of profits.

2. More features may not be better

How many features does a typical user actually use in a typical software product, such as a typical word processor, spreadsheet, or presentation tool? Out of all the esoteric features, a typical end-user
is probably only going to use a handful of them. What's worse, a typical user is unlikely to read the thick tome of a user manual. Therefore, having a dense code base does not make sense in the real world, and not only create a complex software development process, also creates many "black holes" for potential bugs. A simpler, leaner code base is light on computing resources, and easily gets the job done for end-users.

3. Customers are our allies to test and improve our products

End-users or external customers are our allies. All too often, the classical "waterfall" approach leaves the end-users or external customers out of the equation of software development, and they only get to use and test the product when it is already in alpha, or beta, with all the inherent fixation on design, philosophy, features, and of course, bugs and vulnerabilities. With the Agile approach, we engage the end-users and external customers in the developmental stages early and often, so that they have part ownership on the process, and the ultimate deliverable. We like to think that everyone will ultimately be happier.

4. Building it right the first time

The whole point of software is functional code that does not break, or cause vulnerabilities to compromise operations. And yet, that seems like the elusive path for many software projects. With the Agile approach projects are delivered in small steps, called iterations, which are then delivered to end users. Each iteration allows for the opportunity to see the product in action, learn from user interaction, and apply feedback to the product for subsequent iterations. Every "baby step" is cumulative towards the end goal of the complete software product, so in practice, the Agile approach removes many possible points of failure, and allows us to microscopically examine each iteration to reduce or even prevent bugs from creeping in.

5. "Done" has to be defined clearly and why

The Agile approach is based on iterations, which are micro-goals, which all culminate towards the complete product. Rather than keeping you and the management in suspense, we aim to deliver digestible iterations to you and our end-users every step of the way, on a timely manner. So "done" can be re-defined as many successes that all converge to the finished product at a foreseeable future.

6. We need your vision

As our boss, your vision, your wisdom, your clarity, and your support, are all absolutely vital to our success to complete the software development projects. We can establish a "social contract" that we can always count on your executive support no matter the outcome.

7. We want you to know what we are doing too

What gets measured gets attention. By using the right metrics, you can be sure of what is going on with your developmental team, and the successes every step of the way towards the fruition. It is all about insight. Raw data is meaningless unless you, the corporate manager, knows what the data means, in a succinct, and easily articulated format that you can share with your fellow managers, or even customers.

8. Why we reject work sometimes, out of necessity

A good surgeon may sometimes reject an operation, because there may be a better alternative. Likewise, sometimes we may turn down certain requests, because such requests may not meet the complete objective, or may simply require a postponement due to our discernment to better streamline and queue the iteration. So we may reject a small portion of coding, and re-assign it till later along the flow, where it may make more sense.

9. We want to do a good job*

We want to complete not just tasks and projects, but celebrate the success with you too. So expect us to soldier on until we shout the "hurrah" on the peak of completion. Nothing pains us more than a failed implementation or an ever-incomplete project that seems to miss the "last mile" again and again ad infinitum. Nothing gives us more satisfaction then seeing a goal or purpose achieved. Count on us to finish the project, in small iterations, and to show you our successes along each of these iterations. Let's pop the champagne at the end of the complete project, and we assure you we will, together.

10. Play is important to us (we are not lazy)

As the age-old adage goes, all work and no play makes Jack (insert any other name) a dull boy, or girl. We love to work, we love to excel, and we love and appreciate your endorsement of our efforts. Along the arduous design and development process, we do need to take short breaks now and then, and play a little. A small dose of occasional play takes the stress out of doing developmental work which demands much of our brains, and allows us to get recharged for the next big round of continued development.