Scrum Does Not Have a “Sprint Zero”

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.

Contact us today



Too Many Meetings: Recognize the Signs

We have received a lot of feedback on our post: Scrum Events – The too many meetings problem. Many people are reaching out to us and provided feedback on the frustration stemming from meetings.  

Meetings in the United States are a big problem.  Nearly 37 billion dollars is wasted annually on unnecessary meetings, and in the Agile community, Scrum meetings are getting the blame.  Our stance is that Scrum is not the issue but rather how companies are their conducting meetings.

Below is a list of the 9 top meeting “smells” to recognize and avoid in meetings:

  • Lack of clearly documented Agenda.
    • If a meeting invite doesn’t have an Agenda, I automatically question the importance of the meeting.  Why should I attend a meeting that the organizer doesn’t think is important enough to generate a clearly defined purpose?

My rule: No Agenda NO Meeting.

  • Lack of definition or goal.  What type of meeting will this be?
    • Status:  Share Information, Provide Status, Give Update.  Participants generally will restrict their participation to questions or clarification about the subject at hand.
    • Advance Thinking: Define and\or analyze a problem, planning session, evaluate options.  Participants are asked to advance the knowledge on a meeting topic.  Decision is not necessarily required.
    • Make Decisions:  Address issues, determine solutions, and bring to closure.  Decision required
    • Obtain Input:  Sponsor is looking for group input.  Decision is not required
    • Retrospective: Strengthen Relationships, Improve Process. Determine what is working? What is not working? What improvements can be implemented?
    • Team Building: Strengthen Relationships, build Mutual Understanding, build community.
    • Skill Development: Training, Increase subject matter knowledge.
  • Lack of defined roles.
    • How do you expect meeting attendees to participate in a meeting?  Are they a subject matter expert (SME), note taker, active participant, observer, or other?  Give those who will be attending the meeting an opportunity to prepare for the meeting based on the Agenda and the Role that they are expected to perform.
  • Scheduling too much time.
    • When a 30 minute conversation blocks off an hour of your day. Did the participants get off topic? Was proper preparation completed in advance before the meeting was scheduled?
  • Meetings that continually go over their time limit.
    • Did you invite the right people? Was proper preparation done? Does the meeting organizer have the necessary facilitation skills?
  • Scheduling meeting to ‘discuss’ when a quick conversation is enough.
    • “Discuss” is never a valid meeting topic.  If you just want to discuss something how about we go to coffee or sit in the break room and have quick chat.
  • Meetings with more than 8 people.
    • Meetings with too many participants can be difficult to manage.  If you are scheduling a meeting with more than 8 people check to make sure the right 8 people are invited.  Ask yourself if the proper pre-meeting preparation has been completed to make the meeting valuable for everyone.
  • Meetings that could be covered in an email or quick conversation.
    • Why waste time with a meeting that could be simply done in an email? If you are not sure, start with an email. Better yet, a quick face to face conversation.
  • Meetings to review previous meeting (rehash)
    • We have all been to meetings that rehash a previous meeting.  Why? Was the first meeting not enough? Did we not send out notes for the meeting? Did new information develop?

Always ask why

Every company has issues with too many meetings.  If you would like to develop skills to help your staff have more productive meetings, check out our Facilitation course.

When Building Process, Ask Why

Process is not a term belonging uniquely to business. Process fills our lives.

There are things we all do on a regular basis which are wrapped in processes we may not even realize have been established. (I bet you washed the same parts of yourself in the shower this morning in the same order you washed yourself the last time you showered. It’s your process.)

The most critical piece of creating any successful process is knowing why.

agile developmentWhy can be a bit of an irritation, so we like to avoid it. But without knowing why we do something, why we own something, why we buy something, etc – we end up with waste. Wasted time, wasted space, or wasted money.

Process in business often goes unquestioned. Nobody asks why.

If those same processes were implemented at home, someone would ask why. 


At home, imagine you were asked to cook dinner.  You were told that you’d be cooking it with two other people, but none of you could be in the kitchen at the same time.  You’d each take turns alone in the kitchen, working on the same meal.

You’d ask why.

How will the other people know that you edited the recipe or began the sauce already? You will have to devise a way to pass that information on before you hand things over. When it’s again your turn to be in the kitchen, you’ll need a way to know what the others have done.

But wait – what if you forget to tell each other that you salted the meat, and it’s over-salted? I guess you just have to be sure that your communication is flawless.

Can you imagine tag-team dinner preparations at home every night? You’d ask why.

But in business, we don’t ask why.

