Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
In a traditional software development lifecycle, a team might plan an entire piece of software from start to finish. The business would set the scope, the budget, and the timeline up front and might not even talk with the development team before committing to those elements of the project.
However, there are some clear challenges when doing all of your software planning at the very beginning of the project. The Agile Manifesto attempts to address those concerns by placing a focus on individuals and interactions, working software, customer collaboration, and responding to change.
One of the Agile Manifesto principles states that software teams should “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Rather than delivering working software every six months or every year, teams are starting to release much more regularly, on a timescale of weeks or even days, instead of months or years. By releasing working software more frequently, software teams are able to deliver value more frequently to their end user.
When teams deliver more regularly, they’re able to change directions in an agile way. Rather than waiting six, twelve, or eighteen months to get feedback from the customer or end user, agile teams can get feedback every couple of weeks. This puts teams in a much better position to pivot when, inevitability, the market changes or bad assumptions were made.
It helps to check your assumptions. Did you make a year’s worth of assumptions or two week’s worth of assumptions before you get feedback? You don’t actually know what the user wants and sometimes the user doesn’t know what the user wants. By over-planning the project early on, you lose the flexibility and agility to make changes based on frequent feedback.
But planning doesn’t go away in agile. In fact, for new teams, a strong planning process is key. New teams should spend more time planning than they’re used to and even more than they might in the future once they have an established cadence. Once they’re able to release something in that short time period, once they see it roll out and they see how happy it makes their client or users, it makes agile software development easier to sell. It becomes obvious why it’s so great.
Transitioning to an agile process, however, isn’t always so easy. One of the biggest challenges in transitioning, especially if you have a pilot team and the whole organization isn’t transitioning at the same time, is that teams can still be held up by other teams who they’re dependent on. If other teams aren’t working in the agile methodology, it can be frustrating.
When you start your agile journey, and even as an experienced agile team, focus on what’s in your control. By focusing on the technical and cultural changes within your control, you can start to show your organization why agile development is critical to delivering working software.
I’d love to continue the conversation with you in the #agile channel on the TechWell Hub.
