Is Your Organization Agile Ready? Part 2.

Last month’s blog was the first in a series about organizational readiness-ready, that is, to provide resources necessary to succeed in an agile environment. We asked these four questions on our Agile organizational readiness checklist:

1. Will your organization provide a dedicated product owner for each scrum team?
2. Will your organization provide dedicated team members?
3. Does your organization support time-boxing each iteration?
4. Does your organizational culture support just-in-time requirements?
   
   

This month we’re going to look at Agile organizational readiness from the perspective of false expectations for some organizations that have decided to implement Agile methods.

Does your organization support “cowboy” development?

Some organizations adopt what they call an “agile methodology” as an excuse to eliminate discipline, commitment, and ownership. They have the mistaken belief that a lack of discipline equates to getting the work completed sooner. In some organizations senior leadership decides to adopt “Agile” without understanding what it entails and the commitment that is required to make it work effectively. The term “Agile” becomes an excuse for adopting a chaotic, free-for-all environment. Management in these organizations can boast that they’re “doing Agile,” but might not be aware of the frustration such a chaotic environment causes the team.

Does your organization expect that eliminating the role of the BA will eliminate documentation?

I have heard organizational leaders say something to the effect of “we’re going Agile so we no longer need a business analyst” or “don’t put a BA on this Agile project. BAs will just produce a mountain of unnecessary documentation.” They see business analysis as unnecessary work and the BA as a role whose only goal is to produce a massive requirements specification at the end of one long business analysis phase. In reality, the business analyst is a kind of management consultant, someone who acts “as a liaison among stakeholders ..to recommend solutions that enable organizations to reach their goals” (BABOK Guide ® Version 2.0. As wonderfully articulated by Kevin Brennan of the IIBA, organizations which undertake Agile projects still need help understanding their underlying business problems and figuring out the best ways to solve them. They still need projects to help them solve those problems. And they still need a role that will focus on the requirements of the end product (solution), ensuring that the end result of the project provides the expected business value. In other words, the role of the BA is not to produce documentation, but to help ensure that the end product and its associated requirements help the organization reach its goals. In that capacity, every BA is obligated to produce documentation as appropriate to the project at hand.

Does your organizations have realistic expectations of the Scrum Master?

• Does your organization expect the technical team “leader?” to be the Scrum Master, providing technical expertise and direction to the delivery team? Having any formal lead role on the Scrum project is problematic. When teams are truly self-organizing as ideally they are on Scrum teams, leaders emerge, rather than being designated. In addition, any time that the Scrum Master spends focused on the technical aspects of the project and directing the delivery team is time not being spent on facilitating, removing roadblocks, calculating the resource capacity and burn down rate, and generally doing the work that Scrum Masters need to do. There is a reason why on some Agile projects the role is called “coach,” not leader. Finally, the Scrum Master who works as the technical lead is at risk of providing a more a technical rather than a business solution.
• Does your organization expect the Product Owner to be the Scrum Master? The Product Owner (PO) is a critical role on an Agile project. It represents the business, making the business decisions required to move forward developing the end product. Last month we addressed the importance of having organizational commitment for a full-time PO because it is a full-time position. When the Scrum Master is doing PO work, the Scrum Master work is not getting done. And the decisions made run the risk of ignoring important technical considerations.
• Does your organization expect the Scrum Master to play other roles such as business analyst? I attended a presentation recently promoting the idea of BA as Scrum Master. The central theme of the presentation was that because both Scrum Masters and business analysts are facilitators, the BA is in the best position to be the Scrum Master. I found the premise intriguing and well-intentioned, but misguided. The facilitation that is required of a Scrum Master is different from that of a BA. The former focuses on facilitating the team and its ceremonies, the latter facilitating requirements workshops among subject matter experts. And there is vastly more to both roles. It’s almost like saying that because an insurance agent, a bank teller, and a city ombudsman all interface with customers, that one could easily step into any of the other roles.
• Does your organization expect the Scrum Master to play multiple roles? All but the smallest Agile projects deserve full-time Scrum Masters. Organizations which believe that they can get by “on the cheap” by combining roles on Agile projects may well suffer disappointment in the results that get produced. As on any other project, each will suffer.

There are many more areas that we could cover, but we’ll leave it for now in the hopes that you’ll add your own ideas and experiences to the topic.

Don’t forget to leave your comments below