Once Upon A Time

Once Upon A Time

Once upon a time, I played the role of ScrumMaster for two teams. They allowed my teams to pick between waterfall and agile. Duh, we choose Agile. We were provided with a room that had all the trimmings like wall to wall white boards, a projector, and colored index cards. I brought snacks for the room, and the beverages were free. The teams even named themselves – Team Ying Yang & Team Destiny. Everything that I asked for was granted.

I was in ScrumHeaven (we can talk about that later). Like a good lil’ ScrumMaster, I promptly did everything that I read in the books. I made sure we had just enough backlog items for each team. Some idea of the architecture was agreed upon. Environments needed for development, testing and saving our artifacts. I set-up all the appointments for the ceremonies. I secured the allegiance of the product owners and stakeholders to follow Scrum. Most team members were allocated full time to the project. I positioned each team on opposite sides of the room so that they could see their card walls. It created a healthy competition.

It was a dream come true until we started Sprint 1.

Sprint 1 started out very normal for both teams. We were able to create sprint backlogs and start activities in the sprint backlog with no problems.  About halfway through the Sprint, I was panicking because the burndown chart was not moving, yet no obstacles were surfacing. I addressed this with each team. On the very last day, Team Ying Yang completed all activities, so the burndown chart had that classic ‘I fell off the cliff’ drop. Team Destiny did not complete most of their activities. During the Team Destiny’s retrospective, I found out that they did not want to expose their architect’s absence and the subsequent impact on the team. Both teams came up with good things to work on for the next sprint.

It was tough for me. My first lesson was to learn to trust the team in the next sprints. I had to let go some of the command control behaviors that my prior job taught me. Also, I had to teach them how to have courage even in the face of failure, but I did not have the courage to the have the crucial conversations with them or even stakeholders. Over the weekend, I read a book called Crucial Confrontations, which gave me a few techniques and the courage to deal with the issues that one of the teams were facing.

Sprint 2 started with no problems, and we included actions from the retrospectives. I was able to confront the architect about the absenteeism; then I discovered that he had serious problems with the product owner. As the team worked, I had to pull together the product owner and architect to resolve an issue that they had several projects before the current project. This took about half of Team Destiny’s sprint, so we were not going to achieve the Sprint Goal, but we were on the right track. While my attention was focused on Team Destiny, Team Ying Yang was having problems with people conforming to work at various times and not being available for the team. During the retrospective, each team set up working agreements to become more efficient as a team.

My take away was simple. I had to make sure that I incorporated working agreements as a part of each new scrum team. I also had to learn how to balance the needs of two Scrum Teams or at least to ask for help when I am overwhelmed.

Both teams were very effective during Sprint 3. Each one achieved their goals for the Sprint. I was jubilant like a King, until I met Mr. Murphy.

Right after we completed Sprint Planning for Sprint 4, Team Ying Yang’s system testing environment went down for the entire Sprint. It continued into Sprint 5. As soon as it was resolved, the integration testing environment went down and was fixed at the end of Sprint 5.  When Sprint 6 started, the development environment went down. They had all the problems fixed by Sprint 7. On the other hand, Team Destiny was able to be very effective for the same 3 Sprints.

The biggest lesson that I learned with these team was that sometimes things are simply out of your control. We deal with it as best we can and move on. However, I learned the value of having metrics in place. Based on the metrics that the team maintained, we were able to give the stakeholders a complete picture of both projects at any point in the project. We secured more funding for both teams based on the objective metrics that we were able to provide.

Download PDF Here!

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.