I don't care what you did yesterday

I have worked in different Agile teams for several years. Some of them have been Scrum teams, some Agile teams in other ways. No matter what methodology the team has used, one practice has been pretty much always there, the daily standups.

During that time I have searched the best way to have daily standups. I'm well aware that there are no best practices, just good practices in different contexts, but still I feel that finally I have found (so far) the optimum way to have daily standups.

Let me show you the path I've walked. The starting point shouldn't be a big surprise for anyone.

The 3 questions

What did you do yesterday? What are you going to do today? Is there anything blocking you? These are the questions that probably most of the Scrum teams all over the world ask every working day from every team member. I find this a very effective way to focus on every day work compared to for example weekly meetings.

However, there is one problem here. Scrum should be team work. If the most often repeated ritual focuses on individuals so heavily, something has to be missing there.

Runners and baton

Some years ago I found a blog post (*) that described different approaches to the daily scrums. One of them was user story focused daily standup. The idea is that we shouldn't "focus on the runners but on the baton". Runners obviously refer to team members and baton to the tasks they do. In other words, if the team is supposed to develop user stories, let's see how the stories have progressed, how we plan to advance them today, and if there is something that prevents us from developing them.

The idea resonated a lot to me and I have tried it at least with three different teams, one of them being my current team. The problem is that it never felt natural for the team members in any of those teams. It was quite hard for people to follow what task we were talking about right now and what next. To make this work in practice, there had to be someone who facilitates the meeting. But if you need someone to do that for this simple 15 minutes standup, there must be again something wrong with the method.

What eventually happened in the teams was that we returned back to the basic individual-focused method. I just had to accept that because I didn't have anything better to offer. However, I still felt that there must be something better, I just didn't know what that was.

Making our goals explicit

A couple of months ago I was thinking that it would help our team if we wrote our goals to our board. There were two reasons for this. First of all, when you write something down, you are making implicit explicit. It wasn't always so obvious for us what the team's goals actually were, so this forced us and especially our Product Owner to think about them. Second, when everybody sees the goals all the time, they become stronger. It's much easier to try to reach the goals when they are just in front of your eyes all the time.

Goal-based daily standups

When the goals had been in the board for a couple of days, I finally got it. Even though we hadn't yet even tried, I was convinced that this was the missing thing to make really good daily standups. So I asked our team that could we run the standups so that we just forget the individuals and focus on goals. The basic idea was that we go the goals through one by one and whoever has anything to say to the goal we are talking about can say whatever she wants to say. After all goals had been walked through, people could bring up all the other relevant things that hadn't been mentioned yet.

At this point it may be relevant to notice that we are typically having 4-5 goals at the same time. In the most optimum situation there would be only one goal at a time, and our team would try to get there as fast as possible. However, our work is such that for example the first goal is to help some other teams to reach their own goals. In practice this means that whenever they have new needs that we can fulfil, we do that with the highest priority. Otherwise that goal just hangs out there and we can skip it in the standup. There can be also upcoming goals typically in the position #4 or #5 to tell us what will come next. Even though there may not be programming tasks going on related to these goals, there may be e.g. planning happening and someone in the team can share with others how it is progressing.


Our current goals. #1 is about helping the other teams. #2 and #4 are active in some level. #3 and #5 are new goals that were added today and will become more active when e.g. #2 gets done.

The new setup has worked really well for us. We use the most of the 15 minutes for the things that matter most for us. There is always something else but that stays on minority. I could say that typically it takes about 10 minutes to check the status of the goals and 2-5 minutes for the other things.

You could say that the things we talk about on goal-based standups are mostly the same that we would talk on individual-based standups. However, I find that there is a very important difference on the perspective. It really doesn't matter what you did yesterday or what you are going to do today. What truly matters is what we together have done for the goals and what we together are going to do them today.

Revealing problem with our focus

