Scrum

Sprint Zero: Sprint Zero is the time used to plan and set-up the foundation needed before a team can execute their first successful iteration. Sprint Zero deliverables may include: identify stakeholders, build the team, training, create high-level architecture diagrams, and set-up environments.

It’s become quite common for Scrum teams to begin by planning Sprint Zero. I’m not sure if you’re aware, but Sprint Zero is a bit of a debate topic at times. I’m often asked what my stance is when it comes to Sprint Zero, and I struggle a bit since the real answer is this: it depends.

I know it seems like answering with “it depends” is totally punting and not helpful. However, up-front pre-implementation activities vary greatly depending on what is being built.

1) Large Mission Critical Enterprise Applications

Assuming this is creating something that didn’t exist before, or re-building something that is legacy, I would start with a small core group of “key” people. An enterprise architect, a business leader (Product Owner, perhaps) – the person who owns the vision of “why” we are doing this, possibly some key stakeholders, etc. Ideally no more than 5 people. In this case, this small core group would determine the answers to the questions you ask and then figure out the best way to execute.

Activities would include: determine how to and then get started on setting up environments, technology, CI strategy, training, change management, etc. This small team would also come up with a strategy on how to assemble Agile teams.

I would not call this a sprint zero. As has been said before, it’s not a sprint as defined by Scrum, so let’s not pretend it is.

2) Small – Medium Projects Using Existing Technology

As you all know, these come and go. This is the steady stream of new feature requests that come from the business. It may take just a couple sprints to deliver, or it may take 10 sprints. The number of sprints is irrelevant in this case. There is still no need for a sprint zero. Just spend some time creating the product backlog and start. Business as usual.

3) New Product or Start-up

I have been involved in quite a few start-up ventures as a Scrum Master or as a developer. We start small with a vision (that’s typically been baking for some time) and a quick technology conversation, then we start executing. We have passionate people who all are trying to achieve the same goal. Yes there’s “up front” stuff, but it’s super quick…as in hours. In no way would I consider it a sprint zero.

Ultimately, I would love to eliminate the term “sprint zero” from our nomenclature. Upfront activities (other than release planning) should only be reserved for contexts where complexity, breadth of impact to the enterprise, and cost are all high.

For agile training check out our list of courseware, we would enjoy helping you on your agile journey.

Learning to be a good Scrum Master is hard, but how does a new Scrum Master learn the the mastery of Scrum?

I had it easy. When I learned, I had an awesome team. They were open, engaged, and always wanting to improve. The Product Owner was awesome-again, open and engaged. The thing they all had in common was that they wanted to be better and they wanted to learn Scrum. I was one of group that introduced Scrum to our department. I read a little, implemented a little. Screwed up, tried again. Read a little more, tried a little more. And so on. It was basically a self-study program with help from blogs, books and the team itself.

For me this was easy. I was never really a “command and control” person anyway. Sure, I had my tendencies, but pretty mild. I knew that my teammates were the ones that really knew what to do anyway…so why not give them the tools and empower them and help them to focus on quality and value? There wasn’t a lot of “unlearning” that had to take place for me.

After those first (great) experiences, I became an agile coach. Now it was my turn to help teams transition to Scrum by educating the team, Product Owner, and Scrum Masters. Well, admittedly, I was winging it for a while, but through trial and error I fell into a pretty good groove.

There are three options/approaches to helping others become Scrum Masters.

The Coach Leads

With this approach, the coach plays the role of the Scrum Master, while the soon-to-be Scrum Master watches, and assists. Then, after a while (depending on the Scrum Masters comfort level), there is a switch, and the coach becomes the observer/helper.

The Coach Observes

Here, the new Scrum Master will be the acting Scrum Master. However, the coach will be there to observe (and help) while the new Scrum Master is facilitating. The coach would only correct/advise/encourage in private.

The Coach Advises

In this scenario, the coach is not directly involved in any of the ceremonies. They are only there to advise and hear situations from a third party perspective. The new Scrum Master and coach meet regularly to go over gotchas, smells, and issues, etc. This approach works well for Scrum Master who just need to bounce ideas off of a Coach or validate their approach.

Coach? What Coach?

This is how I learned. We didn’t have a coach. But, we were completely empowered to do what we needed to do to be successful. And, there was buy-in from the team and leadership. Oh, and we were allowed to make mistakes. And, I think what really made it work was that none of us had any “baggage” from other environments. It is rare to work in this kind of environment and going down this road can lead to great success or bigger failure. Choose wisely!

I give my team (and anyone else in the organization who wants to be a Scrum Master) those three options. #2 is the most popular. However, I just had someone pick #3.

So, which the best option? It depends on the experience of the new Scrum Master and the team. It also depends on who the coach is in the organization. If you are introducing Scrum and have hired an independent consultant (coach), #1 is typically the best. If the coach is there to help “improve” their implementation of Scrum, or if the organization is backsliding, then #2 is best. When there are experienced Scrum Masters that are experiencing new situations and need to just bounce ideas off of someone, then #3 fits the bill.

As far as #4…I’ve heard about many teams that tried to “do it on their own”, and completely tanked. They didn’t have that utopian environment that is oh so rare. So if you do decide to do it on your own get some formal training from experts or start reading. Read, read, read, and read some more.Blogs, books, and user groups. Ask questions on these user groups…you will find a wealth of knowledge and people who want you to be successful. Many people post awesome information and articles that are thought provoking and free.

If you are looking for Agile or Scrum Master training check out this link for amazing Agile Training

I would love to hear from others on this topic. What are the approaches you have taken in coaching, or have seen others take? How did YOU learn to be a Scrum Master?