June 24, 2014 • 2 min read
The second principle of the Agile Manifesto is: ‘Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.’
Taking a look at this principle, we start off with: ‘Welcome changing requirements, even late in development.’
If we can agree that satisfying the customer is the top priority for an Agile team, and that customers can change their minds, then this idea follows Principle #1. You have to satisfy the customer, even when they aren’t sure what they want. I think a few important steps here are stating the requirements, checking in regularly, anticipating changing requirements, and deploying early.
One of the most important steps is stating the requirements from the start. We use Trello, a free online project management tool that is easy to use. Trello lets us make ‘cards’ on a virtual whiteboard. The cards are a record of our conversation, the requirements we’ve agree on, and any external links. It’s a great tool.
After we’ve begun work, a second important step is to check in regularly with all stakeholders. Daily stand-ups are one of many opportunities to achieve this.
A third thing I try to do is anticipate changing requirements. If an application includes an administrative dashboard for non-technical staff, I try to imagine whether the feature I’m building needs to be exposed there. It might not make sense to expose it preemptively, but just thinking that through starts an important conversation with the customer.
I also think it’s important to deploy early for testing to a company-wide environment. Seeing the code in action can answer many questions, and help the team catch obvious bugs or holes in the plan. If you can eat your own dog food, all the better. The Iceberg Secret is a crucial tool for managing expectations during this process.
‘Agile processes harness change for the customer’s competitive advantage.’
How can a software development team harness change? I think the main requirement is that the team needs to be composed of pragmatic observers of the technology landscape. Staying open-minded and uncoupled from any framework or ideology allows the team to choose the best tool for the job, even if that tool is new and unfamiliar.
An example would be site responsiveness. Making a site responsive to any screen size is mandatory today, but it was not a major consideration even a few years ago. A team that recognized this early on (say, with the launch of the iPhone or iPad), learned how to make responsive sites, and started building that functionality into their customers’ websites, passed to those customers a competitive advantage. There is a lot to gain by adopting a technology early, and Agile teams take advantage of this by anticipating change.
P.S. Did you enjoy this post? I'm currently launching a React-focused newsletter to help people get up to speed on this exploding technology. Subscribe to React Explained here!