Some time ago the goal-based daily standups revealed a problem we had. I realised that even though we talked about only 5 minutes about the goals, our standups could easily take 20-25 minutes. This meant that most of our focus was in the work that wasn't actually our highest priority. (And besides that, we weren't very efficient when talking about it.) In other words, our goals were listed but the tasks we were working with were mostly related to something else. After realising this we had a good discussion with the team and we were able to solve the problem. Since then the situation has been much better.

In order to emphasise this we have a small sticker next to each goal (see the photo above). Each task then has the same sticker on the whiteboard. This helps us to see that the majority of the tasks either in progress or coming next are related to the goals.

Summary

Very typically agile teams benefit from having a short standup meeting every day. However, the traditional daily scrum format is very individual-focused and can easily forget the team and goal aspects. Instead of that, write your current goals down and put them visible for everyone (e.g. on whiteboard). Then on daily standups do not go through each team member but go through each goal.



(*) I was not able to find the original blog post anymore but the content of this one looks very similar to me, even though this one is dated to 2016: http://martinfowler.com/articles/itsNotJustStandingUp.html

#NoEstimates - not for Big companies

I was having a #NoEstimates presentation about two weeks ago in Agilia 2015, Brno. Really nice conference, lot of interesting discussions. A week ago I got feedback from my talk, collected by the organizers. It was mainly really positive, like this one: "great content, this is what I remember the most from this conference".

One feedback comment however was very interesting:

Very valuable presentation. One thing that I didn't like were the examples, that safely ignored challenges of big organizations and big projects. Henri seems to be working in an environment where #NE seems to be simple. Good luck in trying that in 1k+ employees company.

I'm writing this post since I definitely wanted to reply to the feedback. But before that, let's go back in time a bit.

Agile - not for Big companies

When I heard about Agile software development for the first time, there seemed to be some kind of consensus that Agile is not for big companies or for big projects. The more I read about Agile, the more this confused me. Why wouldn't big companies benefit from things like: faster feedback, ability to respond to the inevitable change, better collaboration between stakeholders, emphasis on working software, focus on the value, attention to continuous improvement, etc?

I never got good answer to this, so I never accepted the "fact" that Agile is not for big companies. And look at the big ones now: everybody wants to do Agile, everybody wants to be agile.

#NoEstimates - only for small?

So let's get back to #NoEstimates and to the feedback. First, if we look at the Woody Zuill's definition (see also this blog post), #NoEstimates is about exploring alternatives to estimates in software development. What this means is that people interested in this topic are thinking critically whether we need estimates in the cases where we use them now, and thinking how we could face the same situations more effectively. Again, I don't see how the big companies couldn't do the same?

Second, I am not doing this in small companies only. When I experimented with #NoEstimates ideas for the first time (then without the hashtag), it was in a small university project. But after that the next company was a very big one, currently having ab. 27 000 employees. My current client has ab. 7 600 employees. Not small ones, right? In between I've worked also for much smaller companies.

Of course not all of the employees in those companies work in the same project. But my work history also contains a company that had over thousand employees working for the same product. There I saw teams that were applying many ideas from #NoEstimates thinking. I saw teams that were using story points without any real need for that. I saw teams that stopped needless estimation. I also saw a huge project that surely had had many kinds of estimates along the way but quite questionable benefits from them.

Seems to be simple

As the last point I would like to thank the feedback giver for the great compliment. He or she said: "Henri seems to be working in an environment where #NE seems to be simple". I say it's a great compliment because when something complex seems to be simple, you have succeeded in something. Either by making difficult things simple or by being able to present them clearly.

The truth is that things haven't been simple, my very first blog post tells one story about it. It took about 1.5 years for the team to get to the point where estimates became irrelevant. And that journey was far from simple and easy.

Along the way I have spent lot of time for thinking about the concepts I have presented in conferences like Agilia 2015. For me many of the things really feel simple, and of course there are still many things that I struggle with. Anyway, it's good to remember that simple does not mean easy. The current project I work in is a good example of that. I may write more about it some day.

#NoEstimates - Alternative to Estimate-Driven Software Development

