Search

6 Steps To Scrum Adoption At An Indian Start-up

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.

6 Steps To Scrum Adoption At An Indian Start-up

637
6 Steps To Scrum Adoption At An Indian Start-up

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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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

Karthik Selvaraj

Blog Author

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. 

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Best Practices of Scaled Agile Framework - Agile Management

The enterprises have many different frameworks and methodologies to choose from once they decide to adopt the ‘Agile’ approach for project/product development. Designed by the Scaled Agile Inc, the Scaled Agile Framework (SAFe®) is an Agile software-development framework. Earlier, the Agile development methodologies were used on a trial basis for various projects at an enterprise level. The development team experimented in making an efficient Agile method suitable to work in their environment. This resulted in evaluation of methods that worked and that didn’t, which ultimately led to the development of various frameworks and strategies for the adoption of the Scaled Agile Framework. Within the last few years, the Scaled Agile adoption has become popular amongst many enterprises. The two most important responsibilities of management are measuring improvement and ROI. The management needs to choose a solution that best equips with their business model and speed up the delivery and release phases. With these benefits coming handy, more and more professionals are practising lean and Agile methods and implementing it in the enterprises. The Scaled Agile Framework is a highly structured and is mainly used in larger enterprises and is primarily used to for agile development. It is an increasingly popular framework that has been successfully implements in enterprises. The nine principles of SAFe® include as follows: 1. Taking an economic view 2. Applying systems thinking 3. Assuming variability by preserving options 4. Incremental built with fast and integrated learning cycles 5. Building the foundation of milestones on objective evaluation of working systems 6. Visualising and limiting WIP, managing queue lengths and reducing batch sizes 7. Synchronising with cross-domain planning by applying cadence (timing) 8. Establishing deep-rooted motivation of knowledge workers 9. Decentralising the decision making There are three levels in SAFe®, and they’re as follows: • Team All the SAFe® teams are the Agile teams consisting of 5–9 people working in 2-week scrums. They have skills to define, develop, test, and deliver value using XP (Extreme Programming) methods. Unlike the traditional development scrums, they work in collaboration. • Program At Program level, 5–10 SAFe® teams consisting of 50–125 persons create an “Agile Train Release” comprising of stakeholders and development teams. They put in sync their iteration boundaries and facilitate delivery of integrated working systems every 2 weeks. The SAFe®defines the Agile Release Train (ART), which in every 10 weeks (5 iterations) delivers a Potentially Shippable Increment (PSI). The PSIs provides a steady cadence (timing) for the development cycle. • Portfolio The lean–Agile budgeting mechanisms are budgeted by a portfolio, which is a collection of value streams. The portfolio management requires program management, investment funding, strategy, and governance. A portfolio is associated with the enterprise strategy in terms of strategic themes. Epics that define large-development initiatives are captured and analysed by a portfolio Kanban system. There are business epics that are customer facing, and then there are architectural epics that are technology solutions. How the practices of the Scaled Agile Framework benefit the organisation? SAFe® is considered as a framework based on Agile Development, Lean, and Systems Thinking, which has gained worldwide recognition throughout the large corporations and enterprises. Following are the benefits of adopting the Scaled Agile Framework for your organisation: 1. SAFe® allows implementation large team programs and portfolios Initially, the organisations adopt Agile approach and experiment it by its implementation with small teams. After gaining moderate success with small teams, often the organisations would try to increase the size by aligning various teams, programs, and various departments in an organisation to promote collaboration and efficiency in development and shipment of the product. By identifying the key Agile functionalities, Lean and Systems Thinking that scale well, SAFe® addresses all these issues. 2. SAFe® outlines a consistent approach for planning, execution, and delivery of value It becomes difficult for large organisations when numerous Agile teams are involved, because the teams might operate on different cadences (timing), or might use various Agile frameworks, or might rely on varying tools for managing the Agile lifecycle, or the teams might have adopted different technique practices. SAFe® makes use of ART (Agile Release Train), which collaborates various Agile teams on a consistent cadence for every 8–10 weeks. It is known as a Program Increment (PI). This enables the teams of the organisations get together and uncover, plan, and address dependencies of the teams and the risks that might arise. All the teams of ART make use of best practices such as the Scrum-of-Scrums during each PI. At the end of every Project Increment, the ART does the analysis of what was done in the past 8–12 weeks. 3. SAFe® addresses roles and responsibilities across Team, Program, and Portfolio levels Adopting and implementing Agile causes a drastic change across the organisation, which can raise questions regarding the current and new functions. SAFe® addresses all these questions across the various levels. 4. SAFe® provides a framework to bring consistency in strategy and alignment to the program and team levels In an organisation, maintaining an overall alignment with the vision and strategy is often a challenge faced by enterprise-scale software development. It becomes difficult to arrange various business departments with similar strategies, and if that is achieved, the problem still persists to communicate that strategy at the team level. SAFe® provides an architecture to implement Agile, Lean, and Systems Thinking consistently to various levels in an organisation. 5. SAFe® improves product development lead times SAFe® is a well-documented approach that applies its principles, benefits, and values to the wider enterprise. More and more large corporations have understood how to scale Agile to lessen the time required for product development and improve the release time of their product compared to their market competitors. SAFe® provides an extensive set of functionalities that can be applied in an enterprise to successfully scale Agile.
1821
Best Practices of Scaled Agile Framework - Agile M...

