Adopting Scrum presents different challenges to different teams. There are those large IT organizations that have been long used to Waterfall, and there are mid-sized companies and start-ups that have developed their own project methodologies – usually some customized form or hybrid of existing methods. However, the Scrum framework in its official form has advantages, especially to a start-up. When the right teams/projects adopt this framework, Scrum can not only lend its inherent agility to your project but also foster a culture of innovation and continuous growth in your company.
In this article, I speak about the challenges we faced as a first-time Scrum team and how we overcame those challenges. The article is a collection of excerpts based on my project experiences.
1. Inducting your team
The best part about how we inducted our team to the Scrum framework is that we didn’t. Well, at least not by way of day-long training sessions or PowerPoint slides. We had an experienced Scrum Master who spent about 10 minutes giving us a round-up of Scrum – the events, the roles, the culture. We relied on organic learning and adaptation once we dived into the project using Scrum.
2. Nurturing your team’s culture
It’s important that a team respects the Scrum values of transparency, inspection and adaptation and espouses the characteristics of cross-functionality and self-organization. We created this by first sharing all development information among all – client needs, risks, mitigation plans, monitoring data, etc. It established trust and quickly led to a sports-team kind of camaraderie. A loud and clear message that we’re all in it together! Also, we respected seniority but not bureaucracy.
3. Autonomy for the Product Owner
Too many cooks spoil the broth. The Scrum guide says there should only be one Product Owner (PO) for a Scrum team. Usually, the PO is a single member from your client’s company, or a business member from your own company. This person should be the one giving requirements to the team. Of course, autonomy does not mean autocracy. We identified a business member (internal) as the PO that will be in constant touch with the client, collect requirements, work with the developers and provide feedback. Our PO was also open to ideas and negotiation with both client and developers. Our team respected the PO’s decision as final when it came to requirements and releases.
4. Collaborative sprint planning
Unlike traditional project planning, Scrum does not rely on a project manager to create estimates and allocate tasks. Scrum encourages the entire development team to estimate the effort, break down the requirements into tasks, decide how much work will be done in a sprint, and allocate it to themselves. We noticed an interesting phenomenon here: when junior and senior developers worked together on effort estimation, it led to exchange of fresh ideas from the juniors and wisdom from the seniors. Although this was a first-time activity, it turned out to be fruitful.
5. Getting the work done
Scrum teams are cross-functional and self-organizing. This meant that our team got the work done without a manager/supervisor constantly hovering over them. As start-up employees, our developers were used to working on their own, but the Scrum culture further enabled them to become more responsible, accountable and cross-functional. Coders and testers, juniors and seniors – all worked hand-in-hand in one direction – ultimately reaping the benefits of Scrum adoption.
6. Staying on track
Having adopted the Scrum framework (or any Agile method) does not mean that anything is okay. Agility does not mean staying disorganized. The whole aim of Scrum is to avoid negative chaos. There were two situations when the “anything is okay” mindset crept in to our team – a) when a deadline couldn’t be met, and b) when client wanted more features in the middle of a sprint. We handled these situations by not allowing ourselves to extend deadlines or taking additional requirements. A balanced negotiation between development team and the client helped us stay on track. Additional requirements were always accepted; however they were not allowed to affect an ongoing sprint.
If you’re wondering where the Scrum Master fits in all this, do not be surprised. The Scrum Master is a servant leader and an enabler. This person is not a project manager. He helps the team adopt Scrum, coaches the PO and developers on best practices, removes obstacles, and constantly carves the team’s path to success. We were fortunate to have a Scrum Master who gave us a right balance of guidance and autonomy to deliver a successful project.
Do you have thoughts about something we could’ve done better in adopting Scrum? Please share your comments below.
