Welcome to GlobalLogic Blogs

Although the merits of Agile have been repeatedly stated and confirmed, adopting it is easier said than done. Breaking from an established process can be overwhelming, especially if you do not totally understand how Agile works or why it’s necessary in the first place. Let’s explore how a hypothetical team makes the switch.

Harvey Hart, a senior developer in a life science project, entered the meeting room just as his project manager, Menny Manage, began addressing the team.

“Team, I have a special announcement to make. I had a meeting with the Vice President yesterday, and he wants our team to adopt Agile.”

Harvey frowned. “Why do we need to implement Agile? Our current processes work fine. And what would we do that’s different? Does this mean we won’t have any planning – we’ll just work in short sprints?”

“Our VP says that Agile will help us deliver more functionality and better quality in less time,” Menny replied. “I’m not entirely sure how it will work, so I’ve asked an Agile expert to come explain it further. He should be here any minute.”

Amy Assure, a test engineer, was thinking about how Agile might affect her work. “Will there be any changes to the processes we follow now for software testing?”

Nobody had an answer. Freddy Fresh, a new team member, had never even heard of Agile but was embarrassed to say so.

Have you ever been in a similar situation where you are told to adopt Agile and you wonder, “How?” Isn’t it similar to the one-line requirements that clients sometimes make at the beginning of a project? You are told to “make it happen,” but you have no idea what changes to make or how your actions will be measured.

Scott Sprint, the Agile expert, greeted the team as he entered the room. The response from the team was tepid, and Menny explained that they had several doubts about adopting Agile. Scott had encountered such resistance before.

“Let’s talk about why you should adopt Agile,” he began. “First of all, it can significantly reduce software development costs in comparison to traditional practices. Agile mandates a highly collaborative environment that enables feedback; creates an ecosystem to inspect and adapt; empowers the team to make the right decisions; and helps the team deliver high-quality, incremental software releases in quicker cycles.”

“I’m still confused,” said Amy uncertainly.

“Agile is about developing products that are the best in all aspects: usability, quality and elegance,” explained Scott. “It doesn’t necessarily mean delivering faster, but maintaining a sustainable pace and making reasonable commitments to clients. Agile is by no means a silver bullet, but it does optimize the software development process by reducing waste and solving existing problems. And, more importantly, it relies on the collective wisdom of the team.”

“That makes sense,” said Menny. “But how much time will it take to train the team on Agile? We’re very busy and may not have time to conduct multiple training classes.”

“Agile adoption isn’t a huge effort,” replied Scott. “You don’t need a series of classes to start using it. You’ll just need a one-day session to learn terminology, roles, and artifacts. The class is actually a lot of fun.”

“That doesn’t sound bad,” said Harvey. “What do we have to do to implement Agile? Can you provide a list of action items or a checklist that we should follow?”

“There is no single approach or method that works for every team,” answered Scott. “You have to find an adoption method that works best for you.”

Everybody looked at Scott in dismay. “How?” Amy asked.

Scott continued, “It depends on several factors. Let’s start by looking at the problems you’re currently facing and figure out whether some can be solved by adopting Agile principles and practices.”

One of the best ways to start adopting Agile is to hold an initial evaluation meeting and pinpoint improvement areas. Going forward, your Agile team will hold a retrospective meeting at the end of each sprint to discuss what worked, what didn’t work, and how your team can improve for the next iteration. Even if the sprint retrospective meeting is the only Agile practice you follow, it will significantly improve your work.

Menny started with his biggest challenge. “Frequent requirement changes delay our release schedules. Just this morning, I received more change requests from the client. I have to update the project plan after this meeting.”

Scott nodded. “This is a classic problem. Try conducting a release planning meeting after every second or third iteration to ensure a more realistic schedule.”

He pulled out a post-it notepad, wrote ‘Changing Requirements’ on the top sheet, and attached it on the whiteboard. “Let’s have all the team members start listing their own challenges. We’ll call this list our change backlog.”

Freddy raised his hand. “I just joined the team, and I’m going through the requirements specification document to get an initial understanding of the project. Like Menny said, the client keeps sending change requests, meaning many sections of the document are not up-to-date.”

“Changing requirements are inevitable,” said Scott. “Work with the client to write user stories that are easy to understand, organize and prioritize. In the event of change requirements, you can simply add more user stories to the product backlog.”

Harvey raised his hand next. “Right now, my biggest challenge is conducting knowledge sharing sessions with new team members like Freddy. I don’t know if this is a relevant issue, but it takes up a lot of my time.”

“It’s definitely a relevant issue – and one you can solve with pair programming,” said Scott. “Pair programming has a built-in mentoring program and provides benefits like continuous code reviews, which we can talk about later.” He added ‘Knowledge Sharing’ to the change backlog.

Amy spoke up. “We find too many defects in the production environment, and many of these defects repeat in almost every cycle.”

Scott added ‘Defects’ to the change backlog list and said, “I would suggest writing automated acceptance tests.”

Amy continued, “We also find too many defects in the integration testing phase. How can we reduce them?”

Scott looked at Menny. “Does the team write unit test cases before creating a new piece of code?”

Menny shook his head. “Writing unit test cases takes lot of time. The developers can’t afford to focus on them.”

“How long does it take to fix defects found in the integration testing and acceptance testing phases?” Scott asked.

“Around 4 weeks,” Menny replied sheepishly.

Scott nodded. “Automated unit tests, coupled with instant and nightly builds, will help the team find and resolve defects very early. It may take time to collect the unit test cases, but the return on investment is significant. “

The team continued to talk about other issues such as code reviews, build processes, communication, distributed development and reporting progress to management. Some of the questions Scott encouraged them to think about included:

• Do you know the client?
• Who estimates the requirements? Does this process involve the entire team or only part of it?
• Who makes timeline commitments?
• How often do you release software to production? If your client wants to release more frequently, can you?
• Does the team know approximately how much it can deliver each month/quarter?
• How often does the team conduct project status meetings?
• How often the team makes a demo of the work for the client?
• How often does the team review how it is doing?
• How many defects are in the defect queue? How does the team address these defects? Does it maintain a queue of defects to fix later, or does it fix defects immediately upon finding them?

Obviously these questions will not all be relevant to your specific project. However, the process of creating a change backlog will help team members identify specific problem areas to address.

At the end of the initial evaluation meeting, the team’s change backlog looked like:

Harvey looked at the change backlog and felt overwhelmed. “I always thought we were doing well, but this is a long list of improvements.”

“It does seem to be a big change,” Menny agreed. “What are the next steps?”

“Put the change backlog in full view of the team and let them choose one or two items to address each week,” Scott said. “Start with the low-hanging fruit first – something that can be solved quickly.”

The team agreed that they would start with retrospectives, daily standup meetings, continuous integration and pair programming for knowledge sharing and problem solving. With this prioritization completed, the change backlog looked this:

I hope you this story has persuaded you that adopting Agile does not have to be a scary or time-intensive process. It’s a matter of understanding why Agile is important and using it to address current problems in small, incremental steps. With trust, honesty and plenty of collaboration, your team can begin its journey to adopting Agile just as easily as Menny’s team did.

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

Popularity: 54% [?]