Being Cellfish : Agile

Definition of mocking

cellfish — Thu, 29 Oct 2009 04:40:00 GMT

When I read what Uncle Bob wrote today about how he usually hand-rolls his mocks it not only stirred up trouble. It also reminded me of why I hate the mock vs not mocking debate. First of all there is a clear difference in what people mean when they talk about mocking. I kind of covered it earlier but here is a recap; Either you mean you're using mock objects or you're using a mocking framework. Most often people mean the latter. And there shouldn't be a religious debate over this because most people would agree that you should always use the best tool for each task. No tool can be used for everything. Also the definition of done is pretty common in the agile world (where I think mocking is used more than outside the agile world) and if we think having a clear understanding of what done means, we should also remember to make sure we define what we're talking about before we get all excited and start argument for either side.

That said I can only say what I think (again). Mocks are powerful and can easily be used wrong (see link to my previous post above). The use of mocking frameworks also tends to make the code harder to understand, sometimes for everybody and sometimes only to people who aren't familiar with the framework syntax. That is an important point to me. Tests should always be easy to understand and to me that means hand-rolling mocks most of the time.

Five reasons to shorten your sprints

cellfish — Mon, 26 Oct 2009 17:26:00 GMT

I've been involved in a few discussion on iteration length lately and was going to write something about it, but it turns out I don't really have to... Since it would more or less be a repetition of this. So sorry, there will not be a list of five reasons to shorten your iterations here... But I would like to add one thing. Scrum is not a silver bullet. Scrum helps getting surfacing problems and if you think the length of the sprint makes something cumbersome you should shorten the sprint because the more it hurts, the more likely you are to address the real problem and fix it. Souse this rule of thumb (not only for sprint length): If it hurts, make it hurt some more. That way you have a good incentive to fix it.

Never convert your story points to time!

cellfish — Fri, 23 Oct 2009 17:23:00 GMT

When I read these observations on estimations I was reminded of a thing that happened to me a few years ago. The team I worked with started out doing story point estimates and then breaking everything down in the iteration into hours. After the first iteration the team know that X points equaled Y hours. Turned out that X=10Y. When planning the second iteration that knowledge was used to "verify the hour estimates" and sure enough it unveiled a few tasks the team had forgotten during planning. So it all looked like a great way for the team to make sure they didn't miss some important part when breaking down user stories into tasks during sprint planning. At the time for iteration three the story points were no longer used because the team felt it was just an annoying double bookkeeping and everybody knew that one point was ten hours anyway. From that day forward the team consistently under estimated their work. This team did not have the time to establish a track record as the team described in the link above but they also never had a chance I think. Estimating software development in time is very hard and the amount of time you spend on making the estimates does not necessarily improve the estimate with the same factor. Add to that what I wrote earlier this week indicating that the size is more or less useless and only the number of things are important.

But in the defense of time estimates, it is not really the time that is the problem, it is the lack of learning from the past and using historical data to predict the future. I was personally once part of a project involving around 20 developers for one year. Turned out the amount of work it took to complete that project was one man-month less than the initial estimate (i.e. less than 0.5% over estimated). The reason for this? The project manager and key developers had developed virtually the same application for another customer a few years earlier... But that is in my opinion a very expensive way to do estimates so I prefer spending as little time as possible on actually estimating things and more time on understanding the user stories and completing them.

How many t-shirts in your next iteration?

cellfish — Wed, 21 Oct 2009 17:21:00 GMT

So considering my last post on t-shirt sizes and burn-downs, how do you decide on how many t-shirts to take on in the next iteration? If you assign some value to each size I guess it is easy since you have your velocity to use. But I heard another interesting thing from a guy I worked with the other day. He had been on a team where they did not assign any number to their t-shirt sizes. They just expressed their velocity in terms of how many user stories of each size they could make in each iteration. For example they might have had a velocity of "2L, 1M, 1S" meaning that in each iteration they tried to complete two large, one medium and one small task. I like this idea since it is simple. And easy to adjust. When you realize you don't have that many large user stories left but a bunch of medium ones, just try a new mix and adjust until you know your new velocity (which might be 1L, 3M, 2S).

How to burn down estimates in t-shirt sizes

cellfish — Tue, 20 Oct 2009 04:09:00 GMT

Some people estimate their user stories is t-shirt sizes, i.e. each story is either small, medium or large. But how do you create a burn-down chart for these estimates in order to estimate when you will be done? I guess a very common way is to assign some kind of number to each size. But what number? I know that one person used 1-2-3 (i.e.S=1, M=2, L=3). Let's assume that you are completing tasks in more or less random order, and random size (but more big tasks than small tasks) then the burn-down might look like this after 10 iterations.