The enterprises have many different frameworks and... Read More

Why An Agile Project Management Certification Is The Right Choice?

Professional certification courses for Agile methodologies is available for IT professionals who have worked in Agile projects or who have worked in complex software projects. These certification courses are designed to test your knowledge and competence of the Agile framework. Though there are several Agile-related certification courses available in the market, most of them can be categorized under the umbrella of 2 main categories namely, Project management-based or Scrum-based. This article discusses the details of these 2 categories of Agile certifications and recommends which is the right one to pursue. About Agile Project Management certification The purpose of Agile project management is on developing software solutions incrementally to enable project teams to respond effectively to change in customer requirement, while delivering the product in quicker time to the customer. A certification course in Agile project management is designed to explain the foundation of successful agile projects and on how to manage the project from the start to its completion. An IT professional, certified in Agile project management, has the following benefits: Develops an advanced level of knowledge about Agile and can apply the project management methodology to any software project. Differentiate between the project management principles between traditional and Agile project environments, and apply the same to different work scenarios. Promote a trustful collaboration between the business owners and the Agile development teams, while providing the management day-to-day visibility into the progress of the project. Experienced IT professionals can also combine the learnings of traditional project management methods and Agile methods, thus providing them more control over a fast-evolving business environment. Improve the success rate and time-to-market duration of software releases. Agile project management certifications, such as the Agile Certified Practitioner (ACP) course from the Project Management Institute (PMI) require students who have real-world experience of being part of an Agile project team and provides the students working knowledge of multiple Agile methodologies including Scrum, Kanban, Lean, and others. Additionally, certified ACP holders must earn 30 professional development units every 3 years to maintain their status. About Scrum-based certification While project management-based certification provides a single certification credential, Scrum-based certification is divided into multiple certification courses based on the role being played by the individual in the Agile project. Scrum-based certification offers courses for the following roles: Certified ScrumMaster Certified Scrum Product Owner Certified Scrum Developer Certified Scrum Professional Scrum-based certification program, such as the Scrum Alliance, is designed for software professionals, who can support the adoption of Scrum framework and its benefits in software development. Scrum-based certification is important for individuals from the software industry, who want to grow in an iterative software development environment. Certified knowledge of the Agile methodology can boost their career prospects. Which certification program is better? Gaining certification accreditation for both project management and Scrum can be beneficial for software experts, who want to manage projects for different types of software companies and can benefit from the different project management frameworks. Knowledge of multiple PM frameworks like Scrum, Lean, and XP can only be gained by pursuing both categories of courses. Besides this, let us look at a comparison of these Agile certification courses in the following parameters: Industry orientation A PM-certified individual is oriented towards being both industry agnostic and product agnostic, meaning their specialization is not restricted to any particular industry, or products that can functions on multiple platforms (example, mobile phone and desktop). The Scrum-certified individual, who typically was focussed on software development, is now product agnostic. Job preference The PM-certified individuals are looking at a career as a project manager, as many software industry recruiters demand Agile certification in project manager openings. A Scrum-certified individual is seeking growth and opportunities in the field of software development or to be a Scrum expert in any Agile software project environment. Recertification requirements Individuals certified in Agile PM programs, require to take a recertification (or continued education) on a 3-year cycle. Individuals certified in Scrum-based programs, require to take a recertification (or continued education) on a 2-year cycle. Eligibility Project managers or any team members, who hold any Project manager professional certificate, can benefit the most from the Agile PM certification program. Software team members, who have working knowledge of the Scrum methodology and have been part of Scrum-based projects, can benefit the most from the Scrum certification programs. Conclusion Depending upon the student’s previous experience and future growth map, either (or even both) of these Agile-based certification courses can be pursued for gaining recognition in a rapidly-evolving software development environment.
6711
Why An Agile Project Management Certification Is T...

