Finishing the race

Just turned Product Owner and there by leaving the sweet safety of the scrum team, I've gotten a better view at what is the hard core challenge with agile development. So, what is the challenge? Well, seeing to that the right stuff gets installed on the user's working environment and seeing to that the wrong stuff don't end up there. Well, that's easy, isn't it? Well, it's not. And like with a Marathon, it's not the first 30k that makes you a Marathon runner, it's the 4,2+ k. Every centimeter counts. Every centimeter. It doesn't help if you're the best the first miles if you're not making it to the finish line. And the right finish line. For the right race.

So, how do you get there? Well, like with a Marathon, you have to prepare. Set a pace. It's no use that before starting to train setting up a full schedule a year in advance. You get sick, you change your plans. But you need to set up a pace, decide how you're going to accomplish the goals. Etc. And you have to decide on the right pace. If you've never run before going for the under 2 hours schedule is probably a very bad idea. You also need the right stuff. Good shoes, for one. You probably don't need the best shoes in the world. But they should work for your schedule.

And then you start running. Following the decided schedule. Evaluating and think if you're moving in the right direction. Changing the schedule can be a good thing but if you half through the schedule decide on doing a cycling race instead, you've probably invested time and money on things you won't need. If accidents happen, you adapt and learn. And so you build your strength.

Racing day. Time to deliver. First, you need to get to the start line. Be on time, be prepared. Preparation never makes you finish a race, but the lack of it results in failure. And you run, you learn and you adopt. And if all goes well, if there are no accidents and if you're fully prepared, you come to the finish line. That is the way it is. And standing there, on the right side of the finish line was what you wanted. They you just want to prepare for the next race.

The time warps of agile development

All trekkies have seen the shows where there's some time loop or a time fold, which results in some fantastic plot. I guess the ideas cannot be completely discarded in this amazing universe, but I don't think it applies to every day life and I don not think that agile development results in time warps. But sometimes I get the feeling that stakeholders believe that. What am I babbling about? Well, of course: changes in priority. Let say we have the following features:
A
B
C
D

And they are prioritized in that order. What happens and what is a natural part of an agile project is that story G is introduced and the stakeholders get the product owner to fit that between B and C. So what happens, well all the time spent preparing C and D becomes waste for yet some few more sprints. They might also become more complex, since story G might be something that adds complexity to the thing. So, the end result is that schedule is prolonged. It takes longer time to accomplish. The duration increases. Simple mathematics, but if you don't say that to stakeholders, it's like they think that the new priority does not affect everything else. I do wish I had Data and the crew on my team, but I don't. So, until then I'll just have to make everyone realize we're still on planet Earth.

The difference between having a role and a title

When using Scrum as a development method, one of the really nice things is the usage of roles. Being the product owner is like being cast to a role in a play. And as important it is to the theatre to be able to have stand-ins, we need it too. When I was a kid they set up a local play in the village where I grew up. It was focused around a local celebrity and the set was huge. Half through the schedule, the guy got sick and half of the shows were cancelled: since everything was built around it being HIM doing the show, it was no use when he wasn't there. Of course, if you're going to a concert, you go to see those guys. But when it comes to theatre or software development: this is stupid.

Last week I was rushed off to the ER. Something that was not wholly unexpected due to my previous problems, but it wasn't planned and it came at a really bad time. But since it's only roles I could talk to one of the guys and give him the role instead. He started talking about being a Product Owner Proxy but that is not an option: a scrum project need a product owner. Someone who takes his own decisions and doesn't hide behind someone who's not there. Not fair to the others, not fair to him and not fair to me. Now, he might be a really good guy and that is why it works out so well, but I do believe it is important to just let go of a role when you're not there. Of course I can say why I've taken some decisions and I can give advice. But as long as I'm not there, I'm not the product owner.

Pain is temporary...

Sorry I haven't written lately but yesterday was the first day in front of the computer for almost a week. If you don't count a hand held device. My gall bladder problems got worse and Thursday, I was operated. The previous week was spent in the hospital with pain killers and IV. But now, I'm back in business again. Well, that is, I'm home from work this week. No running for SIX weeks. Well, pain is temporary, in my case. Which I am happy to say. Chronic pain must be a nightmare. I'm just glad to see improvement every day.

The dark force of software development

Yes, a Jedi's strength flows from the Force. But beware of the dark side. Anger, fear, aggression. The dark side of the Force, are they. Easily they flow, quick to join you in a fight. If once you start down the dark path, forever will it dominate your destiny. Consume you, it will... as it did Obi-Wan's apprentice."

―Yoda to Luke Skywalker^[src]

I often return to this citation: if can be used on many aspects of life: when you know something is right but you also believe it to be harder or more complicated to adopt to. With some changes to the actual words: it could be used for describing how a test driven developers views not test driven development. Just as an example.