From this burn-down we can see that we will need slightly less than 21 iterations to complete all user stories if the trend is correct. But what if the size difference is wrong? What if a medium is three times as big as a small user story and large is five times the size of a small story?

This is the same question another Microsoft developer got when showing some co-workers how burn-downs could be used to estimate project completion. So this person took the actual data he had and changed the values to 1-3-5. Interestingly enough the result was almost the same. I did the same thing on my random data and the estimated number of iterations needed is about the same as you can see here.

So this made that developer think... Maybe the values representing t-shirt sizes does not matter all that much so he gave all sizes the same value; one. I.e. the burn-down basically represented the number of remaining user stories. Funny enough it turned out that the estimated number of iterations needed to complete them all was again very close the the first estimate. Using my random data you can see that it would take exactly 21 iterations to complete all user stories.

Back to that developer that inspired me to write this. He finished the project and it turns out that the actual number of iterations needed to complete all stories was also very close to all estimates made when half the stories were completed. If I remember correctly they turned out be all be within 5% of the final number. And being 5% wrong on estimates is way better than most people I know when trying to estimate in hours, days or weeks instead of looking at the velocity of the team.

Since I had the data I could not resist making a few more tweaks to the graph. Not surprisingly using 1-2-4 is very similar to 1-2-3. Same for using preferred numbers (my data using start of R5 series (1-1.6-2.5)). Made me think... What about values in totally different ballparks so I used 1-10-100 (i.e. Large being 100 times bigger than a small task). Interestingly enough the estimated number of iterations turned out to be slightly less than 20 in the burn-down. And reversing the values (using 5-3-1, i.e. small is biggest task) gives us an estimate of just over 22 iterations.

So is it safe to draw the conclusion that size of tasks does not really matter in your burn-downs? Is it safe to say that the number of user stories is enough? In my opinion; yes. Yes in theory you may complete only big or small tasks in the beginning saving the other type for last which would make your early estimates wrong if you do not take size in to account. But I don't think teams typically work in this way. There will be a mix of small and big tasks in each iteration. I would compare this to quick-sort. Quick-sort is pretty bad for the worst case scenario but pretty decent on average. I would say the same goes for using burn-downs where you ignore the size of user stories. And the benefit is that you do not have to spend time doing estimates. Just focus on completing those user stories delivering value to your customer because having no sizes is probably good enough.

Software development at the fish market

cellfish — Mon, 12 Oct 2009 08:40:00 GMT

The Fish market at Pike place is famous for its flying fish. I was there this weekend for the second time in a few weeks (benefit from having friends and family visiting from Sweden). But it is not the flying fish that make the show interesting I think. It is how the crew is shouting all orders out and get it repeated by the rest of the crew. Most people watching probably just think it is a funny detail in the show. Some might know that it started as a prank only. But what it really is is a great way of making sure everybody involved (the employees) know what the order is and what is going to happen; i.e. what fish will be thrown where. Made me think again about one of my old comparisons between software development and the military. The same thing is used in the army to make sure orders (and important information) are heard by everybody. The fact that an order is repeated is also not only good to make the order heard by everybody, it is also an acknowledgment of that the order has been heard. So when the order maker hears the order repeated he knows it have been heard.

So what about the title; software development at the fish market? Well actually nothing more than I think people in the software business repeat things much too rarely. Not only small things that can be quickly repeated but all kinds of feedback and instructions benefit from being repeated. Think about it. Each time you ask somebody to help you with something, does it turn out as you expected? Probably not. And you either think the other person is stupid or you blame yourself for being unclear. In my experience people are not stupid in general. It is you who are being unclear because the other person has a different set of reference points to what you want them to do. The best thing to make sure somebody understands what you mean is to ask them to repeat,in their own words, what you just said. But don't forget to do the same thing when somebody asks you to do something...

Adding days to an iteration (sprint)

cellfish — Sun, 04 Oct 2009 06:41:00 GMT

In Scrum you never extend a sprint. Read that again. Never. So why do some teams extend their sprint a few days sometimes?

I think the most common reason is there is some functionality that is almost done and it feels better delivering "in a few days" rather than "at end of next sprint". Might even be so that there is a dependency or hard date deadline that needs to be met. I think this usually is an invalid argument. I don't think Scrum says you're forbidden to deliver things to the customer in the middle of sprints. If you really need/want to deliver before the end of the next sprint, do the planning so that you deliver something after a few days in the new sprint instead of extending the sprint.

