In this Innovation Session Rajinda Rathnapala of the Monetization team spoke about Agile, and its use in a real life context.
Agile has been widely touted as a software development approach that is easy to implement, but is that really the case? The Agile process is actually more difficult than what you are lead to believe. More often than not, most case studies that you read about Agile have the ideal environment for Agile always in place. Most companies do not run under ideal circumstances, so let’s discuss agile in real life and take a look at the scrum methodology.
Within Agile, there are several ways in which you can choose to handle your product releases.
One way of doing it is to take an incremental approach. To give you an idea of what incremental development is, let’s take an example. Say that you need to develop a financial data comparison application; to complete this application, you need to have developed the following features – Date Comparison, Index, Stock Chart and finally, related news events. The final product should look like this:
With incremental development, you break down the application and develop them feature by feature. In this example, one possible way of doing this would be to first develop the Date Comparison along with the index and the output given in text for the two stocks. The next phase of development would have been the creation of the charting library, and in the final stage the News feature is implemented.
The main drawback with taking this kind of approach though, is that the end product might not be what the customer wanted, especially if the features that were expected are complex.
Another approach that combats this drawback is the Iterative development approach. With this approach, the product itself is refined through successive releases, and collective feedback plays a key role.
The first step with the Iterative approach is to build a skeleton product, with higher priority features being developed first. The product is then refined step by step – from the skeleton product that it was, to the end product. If we apply the iterative approach to the scenario as above (The Financial Data Comparison application), the product would have been built as follows:
During the first iteration, the date range and the index will be hardcoded, the charting library would be integrated, and only one stock will be displayed.
During the next iteration, the user will be able to select the index that he or she wants, links to the related news, and the date range selection feature.
During the final stage, the user would be able to compare two stocks, with a synopsis for the news.
The final development would look something like this:
Although the differences between these two approaches are subtle, unlike the incremental approach, the Iterative approach provides the customer with a base idea of what the final product will look like thanks to the skeleton release.
Now that we have a basic understanding of what Agile is, let’s move into real world scenarios.
Company A is planning to move into scrum. All required trainings have been done, and the teams are about to start implementing the processes. Time to take a look at the problems:
The Product Owner is absent most of the time. The role of the product owner is critical, and the absence of a product owner is a tough challenge for the rest of the team to overcome. The number of reasons for a product owner to not actively participate in scrum ceremonies is numerous. One common reason is that the PO is a high ranking member of the company with a very busy schedule. If there is no way around his or her busy schedule, an alternative could be to assign a Product Proxy – an intermediary between the PO and team that’s located with the team.
The benefit of having a product proxy is, that they are able to work closely with the Product Owner to understand and then effectively communicate the vision of the product back to the team. In this way, when the development team comes across a problem, they do not have to wait on the PO’s availability to fix it, and things get done faster.
However, before assigning a product proxy role clear boundaries have to be established, such as what decisions the Product Proxy can make. There will be times that the PO will overrule the decision of the Product Proxy, but it remains critical that this is done only when necessary, else the development team will begin to rely less on the proxy and more on the PO, bringing us back to the main problem.
Meeting hard deadlines. In delivery, there are three main constraints that are illustrated below:
There are a few ways in which companies look to handle this triple constraint. If the priority is on the features, what’s usually done is to increase the team size, and extend the deadlines as shown below:
However, keep in mind that increasing the team size will not in the short term deliver the productiveness that you expect. Forming a team goes through phases as well (forming, storming, norming and performing). Because of this, it will take time for a team that’s put together to really kick into gear. Till they reach that point, things might go a bit slow.
When meeting deadlines in Scrum, it’s key to know what your velocity is, what your capacity is, and how much time there is left. Take a look at the following scenario:
Above is your product backlog – let’s assume the team velocity is 10 and the remaining sprints are 3 which means the capacity is 30. The backlog has a remaining value of 40. In other words, completing this backlog is not possible, due to it being above the team’s velocity.
So, how do we resolve this? Although this looks like a tough problem to solve, once broken down, more options seem to open up.
The major factor for the release was the Chart trends. If this is taken out, the release can go ahead with just one feature missing.
Agile is not always easy to implement. The right process has to be in place and the right roles given to the right people, but if done right it could help create the right product at the right time.