Free software development magazine Methods & Tools has published my #NoEstimates article in its Spring 2015 Magazine.

The title of the article is: #NoEstimates - Alternative to Estimate-Driven Software Development.

Comments

If you would like to comment the article, you can do it here in this blog post.

Other posts

If you liked the article, you may want to read my #NoEstimates blog posts.

95 excuses

1. A software developer wasn't happy about the work he was doing. To be precise he wasn't happy about the system he was working in. He knew the concept of a system since he had read books from great minds like William Edwards Deming. Especially the developer remembered how it's 95% about the system and 5% about himself. For that reason he felt that he is forced to continue working in this dummy system where his company as a vendor makes stupid promises for customers in order to get deals. So reluctantly he continued doing his work as before.

2. At the same time the sales person of the same company was feeling miserable. She was going to contract negotiations with a new customer. And she was miserable because she felt that the both companies were doing it really wrong, in a way that doesn't benefit either of them. But the sales person had also read Deming and thus remembered how there's probably not much to do since it's 95% about the system.

3. The person responsible for ICT sourcing from the customer's company was also thinking about the upcoming contract negotiations. He didn't like the idea that he should aim for the lowest possible price instead of focusing on more important things in the vendor selection. But of course he wanted to think about the possible bonus he might get if the deal was well-negotiated. And besides, why to bother trying anything else since it's 95% of the system anyway. That's what Deming was saying in his famous quote.

4. The CIO of the company was worried how the big software project that was about to start would go. He didn't have very good experiences about the previous ones and felt that the company needed a radical change in how software projects were to be managed. But at the same time he kind of knew that he couldn't make much a difference because the company culture was supporting the old way. He was thinking what Deming had said and felt being just a small man in this big system. So while walking to the next meeting he thought that maybe it's just better to continue doing job as before.

5. The company's CTO was sitting in her room and felt disappointed. She wanted to change the company into better but it was so difficult. And when she remembered what Deming had said about 95/5, the change felt even more difficult. She saw so many problems in the system her company was part of, starting from the university education. According to her experience the education system wasn't producing such graduates that the real business world needs.

6. At the same time a professor in the university was angry. She was angry because she had to spend too much time on bureaucracy instead of sharing her precious knowledge for the students. While watching the Deming's quote that she had printed to the wall of her room, she knew that it's just better to keep filling the papers because she couldn't change the system anyway.

7. ...

...

95. ... and because of the 95/5 rule the junior football team coach felt that there's not much he can do.


"No, no, no! This is not what I meant!" Deming couldn't believe his eyes while he was watching this miserable play. "How did this happen?" he was wondering. "Please, let me go back there. There's still so much work for me to do!"

No software development standards

Yesterday I had a day-long discussion about standards on Twitter. It all started with Riina's worrying tweet, following with some jokes:

Obviously behind all that was skepticism towards standardizing certain things. But then we moved from joking to more serious discussion when Ari Tanninen commented that "ISO standard for user-centered design isn't half-bad". He gave a link to a presentation that provides more info about BS EN ISO 9241-210:2010. I was still skeptical. I felt that you shouldn't try to standardize software development.

Good software standards

The discussion moved on. When I criticized standardizing software development, I was mentioned about things like SQL and HTTP - and this:

But my point wasn't that. I see a lot of value in software standards. As a web developer I get big benefits myself when browser vendors follow the HTML and CSS standards. Globally speaking, those benefits are gigantic. So yes, IE6(-8) is a sad story and shows what happens when standards are not followed.

However, I'm not against software standards, I'm questioning the need for software development standards.

Let's make Scrum as an ISO standard?

So what if Scrum would become an ISO standard? Companies doing software development would be forced to use it in case they wanted to get certain contracts. Or companies following the standard would have an advantage in competition because they could say how their software development departments are following the standards, which "prove" that they are doing great work.