Another reason I've seen is that the team have miscalculated the number of working days they could have anticipated (holidays, team events) and some they couldn't anticipate (power outages). The reasoning here is that "planning was for X days and since we missed Y we should extend Y working days". At first glance I think this looks OK. The team is just trying to keep the sprint length consistent. But if you look deeper I think this is also wrong. The team is not looking at the root cause and learning from the failure (i.e. make sure to take holidays and team events into account). Also this is no different than if there is a flu going so that most of the team is sick a few days during a sprint.

Changing the end date for a sprint also introduces another problem. What the team has planned outside work. Personally I tend to plan things like dentist appointments and other meetings during the sprints since I'm more flexible during the sprint. It is my choice if I have to go out for a few hours during the day and I can decide myself to make up for that time in the morning or evening. But between sprints my working day is not that flexible since it typically involves a number of planning and retrospective meetings. Even when I have several days between sprints they tend to fill up quickly with all sorts of meetings. So when the end date changes it is a high probability that some plans I've made for the beginning of the next sprint need to be changed too since it is now in a day between sprints.

So what if there is nothing outside work that needs to be rescheduled and adding another day to the sprint means the ability to deliver something much wanted to the customer. Isn't it worth it? Once? I think you should be pragmatic but in this case I think there are more pedagogic ways to handle this. Handle it as the failure it is, analyzing what went wrong and come up with a plan on how to avoid it next time. Then then take one or two days just focusing on the thing that is so much wanted. This way you are less likely to just accept and forget the failure just because everyone agreed it was a good idea to extend the sprint. And if you find yourself often in this situation, sprints may not be suitable for you. Something like Kanban might be more appropriate for you.

Second Generation Lean Product Development

cellfish — Thu, 10 Sep 2009 06:10:00 GMT

I just finished a nice book on lean software development. I actually started to read it because one acquaintance of mine is quoted in the book. But it turned out to be a really good book covering economic aspects as well as the regular lean topics. A pleasant surprise was that the last chapter covers the topic of balancing centralised and decentralised control and as an example the author uses the USMC. So it looks like I'm not the only person that's collecting things we (as software developers) can learn from the military.

Anyway, I think this book you should read if you have a leading role (CEO, CTO, product owner, coach etc) in your company. It might not be valueble to everybody in the organization (for example junior developers) but it definitly have some good pointsfor everybody.

What does commit mean?

cellfish — Sun, 26 Jul 2009 17:26:00 GMT

I was involved in a discussion on what it means when a team commits to something. In this particular case one person thought that it meant the team will do what it takes to deliver this. I on the other hand I meant the team thinks it can deliver all this and will try to do it. A big difference. Yesterday I read an interesting post on this topic. I like how he talks about soft and hard commitments and this was exactly what I think the difference was in the argument I was involved in. I was thinking soft commitments, the other person hard commitments. And I must agree that in my ears commitment by default sounds hard.

One thing I don't quite agree with in that blog post however is that Kanban a no-commitment framework. It may look like that on the surface but I doubt a team doing Kanban where there is no real team spirit will do a very good job. So even though Kanban does not prescribe any kind of commitments it self, the kind of soft commitments that are mentioned, i.e. an emotional commitment to the team is essential to be successful in my opinion.

And the same kind of argument goes for Scrum I guess. I do not think scrum prescribes any kind of hard commitments. Only bad implementations of Scrum have a PO that demands hard commitments and teams working with hard commitments will also not be very successful over time. This is also mentioned in the blog post linked above so I'm not really disagreeing. I just think that well implemented Scrum is already in the "soft commitment only area" of the graph.

So I guess the conclusion you can draw from all this is that you'll get better results with only soft commitments. And that is hardly any news. Teams that work well together can perform well under most conditions. And teams with no cooperation will probably fail under all circumstances. So getting the team to work well together should be your absolute top priority. And also the use of words are important. Choose your words carefully and make sure that everybody has the same understanding of what a certain word means.

On pride and improvements

cellfish — Sun, 19 Jul 2009 17:19:00 GMT

So yesterday I wrote about being proud about what you do, but also improving yourself. It made me think about a pretty scary thing that happened to me a few months ago. I was attending this training where we were divided into four teams and worked together for a few days to create an application. At the end of the class at the retrospect I suggested that in future classes each team could present some part of their solution they were proud of and wanted to show to the rest of the class. I said this because I thought my team had learned something and had done a few smart things that I wanted to share. We had some time to spare so the trainer suggested I show what I was thinking about and then the other teams could do the same thing.

