Three real agile team challenges and how to solve them

Agile means a lot of different things to different project teams. Many teams I meet describe themselves as “Agilish” or use “Scrumerfall”. These teams struggle with Agile practices as business analysts author reams of business requirements only to have a development team write the user stories. Business representatives assume the product owner role but only check in with their team at the sprint review. Another favorite is adding more scope to an active sprint and the team wonders why they can’t meet their velocity goal.

Many of these issues stem from getting the Agile roles and processes right at the start of the project. According to the Scrum Guide, a scrum team has only a few roles by design – Scrum Master, Product Owner, and the Team. In Dean Leffingwell’s book, Scaling Software Agility, he favors eight or fewer team members including product owner, developers and testers. If you have recently obtained your two-day Certified Scrum Master (CSM) certification, you are likely excited to transform you team with renewed enthusiasm.

Then you take this newly acquired knowledge and real life hits.

Real-world agile challenges

How many of you have experienced these real-life scenarios?

1. The development team is distributed

2. The development team is a 3rd party vendor contracted for a fixed scope with their own software practices optimized for their organization

3. The product owner has the title but doesn’t perform the product owner role. The team then typically struggles with identifying and prioritizing business needs, receiving timely feedback and managing change.

Even though the Agile ceremonies aren’t hard to understand or follow, Agile implementations still struggle if the roles are not correctly understood. Fortunately, there are some Agile approaches to overcome these real-world challenges.

#1 Agile with distributed teams

Co-location is helpful but it isn’t always realistic as organizations scale their Agile implementations. Finding competent local talent isn’t always possible and organizations often select firms located across the country. If the development team is located in different regions, the Agile practices can still be delivered using Skype, WebEx, GoToMeeting or your favorite video conferencing tool. The key is ensuring there is enough communication between the team members including the product owner.

In one of my global programs, we ran two Agile teams distributed in the United States and Europe. The team conducted the Agile ceremonies supported by WebEx and also traveled quarterly to the global headquarters. The team was effective at delivering the backlog but also recognized the value in co-locating for important periods of time.

The key takeaway is to co-locate for a short period of time and communicate daily across multiple channels.

#2 Managing the outsourced vendor with their own software methodology

In an outsourced relationship, the company is entirely dependent upon the vendor’s ability to deliver according to the vendor’s methodology. I’ve seen wonderful Agile presentations from vendors claiming Agile expertise only to see it fall down due to their own internal development process. If you can’t influence or control the vendor’s software delivery process, Agile techniques can still be applied to define user stories and prioritize the most important features.

In a mobile software development project, the vendor claimed to be Agile but delivered in a Scrummerfall manner with two weeks of development followed by a week of testing. The team struggled with changes as requirements were elaborated. The business viewed changes to requirements as defects in the software and the vendor insisted the requirements were not provided accurately nor part of the original contract. Meanwhile, the timeline kept ticking by with a launch date approaching.

The best the team could do was to ensure bi-weekly feedback while they spent an enormous amount of time defining the product backlog. It wasn’t an ideal Agile approach but the team delivered after 6 weeks of system and user acceptance testing.

In hindsight, it would have been better to contract with the vendor on a resource based model allowing the project team to drive scope and determine how the project would be implemented. The scope would be jointly managed rather than contractually managed. This approach puts more risk on the project team but also ensures both the vendor and the project team can function as one team.

#3 Product owner by name only

In traditional IT, the business customer provides high-level requirements to an IT team and accepts or rejects the solution after reams of process flows and requirement documentation. With Agile, the business customer has a new title – product owner – and is expected to collaborate with the team to define needs, refine the product backlog and prioritize features for each sprint.

This doesn’t happen as easily as anointing a business customer with a new title. The reality is the business customer already has a job running the business. It becomes difficult for a business customer to run the business and engage in all the Agile processes. I’ve seen product owners disappear for a week because they were pulled into a crisis or had to resolve a business problem. Consequently, the team struggled with prioritization and feedback.

One approach is to allocate a “product owner by proxy” – an empowered business analyst or additional resource who is not running the day to day business but can help define the product needs while getting appropriate feedback between the product owner and the team. The product owner still needs to engage the team by attending sprint reviews, however, the proxy product owner engages in the day to day sprint execution. This model, although not ideal, still provided enough feedback to the team to develop the right product.

Agile isn’t as easy as it seems

Agile in a textbook and in implementation are two different stories. Teams just don’t become Agile by reading a book or taking a certification course. It takes time putting the Agile theory into practice and optimizing the Agile processes within the team. Executing the Agile ceremonies help identify pain points within the team and the retrospective helps to make improvements frequently.

Adopting agile techniques appears easy but challenges quickly appear if the organization doesn’t solve for solutions to distributed teams, fixed-price contracts or insufficient resources and roles. The challenges previously mentioned are just a few of the roadblocks teams will encounter as they adopt Agile practices. If the team focuses on developing software incrementally with quick feedback loops that enable teams to embrace change, then challenges can be addressed head-on.