Why Should the Business Care About Agile?

In mid-September, Mike Stuedemann, Certified Scrum Trainer and Agile Coach, hosted a webinar entitled, “Why Should the Business Care About Agile?” To listen to the webinar, please click here. While a number of questions were addressed during the webinar, the time-box did not allow all of the questions to be answered.

This blog is an attempt to address questions and generate subsequent discussion among webinar participants and non-participants who are interested in continuing “the conversation”. The unaddressed questions include:

• How to deal with an offshore QA Team in Agile? – Organizations who have an offshore presence can be successful in adopting an Agile method. However, it requires a greater focus on collaboration and communication. Moreover, organizations that are pursuing the benefits associated with adopting Agile may need to reorganize their existing teams. For example, instead of having a QA team as implied in the question, organizations should strive to have “feature” teams comprised of all the skills necessary to get a product to “Done”. This article from Martin Fowler provides a number of additional recommendations for implementing Agile in distributed organizations.

• How to integrate Agile in Infrastructure and Operations Teams? – Infrastructure and Operations Teams can benefit from Agile as a philosophy, but the method that best fits their work is often not Scrum. Kanban, a method that emphasizes visualizing the flow of work through a process, limiting work in progress, and being explicit about process policies, is used by a number of teams in the space to deliver continual value to their constituents. To learn more about Kanban, check out this overview by Atlassian. It includes not only an overview of the method, but also a comparison to Scrum.

• What is the role of a Business Analyst in a Scrum world? – There is a myth associated with Scrum that there is no role for someone with a Business Analysis skill set to play on a Scrum Team. While Scrum specifies only three roles – Product Owner, ScrumMaster and Development Team, the Development Team is to be comprised of all of the skill sets necessary to get the product to “Done”. This means that someone with a Business Analysis skill set can be a member of the Development Team under Scrum. As a member of the Development Team, they can not only bring their traditional skills, they can also expand their skill set by helping the Team in any way possible to get to “Done” including testing and developing code.

• What strategies can be used to manage Technical Debt? – Technical debt is the difference between the optimal cost of making a change to a product and the actual cost of changing the product. All products have technical debt because when they are designed and built, designers and developers will always make less than optimal decisions because none of us can predict the future. For example, I might decide to leverage a local constant in my code and over time find that this local constant is burdensome and time-consuming to update. Technical debt is paid off by refactoring the product. Refactoring, which is defined as changing how a product works in a way that doesn’t change how the product appears to work to those who use it, is how technical debt is reduced. Refactoring should be part of every sprint executed in Scrum so that the Development Team keeps technical debt in check and manageable.

• What pricing models can be used with Agile? – Similar to the discussion of the Business Analyst role above, there is a myth that certain types of projects cannot be undertaken using an Agile philosophy due to the pricing models and contracts involved. While it is true that Agile emphasizes “customer collaboration over contract negotiation”, contracts are still utilized within Agile-based organizations.  However, the types of pricing models and contracts differ significantly from the standard – “Deliver these features, on this deadline and within this budget” – contracts found in most product development efforts. Peter Stevens analyzed these models and identified which fit best in an organization adopting Agile in a presentation a few years back. Essentially, any model can be used as long as it acknowledges the inherent trade-off that exists in all product development efforts between scope, schedule, cost and quality.

Are you interested in how Scrum addresses this trade-off? Join the conversation on our website by posting a comment on this blog or explore some of your Scrum-related questions in one of our upcoming classes.