So I showed our stuff and then no other team wanted to show anything. Maybe I'm a little extreme in my search for improvements and maybe I'm over confident in the excellence of our solution but in a room of 25 people I would assume at least somebody felt the same way about something. I don't believe they were all shy. Instead the class went silent and everybody went home. The thing that really scares me is that I think that there is a good chance that the reason for not wanting to show anything actually was that the other teams didn't feel proud about their solution as a whole. Because there was an element of competition there and it's easy to get carried away because it's not real code in the class room...

Finally I must point out that I do not think you have to do the ultimate solution each time to be proud of your work. I'm sure a master chef sometimes throws together something fast when at home. But I think the mast chef quick lunch probably tastes better than my quick lunch. So the effort needed to be proud might be different for different situations but that hunger for improvements is definitely something I think differentiates the good from the great. So if you do not take pride in anything else, at least take pride in striving to be better and be proud of each improvement.

Do you want to do a good job or do you want to go home?

cellfish — Sat, 18 Jul 2009 17:18:00 GMT

A former colleague once said that there are only two types of people; those who want to do a good job and those who want to go home. And it has nothing to do with working over time. The statement is obviously provocative but you should not interpret it literally I think. What it means is that some people go to work, do what they're asked and then go home without necessarily having a passion for what they do. Others are very passionate about what they do and go to work because they love what they do there.

This to me is just another way of describing software craftsmanship which is being more and more popular lately. And think there are two important aspects of craftsmanship to consider. One is the integrity of being a craftsman. If you want to do a good job you should refuse to do something that you think is a poor solution. Compare yourself with a great chef. A great chef would never serve you something that is not prepared and presented in an excellent way. If you on the other hand just want to go home, just do whatever you need to get home early.

The other aspect is being proud of what you do. It doesn't mean you have to be proud of code you wrote a year ago or even a few months ago. I've written code I wasn't proud of even a few weeks later. The important part is that you're proud of what you do at least when you write the code. I'd even say that it's a good thing that you're not proud of old things you've done because it means you've improved yourself and that is important. If you however just want to go home, then you're probably not always feel proud about stuff you just did and you're probably proud over things you did ages ago. Because if you just strive to go home then you're probably not improving yourself very fast.

Military decision making

cellfish — Thu, 16 Jul 2009 08:30:00 GMT

So I have another comparison between the military and agile and in this case it's lean specifically. Lean prescribes making decisions as late as possible but sometimes it's hard to know when it's time to make a decision. In the military my last company commander taught me a rule he thought work well. It was the one third rule. The rule is that each commander have a third of the time available to prepare and give orders. The rest of the time is needed by the subordinates to execute the order. This means that if there is something that has to be done in one hour the company commander can use 20 minutes of that. Each platoon then have 40 minutes of which the platoon commander should use 13 minutes. Of the remaining 27 minutes the squad leader should use nine minutes to prepare the squad leaving 18 minutes to execute the order.

So this to me sounds very much like a waterfall because of the different levels involved and the 18 minute execution time out of one hour does not sound that efficient. The rule is not really a rule but more of a rule of thumb. I think the important lesson from this is that you should not make a hasty decision just because you're pressed for time. Instead set a time limit, gather as much information s you can and then make your decision. Another important lesson is that you must allow enough time to complete the order. So consider the thing that needs to be done in one hour. Assume you, as a company commander, knows that it takes 40 minutes to complete. So there is only 20 minutes of preparation and the company commander can only use one third of it. That's about seven minutes. The platoon commander get four minutes (one third of 13). The squad leader get three minutes to give orders and the squad get six minutes to prepare.

So far this is hardly revolutionary. Essentially the military decision making process states that you should gather as much intelligence as possible before making a decision (same as lean) and make sure there is enough time to complete whatever decision you make. Also if there is no hard deadline, set a deadline and make a decision.

Another important part about military decision making is that it's important to make a decision. Because acting is better that reacting. In the military you want to keep the initiative because the one who has the initiative will win. The essence is that it's better to make a decision now than the perfect decision later. And you must also know that you're making a decision that you may have to change later when you have more information. So you're essentially improving your decision iteratively. All this is sounds very lean in my ears.

I think good decisions makers make informed decisions. But they do not try to make the perfect decision and are prepared to change their decision when new facts are available. And they make sure there is enough time to complete what needs to be done. And I think being a great decision maker is really hard since it involves balancing between waiting and not waiting for more information.

Pair programming in the army

cellfish — Sun, 12 Jul 2009 07:33:00 GMT

I've lately been thinking about more things that the military do that is either something agile teams typically do or something agile teams can learn from. So one thing I've been missing in my day to day work lately is how I, as a platoon commander, worked with my platoon sergeant (i.e. the person second in command in the platoon). As platoon commander I gave orders for some activity and the platoon sergeant then lead the work and sorted out all the details while I planed our next activity. When in combat me and my platoon sergeant worked a little different. In combat the platoon commander leads the main force focusing on the most important target. The platoon sergeant leads any supporting missions such as outflanks or suppressive fire to support the main force. This type of cooperation is not seen at platoon level only. The same type of cooperation between the two commanders are seen from squad level all the way up to the supreme commander.