We hand things off to other people, wait to see what they do, they come back and ask questions, we explain or document so they all know what they’re looking at, and then we get it back again to finish.

(Many times, the meat ends up double-salted. We dump it out and start the process over again. We don’t ask why, we just repeat the same process we used when we screwed it up the first time and hope for a better outcome.)


documentationIf you were asked to keep notes as you vacuumed the living room, you would ask why.

But if someone in business asks for documentation to go along with whatever is being created for them, nobody asks why.

Sometimes there is a good reason. Maybe the person who bought the vacuum wants to know if the cord is long enough to reach the entire room.  Maybe they are shopping for a new vacuum and they want to know if a more powerful vacuum is needed.

Maybe there is some sort of regulation requiring your customer to own complete documentation of the product you’re building.

(Knowing why you are documenting something can also help you understand how it should be documented.)

You don’t always have to say no. But you should be asking why.


At home, if someone told you that they were going to put a couch in the hallway, you’d ask why.

I mean, couches are cool.  Someone might want to sit in the hallway one day. But they cost a lot of money and take up space, not to mention the work it will take getting it crammed into the hallway.

So why?

But in business, cool features are often accepted without question. Rarely do people stop and ask why.

Process & Change

I regularly use a screwdriver to tighten the hinges on our kitchen cabinets. For a long time, I would go get the screwdriver from my tool bench in my garage, use it in the kitchen, then put the screwdriver back on the garage tool bench where it belonged.

One day I asked why.

It’s common sense and it’s simple, but now that screwdriver belongs in the kitchen.

Also common sense: I did not talk to my husband or children when I made this change. I am the person who uses the screwdriver, I am the person who does this task, so I made the change without wasting their time or mine by sitting down and having a family meeting about it.

In business, a similar change would have required meetings, input, discussion and possibly a bit of documentation.


Stop doing things without knowing why.

If you can’t answer why something deserves your time, money, or space, then it’s time to examine your process.



Agile isn’t something you do, it’s something you become

I would not dub myself the queen of anything.  But if I were to dub myself the queen of something, I would be the queen of abstract logic.  That’s a thing, right?   I love speaking in metaphors and analogies.  (And it’s totally not annoying at all.  Usually.)

It comes in handy when I’m asked questions about fitting Agile or Lean into situations one doesn’t normally consider when thinking of Agile and Lean practices.

There are numerous examples I could give where I’m asked about applying Agile methodologies in areas where typical Agile practices we focus on need to be thrown out.  In many of these situations, Agile development tools and processes don’t apply.

pile-of-booksFor example, I was recently approached by a woman who, along with her children, runs a mail order second hand bookstore from her home.  She wanted to know how Agile could help her become more efficient.  (This is where after explaining what Agile is, I go into Lean processes and get giddy about Kanban.)

topicHomeschoolTeaching_smallIn another example, I homeschooled for 14 years.  In the homeschooling community there is a constant strain toward making the most of your time, accomplishing certain milestones, and struggling with the balance of “the way things should be done” versus “how things work best for our family”.

Situations like these are where I get to talk about Agile as a principle.  I love it.

Agile is not an instruction manual for success.  It is a principle.  The processes and tools we use – such as Scrum, XP or Kanban – have been created to assist us in applying Agile principles in areas that require some kind of team structure and standardization.

But “Agile” is not a process.  Until you can wrap your mind around that, it will be hard to truly bring “Agile” into your situation.

I find myself often saying to people, “Agile means pretty much what we all picture when we hear the word:  the ability to move quickly and easily.”

Very often in life as well as in business, we lose agility because we get bogged down by routine.  Things we do out of habit because that’s The Way it’s Always Been.

To become Agile means that you begin to analyze your own actions and change the way you do things if those ways are making you slower.

Agile does not mean you throw out all standards and structure.  Agile means that you only have standards and structure that work to push you toward your end goal.

One simple example I use involves kitchen organization.  Do you make coffee every day?  Is your coffee maker in one part of your kitchen, your mugs in a cabinet across the room, and your coffee in the pantry?  Why?  Because “dishes must be in the dishes cabinet” and because “coffee must be with the food in the pantry”?  Who made that rule?

1As far as that goes, who said your coffee maker has to live in your kitchen when you spend your morning in the bathroom?

If you’re Agile, you stop and question the way you do things.  You are free to move the mugs and the coffee so that they’re within reach while you’re standing at the coffee maker.  (Or heck, put them on your night stand if that’s where they work best for you.  Just don’t tell people I suggested it.  They already think I’m weird enough.)