Well, I like Scrum and I think that it has brought a lot of good to the software development industry. On the other hand, it's about 18 months since I was last time using it. And this doesn't mean that I'd been in a vacation or unemployed the last 18 months. It means that I've been in contexts where doing software in some other way makes more sense.

You probably already picked one keyword from the text, context. Software development is always very context-dependent, which is one important reason why standardizing it is not so good idea. The same argument works also with the proposed testing standard, ISO 29119. Software testing, as part of software development, is also very context-dependent and creating one standard for it is very questionable.

Unfortunately I'm not able to see the testing standard text but for example the contents of the Test Documentation part just scares me. I have worked with big companies and can imagine some horrible scenarios if they would jump into using such a standard.

Why is software development different?

So why some standards, even software standards, bring major benefits (cost savings, increased market share, even environmental benefits) but I'm against them in software development? I already mentioned context as one important reason. But there is more.

Basically I would say that if the aforementioned benefits can be reached by reducing variation, then a standard makes sense. I mean that's what standards are all about, doing a certain thing in a certain way instead of one hundred different ways.

However, in software development the goal is not to reduce variation, like it is for example in manufacturing. Instead, due to the asymmetric economic payoff-funtion, variability gives us a possibility to exploit opportunities. If on the other hand the development is standardized, we miss those opportunities. (Read Donald Reinertsen's book to understand more.)

So please, be very careful when you try to standardize software development. It can be that you haven't understood the very core nature of it.


PS1. A lot has been written about the proposed testing standard ISO 29119. If you are interested to learn more, read for example Stop 29119 by Iain McCowatt, any of these, or this post written in Finnish by Maaret Pyhäjärvi.

PS2. Standards are not my specialty. If you think I've understood something wrong about them, I'm more than happy to receive your feedback.

Cost of delay and artificial deadlines

This is my second cost of delay post, you may want to read Unquantified cost of delay in prioritization first.

How to recognize an artificial deadline using cost of delay?

Business world is full of deadlines. Sometimes they cause unnecessary stress for the employees and for the organization, sometimes they contain a really important message how something cannot be late. So how to know when a deadline is reasonable and when it is artificial?

My claim is simply the following:

If the form of the cost of delay curve does not change near the deadline, the deadline is artificial.

Examples

Let's take a couple of examples.

In this case the deadline is reasonable. If the company misses it, I will lose a big amount of money.

In this case the deadline is questionable. Yes, in the future the company may lose a big amount of money but why is the deadline so early? If the deadline is met, the ready product/feature/etc is waiting in an inventory for a long time. Another possible problem is that the solution is implemented without using the latest available information. This means that in the worst case the solution can be outdated when the real deadline hits.

In this case the deadline is artificial. You can ask why that particular date was selected? Why not week later or week earlier? It is hard to see the reasoning for this deadline. If there are no bigger cost of delay items waiting to be done, this should be just done as soon as possible. If there are, this task is a wrong one to do.

Also in this case the deadline is artificial. Yes, the company is losing money all the time but why not just focus on fixing the problem as soon as possible?

What to do with an artificial deadline?

If I hear a deadline that seems to be artificial, I always ask how the date was decided? It may well be that I'm missing some important information that I didn't know earlier. In that case the deadline isn't artificial and I just learned something relevant. On the other hand if it appears that the date was "just selected", it gives me an opportunity to have a discussion about the concept of cost of delay.

If you can figure out a situation where the cost of delay curve does not change format but deadline still makes sense, I would be interested to hear.

Unquantified cost of delay in prioritization

Cost of delay (CoD) is an old financial tool for evaluating the cost that is assumed to happen when something is delayed. Its importance in (software) development work probably increased remarkably after Donald G. Reinertsen published The Principles of Product Development Flow (at least from my point of view). In his book Reinertsen explains very thoroughly why CoD is a really important metrics and why it can be a valuable tool to be used in prioritization. His principle E3 says:

The Principle of Quantified Cost of Delay: If you only quantify one thing, quantify the cost of delay (p. 31).

What comes to the prioritization, Reinertsen offers for example this simple advice related to CoD:

I'll just give you two simple heuristics: high cost of delay before low cost of delay, and short jobs before long jobs (p. 70).

So basically it's quite a simple thing. Just calculate the CoD like Reinertsen does and decide. But is it really that simple in practice?

Cost of delay without numbers?

As a development team member I'm making many prioritization decisions every week. Obviously I try to make good decisions together with other team members and stakeholders. In theory CoD is almost all I need but in practice there's a big challenge how to quantify it. Either the numbers aren't available or it is not cost effective to get them. I suppose that Antti is facing the same problem and for that reason doesn't know how to utilize CoD in his work.

Fortunately it is still possible to use CoD in prioritization even though we wouldn't have numbers available. The key is to understand the different types of CoDs.

Example

This is quite a recent example and related to the original tweet. We had to decide whether to implement feature A or feature B first.

The company was about to start a print marketing campaign. The question was: should they include the feature A to the marketing material or not? Obviously if they mention about it, the feature has to be ready when the campaign is out. If they do not mention it, there's no hurry with building the feature but then they miss an opportunity to sell the feature for the potential customers during the campaign.

The feature B on the other hand was more of a "regular" feature. There was no marketing campaign related to it, nor any seasonal specialties.

Without having any numbers available, I was immediately thinking how the CoD curves would look like in each case:

 

Cost of Delay - Feature A

 

Cost of Delay - Feature B

The feature A has a cost of delay that is clearly related to the marketing campaign. The cost here is the lost additional sales that the campaign would probably bring to the company. The feature B has no such attribute. The lost sales (or satisfaction of the current customers or some other value) increases steadily among the time. Based on this we decided to prioritize so that we build feature A before B so that the company would not lose the opportunity window that would be open during the campaign.

Is shape enough, don't absolute numbers matter?

There is a reasonable question flying in the air. Are you sure that the curve for the feature A is above the other curve? In other words, how can you be sure that when combined, the curves don't look like this?

 

Possible cost of delays

My answer is that we cannot know for sure. But we have some hints that we can look at. The implementation of both features has been delayed already for quite a long time. If the CoD curve of the feature B would be very steep, the feature would have been probably implemented a long time ago. We can reasonably assume that since both features have been approximately at the same height in the backlog, their business value is pretty much the same. Now it just happens to be so that feature A fits very well for the marketing campaign that is about to be started. And the campaign starts no matter whether this particular feature is ready or not.

Classes of services

Another person who has popularized CoD in software development is David J. Anderson with his Kanban: Successful Evolutionary Change for Your Technology Business book. (Btw, check who has written the foreword for the book.) Anderson talks about classes of services - expedite, fixed date, standard, and intangible - and relates them to the different kind of CoD curves.

I'm not going to talk about more of them in this post, you could read e.g. Andy Carmichael's excellent blog post Selecting Backlog Items By Cost of Delay. Another post worth to mention is Mike Burrows' Kanban prioritisation and scheduling with classes of service. Nevertheless, I think that understanding those classes helps you in using CoD in your daily work, even without quantifying the cost.

Summary

I would like to emphasize that I'm not trying to understate the importance of quantifying CoD. And I really like how Reinertsen highlights that our decisions should be based on quantifiable economics instead of e.g. gut feelings. However, in real life the available data is very often insufficient and getting better data isn't necessarily cost effective. Still you need to make decisions and you try to do them as well as possible. In those cases it helps if you understand the principles of CoD, even when you decide not to quantify it.

Another point of view is that in agile software development we try to make many small decisions over the time instead of few big ones in the beginning. Then it doesn't matter so much if the decisions made are wrong because we can usually fix them rather quickly. In that kind of world using too much time on getting exact information isn't necessarily justified.

Obviously the bigger the impact of the decision is going to be, the more you should invest in making better analysis of the situation and actually quantify the CoD. And you can always think how you could improve your system so that relevant data could be available for the smaller decisions as well.