The same type of cooperation I experienced in the military is what I see when I do pair programming. The only difference is that there is no commander. The commander role switches all the time. There is two ways to see this. Either the person at the keyboard is the platoon sergeant carrying out the last order (i.e. making a failing test pass or refactoring). In the mean time the person not at the keyboard is thinking about the next step. Or the person at the keyboard is leading the most important part of the mission (making a failing test pass or refactoring) while the platoon sergeant next to him do supportive tasks.

Either way you look at it the way a squad, platoon or company is lead by its commanders is very similar to how pair programming works. And if that is very similar then we should be able to compare how things work when you're not doing pair programming. If I lost my platoon sergeant and did not appoint a new one my work as a platoon commander became much more cumbersome and less fun. Also I tended to make more mistakes and wrong decisions when I did not have my platoon sergeant to help me out with practical things nor having him as somebody to discuss possible solutions with. And I think the same applies to not doing pair programming. You tend to make worse design decisions and more mistakes if you sit by your self all day. Naturally you can get some of the synergies without pair programming if you make sure you discuss all design decisions with somebody. But pair programming will give it to you auto-magically in both big and small decisions.

Remember why you make estimates

cellfish — Mon, 06 Jul 2009 07:21:00 GMT

Dan North recently wrote about a situation I regretfully recognize too well. Imagine you're asked to take a number of user stories and estimate them using story points. You spend some time breaking the stories up and start estimating and then you get the question; so how much can be done in one year? You respond it is impossible to know since you don't know your velocity yet. And so everybody is frustrated. The customer have no idea and thinks story points is stupid because it doesn't help him. And you feel frustrated because the customer didn't tell you in the first place that he wanted to know how much could be done in one year.

I believe the use of story points is good since people don't estimate in time very well. The relative nature of story points and velocity is in my opinion a better way of updating release plans over time. So the effort is not wasted. And after a few iterations the customer will be happy about story points. But you have to do something else in the beginning. I favor making really rough estimates in man-months or man-iterations and using that as an indicator to the customer about the release plan for the next year. But I also tell the customer that this is just a rough estimate and as soon as we have our velocity we will have better prediction of the actual content of the release. Personally I also throw the initial estimates (using time) as soon as they have been presented. And I try to make the customer do the same thing.

Three good reasons to make small tasks

cellfish — Thu, 02 Jul 2009 07:05:00 GMT

When talking about Scrum you often hear that the sprint backlog should be broken down into tasks no greater than 16 hours in size. The reasoning behind this, in my opinion is to force the team to breakdown things. I know of several teams that decide on even lower limits. And even if you do not estimate the size in hours because you only burn down the number of tasks in the sprint it is still common to have some kind of guideline for a maximum task size. And there are at least three good reasons to break things down into small things.

In my experience, the more things you break something down into, the larger the total gets. The positive side of this is that things tend to get larger as a whole because when you break things down you remember to take all kinds of small things into account. The only real downside with this is that each estimate will probably include some buffer. On the other hand people generally underestimate things a lot so breaking things up often adds the "buffer needed" to get everything as a whole completed. And I think this is a better way than just having a fudge factor (i.e.multipying everything with some constant) since each task adds value when it says what to do. A fudge factor does not tell you about all the small things to remember.
Jeff Sutherland has pointed out a few times that teams that burn down stories tend to perform better (example). I think the next best thing is burning down the number of remaining tasks. And with smaller tasks you'll get a steady progress each day since each team member will be able to complete one or two tasks each day.This will make the motivation for burning down hours less of an issue since the task number burn down will be virtually identical to an hour burn down with slightly bigger tasks. Also not only the burn down will reveal a flow.
As a team member working with tasks that takes around a day to complete you can find yourself in one of two very stimulating situations. Either you complete a task each day before you go home which leaves you with a nice feeling of satisfaction each day. I personally like this very much since it means I can start with whatever is necessary the next morning, a new task or something else that has come up. The other situation is that you complete a task during the day and starts working on something new. I think this leaves you with the same kind of satisfaction of completion but also the warm feeling of knowing what to start working on the next morning.

There a certainly more reasons for why you should break things down into small tasks and probably a few why you should not do it. Even though I think the key when looking at when not to make small tasks is more of a when thing. Breaking things down into one day tasks and then saving it for half a year and then start working with them is not a good idea.