Implementing Scrum in a Conventional Waterfall Team
Our Journey in becoming a true Scrum team — failures, wins, challenges, and key takeaways
We recently finished a project of converting our intranet landing pages to a unified single landing page for the entire company. This project has helped us in becoming a true Scrum team and has made its impact beyond the project itself. The big deal is that the rituals, which sounded unnecessary and time-consuming, have become our habits. Instead of “questioning” these rituals, we “expect” them. That’s where the mindset changes. Coming from a traditional project management background, it was not easy for us to adapt to the new Agile/Scrum methods. With this article, I would like to share our journey with others. The takeaway from this article will be multifold.
1) Scrum Masters and project managers will get a few key elements which will help them in transforming a conventional team into a Scrum team
2) Managers and team leaders will get a few key elements on how to support their Scrum team
3) Programmers will learn how these changes will impact them and how they can support the transformation process
Please note: This is not a step by step guide of the implementation.
What do I mean by the Conventional Waterfall Team?
A typical waterfall or conventional team is a team in which team members constantly switch between the project work, support work, and ad-hock requests. The work is assigned via email, verbal assignments, and ticketing system. The manager typically makes the work assignments and reviews them on a weekly basis. Each team member is expected to manage their project, tasks & time.
Higher priority projects are typically well planned and have defined milestones, next steps and due dates. We used to reverse engineer the project milestones based on a given due date and have successfully completed many projects using that methodology. Typically, we see the team work extra hours towards the end of the projects to finish all pending tasks, especially the tasks which were stuck at 90% for a long time.
We were proud of our well projected go-live dates, training and rollout schedule while making fun of our sister team which had much better Scrum implementation but would typically respond with, “We will know after finishing our current sprint.”
Following is a slice of our yearlong project of migrating our intranet to SharePoint Online and rolling out to 40+ hospitals. This type of detailed planning is needed to make our training & travel plans months in advance.
Please note: Following screenshots does not have any sensitive information
Example of conventional high-level requirements
Our Scrum Journey — First Attempt
During the last decade and a half, many conventional teams have tried to adapt to agile and Scrum but they either could not start or experienced a halfhearted implementation. One reason for this is because it is hard to get funding for the training and to hire Scrum Master and Product Owner.
In such cases, the teams may try to be innovative and implement without going to expensive training and without hiring a Product Owner and Scrum Master. Our team used this approach, and we started our Scrum journey by having daily standings. We had to start somewhere, right? Back in these days, we thought, “We are doing Scrum because we are doing our daily standing!” Now I laugh of those good old days.
Similarly, during this time we hired a vendor for some web work. While we were excited that our new vendor will use Scrum we kept asking them for a statement of work with a fixed scope, timeline and cost.
Our Scrum Journey — Second Attempt
Our real transformation happened two years ago, in March of 2017, when we completed a yearlong project of migrating our intranet to SharePoint Online. While we meet the release timeline, we spent 3 extra months just in support and bug fixing. The team was exhausted and it was time for us to change.
This was also the time when we merged with our sister team and inherited their Scrum Master, Agile Coach and departmental initiative of becoming a true Scrum team. Having our leadership onboard with this initiative was a big blessing and foundation to our efforts.
We kickstarted the transformation by arranging a full day of Scrum training for our team. We also sent our manager (myself) and director to a Product Owner training. We did not have a Product Owner, so we decided to use the manager and director as our interim Product Owners. As a manager, I coordinated with the stakeholders and created stories, tasks and bugs. Soon, we were able to have our stakeholders start attending backlog refinements and sprint reviews. This was a game changing event.
How did we Start Implementing?
We went through the following steps which took approximately 2–3 months to finish our pre-planning and kick start the first sprint. Our team had four programmers, one Scrum Master, a manager and heavily involved director.
• Meet & Greet with leaders
• Meet & Greet the team
• Set up tools needed
• Certification Training
• Work Initial backlog
• Start planning the first meetings
• Team Building & Training
• Start sprinting!
How did we Sustain Agile!
Religiously following the below listed rituals helped us sustain the initial momentum.
• Daily Standing
• Sprint Reviews
• Sprint Planning
• Backlog Refinements
• Release Planning
Highlights of Our Setup
Because we did not have a Product Owner, our manager and director teamed up to coordinate with our stakeholders and write stories. Soon, we were able to hire a Product Owner. Our stories included the description and/or mockups, plus acceptance criteria. Our Product Owner and team leader met before the backlog refinement to add additional details. Our developers add subtasks to some of these stories. The idea is that the Product Owner defines the “What” and developer defines the “How”.
During the backlog refinement, we added additional research tasks to help developers in estimation. We also added additional tasks for any non-project item such as support.
We religiously meet every day at the same time for the daily standup and try our best to finish within 15 min. The entire team, including the product owner, analyst, and scrum master joins these standups.
The team demos their completed work during our sprint review meetings. We make sure our product owner and stakeholders join these meetings.
Successfully completing a sprint was a big deal for our team and we celebrate these successes.
We make sure to have retrospective after every sprint. At first, the team would hardly speak during our retros, but later these sessions were very interactive. We made sure that the team is picking at least one idea to improve on next sprint. This helped, as they felt empowered to make positive changes within their own team.
Retaining the initial success was not easy with the changing landscape and challenges. We slipped many times, but with constant reminders & coaching, we were able to get back on track. As a team, we have done some experiments and tweaked some processes to accommodate various situations and to provide a great working environment for our development teams & for our product owners.
The Transition Challenges
This transition was not easy. We understood the mechanics but transition required us changing the way we think, the way we behave and the way we react to things coming at us.
We needed daily and weekly coaching to transition from conventional methods of doing things to Scrum/Agile based methods.
Most of the challenges were within the team. Team members continue to accepting email request directly from our customers. Obviously, they were customer focused and can’t say no to the customers.
I was big part of the problem as I continue to assign hot issues directly to the team members and asked the team for ad-hock brainstorming meeting instead of using backlog refinement meeting. Making an issue list in an excel file and not using our Scrum backlog. Our agile coach spotted this and helped transition from excel to Scrum backlog.
I think the most challenging part of any agile or scrum transformation is that it requires changing the way you think and the way you work. This is because, every time we faced a difficult situation, we tend to go back to what we knew and what we were comfortable with.
During this journey, we found that Small wins make a big difference. We found that small successes created a lot of excitements and encouragements within the team and our leaders.
Following are some of our small wins during our journey.
Our stakeholder stated that this new process clearly states what will get done and what will not.
The team understood the value of daily standing.
In the retrospective, our team openly spoke their minds to reflect and make our future sprints even better. This small win was amplified when the team saw changes as an effect of the retrospect then they felt empowered.
Daily standing provides product owners and managers a snapshot of the work being done by the team and the blockers they are facing. The daily standing helped us build trust and helped in avoiding micromanagement.
We used the slogan, if it is not in JIRA then it does not exist. Soon, everyone started using this slogan.
We value the work put into our Sprints and Backlogs and avoid on-the-fly assignments.
Our product owner and creative staff started communicating using backlog stories, mockups (we use Invision), comments, and backlog refinement meetings. Our technical teams expect the well-written stories/backlogs before our backlog refinement meetings.
Everyone started questioning any unplanned activity and direct assignments.
1) Your leaders must support this. Get your leader’s buy-in. You will not succeed without their financial and conceptual support.
2) Identify your stakeholders and product owners. You can start without them entering requirements (stories) in your system (for example, JIRA) but they have to be open to provide you requirements and review progress on a bi-weekly basis.
3) You will have to encourage the team to not accept ad-hock requests and their manager and director to not assign work directly to the team. In our initial sprints, we used to leave 30% buffer for such ad-hock requests and support work.
4) Add additional research tasks to help developers in estimation. At least in the beginning. Your programmers are used to real estimation with buffer for negotiations. They were held accountable for their estimation. Give them some time to adjust.
5) Everyone tends to fall back to their comfort zone when they face issues. We needed daily and weekly reminder and coaching. These coaching sessions allowed us to review the problem and understand the Agile/Scrum way of handling them.
6) Forget if trainers say that in an ideal Scrum team, you don’t need a manager. In our case, as a manager, I was able to contribute a lot to create an environment where the team can function as a scrum team. This involves, onboarding everyone with the daily rituals and behaviors. I also helped by setting expectations within the team as well as outside the team.
7) Retrospectives are the key to improve. Do not ignore them. Be creative and encourage all team members to talk.
8) Becoming agile is not a checkbox which you can mark complete, but it is a way of working. This requires a change in mindset and change in the way you think about the work.
This article is a small attempt to share our journey with you. I hope that you found a few takeaways from our learning which you could implement in your environment. Please post your comment to share some highlights from your journey to build a better workplace.
We presented this topic at the Florida Drupal Camp. Here is the recording of that presentation.
Thanks to Cassie for reviewing and correcting this article.