Plan and Schedule You Sprint Meetings With This Handy Template

In large corporations, everyone's schedule is packed with meetings. This makes is difficult to schedule the important meetings Scrum needs.

I have created a template that I have been using that is simple and easy.

It includes the name of the project and the sprints contained in a given release. Dates of important activities and meetings are also included.

Once the dates have been established, I schedule All Of The Meetings well in advance. Normally schedules are more open weeks in advance. Once these meetings are on the team's calendar, they schedule other meetings around the existing sprint meetings.

You may access a copy of the template here.

It's Not Your Code

I have worked with a number of teams over the years and from time to time I encounter developers who are very resistant to code reviews. This is normally related to some type of fear.

Some developers are fearful of having mistakes pointed out. This could be because of past experience where the review was painful and took on an accusing tone. Reviewers need to be respectful when reviewing  a set of code. It should be a learning experience that provides value to the developer who's code is being reviewed.

There is also fear that with tight deadlines, the code review will add unnecessary time to an already stress filled schedule. Proper time must be included in the estimation to account for the review. In the end, time will be saved because less bugs will be found.

In rare cases, I have found developers who believe they do not need code reviews because of their experience. We need to point out that a second set of eyes will find things that were missed regardless of experience. Many very experienced developers embrace pair programming, which is in effect a continual code review.

There are some good articles that discuss the code review process.

Jonathan Lange has a nice article, Your Code Sucks and I Hate You where he points about why a code review is necessary and provides some excellent points about how to conduct a proper review.

Esther Schindler makes some excellent points in 5 Reasons for Software Developers to Do Code Reviews (Even If You Think They're a Waste of Time). Point one says that code quality improves simply because developers know their code will be reviewed. This is a perspective I had not thought of myself. There are also useful links in this article that provides tips on conducting a code review.

My message to developers is the code you write is not your personal property. It is an asset of the firm you work for and is part of something much bigger than you, a single developer. It is part of a larger product that will change the world in some way.

The Power of Scrum - The Backlog and Product Owner

The more I work with teams and use Scrum to deliver software solutions, the more impressed I am with the simplicity and power of Scrum. I thought I would take some time to blog about some of the more powerful points. I will start with the Backlog and Product Owner.

Build the Right Thing

In this competitive world, one of the major risks we face is, are we building the right thing? This has two important aspects to it.
On one hand, are we including the most important features for our product? If we miss an important feature, we may miss a competitive opportunity and lose market share. Our competitors may beat us to the punch.
Or perhaps we are building many features, but not the ones that really add value. We could be very efficient, and deliver features on time and within budget. However, if these features are things our customers do not need, it has been a waste.

The Product Owner

Scrum has a role that focuses specifically on this challenge. The Product Owner is the person who understands the Product being delivered better than anyone. She understands the competitive marketplace and understands what features are important for the Product. These features are maintained in a prioritized list known as the Product Backlog.

The Product Backlog

The backlog is fluid and changes often. As the Product Owner conducts surveys and interviews stake holders, the features on the backlog and their priority change.

This sets Scrum apart from more traditional development approaches where we define what we need up front and consider most changes as an unwelcome event. Scrum embraces change and accommodates it as a core principle.

Stop at Any Time

Since the backlog is prioritized, the most important and valuable features are at the top. This means as we move down the backlog delivering features that are a bit less valuable than the previous ones, we can stop at any time.

When we have delivered enough value, what ever that is, we can stop. This also sets Scrum apart. Under more traditional delivery approaches, we deliver everything we defined at the beginning of the project, even if a feature is rarely used.

Global SCRUM GATHERING® New Orleans 2014 - The Scrum Master

This is the final article about some important points I took away from the Scrum Alliance Global Scrum Gathering in New Orleans. This was an excellent conference and I learned many new things. Also, practices that I use regularly were expanded and important details were added to my knowledge base.

My first article pertained to The Team while the second focused on The Product. This article will discuss the Scrum Master.

The Scrum Master

It was very interesting to see a large number of people who are experienced Scrum Masters. Each of these people brought their experience to the sessions I attended.

A common theme was to show respect whenever you are talking to the team or individuals and be wary of your body language as you interact. It is very easy in the heat of the moment to become emotional.

It is important to remember that the Scrum Master has no decision making authority. This is actually a powerful position because it focuses decisions on the team who after all are the experts.

A scrum master should become the Master of the Question and facilitate Fact Based Discussions. It is also critical to remember to ask the team as issues and decisions need to be made. 

I attended a session that focused on listening. Some important points we discussed were:

  • Maintain eye contact as you talk to a person. Watch their body language as you interact with them.
  • The person you are talking to is the most important person in the world at that time. 
  • Pocket the phone when you talk. Do not check emails or answer a call unless it is an emergency.  If you must take a call excuse yourself with a statement like “I am sorry, this is my daughter, it may be an emergency”.
  • Re-state what the person said so you can validate your understanding of the conversation.
  • Write down the person’s name if you are new to a team, it will help you remember them in the future.

A number of people mentioned that they use a Scrum Master Checklist as a way to stay on track. This checklist asks questions about the backlog, user stories, and other important points that help keep a project on track. I have created a checklist in Excel that I plan to use from now on. If you want to check it out, it is available here.

One of the more creative sessions was titled Coaching Like Columbo by Dr. Patrick McConnell of CSC. The premise of this session was to:

  • Ask a very simple, non-confrontational question focused on outcomes or daily experience.
  • Shut up, for a while.
  • Start connecting the dots backward to choices.

We used the diagram below ask questions and broke off into teams.

Columbo Questions.png

How did your last release go?
For the Un Healthy answer we Came up with:
The release was late, someone died and our company’s stock price went down.
For the healthy answer we came up with:
We released more than planned on time, the product won an award and we became rich because of our stock options.
We then worked on the conditions for each of our answers. This light hearted approach was fun and a method to uncover creative answers. I plan to use this on some of my future projects.
I was very happy with the outcome of the conference. I would recommend it to every agile practitioner.

Learn More 

Vendor / Content

  • Visual AGILExicon – This was developed by Ken Rubin who wrote a very popular book and has trained thousands of people. This AGILExicon Visual Agile Lexicon  is a set of re-useable graphically rich diagrams that cover the concepts of Scrum. It is available to all for free to use.
  • Axosoft - Axosoft is a vendor who sells a suite of agile tools. The bug tracker tool is available for $1 per year for teams of any size.
  • Cisco Products - This is a set of high end tele-presence products for geographically separate teams.
  • Sococo Products - virtual office software for geographically separate teams. Virtual offices, chat and meeting rooms keep teams together.

Books / Articles

Conference Slides and Keynotes  

These links provide access to the session slides and keynote presentations. You have to be a member of the Scrum Alliance but after that, the content is free. I highly recommend The Business Value of Joy, Richard Sheridan. It got a standing ovation and is excellent!