Monthly Archives: November 2014

Overtime hurts – Your company and Yourself

Welcome dear reader,

Have you done overtime in your life? Did you have that one project that meant a lot to you, and you really wanted to get it done?
Are you currently working 10+ hours?

Currently I’m working on a project and I know that every hour I don’t invest in the project could potentially mean failure. Failure would directly affect me since I personally gave my word to finish this project because I believe it can be done. It would mean dishonour, loosing trust and potentially severe consequences for people that trust me to get things done.

All good reasons to do overtime, no?

Overclocked and Overworked
Overclocked and Overworked © by Bryan S on flickr

“Working longer hours creates more work than it accomplishes”

This is a direct quote from Jeff Sutherlands newest book and it is completely true.
Thinking about why I’m doing overwork right now brought me to the conclusion that currently I’m not only damaging my personal life by working too much, but also the company I’m working for.
Let’s analyse a bit what I’m currently doing so you can understand this better.
For the current project I’m working as a Product Owner. And we’re closing in on the release date of the project. We’re supposed to work agile and we’re in the “stabilising and bug-fixing” phase.
Those of you who understand what “working agile” means already spotted anti-patterns in what I just wrote.
Right now my main duties are:
  • Writing Tickets to resolve Bugs and retesting them
  • Testing
  • Defining Test-Cases for manual testers
  • Organising test runs and all pre-requisites
  • Taking care of a sub-project that is critical for the projects success

Don’t do work that you shouldn’t do

Now as a PO I shouldn’t do a lot of what I’m currently doing.
If you know what a Product Owner is supposed to do you probably understand what I mean.
But why does this hurt me or the company?
The company is hurt because you’re compensating for a lack that actually the company should address. In my case the company should focus on getting better in testing to be able to deliver “done” functionality after each sprint. This includes a lot of work since the only way how to do that is automated testing and this requires a lot of learning on the team side.
But as long as this is covered by people that take this important role on them by doing it manually the company will not do anything. And the company should really do something here.
But much more important hurting yourself is much worse.
If you work too long you feel that personally through one or more of the following symptoms:
  • Feeling tired and exhausted
  • Not having time for your loved ones
  • Learning, Sports and other activities are things you always want to do “next week”
So if I work longer than 8 hours I’ll hurt myself because I cannot focus on other things that are important like Sports to give me more energy or learning  that will make me better in my job.

Be professional and make it transparent

If you want to be professional in your job this is something that you have to highlight.
This can start by saying NO, when you’re asked to do something that you shouldn’t do.
Now please don’t confuse that with narrow roles and the typical “this is not my job” statement. In a cross-functional team it’s the whole teams responsibility to get the job done.

But there are limits to this and you most probably know best where those limits are.

So whenever the limits are broken for yourself think about what you can do. Simply saying NO might not always be an option. But there are other possibilities:

  • Highlighting the broken system (in my case showing how the quality is not sufficient)
  • Talking with a sponsor, mentor or stakeholder
  • Giving suggestions on how a possible improvement could look like

Improvement – Everyone is responsible

Teamwork – by Ice Birdy on flickr

It should be the responsibility of each and every person in a company to improve. If you don’t get what I mean by that read this great blog post by @WoodyZuill to understand it better.

Whatever doesn’t work in your company shouldn’t be taken for granted. And everyone should be able and asked for improvement contributions.
This way if you find some dysfunctions like the one described above your feedback will not be treated as criticism or negative but rather welcomed and appreciated.
When you bring forward your idea of improvement start with that. Any leader who takes the well-being of the company serious should be more than willing to set some learning system up that will boost long-term improvements.
While reading this you could have thought about that one thing in your work that you have done for weeks or even months but always thought that it is wrong.
But there was never anyone to do it other than you.

Think about the long-term success of your company and answer yourself the question: should it continue like that or are there better alternatives?
If you have one or more alternatives find the right person to talk to and start improving TODAY.
There is no reason to wait any time longer. You’ve waited long enough.

I hope this gave some of you a little bit of inspiration to start improving.
I’d be glad to hear about your improvements in the comments or on twitter @MrSnow76.

Thx for reading,
Sven Schnee

Dear Product Owner, Scrum Master, Stakeholder or anyone else who needs to know when their project/release is finished,

in any project or product development there is a need of being able to know when your fancy new product is ready to go live or when your piece of work can be integrated with the rest.
There are many good reasons why you want to know when you’ll be done.
As we all know in traditional waterfall projects you always know when you will go live, sometimes years ahead, UNTIL the hidden monster of variability shows up and kills the deadline several times. Sometimes up to the extent where the whole thing gets cancelled.
In this blog-post I show you a different approach on how to keep progress transparent to ensure you can keep your deadline.

Variability kills Deadlines – and Projects