Starting to build up your technical debt in a software development project is also using the dark forces: fast satisfaction but at a greater cost than you could ever imagine in the long run. And being the stead fast and principle focused product owner, you're in the risk zone of being the Anakin Skywalker turning to Darth Vader. I know the dark guys wears the best costumes in the films and are the funniest. But we want to be the good guys, don't we?

Testing or trying

Tomorrow, we're starting the more structured acceptance testing before our release candidate on Monday. And we're including Testers and Tryers. So, what is the difference? Well, when you have a tester on a team, he works like a doctor with a sickly patient. He goes in a structured way through all the symptoms to find out what works and what doesn't work. He's an expert at finding software related bugs and will report a splendid bug report which my developers will love to work with.

But is the tester a normal user? Well, no! He doesn't work like a normal user and can never say "well, this will work with the user of type two." For this, we need the tryers. They try everything possible and impossible which a user can do in an very unstructured way. This works very well combined with with personas - the tryers should act like a user of a specific kind. Like the mad lady Vera at Customer C, who always double clicks Cancel when ever that button is visible. The tryer is not good at identifying actual software bugs and will never give a report which a developer can work with (other than saying cannot reproduce). But trying as as valid a test method if you use it properly. If the tryers think the customers will benefit from the new version, this is just what we need to know to go ahead with the deployment.

Running after rabbits

It's January 14th, and I'm already starting to wear spring clothes while running my morning runs. It is dark and wet, but it's not winter. The problem is that there are still some icy spots so most of the times I can choose between icy or getting my feet wet. So, no, this is not my favourite running weather. But I can't complain. It means less stuff in the rug sack which I use while running to work.

This morning I spotted a woman on top of the steepest hill on my morning run. A rabbit, I thought. Then NOOOO. No running after rabbits. Since I'm running on an empty stomach, I must be careful and take it slow so I don't push myself to hard: running empty on fuel is not the best way to start a morning. So, I said to myself: don't you try catching her.

But what my inside thought was a completely different story. So, I chased after her. Of course. Well, I was pretty nice and didn't linger in front of her after I'd passed. I just got moving. You might think I felt some kind of pleasure, but I was to tired to even think that. I'd moved to survival mode having 2k left to run. I thought I would die when I got to work. Well, I did not deserve something else, either. But it feels good knowing that the focus on shorter ranges has increased my speed. (well, I do something to put the blame on.)

Sprint planning meeting using TFS

One of our most important lessons during this first year of development is that there can only be one sprint backlog. As soon as one or many team members starts using their own tools, the sprint backlog becomes useless. For example if there is a sprint backlog in Excel and that is on someone's computer, the others start using their own lists and post-its.
The best part about using TFS for the sprint backlog is that this is the everyday tool of the developers. The possibilities of linking the check ins to actual sprint items makes it awesome. I saw that Rosario will fix the visualization problems we have with getting an overview of related work items (no, links tab and reports are not good and since the excel integration only lets you see that there are linked work items, that is simply not good enough).

During the sprint planning meetings we go through the highest prioritized items on the product backlog. The product backlog consists of scenarios and bugs, where scenarios are our user stories and the bugs are problems that are hindering us from setting the scenario as for filled. Bugs that are related to scenarios are of course linked to these but we also give them the same Importance (or priority if you prefer that term). Please observe my definition of bug in this perspective: it is a problem which hinders us from demonstrating a use case.

We've sorted the product backlog after Importance and Work item type so when we come to a new priority (for example three), we can first see the scenario in the list and after that comes all the related bugs. If there are no bugs related to the scenario, the product owner can decide to set the scenario as accomplished. I like doing that during the sprint planning meeting so all can see that one of the objectives are reached.

As I mentioned, we go through the product backlog, top down, and the method we use is that we right click the first bug and create a work item of the type task. The task is placed on the sprint backlog by us setting the sprint (or iteration path) to the sprint in question. The task is estimated and then we move on to the next one until the team think they have a good list to work with.

Product Backlog in TFS

Despite us using scrum as a development guidance, we still use the TFS MSF For Agile 4 Template. But, we've done some adjustments to support scrum but most important: our process.

Our product backlog is a query which fetches all work items of the types Scenario and Bug. It includes the fields type, title, Sprint (Iteration path), Importance and Magnitude (estimate).

The scenario work item type has been adjusted to meet our needs: we've included a How to demo field for the product owner to inform how the scenario is to be demonstrated.

The bug work item has also been adjusted and we've included the importance field to make it possible to have on the product backlog.

What is important to us is to keep track of which bugs are related to which scenarios: this is most commonly accomplished by linking bugs to scenarios. A bug should be linked to a scenario when the bug hinders someone to demo the scenario as described. A bug that hinders a scenario from being accomplished is also given the same Importance to the linked scenario.

Another importance change we did was using our own Importance field instead of the MSF For Agile 4 field Rank. Rank is a string field for some strange reason, which meant the backlog was not sortable by number.

What is a bug?

