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.