Ok so here I go, being Scrum Master of a fresh one year project and we got a new Product Owner that never worked with Scrum before and had a Waterfall career for 15-20 years.
We started the project and after 3-4 months senior management steps in to ask “where are we standing with the project, will we deliver on time within budget?”.
And the PO tells them he doesn’t know. So senior management tells him to create the full backlog of things that have to be done for the project and estimate them with the team. But better use only one or maybe two persons of the team, because that’s cheaper. 😉
So the guy goes off for 2 weeks and starts writing Stories after stories until there are 180-200 stories in the backlog. And he hands that over to 2 developers to estimate the whole lot of stories.
So after 2-3 days of going through all that stories and estimating them those guys come up with a whooping 1000 Story Points to be delivered.
So the PO came to me and said, tell me when we will be ready. And I told him “I don’t know”.
“You have a completely fresh team of people that never worked together before, it takes at least 2-3 sprints to settle the team and get an idea about their velocity. And even then this velocity is a very bad indicator to tell you if you will be done in time or not. There is a lot of work yet undiscovered that will completely ruin what you will create now as a graph trying to predict the future.
The guy continued his journey 1-2 more months until the team asked me to step out of my Scrum Master role and into the Product Owner role.

You can never accurately estimate what you yet don’t know

So my first course of action was to throw away the old backlog and together with the customer discuss on a feature/epic level what they urgently need and what can be left out.
On this rough level I asked them to order the features in terms of importance and value.
From there on I started to break those features down to “Vertical slices” (I’ll explain that in a future blog post). And to know where we are compared to where we want to be at the end of the project I created a Release Burn-Up.
The blue line (and y-axis) on top shows the number of work items to do (in this case stories).
The x-Axis shows the number of sprints
The orange line is the speed needed to reach the Go-Live date.
And the red line shows the number of items done so far.
As you can see the project was in deep trouble when I initially took over and created that chart.
The easy and secret ingredient to this graph is:

The count of Stories done per Sprint

Teams output can vary a lot, depending on unknowns, sickness, vacation and input.
Also stories can be quite different in size and complexity.
Here is the distribution of the stories for this 12 month project.
The average of all the 191 Stories done in all the sprints was 8,91.
The majority of all stories was 8 or 13.
Now you might wonder, why this team still had story points? #NoEstimate tells you to get rid of estimations, right? Story points were here used to tell apart big stories from properly sized ones. A story with 40 story points never made it into a sprint but was splitted in at least 2-3 smaller stories.
What you want to have for #NoEstimates is small stories that can be done in 2-3 days.

Stories done per Sprint

With  average sized stories the secret of this approach starts to work.
You are able to calculate the average of stories done per sprint to use it in the forecast of when you will be done.
As you can see in the graphic below the number of items done per sprint stabilises as the team stabilised and the collaboration got better.

The full journey

Now with all this information I was able to talk about scope, deadlines and re-plan the whole thing.
As you can see in the picture below there were regular corrections on the scope as well as on the go live date. If you can tell a customer, you won’t be able to get all of the scope Sprint 16 but we can deliver it after Sprint 19 do you want to keep the Scope and get it later or de-scope and get it earlier, you can have much better informed decisions.

What is the difference between Estimating and this approach?

Let me come back to the initial story of having the initial backlog completely estimated which resulted in a total of 1000 story points for all the things to do.
  • Over the course of the project many stories that were initially estimated as 20 story points literally “exploded” to 5-6 stories of 8-13 story points
  • Almost none of the stories were underestimated
  • A lot of stories that have been estimated were no longer needed
  • 6 months later of the initially estimated 1000 story points a whooping total of 1685 story points were finished, which is a deviation of 60%, which is actually not that bad for an estimation but would have been disastrous for the Go-Live of the project
  • Estimating costs time and money, in this example the initial estimated was more than one full week for one person and for it to be meaningful you would have to re-estimate after every sprint
  • Estimating doesn’t deliver value, no story is delivered by it, no customer would ever pay for it
Counting done Stories is much easier and much more precise than using estimates.
And much more important: it’s based on empirical data rather than weak attempts to predict the future.

All you can do is manage Scope

What I’ve learned from all the previous products and teams that I’ve worked with is that the only reliable way to ensure that a project or product Release is on time is to actively, aggressively and well-informed manage the scope.
Please have a look at the blue scope line in the “Release Progress over time”to see how the scope changed over the course of the project.
  • You can’t speed up teams by incentivising them or using the whip on them
  • The more people you add to the project the later it gets
  • Variability will bite you in the ass every time there is a chance for it

Before you start your next Project/Release

Think about what you already know about the work that lies ahead of you.
If it has many unknowns, but you have a stable team that worked together for some time and also a PO who knows how to slice the work you might want to start this new way of doing projects.
It will give you much clearer information and removes the hassle of doing the big specification up-front.
In case you want to learn more please read this and other blog posts of my good friend and mentor Vasco Duarte: The No Estimates principle: The importance of knowing when you are wrong
If you have questions on how to implement the approach feel free to add a comment or write me on Twitter @MrSnow76.
Thx for reading,
Sven Schnee aka MrSnow76