By Maria Matarelli
I’ve used Scrum on many software development and IT projects. In addition to the projects I was working on, I received a request to work on a role-advisory team tasked with analyzing the effectiveness of a specialized project role. This new team was pulled together with minimal allocations and replaced a full-time team that had just been disassembled due to budget cuts. Given the constraints and uniqueness of the project, we decided to use Scrum for our approach. It worked—flawlessly.
Demanding Circumstances
The going was uphill from the start. We were a team of ten, allocated to contribute only 20 hours per person over the entire calendar year. The team was just told, “Go.” Success was undefined and the scope was unclear. With a meager budget and minimal direction, we had to guide role development, training, knowledge sharing, and create a solution to provide overall direction to support more than 150 people. The only thing we knew for certain was that the requirements were bound to change as work progressed.
As we discussed our options, it became more and more apparent Scrum was the right approach. The limited ingredients and project constraints were the perfect recipe for a self-directed team. Though we could have easily made the business case for additional funding, we were told from the beginning that “additional funding is not possible.” Any solutions we found would have to be found within the team itself. Frequent, incremental deliveries would help bring clarity to the project vision. Though only few of us had used Scrum outside of IT (and most of the team had never used Scrum at all) we felt it was the perfect solution for the constraints facing our team, constraints that probably sound familiar to many teams out there.
A Creative Solution
I was elected as the ScrumMaster. My job was to guide the team through the framework, facilitate our meetings, keep the team focused on the goal, and remove any impediments standing in our way. We selected the functional manager as the product owner, our primary interface with the other stakeholders. We created a product backlog, using the list of work items as epics and categorizing the stories appropriately. We ranked the priority and voted on the complexity of the stories. With the limited availability of our team, we could only work on very small chunks of work within a sprint.
Our success with Scrum was directly tied to the team’s commitment and buy-in to the framework from the beginning. Those that were new to Scrum listened to the overview of the artifacts, roles, and ceremonies, and eagerly applied the practices to the work to be accomplished. As a result, project overhead was reduced and the team began producing results immediately. In the coming sprints, the team was able to collaborate more effectively, giving them the time they needed to maintain their existing workloads.
Something to Prove
Meanwhile, the people who were working in the role that we were redefining had little confidence in the announcement of a new guidance team. Although they had been promised changes by previous "strategy teams" the end results were not always seen or had little value. Our team was able to build trust with this community by sharing our backlog and deliverables in a collaborative online environment. This transparency enabled our team to provide a forum for iterative and incremental feedback.
Our team went further into engaging the input of these and other stakeholders. It was apparent that we neeeded to gain buy-in in a short amount of time. I introduced the team to Open Space, a meeting format in which a theme replaces the traditional agenda and the participants identify the topics for discussion. Using Open Space, we asked the people what they wanted to talk about and enabled them to self-organize and discuss the topics that were important to them. The greatest benefit from our use of Open Space was the involvement from the people that attended. Our team was then able to get input on many items in the product backlog from the entire community while also gaining their buy-in and understanding the root of any issues. While many of the backlog items were completed within the Open Space session, we also added new stories as a result of the discussions, helping us to avoid critical oversights. By engaging the community in such an open way, we not only were able to greatly increase our velocity in a given sprint, but also were able to uncover additional ways we could enhance the role and truly deliver value as a team.
Space to Work
The product owner asked me to explain our approach and review the backlog with other stakeholders, including high-level managers. The backlog prioritization received a lot of scrutiny. The stakeholders had many questions as to why certain items were chosen for the current sprint over others they felt were higher priority. Their questions gave me an opportunity to explain the Scrum framework. I discussed planning and complexity size. I talked about how we worked with the product owner to deterimine our priority and took into account work for future sprints through release planning. I explained the need to bring in only one or two high complexity stories per sprint and how we broke large stories into smaller deliverables. Given our team's velocity, some lower-complexity stories were often brought in to help round out the sprint with what we could accomplish to achieve some quick wins.
After explaining the rationale behind backlog prioritization and sprint selection, management and the other stakeholders trusted the team’s approach and allowed us to continue working without interruption. The Scrum framework worked as designed, protecting the team, the work in progress, and ultimately the project’s overall integrity.
A Clear View Changes Perspectives
Another benefit of our approach and backlog overview was that it gave management insight into how much work we could take on during a sprint’s timeframe and still fulfill our other work commitments. Had the other managers been able to interject new work mid-sprint based on their own prioritization schedules, the team would not have been able to deliver and would have accumulated multiple work in progress activities without completing any of them. By displaying the work priorities in the backlog and communicating the timing of the sprints, we were able to project which work items could begin in the next sprint without interrupting the current sprint. The framework provided a means of having a single source for prioritization. It is not always easy to tell a manager, "no," but when you can explain the framework you are using to complete the work and provide them a controlled mechanism to provide input to the work, they will have a way to navigate work priorities without disrupting the team.
Scrum Just Fit
This was a small team of people in a large corporate arena. Our ability to adopt the framework and willingness to try something innovative is how this project got “done” in spite of the constraints that come with large enterprise. The product owner quickly picked up on his role and was very engaged. The team self-organized, took on the work we could, and consistently completed the work we set out to do. Our managers understood what we were doing and left us alone to do it, meanwhile still having input into future tasks. We gave our customers the ability to communicate their concerns and opinions through collaborative tools and open space activities, a key factor in our success.
We pulled off the near impossible, moving from a challenge with countless limitations to a valuable end result. We credit Scrum's simple framework for enabling our high productivity. Through self-organization and collective incremental delivery, we built momentum that translated into real value. Our experiment, born of necessity, was a true success and is a model that other projects can follow. While we can’t change the whole business all at once, we can inspect, adapt, and start the transformation one opportunity at a time.
