People don’t buy what you do; people buy why you do it Everyone can say what they do or what they make. Not many people or organizations can tell you why they do it.

This blog post isn’t specifically about Scrum. It is, however, at the core of running a business and making products. Your cause, belief or purpose for doing the things you do relates back to a previous post I had about motivation, where mastery, purpose and autonomy were highlighted as the drivers of Motivation 3.0.

dilbert_magicmotivation

To start with why in everything that we do we must ask ourselves what our cause is and what we believe in. If you don’t know these things chances are motivation won’t be all that great. Organizations that don’t really know why they exist will have a hard time both recruiting and motivating new employees and keeping the ones they already have motivated. Making money is just a result of what we do, not why we do it. To get high performing (scrum) teams it must have a purpose. Sure you can get a good implementation of Scrum – but it might very well just not “feel” right, and it will certainly not be a hyperproductive team. It’s not enough to recruit team members by saying what cool stuff your are building and how you are going to do it. It’s also necessary to state why the product you are going to build matters and its greater purpose. So initially the organization as a whole must have a reason for existing and then this must be a reason so clear and consistent in all that the organization do, that everyone in the company can share the same belief.

In his book Start with Why: How Great Great Leaders Inspire Everyone to Take Action, we get an explanation for why some people and organizations are more innovative, more influential and are able to inspire greater loyalty and engagement among their customers and emloyees than others. The reason is that they all think, act and communicate in the same way – and that is the opposite from almost everyone else. Every single organization on the planet works on three levels:

  • What we do (products or services offered)
  • how we do it (the organization’s or individual’s strength, values or guiding principles which they feel sets them apart from their competition)
  • why we do it (purpose, cause or belief)

When all these are in balance others will say with absolute clarity and certainty that they know who you are and what you stand for. Sinek calls his idea the Golden Circle.

goldencircle

 

The way people naturally communicate is from the outside-in, from what is easiest to understand to what is hardest to understand and explain. They tell what they do and how they do it different or better, and then expect people to buy their product or service, or get their vote or support. Leaders and organizations which inspire and creates loyalty and engagement does the exact opposite – they communicate from the inside-out.

The example which is perhaps easiest to understand is Apple. They start with why – they communicate in a way that drives decision-making and behavior, and literally taps the part of the brain that influences behavior. If Apple were to communicate like everyone else, this is could be how their sales pitch for their product ideas would look like:

  • We make great computers
  • They’re beautifully designed, simple to use, and user friendly.
  • Want to buy one?

This seems like a pretty standard pitch. You say what you make and how it’s better, then ask people to join/buy.

The way Apple actually pitches their products:

  • Everything we do, we believe in challenging the status quo thinking differently
  • The way we challenge the status quo, is we make our products beautifully designed, simple to use, and user friendly
  • We just happen to make computers – wanna buy one?

It’s of course not as easy as reversing the order in which you communicate your product ideas. It’s also of course about how you think and act. There must be clarity of why – you must know why you do what you do if anyone else is going to see this. How you do things must be aligned with these values, principles, strengths and beliefs. Lastly, everything you say and everything you do must be consistent with what you believe, because this is the only way people will know what you believe.

Sinek sums it up as this:

People don’t buy what you do, they buy why you do it.

So to get motivated and loyal employees and also loyal customers who “just feels” that your product or service is worth buying you should start with why. Any Scrum team that don’t have this clear sense of why will struggle in the end. Sure it’s the product owner’s responsibility for sharing a vision to the team and through that inspire and give a purpose for the team’s existence. This is not easy if the product owner is employed in an organization without a clear sense of why. So to every organization and every individual out there: Do you know your why?

Why you should estimate in points Estimating in points is more accurate, faster, important for release planning and will help your team improve performance

It’s easy to understand why Gantt charts initially are so appealing. They are easy to understand and you see the timespan for all tasks with a start and end date, leaving the project manager with the complete overview of what is being worked on right now and when it is going to be done. So using Gantt charts seems really easy to use when you do release planning. The problem is that the hours that these charts depend on assumes that you have a fixed amount of hours for some person and that none of the dependencies ever change. The hours to do a story of course rely heavily on the person doing it and is impacted by changes in dependencies. This means that to be valid a Gantt chart needs to be updated a lot. On big projects you might even need resources whose only task is to make sure the Gantt charts are up to date. Story points are more stable – and that makes planning with story points a lot easier. 5 points today will be 5 points a month from now or a year from now.

By doing estimation in story points a team can establish their velocity, a measure of the amount of work the team are able to handle during a single sprint. The nice thing about this is that the product owner can use this velocity to plan a release date. Knowing approximately how fast the team is moving s/he can calculate how many sprints it takes to implement the needed functionality for the product to be shipped. Using hours you don’t know the velocity of your team – and that also makes continuous improvement hard. How do you know if any of the teams process improvements work if you can’t measure how fast you are moving. Using points as a measure of output you can easily see if your improvements are working or not. When using hours, both input and measure of output will be hours. Since there are a fixed number of hours every day velocity based on hours can’t really be increased. There is a way it can be increased, but the only way to increase output when using hours is by increasing the number of hours put in. This means making your people “burn the midnight oil”. Studies shows that productivity dramatically decreases when working long hours, and of course – long hours is not the “sustainable pace” that we want.

