An Agile Case Study in a Medium Sized Enterprise!

Introduction

We had the opportunity to work with a medium-sized business on one of their high-profile web applications. For some time, the client has struggled to deliver the required functionality and to bring the necessary improvements to the application. It was not because the members of the technical team were incapable of delivering the features, it was because there was no clear leadership and the business did not have control over the development process. The technical team often placed the business in an impossible situation announcing that some features simply cannot or will not be done; and delivering the functionality too late.

Cake Solutions were able to introduce agile methodologies, improve the team work and put the business back in control. Ultimately, we were able to meet the deadline and implement the required functionality.

In this case study, I will show how we have achieved this; I hope our results will encourage you to use agile in your own projects.

Before Cake

The client had a strong development team, who were responsible for maintaining and developing large Java EE application. The team struggled with some of the legacy code and thus was unable to meet the business expectations to deliver new functionality and reduce the maintenance costs of the existing system. It was only when the board of directors imposed a strict deadline to deliver the new application, the management realised that they needed to change the way they worked.

In the days before our involvement, the technical team sometimes over-ruled the business; with the best intentions, nevertheless, the business was not in control of the development process. The technical team would often force their vision of the features upon the business. Furthermore, even though the business analysts worked hard to produce detailed requirements, once they were done, the technical team took over the implementation. If there were a change, the analysts would have to prepare change requests, update the requirements and prepare summary of the changes for the technical team. The entire process was difficult to control & manage and I will stress again without any ill will, the client struggled to deliver the right systems at the right time. It was high time for change.

Enter Cake Solutions

The client approached us to help them with the development. We decided that the best way to work with this client would be to offer 2 excellent programmers and one architect and project lead to become part of the client’s team. This way, we were able to coach the internal technical and business teams; it was only the combination of our technical excellence and agile project management experience that allowed the team to swiftly leave the traditional working practices behind. On the face of it, the recipe is simple: take 1 traditional team, add 1 business analyst and 1 manager, combine with experts from Cake Solutions; allow to simmer for three months and out comes excellent application. The execution, however, was far from trivial.

The first task we had to face was how to transform the specifications into the product backlog. The specifications document was very complex and very large. We needed to have a grand view of all the features of the system so that we could all understand the complexity of the system. We spent the first week talking with the business analysts, transforming the requirements document into a prioritised spreadsheet listing all features (stories in agile-speak) and working on the definitions of done.

Next, we invited the technical team to estimate the complexity of the stories in the product backlog. The team was very hesitant to come up with their estimates. This was largely to the fact that we were introducing too many new things at once: the new way of running a project, a new framework and a new way of working. In the end, our programmers worked through the technical details of some of the stories with the client’s team and were able to show the reasoning behind our estimates. This allowed the client’s team to come up with their initial estimates. We accepted their estimates: this proved to the first brownie point. Until this time, the team had the timescales and complexity imposed on it from the technical leads and management. We were careful to direct the team to focus mainly on the stories in the upcoming sprint, giving less attention to the stories in the next sprint and asking them to give only very rough estimates for the features towards the end of the product backlog.

So, we had the product backlog, good estimates and good understanding for the features in the first sprint. We were able to begin in earnest. But we were one week in and it is good practice to have two-week sprints. We used the second week as sprint 0: we configured the continuous build infrastructure, introduced new development tools and made sure that every developer is comfortable working with the new tools. We also practiced how the team would use the version control on a large project. At the end of the first 2 weeks, we were truly ready to begin the code.

In the first sprint, the team were able to complete all tasks they selected in the planning meeting; even better, we were able to bring more stories into the sprint. This is because the team have given overly pessimistic estimates. Interestingly, the team members have been pessimistic, because they did not yet have the discipline to treat every story as its own unit. The team often implemented the story and then we (Cake) had to stop them from gold-plating it.

Again, gold-plating with the best possible intentions: but we’ll need to delete the users, too, so we might as well do it now, we could give the users the ability to search by first name, last name and the middle name and such like. Because we have often seen this behavior, we were able to recognise it and stop it in time. Furthermore, we tormented the team with our strict insistence on unit and integration tests; I often found myself saying, well, there are no tests, the story is not done yet, is it? despite having seen the story working on the user interface.

In the second sprint, the team became enthusiastic and optimistic and, inevitably, selected more work from the product backlog then they were able to complete. We had to allow the team to make this mistake. We therefore spoke to the business by now, the analyst was on his way to being a good product owner and we explained that the team will most likely not complete all stories in this sprint, but that it is a mistake we have to allow. And so it came to pass that the second sprint ended up with stories that we were unable to complete. We discussed the reasons for this in the retrospective meeting and the team realised that they simply became too optimistic and that they will need to think harder during the planning meeting. In the retrospective session, we discovered several improvements to our way of working.

By the third and fourth sprint, the teams were progressing steadily though the stories. We had a stable platform, the Cake experts were able to solve the most complex technical issues and keep the team using the best practices. We were very strict and did not allow any mediocre, will- have-to-do, not to mention downright hacky code to make it into the product. This way, we were able to keep the team’s velocity steady; we have also seen tremendous improvement in the team’s technical skills. People who were shy to offer their opinion and who stayed back when asked to estimate were now eager to pick up new work and were becoming more and more accurate & confident in their estimates.

In the end, we were able to devote part of the team to bug testing and polishing before the final deadline to make sure that the system we deliver is of the best possible quality and truly meets the business and customers’ requirements. In addition to these tangible benefits, we were able to improve the team morale: the team members now own the stories and truly commit to completing and there is now a continuous feedback amongst the team members.

After Cake

We knew from the start that we would not be able to keep helping the team forever. This is why throughout the development process, our programmers and agile managers did not just sit in their ivory tower, giving instructions to the team below. No, we worked with the client’s team and we took extra care to explain, as best as we could, the principles of the new way of coding and managing the work. We ended the work by gradually reducing our commitment, passing on more and more responsibilities from us to the client’s team. In the end, the in-house team was able to run the project in an agile fashion on their own. Naturally, we still keep in touch and are able to help solve some of the more complex problems.

We are confident that the client will continue to use the agile methodology to run the projects and that from the technical perspective, the client will be able to build on the platform and architecture we have set up over at least 4 more years.

Summary

In this case study, I have shown how Cake Solutions were able to help a client who was struggling to deliver the functionality on time and within budget; technical teams who were listless with lack of leadership; business that was not firmly in control of the development process.

At the end of our involvement, we have a completely new picture: the business now drivers the development, is involved in the technical decisions to ensure that both parts of the company can work towards the same goal. The technical team is now much more focused on the task at hand and is able to use the most up to date approaches in software design and implementation.

The client has realised that the worries about agile processes being unmanageable, unmeasurable, never-ending anarchy are completely unfounded; that the opposite is indeed true.