Transitioning to Agile

The Business Perspective

3 April 2014


Successful software development requires support and active participation from a wide variety of people from across the entire business. When traditional Waterfall approaches to software development are not producing the required results, it's natural for Agile to be considered an answer. While I have nothing but support for such a decision, it is not an easy path to follow. Anyone embarking on this journey will face many challenging times, to the point of questioning whether the good old way really was just that, as for every two steps forward that you take you feel like you're taking one step back. This article has been written to prepare teams for what lies ahead.

The transition to Agile can see your team quickly divide into two. On one hand you have the technical team, developers, QA, UX, visual design, dev-ops -- those who are involved in the day-to-day development efforts. On the other hand, you have the business stakeholders, who provide that all-important direction, finance, and customer support, and who drive sales. While they are very interested in the project's progress, they are only involved at key milestones.

At times it will feel as though these two teams are in conflict with what you are trying to achieve, instead of working toward one united goal of producing high-quality software that your customers cannot wait to use. Remember: This goal is still there, and a successful transition to Agile is only complete when your team is working as one.

If you are to conquer this problem and fully adopt Agile, it is important to understand the cause of this divergence. With a good ScrumMaster, technical teams will benefit from the introduction of retrospectives and being able to remain focused throughout a sprint without disruption. However, this transition is not as straightforward, easy, or obvious for the business stakeholders.

The business stakeholders like the idea of Agile -- the promise of reduced times from concept to delivery, the ability to get feedback early, and the ability to quickly change direction as business needs demand are all very alluring. However, there are greater challenges that will often feel more important than the benefits. Understanding these challenges and bringing the entire team together to overcome them is the sign of a good, mature Agile team and is the ultimate key to successful Agile adoption.

High-level challenges

Waterfall appears to offer business stakeholders required information and early reassurances to enable them to fulfill their roles successfully. Sales and marketing teams like to know in advance when the delivery date will be and what will be included so they can successfully plan their campaigns. Feature sponsors, who ultimately take responsibility for the success/failure of a feature, are heavily involved in the requirements gathering and sign-off of full details before development work starts. Moving to Agile puts a very large question mark over how these important aspects of delivering software will be achieved. If left unanswered, these questions will be the main cause of divergence within the team. Understanding why this is challenging to your stakeholders is the key to working with them to ensure that Agile is fully adopted.

Training

Where Agile training is provided, it is usually only given to those closest to delivery, i.e., the technical part of the team. If the business part of the team is not included at this point, then your team divide has already started before your first sprint begins. When business teams are invited, the content is usually focused on the changes the technical members of the team should adopt and does not address how business stakeholders fit into the new world, nor how long-term planning should be completed. This introduces a gulf in two ways: Business stakeholders are skeptical that Agile can provide everything they need, while the development teams are left unaware of the new challenges the business stakeholders face.

Delegation

Agile empowers the entire team to make decisions. In the majority of cases, this will mean asking some of the business stakeholders to play a different role -- which, ironically, should reduce their workload. For example, working out the detail of how a feature is best delivered will fall to collaboration with the technical team, with feedback coming from the business stakeholders at sprint demos or feature sign-offs within the sprint. This is a huge shift from the days of the feature sponsor working with a BA to produce a detailed specification that is signed off before development starts, especially if you're that member of the team who was never sold on the adoption of Agile.

A successful transition will need to ensure that the feature sponsors know that their inputs are needed (and when) and that they are still crucial. Reassurance is needed that Agile is not about some techies, unconnected to the customer, making decisions but that it's about a team effort. If decisions are made that ultimately do not deliver the required business value, then they will be identified early and can be rectified. It is also natural to be skeptical of the inspect-and-adapt process, and when it's your feature and you feel responsibility for its success, the knee-jerk reaction is to want to specify and sign off everything within every inch of detail before approving the development effort. This is achieved by good sprint demos and encouraging feature sponsors to define the new feature in terms of what it needs to allow a user to achieve and why, instead of a focus on the how.

Finally, there is the aspect of trust -- trust that the detail can be done without the feature sponsor and, where detailed design results in new ideas and approaches, trust that this design has been made with an understanding of good software practice, an appreciation for quality, expertise in defining a good user experience, and a detailed knowledge of the product so that the design complements existing features.

All this takes time, but understanding these concerns and ensuring that decisions and conversations are held appropriately and sensitively with the right people, combined with a positive team-wide attitude toward embracing change, will ensure that the transition does happen.

Release planning

The ability to respond to business change quickly contrasts with being able to define the full details of a release that is months in the future. While business stakeholders will quickly recognize the benefits of rapid change to ensure that the product remains competitive, the need to have a long-term plan is important. It is often worth remembering, too, that business stakeholders need to interact and report to other parts of the business that may perceive software development to be a black art completed in "that part of the office." They may be unsympathetic or ignorant of the differences among the actual methods used to deliver the software.

Addressing this issue is, in my opinion, the biggest challenge. At the start of the release, you cannot commit to the "what" and the "when" simultaneously. And even if agreement is met at the beginning, pressures from senior management may cause your business stakeholders to waver and put the team under unreasonable pressure to deliver features. The use of a trade-off matrix helps with these discussions and keeps the mind focused across a release. Talking about features (in broad terms) and capabilities and ensuring that they are always prioritized with business value (in financial terms where possible) also ensures that conversations and decisions are focused.

The final major part of this puzzle is the marketing and sales teams. Working with them to understand what information is required, and when, is the way forward here. It may be that by providing information on the work completed at the end of each sprint and keeping them up to speed on changes in new feature priority will be sufficient to ensure that they can be successful in their roles too.

Above all, it is important to always remember that a software product is only successful when every member of the team -- technical or business-facing -- is able to fulfill his or her role completely.

Time and commitment

Waterfall approaches often demand a lot of time up front from the business stakeholders. However, a successful transition to Agile needs that time to be distributed across the release of a product, with small spikes at appropriate points in time. This may feel unmanageable to some business stakeholders, who already have an overflowing calendar to manage. So this may mean that you do not feel you are getting the support you need in the first few sprints. But adding ritual sprint meetings to all calendars far in advance will ensure that this situation improves. In the meantime, try to find a way to be sure the business stakeholders are up to speed with the project, as this will maintain that all-important buy-in needed for the success of both the product and the adoption of Agile.

Summary

Typically, the time before business stakeholders will see the benefits of Agile for themselves will be longer than it is for the technical teams. This is compounded by the fact that the challenges to changing their way of working to support Agile are harder to achieve.

So as different members of the teams adopt and embrace Scrum at different speeds, there will be growing frustration that needs to be managed. You'll find that part of your team wants to push forward but feels held back by seemingly incomprehensible blockers and outdated attitudes from other parts of the team -- those who are struggling to embrace Agile and trying to return to the comfort of Waterfall to gain the answers they need to support their roles. In all of this, remember the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
 
So ensure that you work with the business stakeholders. Remember that they are part of the team, bring them along on the journey with you. Through retrospectives, listen to everyone's concerns, hear about the challenges (technical or otherwise) they have faced over the past sprint, and encourage the entire team to find the solution together. My one piece of advice for this situation is to work tirelessly to ensure that your team does not divide into two. Remember that everyone's contributions are needed to ensure success. Finally, if someone appears to challenge or go against the Agile process, the reasons for this need to identified and brought to the attention of the entire team, to solve together.

All of this is hard work and is a huge challenge, but I promise you, it's worth it in the end.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (2 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.