Why Scrum fails…

My biggest issue with Scrum is not the methodology itself which I believe is very effective for software engineering, it is how Scrum is typically adopted by development teams. In my experience most teams that are new to SCRUM seem incapable of trying to use and understand Scrum without first modifying the Scrum process to ‘suit their unique development culture’.

These modifications while being well meant usually distort the Scrum process sufficiently to doom the process e.g.

• The scrum master is also the product owner.
• Assigning each programmer to multiple scrum sub-teams.
• Weak scrum masters that are unable to control a stand up meeting.
• Scrum teams of 20+ programmers.
• Stand up meetings with chairs…
• Stand up meetings taking 30-60 minutes due to meta-discussions.
• Not reviewing task estimate accuracy.
• Not tracking all work being performed e.g. bug fixing, training, holidays etc.
• Not engaging stake holders.
• Not having daily stand ups.

I think Scrum is a very useful methodology when its applied correctly as it constantly captures, measures and responds to changes in the project. However Scrum seems to have a fairly unique problem that its very hard to stop teams tampering with the methodology before they really understand the implications of their changes.

Fight daily meeting drudgery!

I have noticed over the years in daily stand up meetings that there seems to be two common forms of answer to the standard Scrum questions:

• What did you do yesterday?
• What are you doing today?
• Are you blocked by anything?

The first type is the concise answer which is in my mind the ideal answer, one that provides the necessary information in the minimum amount of time without any excess fluff.

The other type  is the rambling answer that attempts to contextualise itself but really just drowns in excess information.  I have even witnessed people using the questions as a chance to rant at their (effectively) captive audience or as a chance to start discussion.  Discussion is a good thing but not during a daily stand-up with the whole team listening into to a few individuals discuss something, that gets old fast.  Have your discussion after the meeting to spare those that are not required.

These two different styles of answers can make or break the scrum experience for the participants: too many ramblers in a stand-up meeting can make the daily meetings feel like a sentence instead of a chance to find out what everyone else is doing.  The purpose of these daily stand-up meetings is to: update the rest of your team on your state: what you did yesterday, what you are working on today and any work blocking issues you are experiencing.

The goal is team wide visibility into the state of development and the corner stone of it is quick efficient short daily meetings.  So keep those answers as concise as possible, this will require thought on your part to compose your answers before its your turn but your co-workers will appreciate it!

Useful Status Reports

Status reports are a way of life for most developers, however there is no standard way to write a status report unless you have a manager or team leader that is supplying some sort of template to fill in.  This lack of examples leads to a lot of confusion about what information to include, the type of details to supply and the size of the report to deliver.  There is always the suspicion that these reports are seldom read and the urban legend of the engineer that wrote their reports in a foreign language to see if their manager would notice, which allegedly they didn’t.

In my experience I’ve only ever had one manager who I know who would read and understand the reports given to her by her engineers in whatever format their engineers chose.  Most managers are not usually as flexible as this or as technical which leads to problems with them not understanding the reports and the potential for developers using technical terms as a smoke screen.

I think the best way to think about how to write a status report is to think about what the motivation is for the person who is asking for the report, what do they want to know?  In most cases what they want to know is:

• The work that has been completed since your last report: the gains.
• What could cause problems in the future: the risks.
• Things you’ve encountered that caused problems: the issues.

It is also worth considering how they want this information presented:

• An easily digestible format: the use of technical terms for non-technical individuals is counter productive.  Even if your manager or team leader is a technical individual it is quite likely their superiors are not technical or not closely familiar with your teams problem domain.
• In a concise manner: most managers or team leaders usually have to supply reports of their own to their superiors so having to distill the reports given to them during the preparation of their team reports is inefficient.
• In a single sentence: The more senior a person is the more likely they are to skim reports given to them due to time constraints. This makes concise non-technical summaries very important for getting the key points of the report across.

Below is a template I currently use for my end of scrum status reports for my team, which I supply to my non-technical manager as an email. The colour coding seems very popular and makes it easy to skim.  There are notes in the template that I write over that I added for myself to guide me while I write the report, which takes no more than ten minutes.  I keep this template inside a task in Outlook which I have set to recur at the end of each sprint, so I don’t forget to write the report or lose my template.

Summary sentence, avoiding technical terms and picking out the most important points, as this sentence may be as far as some people read.

Gains:

• List of completed features.
• Concise as possible.
• No technical terms!

Risks:

• Possible future risks and potential solutions.
• Concise as possible.
• No technical terms!

Issues:

• Problems experienced and the solution(s) used.
• Concise as possible.
• No technical terms!