You don’t stop and question if that is the “right” way to do things.  You simply realize that it makes you more efficient, and you adjust to make the change.

“Agile” isn’t the part where you move your coffee mugs.  “Agile” is what made you stop and question where the coffee mugs were in the first place.

“Agile” doesn’t care where you keep your mugs.

“Agile” only means that you continue to review your own process and make improvements when you need to do so.

Many times, people get stuck on this and think that “Agile” means you’re following some sort of standardized plan.

Agile is exactly the opposite of that.

When I think of great examples of agility in this world, I always think of monkeys.  There are few things more demonstrative of agile than a monkey who quickly and expertly moves from branch to branch in a tree.  They’re agile little suckers.

Monkey-On-Tree-50Monkeys aren’t bogged down by wondering what is right or wrong when it comes to grabbing branches and moving themselves along to their destination.  They trust themselves.  They adjust as they go, quickly grabbing which branch makes the most sense and moving on to the next.  Rarely will you see monkeys following the exact same climbing pattern on four different trees.  They adapt quickly to their current task and they move fast.

I once saw a monkey fall during his climb at the zoo.  I don’t know if his grip failed or if he missed his mark, but he aimed for a branch and ended up falling about two feet before he grabbed a lower branch and continued his climb.

He didn’t stop.  He adjusted his climb without pausing – skipping that tricky branch his second time around – and made it to the top of the tree seconds later.

That’s agility.  That’s being agile.

Agile isn’t a method.  It’s a principle.  It’s not something you do.  It’s something you are.

Because this is so hard to understand sometimes, artifacts like the Agile Manifesto have been made to put it into terms that apply directly to our industry.
agile manifesto
But when I’m asked by a homeschool mom or a college student, “How can Agile help me?” – there is no manifesto.

That’s when I get to talk about coffee mugs and monkeys.

Talk to Us Today

Agile won’t work on [fill in the blank]

I have four kids ranging in age from 21 to 10. For some reason, people without children really like to give my wife and me advice on how to raise kids. Usually they will provide analogies using their favorite pet. Or they will tell me about their second cousin twice removed who “just had a baby”, and here’s what they plan on doing. I just politely nod and say “thank you”.

Find out if Agile will work for youSo what’s my point? I also tend to get a lot of advice regarding agile development and how it won’t work on certain projects. I’ve heard it won’t work on complex projects, big projects, geographically disperse projects, mission critical projects, non-software projects – you name it.  Everyone who tells me this has either a) never worked on an agile project or b) worked with a poor implementation of agile.

Instead of politely nodding and saying “thank you for your advice” as when I’m given child-rearing advice, I’ve recently decided to politely challenge these ideas with questions such as:

“What experiences have led you to that belief?”

“Why can’t an offshore project implement agile methodologies?”

Below is a post that I saw on LinkedIn:

As with any project management tool, it is situational. If, like in many software development environments, there are one or two key people involved in each and every task, Agile tends to break down. In this case, there are better methodologies to employ. Like any concept, I think the rub is that no technique fits all situations.

This was written by someone who has clearly either never worked in an agile environment, or has suffered a poor implementation.

I responded:

“There is a very broad spectrum of agile methodologies out there to cover any situation. Being agile also means adapting the process to fit your needs as it’s an empirical inspect & adapt approach to managing projects. For instance, typically Scrum & XP are implemented together. Scrum only addresses project management practices, while XP addresses development practices.

