Agile Development: How to Execute with Cadence and Quality
Writing software with the right balance of responsiveness, predictability, and reliability is a constant challenge. Overlay the environment of regular technology revolutions that disrupt the status quo, and you have a very dynamic ecosystem with relentless pressure to deliver and a constant struggle with the paradox of figuring out how to do more with less.
It’s metaphorically equivalent to changing the engines and guidance systems in your rocket ship while you’re in flight. We are blessed (or, some might say, cursed) with a plethora of choice when it comes to ways to get stuff done (also known as methodologies).
We’ve experienced practical examples of key elements that will help achieve and maintain that balance, drawing predominantly on agile-based methods. Hopefully you’ll glean some constructive ideas about getting stuff done in the knowledge economy.
Iteration reduces value and execution risk
Iteration simply means maintaining a regular start/stop cycle and the key word here is “regular.” Get the team into a rhythm with cycles that last two to four weeks. Anything less than two weeks, and the rate of work completed can fall to to the point where you don’t make meaningful progress and morale declines.
Each cycle brings with it a certain amount of administration that can become significant when iterating for longer than two weeks. But a cycle longer than four weeks might send you drifting off-course before you realize it. Getting this balance right will afford you a clear view of your progress and provide you with ample opportunity to course correct before you get too far along and feel compelled to continue investing, because you’ve already put in so much time and money (this is also known as the Sunk Cost Fallacy).
People suck at absolute estimates
You cannot rely on absolute estimations of effort or how close a project is to completion. How often have you thought you were 95% complete only to find it takes you the same duration again to complete that last 5%? To illustrate with a simple example, take a look at your nearest gate. How wide and tall is it? You will likely be hard pressed to estimate accurately. Now compare that gate to the gates at the main entrance to the White House. Is it larger or smaller? You’ll be able to answer that question pretty accurately and quickly. People are much better at relative estimation, so build that into your planning model.
You have to start with some common reference point, however, so the first project or deliverable should become the yardstick that all others are compared against. Use an abstract number series, like a Fibonacci series, to assign relative complexity to your tasks. Gather metrics over time and, after a few iterations, you’ll have a read on the quantity of these abstract story points (or velocity) the team is able to get through in a given iteration.
The great thing about velocity is that over time it accounts for the hard to predict things like interruptions, distractions, and estimation errors and will give you a meaningful way to make time estimates. A word of caution: velocity is specific to the team and the cycle duration. If you change the team or the cycle duration, then you’ll need to recalibrate your team’s velocity. It is not transferrable or comparable; don’t fall into the trap of trying to motivate two teams by playing one’s velocity off against the other.
Beware the allure of “cheap” credit
A classic mistake made time and time again is compromising quality to meet short-term deliverables by way of accumulating technical debt. The interest on technical debt is always compound and adds up much faster than you expect. What seems like a compelling corner to cut or a quick win now will hurt you in the future.
Start as you mean to go on. Think about how your project will scale as you become successful and expand the team. Invest now in Continuous Integration (CI) and Continuous Delivery (CD) tools and methods. Make sure your code is being well checked and tested with portable automated tests for functional (feature) and nonfunctional (security, reliability, scalability, and performance) characteristics alike. Make sure it’s just as easy to add test cases and home in on test failures as it is to add code.
Avoid making quality someone else’s responsibility and instill in every developer the mindset that testing and test automation is coding too. Automate anything that you do more than once in the process of getting code into production so that you standardize as early as possible, keeping the operational aspects such as configuration and code deployment the same throughout all stages into production. Finally, eliminate dependencies wherever possible by building discrete and autonomous components, with published interfaces.
Eliminate status meetings
If you really want to track activities, make it asynchronous. For example, everyone should complete a simple Google form once a day with daily summary emailed automatically to the team. Focus interactive sessions on priorities, identifying and eliminating blockers, and design and implementation details.
Break out into smaller, targeted follow-ups as required to get into deeper detail. In the early stages when a team is forming and particularly when a team is not co-located, you may need to hold these meetings as frequently as daily. As the team settles into their rhythm, the frequency of these can be reduced. Always encourage the team to tackle blockers wherever possible as they come up—they shouldn’t wait for the meeting to raise these issues.
There’s a very large volume of anecdotes, theories, and best practices regarding how to get things done. There’s only one truth, however: there is no single, guaranteed recipe for success. Great results depends on the commitment and talents of everyone on the team. Working out how to best organize, motivate, retain, maintain, and constantly improve is itself a complex balance of talent, skill, and experience.
Do what works for you and your team and get executing with cadence and quality!
Photo: Matt Biddulph/Flickr