I have heard many reasons why a new team should wait to start “doing” Agile. Recently, I was asked to help a group who was struggling to get a Scrum team started. They had real obstacles to overcome, but waiting wasn’t helping them.
This group was part of an IT initiative to develop a business intelligence program for a large energy company. The existing processes were highly inefficient and wasteful. The losses were in the ballpark of $1M/day. There was a long history of failed solutions. Needless to say, this was a critical project.
Those of us who understand Scrum well know that the more critical a project is, the more urgent it is to get a team up and running as early as possible. Unfortunately for this group, there was a great deal of cultural inertia from the IT management holding them back, including chronic distrust between IT & business leadership. IT management perceived Agile to be a risk and a threat. They were tolerating it as a “pilot project”. They wanted to be sure that when Agile failed, they would not be left holding the bag. Their solution for self-preservation was to insist on getting the architecture of the system in place before the team started to work on features.
The only developer that management trusted with the initial architecture work was also extremely busy working on other projects. This individual and several other people slated to be on the new Scrum team were tied up working on change requests for a Waterfall project with no clear end in sight. It seemed impossible to predict when the system architecture work might begin, let alone end.
Meanwhile, the Product Owner was waiting for some new functionality that he could use and show to his superiors—the stakeholders that he reported to in the business. The program manager, who was the champion of the Scrum implementation, understood Scrum to be the way to succeed. The first Scrum team was wrapping up on the first project in the new program and the business was happy with the process and the results. This confirmed his understanding and gave him some traction to move forward. But he didn’t have authority over all of the slated team members (specifically the sole developer trusted by IT management) to start.
I tried to explore possibilities of moving forward with the program manager. The conversation went something like this:
TB: Are there some people who are available to start as the team for the new project?
TB: Great! Do you need the star developer on this project or are there other people who have the skills to do the work who could be on the team?
PM: There are other people with skills who are available and who could be on the team.
TB: Great! Do you have the authority to make that happen?
TB: Great! Can we have the first Planning Meeting tomorrow?
TB: Great! What time do we start?…
One might get the impression from reading that conversation that we were on our way to Sprint 1. However, as we know, things are usually not that simple. There were several more obstacles to work through.
(As an aside, I know that some people reading this might be thinking “what about Sprint Zero”. These guys were talking about Sprint Zero, -1, -2…basically all the way back to Waterfall. I needed to help them overcome that tendency.)
Below are a few of the other obstacles they were struggling with:
1. The program manager had assigned a project manager, one of his direct reports, as the ScrumMaster to the new Scrum team. This person was already responsible for (and overwhelmed by) the Waterfall death march project now in perpetual change request mode.
Advice for anyone in this situation:
Find someone else to be the ScrumMaster. It would be a better use of the external consultant (myself in this case) to serve as an interim ScrumMaster (coach) so that the team could just start, rather than trying to use a traditional project manager who was already overwhelmed by other responsibilities. In other words, don’t wait for your ideal ScrumMaster candidate to be ready. In most cases, management’s first choice for ScrumMaster is often not the best one. If you do not have an experienced coach to serve as interim ScrumMaster, then the best thing to do is hire someone specifically for this role. Again, it is better to just start than to wait for this new hire. If you have to wait for the new hire, someone from the team should just volunteer and learn on the job until help arrives. Even that will give you far better results than waiting. Just start!
2. The project manager who was assigned as the ScrumMaster was assigning Product Owner responsibilities to a business analyst that reported to him. The “BA” was worried that the Product Backlog was not ready for the team. The real Product Owner had created a high-level Backlog with items that were most likely too large for the team to complete within the two-week Sprint duration that they had decided on. The BA was trying to work with the PO, but there wasn’t much reciprocity there, mainly because of lack of knowledge of the business on the part of the BA and the PO’s lack of trust in the BA’s ability to serve as his proxy on the team. During one of my previous visits over a month before, the PO, BA and a few of the other team members had workshopped the Product Backlog, refining the top “epic” and creating a User Story small enough for the team to start working on and complete in the first Sprint. Now, that story was lost and forgotten.
Advice for anyone in this situation:
Don’t wait for the Product Backlog to be perfect. If the Backlog is not ready, use the first part of the planning meeting to identify what the team and the Product Owner can agree on as the deliverable for the first Sprint. In fact, that is all you should be discussing in this meeting in any case. With the right people in the room (the whole team) this can be done well enough. If the team is not able to agree within the time box of this meeting, it most likely means that you don’t have the right people in the room. For example, there may be a project manager and a BA who want to delay the start of the project because they feel uncomfortable with the perceived ambiguity of the process. It would be better if these people were not on the team and not in the room. If the team says something like “we can give you ‘X’ in two weeks” and the Product Owner says something like “good with me”, then make that your Goal for the Sprint and get on with the second part of planning—creating a set of tasks to execute the deliverable.
During the first Sprint, the Product Owner can be working with the team to refine the next items in the Backlog based on what has been learned from the Planning Meeting, which is probably a great deal. The purpose of the Product Backlog is to realize a great Product. Don’t wait for a perfect Backlog—just start!
3. The culture of fear and distrust perpetuated by IT management was pervasive and the team was afraid to make a commitment to a deliverable.
Advice for anyone in this situation
Help people understand commitment as a team capability that develops over time. Teams are able to make and keep commitments based on historical velocity. For at least the first Sprint and perhaps for a while after that, new teams will not be able to make firm commitments. Most teams fail to deliver after their first Sprint. There is a learning curve to Scrum. There is a lot of change and a lot of new things going on. The environment of a new Scrum team is drastically more dynamic and complex than what most people have previously experienced. It takes getting used to. People need space to learn. Help them overcome their fear of failure. Agile is about failing fast. Get it wrong early, learn, adapt and change course. What a young team needs to be committed to is learning what it needs to do in order to deliver potentially shippable product every Sprint. In order to do that, you need to be doing Scrum.
I started this post by identifying that there are many reasons to delay “doing” Agile. I believe this stems from a cultural dichotomy in our society between “being” and “doing”. We don’t start doing something until we believe that we are prepared to succeed at it. We have to “be” ready before we can “do”. This is a false dichotomy that Agile is designed to help us overcome. Another dichotomy is success vs. failure. The only real failure in Agile is the failure to learn and improve. Even the notion of “failure to deliver” is misguided. The real failure is not learning to deliver. In order to “be” Agile, you need to be able to fail. In order to “fail” at Agile, you need to do it. By doing Agile and failing, we learn to be Agile. There is no other way.
So, please… just start!