The failed agile implementations I have seen were caused by one or more of the following:

  1. The team is not empowered and self-organizing.
  2. Team members are working on too many projects, resulting in excessive context switching.
  3. Management is committed to command and control (related to #1).
  4. The customer or customer representative is not involved.
  5. Processes are not allowed to evolve.
  6. There is no dedicated product owner, i.e. someone responsible for the ROI that the team can go to (getting rid of the multiple boss syndrome).
  7. Those leading the agile implementation have not been properly trained in agile.

Agile works on huge complex mission-critical projects

Agile breaks down when the organization is not ready to accept its principles. If the organization is not willing to change from command and control to servant leadership, empower the team, assign one product owner, and get the customer involved, then it will fail.“

If you feel that agile just won’t work on _____, I encourage you to find out for yourself. There are plenty of cases where agile has worked on huge, complex, mission-critical projects.

Below are some examples of successful agile implementations where I’m sure many would have said “agile won’t work”:

Talk to Us Today

Your Scrum Team Might Be Too Big

According to the ways of Scrum, the optimal Scrum team size is between five and nine people. Interestingly, I’ve seen this as a point of concern (sometimes contention) when I’ve coached people on Scrum. Please note that this is not a rule that must be followed at all costs. God gave us a brain, so we should feel free to use it.

While I know it’s rare, I personally have seen successful teams that consisted of 10-15 people. I believe that if a team consists of any more than 15 (or so) people, you are reducing your velocity.

Now you have a bloated team.  What should you do?  Well, first thing you should consider is to take some ideas from Kanban. Visualize the work, make the process and policies explicit, limit work in progress, measure/minimize cycle time, etc. (read more on Kanban here)   The purpose of all of this is to gain clarity on what kind of work is actually taking place.  In addition, you will gain insight into the quality of the deliverables and where the bottlenecks are.

Once you have this information in hand, you then have three choices.

1.  Split the team into multiple teams.I have seen large teams have several very distinct types of work occurring. If there are distinct types of work, i.e. completely different categories of stories/requirements with different goals, and the team is forced to act as one, then there is waste. For example, during the standup, there will be members of the team that have to endure hearing the updates about requirements that they have no interest in, nor can they contribute to the delivery of those items (usually). This is likely the optimal choice.

2.  Reduce the number of people on the team.This is the tricky one. You may find that there are people that don’t have the necessary skills, or you may find that there are too many people with one very distinct skill set. If one (or both) of these scenarios holds true, and you are sure that these folks can’t contribute in other areas, then make haste and remove the people from the team. Everyone (including those let go from the team) will end up happier and more productive.

3.  Keep everything the way it is. This is a very, very unlikely choice. I have never personally experienced a time when it was a good idea to keep one team larger than 15 people. I would love to hear from others where this has worked well.

If you are a Scrum Master, and you are experiencing team bloat, then it is your responsibility to recognize it, determine if it’s an impediment towards improvement, then handle it.

Talk to Us Today

Experiencing the Agile Transition

There’s a benefit to working on a team as it transforms to Agile as opposed to jumping ship and moving from a company without Agile to one that practices Agile.

Don’t get me wrong – moving to a new company and experiencing Agile is a cool thing. But seeing a team of people you’re familiar with as it transforms is powerful. Watching familiar frustrations fade and seeing timelines shrink – with the same people on the project – is exhilarating.

The first time Agile was introduced to me, it was proposed that we adopt Scrum. My team was barely meeting our deadlines and we were working twelve hour days. We always managed to deliver, but it was because we were killing ourselves to do so. Often we’d be on conference calls at night from home, trying to finish up pieces of our product before a release date. We operated under a sense of constant panic and rush.

When we were asked by our project manager to read sections of Agile Estimating and Planning and User Stories Applied (both by Mike Cohn), we couldn’t believe he was making us invest time in something like a new methodology while we were all struggling to just keep our heads above water. But he insisted, and we all grumbled our way through our first few weeks of Scrum, waiting for it to fail and for our PM to allow us to go back to what we were doing before.

I clearly remember thinking that this would be the thing that pushed us into failure. We didn’t have time to mess around with some new methodology. I hoped that our PM would realize that before it was too late, but I had no option other to go along with him and indulge his new hair-brained idea.

Somewhere into our second week, we began to understand the process and embrace the tools. Somewhere into our fourth week, it became something that we would all insist on continuing even if it was no longer required of us.

Days of frustrated moans and frantic hallway conversations morphed into coordinated efforts and understanding.

Nights of working from home vanished as our estimates and efforts became more effective.

Rather than packing up at the end of the day and rushing home to complete something that we just found out we had to do, we were packing up and heading out for drinks because we knew that we were on schedule.

Relationships began to solidify, and our team felt a bit like soldiers returning triumphant from battle. (I know that sounds dramatic, but it really was a battle for us before Scrum. We all have mental scars from the days of fighting toward deadlines. From giving our all and realizing that our all was barely enough to pass muster.)

Other teams saw what our team was doing, and began to implement Agile, as well. Scrum terms became a part of daily communication, and the entire office changed dramatically.

Before Scrum, it was a stressful environment full of high achievers who constantly felt as though they were tugging against some invisible force in order to complete the bare minimum.

After Scrum, those same high achievers were allowed to sail forward together. The entire culture of our office changed within six months of Scrum making its way onto our team. (Remember – same people, same products, same office, same leadership. The only thing that changed was the fact that we became Agile.)

If I hadn’t been there for the transformation and experienced it firsthand, I don’t think I would have understood the significant difference that Agile can have on not only project completion, but on the people involved, as well.

Talk to Us Today
post =