So points are stable, making release planning possible. Being the measure of output it’s also possible to measure improvements done sprint by sprint. In addition story points are a lot more accurate. Humans are pretty terrible estimating stuff using hours. Studies done as early as the 1940s by the Rand Corporation showed this. A way to overcome this was by putting things in relative sized piles using the Fibonacci sequence when doing estimation, instead of using hours. This method is called the Wideband Delphi estimation method. The same technique is what Planning poker is based on – and most agile teams are familiar with this practice. A quite recent study at Microsoft shows that in the early stages of the project the estimation error using hours is as much as 400% vs 50% using story points.

cone_of_uncertainty

 

In addition to all this story point estimation takes a lot less time. According to data presented by Jeff Sutherland story point estimation would cut estimation time by 80% for a CMMI Level 5 company and a telecom company reported that story point estimation with planning poker was 48 times faster than waterfall estimation practices within that company. Since we are reasonably comfortable with relative sizing vs not too comfortable with estimating actual sizes we tend to spend a lot longer time to do those estimations, taking the level of discussions to a couple of levels deeper than you would with point estimations.

The takeaway here is that you should just stop estimating in hours. Numerous studies backs this up – use story points instead!

dilbert_estimation

 

Context switching causes brain damage It is well documented that multitasking kills productivity. Can Scrum help you reduce waste created by context switching?

That multitasking causes waste has been documented well and is to my opinion a well known fact. The most referenced book is probably “In Quality Software Management: Systems Thinking” by Gerald Weinberg. Whenever this is referenced the following chart is presented:

weinberg_contextswitch

 

Weinberg calculated that having just one project to focus on lets you spend 100% of your time on that. Adding just one project to two in total will cause you to lose 20% of your time to context switching. These numbers have proven to be true or even worse in real life scenarios. Another study done in 2007 with workers at Microsoft showed that even just responding to email or instant messaging lead to an average of 10 minutes or more resumption time. To truly get back to the task they were doing before the interruption it took an additional 10-15 minutes.

In addition to losing time to context switching it actually causes damage to your brain cells! Psychology Today reports the following:

A new body of research has found that multitasking makes people less efficient and reduces the level of brainpower used for each task. Also, people who overburden their minds with too many tasks at once can have problems with short-term memory.

Further it is reported that the mind slows down and adds a few seconds between each task. You get more stressed, causing a stress response. This stress response causes an adrenalin rush that can damage the cells that form new memories (short-term memory). In addition this stress response might weaken attentiveness and alertness.

It is pretty obvious what we should do – focus on on fewer tasks! In other words we should limit work in progress and avoid interrupts as much as possible. This is, as most of us know, easier said than done. For the most part it seems it is expected that you are available all day, on the phone, instant messaging, mail or in person. As an individual it isn’t easy to say no to management if they expect you to always be ready to shift your focus. Maybe Scrum can help us?

In Scrum the WIP limit is set per sprint, so that the team ideally only need to focus on the sprint backlog for any given sprint. Having a limited number of stories which are in play each sprint will help reduce context switching. However, it’s still possible that team members switch between backlog items. This could be because impediments limits team members from finishing the backlog item they are originally working on. If this is the case it is important to have a ScrumMaster that actively works to remove such impediments as soon as possible.

Pressure from external parties such as management or stakeholders could also cause team members to switch to and from backlog items. This interference with the team could also involve doing stuff that’s not even in the sprint backlog. In these cases it is important for the ScrumMaster to protect their team from such distractions. This protection could go as far as protecting team members for timeboxed bursts of work of 90-120 minutes followed by some recuperation time, so that during these bursts of work the team is not available for external interruptions.

The product owners also have an important job of demonstrating to management that focusing on fewer tasks and letting the team work uninterrupted is the best way to do things. Although the timeboxing of sprints in Scrum is one reason management might feel that Scrum is too rigid, there is a reason for this rigidness: Context switching is expensive. It is, as mentioned in an earlier blog post, possible to use an interrupt buffer each sprint. Here typical interrupts are calculated for. The thing about this buffer is that it should never overflow – if it does the sprint should be aborted. This is something management doesn’t want because aborts are visibly expensive – and thus interrupts will be kept at a minimum whenever they are kept visible through the use of an interrupt buffer.

All in all – Scrum can help reduce context switching. Sprint backlog reduces the number of items that can be worked on and ScrumMasters and Product Owners together protects the team from external interruptions. If you work on a team that is pretty much protected from external noise you also need to take action as an individual. Turn off your phone, exit Outlook (or whatever you are using) and exit whatever software for instant messaging you are using. Of course, I don’t think it’s realistic that you can always work like this, but having work bursts of 90-120 minutes where this strategy is used will without a doubt increase productivity.