fbpx  

scrum

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.

,

Shake Up Your Daily Standup

The Scrum Guide says the following about the Daily Standup:

The Daily Standup or Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The Daily Scrum is held at the same time and place each day to reduce complexity.

During the meeting, the Development Team members explain:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

Agile Daily Standup-breaking out of the mold

We all the know the importance of the Daily Standup, but how many teams are actually gaining real benefits from the Daily Scrum or Daily Standup?  This ceremony is not meant to be a ‘Status Report’, but in reality that is exactly what this meeting has become.  If you have fallen into the ‘Status Reporting’ trap, then you may want to consider cancelling your Daily Standup all together or making some simple changes to shake it up!

5 suggestions to shake up your Daily Standup:

1. Extend the length of your daily scrum

Yes, you read that correctly.  If a team of 8 people all have to give an update at a 15 minute Standup, that is less than 2 minutes per participant to provide valuable information.  If someone has a question, then forget about finishing in 15 minutes.  Given the time crunch, team members will hesitate to provide all the information needed in order to allow the team to gain the full benefit from the meeting in favor of meeting the 15 minute deadline.  Stretch a little; give the team some extra time to collaborate – isn’t that what it’s all about?

2. Stop answering the three questions

We all know that a team should be limiting the Work in Progress (WIP).  Let’s say your team should be working on only three stories at a time: review each WIP story in-depth.  Allow each person who is contributing to that story to provide their insights.  Address all issues or questions, or put them in the parking lot for ‘Post Standup’.  (See number 3, below.)  Once you have completely discussed the WIP stories, ask if people are working or need to work on other stories.  This should avoid the schizophrenia that occurs with the round robin approach.

3. Create a post standup meeting

As the team is reviewing each story they will have in-depth questions, concerns, and ideas.  Use the time right after the Daily Standup to pair program or swarm around items from the Standup.  I like to keep a white board at hand and I write down  ‘Post-Standup’ items as they come up.  This gives everyone an opportunity to participate, including Developers, Product Owners and Scrum Master. There is no set time-box for Post-Standup-it is all about collaborating and getting stories to completion.

4. Allow the product owner to participate

If the Product Owner (PO) has questions about the story or wants to provide insight – let them.  Why Not? This is the time when the team is trying to make sure they are meeting the objectives of the Product Owner.  If the PO asked a detailed question that will take more that a few minutes, move it to Post-Standup.

5. Have fun

Banter a little! Life is too short to just jump into the heavy details of the Daily Standup or Daily Scrum.  Take a few extra minutes (see #1) to strike up conversations with your teammates.  Use it as an opportunity to do a little team building and get to know each other. Come prepared with an interesting topic and throw it out to the group such as “Name three things that you think will be obsolete in 10 years”. You will be surprised how far a little fun will go!

Talk to Us Today
,

Scrum Does Not Tell You How to Build Stuff

There have been some respected leaders in the industry that evidently just don’t get what Scrum is meant to provide and, more importantly, what it’s not.

Scrum does not tell you that you have to use TDD, BDD, Continuous Integration, Continuous Deployment, OOP, etc. Scrum also does not tell you that you have to use User Stories that are estimated with the Fibonacci-ish scale. It doesn’t tell you how and if to do exploratory testing, load testing, performance testing, acceptance testing, or anything else.

Why? Because it wasn’t meant to. Are all of the things I mentioned above good things? Absolutely! Is every team ready to adopt them? NO.

100% of the teams that I’ve coached were not ready to take on the additional stress of learning these practices that Scrum does not require. The FIRST thing they had to work through was how to be a team. How to understand what commitment means. How to respect and trust each other. How to feel and be empowered. How to build trust with the customer that had been long lost or most likely never existed. How to better predict what will be delivered. What it means to deliver VALUE.

Focusing on these things is many times almost more than a team can handle. I’m surprised that anyone would think it would be a good idea to right away add on top of this the pressure of learning new technical practices. The fact of life is that most enterprises do not have the processes, infrastructure, or culture that allows quick adoption of modern development practices. Change takes time. Take a deep breath and embrace it. Only then will you be able to make real change.

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 =