Professional certification courses for Agile metho... Read More

How SAFe® Became Pioneer In The World Of Framework?

SAFe® principles and practices aim to provide guidance on successfully leading agile projects. It is the approach that helps scale agile to the highest level being the enterprise level. Leading SAFe® is a known Certification that teaches concepts on agile and value delivery through scaled agile framework. It provides insights on lean mindset and approaches to deliver agile release trains. Why companies choose SAFe®, now this is the trending topic in agile members. One of its key focus is also on how to develop and implement agile approaches organisation wide and align team goals to enterprise goals. A major contributor to the wide adoption of Scale Agile Framework Certification and Training is that most of the success on agile so far is based on scrum. While scrum works effectively for small and medium sized organisations where it is relatively easier to manage teams. A greater challenge is posed by large enterprises. These organisations usually have bigger teams and varying team cultures. SAFe® training helps in articulating the ways and approaches that support scaling agile. Multi team and multi project queries are a part of the scaled agile framework Certification giving a methodology that helps guide on how to manage the flow of value from the strategic ideation to actual release in the product. SAFe® brings three critical levels to align their processes and goal guidelines so that they ultimately support scaling agile. These levels are portfolio level, programming level and finally team level. While portfolio level focuses on the strategic decisions, it is the program level team that handles estimations and analysis to decide user story deployment approach. Team level is responsible for the development, testing, and deployment of agile trains in line with all the strategic and operational inputs that flow from above levels. Lean Thinking also plays a critical role in successful Agile Implementations. This mindset is the core of SAFe® Certification. The main goal of introducing lean mindset is to encourage delivery of value to the end user with utilisation of shortest lead time. All key variables of bandwidth, time and effort are organised to ultimately support the goal of giving results within a shorter timeline. Amongst the pillars supporting the concept of SAFe®, a key ideal is respect within the team. Despite the fact that every organisation big or small carriers its own culture, a primary focus on respect enables team members to be open and discuss challenges. Respect is also important to maintain because in agile individuals are empowered to continually focus on improving their methods to deliver better with the agreement from the team. Value Delivery is another reason for this framework gaining more acceptance. The importance of value delivery is evident as each iteration uses some feedback from previous iterations to further improve the end-product. This way the focus is also on continuous improvement of the product through development helps in better prioritization and managing queue of deliverable pieces. Being holistic is also an advantage that SAFe® framework carries. It helps to give a bird’s eye view of all the complex work that happens in the Development and release process. Attention to alignment with top level Strategic goals of the enterprise gives work greater visibility and Helps focus on continuous improvement with each deployment. SAFe® framework is indeed the complete framework for enterprises that want to move away from the traditional waterfall to agile. Since scaling is the biggest challenge of scrum, SAFe® helps to align all targets to ensure that value delivery reaches end user in the shorter span of time and with lean mindset. Supporting lean also helps teams to be more efficient and diverts focus on strategic and iterative improvements sooner than traditional waterfall approach. Continuous process improvements originating from teams are also encouraged to bring greater efficiencies much sooner in value delivery.
3590
How SAFe® Became Pioneer In The World Of Frame...

SAFe® principles and practices aim to provide gui... Read More

Useful links