Is Your Organization Agile-Ready? Part 1.
Lately I’ve been getting questions from Agile seminar participants about how to apply Scrum to “real life,” as though these methods are “good in theory, but not at my company!” Some organizations may not be ready to adopt agile methods completely, so I encourage students to take an organizational readiness self-assessment to see if Agile in general and Scrum in particular is right for them. The questions on the self-assessment can be used to begin conversations as a way to raise issues that need to be resolved in organizations thinking about adopting Scrum.
Will your organization provide a dedicated product owner for each scrum team?
A key role on a Scrum effort is the product owner (PO). This is the role that represents the business community, particularly the project sponsor (sometimes called business owner or the stakeholder), and therefore is tasked with answering the business questions and making the business decisions. This is the go-to person for the requirements, for answers to the team’s questions about the features and functions that the business wants out of the end product. This is also the role that prioritizes the items on the product backlog. It seems to me that in the heat of the iteration or sprint, the team needs immediate access to the person making the business decisions. In order to complete the sprint in a short time-frame, such as two weeks, the team cannot wait for the PO to get back to them at their convenience. They cannot wait for the PO to check with other SMEs to come to consensus. The team needs immediate answers. Having a dedicated PO is critical to the success of a scrum team.
Will your organization provide dedicated team members?
Many organizations allocate resources to multiple projects. I often get the question “do the team members ever work on multiple projects in Agile?” When I answer that, in order to complete sprints every few weeks, it is necessary to have dedicated resources, I often get pushback. “Everyone at my organization,” I’m told, “has to work on multiple projects.” In some organizations the motto is “we’ve always done it that way” but we want you to do it faster, which we’re going to call Agile. But you need to continue to do things the old way.
There are huge advantages to having a dedicated team, such as time wasted trying to keep track of where we left off another project or dealing with team dynamics that are wildly different from one team to another. It is hard to create a self-organizing team when members float from one team to another. And team members who have been part of a high-performing, self-initiating, and self-motivated team, all of whom do whatever is needed to get the job done, rarely want to return to a more traditional team. This is particularly true when they have to jump back and forth between the two.
Does your organization support time boxing each iteration?
One of the most frequent questions I get asked is “are Agile time boxes fixed,” going on to explain that at their company the powers that be keep adding features that extend the number of days in the sprint. In these organizations the time boxes become fluid and it’s hard to plan what can get done during the sprint. In order for a team to establish its velocity, that is, how many user stories can get completed during a sprint, it is necessary to have a fixed number of days in each sprint. Organizations insisting on throwing additional features and extending the current sprint may not be ready to take full advantage of Agile projects.
Does your organizational culture support just-in-time requirements?
Organizations that have a one-process-fits-all set of business analysis processes might not be ready for an Agile environment, particularly when those processes have proven burdensome for some projects. I have worked with clients who have proudly showed me their new requirements process. Some of these companies do not differentiate between project types, approaches, and final product, so that the processes for developing software are the same as for new processes, and new product development, marketing campaigns, new bridges, etc., and processes for large projects are the same as for small ones. On the flip side, teams often struggle when organizations don’t recognize the importance of requirements, or the role of the business analyst, or why we need any requirements processes at all. In these companies, doing just-in-time requirements means moving straight to design.
Just-in-time requirements mean that requirements for upcoming sprints are defined completely before the beginning current sprint. One clear advantage is that when requirements are “groomed” or defined before each sprint, time is not wasted during the sprint trying to figure out what each user story means. The PO does not need to take time away from the Team to meet separately with other subject matter experts (SMEs) to uncover needs and expectations. That work has already been completed. As I’ve said in past blogs, who is better to groom the backlog than the BA?
Next month we’ll explore other questions that organizations can use to help them decide whether they are ready to make the necessary commitment to ensure the success of agile adoption.
Don’t forget to leave your comments below