I recently had the opportunity to manage a project team that had been working on a data warehouse project, using Waterfall. The team was at the monitoring and controlling phase of the project. While slowly taking the reins, I noticed that a few issues were popping up that made it hard for the team to predict how much time they could put into the project from week to week. From what I could see, it was hard for the team to prioritize due to scope creep and operational issues. The final date slipped multiple times, causing frustration for both the team and leadership.
Seeing these challenges, I wanted to introduce Agile — specifically Scrum — to the team, but I needed to do a few things first.
Is this really the problem?
I needed to make sure that the challenges I thought I was seeing in the project were really the challenges the team was facing. I interviewed the team members individually and collectively to get their feedback on the process. I synthesized the feedback and found that the team was struggling with the following issues:
- Constant changes in requirements
- Not feeling a sense of accomplishment
- Conflicting operational priorities
This all resulted in miscommunication and frustration within the project team.
One big step that I knew couldn’t be skipped was taking the time to socialize the feedback to all the stakeholders. It was important for everyone on the team to acknowledge the challenges in the project so that we could find opportunities.
Propose, communicate, explain
The team had a brainstorming session during which I introduced Agile. I gave the team the concepts of Scrum, Kanban, and even hybrids such as Scrumban. The project team liked Scrum, so I dove more deeply into that concept.
It soon became apparent that the team members had very different ideas of what Scrum entailed. Some thought it was Kanban, for instance, while others thought Scrum just entailed daily stand-ups. The full concept of Scrum needed to be clearly and simply explained. I knew that if I could take the time to address all the questions and build the foundation, then we would have an easier time when we were in our sprints.
As I explained the elements of Scrum, I realized that I needed to remain flexible. All the facets of Scrum are important, but you have to adapt to the team’s environment. As an example, I was explaining estimates. Task estimates are done in story points, but some teams do them in days or hours. In this case, one stakeholder wanted them in story points and the other wanted them in days, finding that easier to process. We discussed this for a while, but in an effort to not derail the whole process, I mentioned that we could find a way to do this to the stakeholder's satisfaction after one or two sprints were under our belt. It was a compromise, but I believe it was worth it, since we still had 90% of the process agreed upon at the time.
After two sprints, members of the project team were ready to talk about estimates, since they were now comfortable with the cadence. So, even though we didn’t have the full process flushed out, getting the team comfortable with the process led us to fill in the gap that we had left in the beginning.
Team and cadence change
Scrum basics include having a dedicated project team and a fixed cadence. While this ideal, it is often not reality. In the first two sprints, we started with a shorter cadence followed by a longer cadence. The two cadences were different due to staff leave times, busy schedules, and holidays. We also wanted to start off slowly, since this was a new concept for everyone.
While the following sprints followed a two-week schedule, we had significant team changes around the same time. We had to adjust to different levels of expertise and to loss of team members. This affected our estimated time and what could be agreed upon. We had to essentially start from the beginning, yet still move forward. Being flexible and communicative was crucial.
Also, we didn’t have a dedicated tester. However, the testing manager was the stakeholder and agreed to pull in a tester for each sprint. It was not ideal, but in an era of limited resources and conflicting priorities, we have to work with the restrictions that we have, or else risk not have anything delivered.
Moving a team from Waterfall to Agile is not a trivial task. The team has to be ready for a change, understand and embrace the concept, and be ready to communicate freely and openly. Flexibility is highly important, because even if the concept makes sense on paper, real teams and real projects are messy and complicated. See what your team has to offer, and adjust what you must so that you can have a successful project.