website-logo
GET IN TOUCH

Maintaining Business Agility With Agile Development

May 31, 2017

featuredimage()

Most companies are in fast-paced environments that constantly require them to deploy new technology that meets growing customer needs. Tech teams must be ready to pivot, a key advantage of Agile development, which focuses on meeting business value dynamically.  

Agile development allows dedicated teams to rapidly deliver new features. Stakeholders no longer have to wait months to assess a soon-to-be-deployed feature and verify it meets business needs. After each cycle (3 weeks on average), the client receives an executable version that they can test.  

Another key benefit of Agile development is stakeholders’ ability to directly participate in iterations or “sprints.” This allows the company to see possible shortcomings ahead of time, so that the development team can address them rapidly. Stakeholders waste less time, and developers have peace of mind that they’re on the right track.  

Role of Documentation in Agile Development 

Traditionally, development teams have heavily depended on documentation. However, documentation is not as time-consuming in the Agile process. Instead, teams focus more of their time eliciting feedback from the stakeholders and analyzing the effectiveness of new features.  

In general, teams can spend their time during the documentation and review phases on five core activities: planning, eliciting, analyzing, documenting, and reviewing. How much time your group invests in each of these activities largely dictates how easy it is for them to dynamically respond to new demands. There are many factors, including the 7 Product Dimensions, that will impact feature requirements. That’s why it is important to be ready to adapt.   

So how much time should Agile development teams spend on each of these tasks? Let’s look at two examples to get a better idea of how they should divvy out their time:  

 

 

Figure 1 – Slow requirements process 

agile requirements

 

 

Figure 2 – Faster requirements process 

If your team’s invested time looks more like the first pie chart, beware. You may be putting a lot of effort into documenting and reviewing, something that might change and, therefore, require rework. Teams should anticipate that new requirements will emerge in meetings and during QA testing. 

Unlike Figure 1, the second pie chart shows how the requirements process should look for an Agile team. In an ideal Agile sprint, gathering requirements and analysis should take up 5-10% of the documentation and review phase. This lowers the risk of rework for development teams and opens the possibility to pivot quickly.  

The great challenge of requirement gathering is to document knowledge in a way that is useful to everyone and can be updated to keep up with constant changes. Perfecting this process will take time, and no one should expect to get everything right in the first sprint. Learn how your company can benefit along the way from Programmers’ Agile Experience.