6 Steps To Scrum Adoption At An Indian Start-up
By Karthik Selvaraj
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. 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. 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. 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. 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. 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. 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.
Karthik Selvaraj
Karthik Selvaraj is a senior Business Analyst professional and a Certified ScrumMaster®. He works/has worked for India’s leading IT companies and a startup incubated at IIT-Madras.
Posts by Karthik Selvaraj
6 Steps To Scrum Adoption At An Indian Start-up
By Karthik Selvaraj
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. 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. 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. 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. 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. 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. 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.
641
- by Karthik Selvaraj
- 10 May 2017
Adopting Scrum presents different challenges to di... Read More
Built Instability Fosters Innovation New Product Development
By Karthik Selvaraj
As funny as the Calvin and Hobbes comic is, it conveys an important message about how creativity and chaos almost always go together. In 1981, when Honda was developing Honda City – the innovative first-of-its-kind compact car – an executive in charge of its development remarked, “It’s like putting the team members on the second floor, removing the ladder, and telling them to jump or else. I believe creativity is born by pushing people against the wall and pressuring them almost to the extreme.” Haven’t most of us experienced this at some point in our lives? The idea of “built-in instability” was first published in a 1986 Harvard Business Review paper, which kicked off the Agile movement. The paper names built-in instability as a top quality of new product development at leading companies such as Honda, Fuji and Canon. Well, what does built-in instability mean? Why is it important? How does it help teams succeed? Let’s address these questions one by one. What built-in instability means When a company’s top leadership does the following: establishes a broad but extremely challenging goal, does not provide a product definition or a work breakdown structure, AND offers the project team ample room for experimentation and failure … this is called built-in instability. The leaders have basically created an environment of constructive chaos to serve as a catalyst for creative output. Why built-in instability matters Honda’s leaders instructed the Honda City project team to develop “the kind of car that the youth segment would like to drive.” Do we see a goal here? Yes. But is the goal well-defined? No. Do we see what kind of product is expected? Uh, maybe. But do we see the steps to get there? No. With a goal like that, the only way leaders can expect the team to succeed is by letting them fail – to fail early, fail often, and fail forward. When a team has the freedom to fail and knows there isn’t a firing squad waiting down the road, it begins to break traditional boundaries. And companies that thrive beyond decades or centuries with avant-garde products do not get there with traditional thinking. This is why built-in instability matters. How built-in instability fosters success Look at the Honda City team’s goal again: to develop “the kind of car that the youth segment would like to drive.” A broad goal like this naturally demands cross-disciplinary work across a broad spectrum of organizational functions – market research, finance, planning design, production, testing, sales and service. When the team wants to succeed while having the luxury to fail, the built-in instability fosters collaboration among individuals from various functions. In the words of a member of the Honda City team: “You then start thinking in terms of what’s best or second best for the group at large and not only about where you stand. If everyone understands the other person’s position, then each of us is more willing to give in, or at least to try to talk to each other. Initiatives emerge as a result.” In sum, what we today use as Agile/Scrum or other modern methodologies essentially relies on built-in instability. By giving teams the freedom to fail, the process encourages a DNA of experimentation, learning, innovation and continuous growth.
1979
- by Karthik Selvaraj
- 01 Mar 2017
As funny as the Calvin and Hobbes comic is, it con... Read More