Scrum master woes

The scrum master was genuinely upset:

-  Scrum is so hard. Engineers do not like it. They feel exposed.
-  Well, yes – Scrum calls for transparency, and that is a good thing. Engineers will learn to share.
-  But we have to do estimates. And then we have to deliver to those estimates. Then things happen. And engineers hate to do it, and then explain how a task that was estimated at 2 hours took three and a half.

It is easy to see why engineers do not like this process. Rapid churn of iterations calls for very frequent estimates – and regular inspections of why these estimates turned out to be not quite right. It is painful to be continuously wrong, and even more frustrating to have to defend tiny details of the complex minutiae that is software development.

What can the team, and the Scrum Master, do, to lessen the pain?

The scope of estimates is negotiated between the project manager or product owner, and the product team. Many a project manager would like correct, non-changing estimates provided on the first day of the project. Many a team would be perfectly happy to not estimate at all. Usually, neither gets exactly what she wants, but instead negotiates a compromise with the other side.

The scale of possible compromise solutions

• The team does not provide any estimates. Project manager, with the help of the Scrum Master, makes educated guesses, based on their experience with the team and the project, when the backlog items will be completed. In this case the team may not share how it is breaking down the work, the progress it is making during the iteration, nor the problems it encounters. Priority of backlog items is established based on their value, and only project managers’ perception of the size and complexity of each item, since the team may not share its evaluation.


• The team provides detailed estimates to project manager at each iteration, and works hard to deliver per estimated completion times. Project manager gets a full report of each working hour of the product team, and gets to control how the work is broken down and accomplished by the team. In this case the team may not be fully forthcoming about how long each tiny item will take, and pads the estimated schedule so that there is enough slack to deliver even if things go wrong. Even if everything goes fine, the team is more likely to deliver on a padded schedule and use the slack time to relax, rather than forge ahead. Even with seriously padded timeline, estimates are often too optimistic, in which case the team will be blamed for incorrect estimates, encouraging even more padding going forward. Detailed estimates take a lot of time and effort, and so does hiding the slack/padded time that the team puts into estimates. The team will be working harder, without a corresponding rise in productivity.


• The team provides coarse-grained relative estimates, by sharing with the project manager how hard each item of work is expected to be. The expected delivery timeline can be deduced, but is not promised, so that the project manager shares in the uncertainty of software development. Still, the project manager can use that information to adjust priorities of various backlog items. The product team does not have to be defensive about not delivering per estimates, because no particular timeline is being promised. The mutual expectation is that most of the estimates will turn out to be wrong, but when the estimates are averaged over multiple backlog items and several iterations, they will provide valuable, actionable information to the team, the project manager, and the rest of the organization.

What are coarse-grained estimates?

It is helpful to classify pieces of work on a scale of Trivial, Small, Large, etc.  Fewer options means coarser estimates.  Using numbers (prime, Fibonacci, etc.) may encourage defining too fine-grain a division.  Using hours or days creates a direct timeline, suggesting that a particular delivery date has been promised. Another option is to use anonymous units of complexity, and those are great if the team can in fact treat them as abstract units (and not convert units into timeline, as it often happens). 

Having less-than-perfect estimates, and no timeline, requires and helps build trust between the team and the project manager. The team is held responsible for the average productivity, rather than each particular estimate. The project manager is asked to give up the illusion of full control over the project timeline and trust the team to deliver as best they can.

Scrum Master is tasked with negotiating the compromise, and holding both sides responsible for their respective contributions.

Lack of women in technology industry starts early

As a part of the wonderful HoustonTechFest, an annual community event for the technology industry, we got to have a very important conversation on diversity in our communities. A very small portion of software engineers are women. It is rather rare for women to enter, thrive, and build successful long-term careers in the technology industry.

During our panel discussion at the HoustonTechFest “BuildingSoftware Is A Team Sport: Women In Technology” we discussed the benefits of having both men and women participate and be successful in technology field. Participants talked about the problems for different ages and career stages, and what we as a community can do about it. We also looked at the societal biases, rooted far outside the technology industry, that keep men and women apart and less than successful professionally, and how each one of us can help our friends and colleagues lessen the effects of these biases.

As a technology professional, I observe these biases nearly every day. I work with many smart, successful, and open to diversity and true meritocracy men and women. I also interact with people who believe that women cannot be capable engineers.

Recently, I’ve come across a scary source of these biases.  My toddler attends a wonderful daycare center – a loving, fun place where kids play, learn, and build their social skills through interacting with other kids and many excellent teachers. Yet, one day my child came home from daycare with this scary idea: “Girls are nice. Boys create messes. I do not like boys.” She went on to name girls who she likes, because they are girls, and boys who she does not like, since they are boys.

We have had several conversations as a family how boys and girls are both kids who play and learn together, how boys and girls can both be nice and fun. How it is OK to not like kids who are mean or angry, but it is not fair to not like or not play with a kid simply because he is a boy (or a girl, for that matter).  

However, this is a tough message to deliver to a little kid. Just as tough as it is to convince grown up, professional men and women with extensive work and life experience, that both men and women can be smart, capable, innovative, and contribute greatly to the success of the industry, if given a chance.

The struggle continues.  Please join us for our next discussion about successful diverse teams in technology.