Welcome to GlobalLogic Blogs

One of the biggest misconceptions is that iterative equals Agile. Although iterative development is part of Agile, it should be accompanied with other best practices. It is imperative to set a goal for each iteration and then verify it against the requirements upon completion. Goal-setting, retrospectives and regular collaboration with the client are key to successful Agile software development. Let’s review a common scenario involving a hypothetical character named Karen that demonstrates how iterative development can fail if not executed properly.

…………………………………………………………………………………………………………………………..

 Karen is an experienced project manager in a large, multinational software product development firm. Although she has a great track record, she was shocked to receive dismal ratings in a recent client satisfaction survey. She felt her team was doing a great job of building a very complex product – especially considering that the client had demanded a large amount of requirements changes during UAT while refusing to budge on the release date.

To make matters worse, the company’s vice president had just requested to speak with her. As she anxiously walked into his office, Joe said, “I just saw the client satisfaction ratings, and I’m not pleased. Is this what you consider good work?”

“I’m shocked by the ratings myself,” replied Karen. “Two weeks ago, everything was going as per the plan. But then we started user acceptance testing, and the client was not happy with what we had developed. Now they’re asking us to make a lot of last-minute changes.”

“Are these new requirements?” asked Joe.

“Yes and no. In my view, these are new requirements. However, the client views it differently. It appears we interpreted some of the requirements differently. But let me say that my team developed the software as per the requirements described in the specification document. We shouldn’t be blamed for the requirements changing six months down the road.”

“Well I hope you’re aware that the organization’s reputation is at stake with this project,” said Joe. “This is a long-standing client that we cannot lose. What’s your plan to fix this situation?”

“I’ve already discussed the situation with the project team. Although they agree with me about the requirement changes, they have committed to do everything they can to meet the deadline. Team members have cancelled their leave plans and have committed to work nights and weekends, if needed.”

Joe nodded. “I know you’re a very good leader and have done exceptional work in the past. Can I trust you to turn things around?”

“Yes, of course,” Karen replied.

“Let me know if you want any additional help or resources from me,” said Joe.

Karen thanked him for the offer, but she knew that adding people so late in the project would not improve the situation. She walked away from the meeting angry and depressed. In her long career as a project manager, she had never received such low ratings or had doubts raised about her abilities.

…………………………………………………………………………………………………………………………..

Have you ever been part of a project gone wrong? The 2009 Standish CHAOS report confirms that only 32% of projects are delivered on time, on budget and with the required features and functions. Although this is a shocking figure, we have all witnessed or been part of similar situations.

…………………………………………………………………………………………………………………………..

Karen began to carefully analyze what had gone wrong. Her root cause analysis pointed towards the requirement gathering phase. Her team worked in an iterative mode and monitored the progress after each iteration. “What can we do if the client deviates from the requirements?” she thought.  “Why should I or my team be responsible?”

As she was thinking, Karen recalled an incident from college that felt very similar to her current situation. Her professor had asked the class to read three books and answer 10 questions based on their understanding. Karen strategically divided the assignment across five days so she could complete it before the weekend. Her plan was to read the books in three days, answer the questions on the fourth day, and review her responses on the fifth day.

At the end of Day 3, Karen successfully completed reading all three books and was pleased to be 60% finished with the assignment. However, on Thursday morning she was shocked to find that the questions were very complex and would each require inputs from multiple books. Frustrated, Karen cancelled her weekend plans in order to re-read certain areas of the books and answer the questions. She dedicated half a day to each book and was done answering the questions by Sunday evening.

Unfortunately, Monday morning revealed another shock: her professor did not like her assignment! “I wanted you to answer the questions with your own ideas, not quote the book,” he explained. What had gone wrong? A deeper conversation with her professor helped Karen find the root cause of her mistake:

• First and foremost, Karen failed to understand that just being iterative does not guarantee success. Although she had measured her performance by the number of books she read, the real objective of the assignment was to answer the questions. When she thought she had completed 60% of the project on Day 3, in reality she had not yet even started. Instead of blindly taking an iterative approach, Karen should have defined a goal for each iteration that was aligned with the overall goal of the assignment.       

• Karen should have also first reviewed the questions to better understand which areas of the books she should focus on while reading. This strategy would have helped her get a better picture of the project’s overall goal.       

• Karen could have saved herself a lot of time and rework by obtaining her professor’s feedback on a few answers before continuing with the rest of the assignment. If she had known early on that he did not want answers from the books, she could have refined her work to ensure a successful paper that met her professor’s expectations.

…………………………………………………………………………………………………………………………..

A key ingredient of Agile development is regular client feedback (i.e., after each iteration). We all know that product requirements are bound to change when you actually see the product. It is very difficult for the client to imagine how the product will look at the time of requirements gathering. This is the reason it is important to manage the changes rather than stopping them, which will ultimately lead to a better product and a happier client.

Also imperative to Agile development is to constantly retrospect your work and learn from your mistakes. Teams that learn from their mistakes early on avoid making high-impact mistakes later, thus delivering higher quality products. Remember, quality is measured by a team’s conformance to spec as perceived by the client.

…………………………………………………………………………………………………………………………..

In recalling her failed college assignment, Karen could identify what went wrong in her current project. She realized that although her team had utilized best practices, optimized the design and delivered a product very similar to the client’s original requirements, they had not cultivated a deeper understanding of what the client actually valued during the development process itself. The product would never be considered a success unless it achieved high market acceptance; the only way to ensure this was to adapt and respond to changes proposed by the client.

• Work in collaboration with the client towards a single goal
• Understand what the client values most and prioritize these features and new change requests
• Work on the simplest changes that will satisfy the client
• Plan for iterative and incremental releases, then share the working software at the end of each iteration
• Regularly obtain feedback from the client by conducting reviews of working software at the end of each iteration
• Carry out retrospectives at the end of each iteration

The result of Karen’s new strategy was that her team successfully delivered the client’s most important features on time and within budget. They were able to win back the client’s trust, which was a dramatic and happy turnaround.

…………………………………………………………………………………………………………………………..

Every project goes through rough times, and Agile can be an effective tool in resolving them. But remember that although Agile is iterative, each iterative process is not Agile. Collaboration with the client and working as a single team is the key to delivering successful results.

…………………………………………………………………………………………………………………………..

This Post was an Agile collaboration between Peter Harrison & Mayank Gupta of GlobalLogic

Popularity: 74% [?]