What is a bug? I had no idea this was such a delicate issue. The emotions involved while discussing the term can be overwhelming. In a previous project it had a practical reason: if something was declared a bug the development team was responsible for documentation and investigation. A bug was also given a higher priority than a change request of the same kind. So, the development team had an interest in declaring something not being a bug while the reporter had interest in declaring it a bug.

I've never found a definition I've liked. All that "not as designed" is so vague and imprecise that it means nothing. So, I've come up with my own definition. A bug as a by a user perceived malady while using a computer software. But, but, but,but if the malady is due to the user not turning on the computer, how can you classify that as a bug??? Well, the CAUSE of the bug may not be in the actual software: bugs can be found in knowledge, software, environment, processes and use cases. But the user doesn't care why. He sees a malady and for him it's a bug. And there should be a incident report on that. We have a not so satisfied customer, and we need to know that.

When I function as a product owner, it is important to keep track of all those bugs. If they are in knowledge, perhaps time should be spent on education. If the bug is due to process or usage, information concerning supported use should be improved or perhaps there is some nice business opportunity in the lacking process support. And if there is something sick in the code, perhaps we should fix that. Working agile and lean is focusing on the things with highest business value. And that does not mean coding in every instance.

Deciding on a sprint length

One week with one day long sprints. So, what is the verdict. Well, the first question is who decides on sprint length?
In our case, I've told the team when and how I want deliveries. AKA sprints from my perspective. Since the delivery and product increment needed are bug fixes the scenario they works with include fixing bugs. But we had a testing debt which meant we didn't know which bugs were highest prioritized. So, to accomplish the task, they decided on shorter sprints: they could not commit to a bug list which was not complete. So, they decided on one day long sprints and gave the testers some time getting back on track with testing. Every day the product backlog was filled with new bugs.
On Friday, I do believe we finally was back on track, having gotten a better picture of which bugs are present. And I can tell the team that these tasks are needed to accomplish the objective of the scenario.
If this means that the team will turn to longer sprints is up to the team. The over head costs for one day sprints are huge and causes frustration in some cases, team members feeling they cannot work undisturbed. But I don't believe that sprint length is something a product owner can force on a team, he can say how often he wants to be presented with product increment but the team needs to decide which flow they need to have to be able to deliver.

One super crazy week is over

Well, I've not been blogging so often lately. I've been working and spending time with the family. Often at the same time.

Leaving the scrum master role is hard. I have to bite my tongue at least once a day trying to stop myself from scrum mastering. My best tools are:

1. A dedicated scrum master telling me to shut up when I'm scrum mastering
2. Listening to music when the team are working. I'm present and they can throw stuff at me to get my attention but I don't get involved in their actual work.
   

Micro sprints or extreme agile?

How do you commit to a sprint which only include bug fixes? Can you commit to solving bugs 35-69? This came up as a long discussion during the Friday sprint planning session. It after a while became clear that you cannot commit to a so long list for a so long time. So what we'll do is turn to very very short sprints. Every sprint will be just one day long (lunch-lunch). Every sprint will start with a quick sprint planning session when we create tasks for the bugs we commit to working on during the sprint. And then we get cracking. Parallel to the bug fixing, the test team will test the previous sprint increment to form a list of the most prioritized bugs for the upcoming sprint.

Of course we'll have problems with hard to solve bugs which takes more than a day to fix but we hope that this will be a method which works during this month. We will also need a very involved product owner who can work on the product backlog every day. If the sprints turn out to be too short, we can make them longer. But by working like this, the product owner can decide when he believe the product is as good as we want it and when we have a release candidate, which is the real objective of the sprint.

We'll start the new sprint length Wednesday lunch. Get back to you with the result.

Changing the TFS template

We've already decided on using a real scrum template when we move over to TFS 2008 but since this is not due this month and we also are interested in how we could implement customization of our forms, we spent some time exploring the customization of TFS work items this Friday. Perhaps not the best way to spend a Friday night, but it was really and interesting exploration and it lead to completely new discussions concerning our processes. Parallel to the customization I wrote a quick HOWTO for our new sprint backlog and when describing it, we came to realize some unexpected changes to fields and process steps that we really want and need. And now, this is included in the actual template and team members have better support when working with the sprint backlog.

I can't say I suggest everyone going through the templates for work item types in their TFS installation, but for me it was really worth while. Now we have a process I can stand for and a process I can explain. "That's just the way it is" is no longer a plausible explanation.

A way to spend a Friday evening

It is strange how things work. Things like me. It is almost mid night and I'm at work. Why? What am I doing? Well, updating the TFS template! Isn't that the best way to spend a Friday night? This was not what I meant. We were just going to do some mild changes and suddenly it was very dark and cold outside. And one change lead to another. But now we have a good template. Hope the other guys sees it like that.

New year's resolution

Oh, this post seems to have been posted without a content. I don't believe in new year's resolutions. I often meet them during the weekend runs. They last as long as one can expect: about a month. Making a resolution because it's new years is probably not a good idea. Make a resolution when you mean to live up to it. I've been running since August 2000. Not because a new year's resolution but because a promise I made to myself. Keep running.