Giving a retrospective for another development team

Yesterday, I helped my husband and his development team at Concordia Bus IT to have a retrospective. I used some of the exercises earlier discussed on this blog, staring up with some emotions, drawing a time line, prioritize with dots and appreciations.

It was really interesting watching another team during a retrospective and it's really something I recommend to anyone being responsible for a retrospective. Not being a part of a team or a project changes how you view upon the whole experience and the exercises. I also think it can be a good thing for a team to have an outsider hosting a retrospective: they can all focus on the retrospective.

It was a really good and interesting experience and I'm happy to have been given the opportunity to participate.

Fly away fly away fly away

Early next year I'm moving along to new exiting challenges at Fritidsresor, part of TUI Travel. I'll be a part of the development department working with project management and requirements. Fritidsresor is an interesting company which embraces lots of the ideas I've tried working for at my current position. I love the idea of not viewing something as a software development project but everything is business and process development.

When given the question what I believe will be hardest at my new position I believe it is understanding and embracing the business. But this is also the most important challenge.

In december, I'll be taking some weeks off and perhaps try gathering some of my notes on product ownership and if all goes well, I'll try publishing a more structured document which describes my ideas and suggestions from project initiation to release.

Who's this?

Have you heard of Manfred of Richthofen? If you're into WW1 (isn't it strange that so many were interested in WWII when no one seemed interested in WW1 in school??) you probably know. But for the rest of us normal people, this is not a name which we remember. And if you're not German it is probably a name which you have a hard time spelling. Manfred of Richthofen is not a good product name.

If I say The Red Baron, more of you know who I'm talking about. How many of you believe that Manfred would have made himself one of the most recognised icons of WW1 haven't he been called The Red Baron instead of his given name?

This is of course nothing weird or strange: people who are good at marketing know the importance of product names and logos. But still, the story of Manfred of Richthofen is an interesting one, and it would have been such a shame that the story could have been lost due to his name. But most people doesn't know more than "German flying ace".

On November 11th, it is 90 years since WW1 ended. Wars are horrible for those involved but WW1 was more horrible than most. I'm taking the time to read some books and texts on WW1. We never read much on WW1 in school and I must say I'm an illiterate on the subject. So, why not take the time and get yourself educated on one ugly war which set the basis for the 20'th century. Why not starting with the wikipedia article on Manfred?

Taking some time getting to know Kanban

As I've discussed earlier, I believe there are no silver bullets in software development. But I do believe in having as an objective to have the code so stable that users and acceptance testers "often" (and what I mean by that of course differs between solutions, cultures, users and so on) can start up the current version and test the current functionality. Why? So they can confirm that the development is going in the right direction.

Therefore I believe in agile software development and that is why I believe in many of the habits of a acting scrum team.

But something I and my team has struggled with during the project is that we still have the problem that sometimes nothing works. I cannot test anything. The reason for this is multiple stuff in progress. Stuff that makes things stop working.

Kanban is said to address this problems, so I'm going to take some time now getting to know the fabrics of kanban. Keep you posted!

Some changes to the blog

I've at last given some time on my blog and for example added some links to my favorite blogs and a gadget which shows my most common tags on Delicious. The blog links shows the initial text of the blog's latest entry. (And I've changed my picture to one from Midnattsloppet, where I ran as a Knight's Templar)

Get yourself educated

Looking back at this project going scrum and agile, there are many mistakes done, many experiences won. But the thing that made the most importance was training and knowledge. I've read many blogs and books: for me one important lesson was not just following the advice of one guru but listening to many and choosing the right path for your organisation. Toyota states that going lean is not just following a book on Toyota and expecting everything to work. The solution has to work for that line of business, that company, culture and so on. I do not suggest just picking and choosing: it is important to have a clear strategy. And you do not get a clear strategy if you only pick small stuff without any thought.

The thing that made the greatest impact on me was attending the certified product owner class I took early this year. And now I don't mean the title and stuff, but putting it all together during two days was awesome. It made me really understand the objectives of the stuff I'd read on the blogs and books and in all the advice. Now I had the privilage of attending the class with Mike Cohn, a pragmatic and direct no-nonsence-guy with a huge experience. Also, he knows this is not about being into the cool stuff for the moment, it's about delivering the right stuff to the right price and with the right quality. He discussed not only how you arrange post its but the really important tasks, most prominently: communication (with stakeholders and team) and estimations (of cost and time).

I know there are two day classes and one day classes: for me a two day class was really good. Going home and thinking things through made room for some interesting questions day two and there was also room for all these exercises. These were interesting in two ways: they illustrated some chores in scrum and since there were 50 or so product owners present one could also see how different personalities work with that role.

Spice up your retrospectives

Even if I believe in having about the same tasks on a sprint retrospective, sometimes you should spice it up with some new stuff. And if there is a project retrospective or a release retrospective, you should really spice things up. Mark Levison gives some really good advice on both Info-Q and on his blog on some fun activities which real objectives.

New tactics with free software

Being the kind of gal who reads Seth Godin and Chris Anderson, I'm of course interested in new ways of marketing products and concepts. And having a free version of software is a well used concept, but now I've really seen it with a new twist.

Scrumy is a product for handling sprint backlogs and like most others they have a free version and a pro version. And like most others they difference their versions with functionality. But not always the way you think: the free version has something the paid for version lacks: sometimes the free version shows Fresh Prince of Bel air. Since I could never stand the annoying guy when the show first aired, I would gladly pay to not have to see him. It's a wonderful idea. And their commercial is lovely! I hope their product is nice!

Getting to learn yourself - have a meeting

Having had a number of meetings the previous weeks, I've gotten into some interesting discussions on how I view software development, Agile, Scrum, requirements handling, team work and communication within and around a project.

And what never stops amaze me is how much you learn about yourself in these discussions. Now, I've had the privilege to meet people who really listen and who does not only accept what others say, but who questioned my views and statements. It has been some excellent discussions which has gotten me thinking a lot about my self and the subjects we've discussed. And one thing is for sure: I've gotten to know myself much better.

The human interaction is something powerful and should be used in projects. I know there are all these useless, long meetings and that many developers sits through them thinking "when can I start working again".

A meeting should be as it states: a meeting. A meeting is between people and does not constitutes someone giving a lecture which the participants does not understand how it affects them. The thoughts of the developer reflects on him not thinking that the meeting makes them do their work any better.

So, the first thing a meeting should do is make sense. ALL the participants must know why they are there and what the exit criteria is. If there is a meeting there are participants. All should be participants and therefore participate. If someone is "present but not participating" that should be clear to everyone.

And finally, if the "meeting" is really someone giving a lecture, just call it that.

There are no magic pills

If you've read Lucky Luke you've seen them: the witch doctors which sold those magic pills which were supposed to cure every problem. Being a skeptic, I know there are no such things as magic pills. Not in medicine. Not anywere. Not even software development.

In accordance to Swedish IDG, Scrum is under heavy attack. Be happy that the story is written in Swedish, for I've seldom read such a sorry story. Ivar Jacobson, one of the fathers of RUP goes to "heavy attack" on Scrum. It is good for small agile projects but not on large ones with a service oriented architecure. Well, if one of the fathers of RUP weren't of that opinion, I would find that more strange. Or?

Then the writer of the article states that Jacobson is being backed up by a master's thesis from the university of Karlstad. The writer of the master thesis states that scrum is customized in larger projects. Well, that is only true for scrum. Right.

Then the story becomes really weird. The writer states that there is no room for sprint reviews. I had to re read this a couple of times and I still do not understand what the problem was, besides companies not taking time for retrospectives or acting on the result. And I guess that is not only true for scrum.

Scrum is no magic pill and I've never heard Ken Schwaber stating that. If you have a product owner who lacks domain knowledge, who doesn't participate in daily work, if the scrum master and product owner does not communicate properly to stakeholders, if there is no product backlog, if there is no product/project vision, there is a good chance the project will fail. No one has ever said that labeling a project as using scrum automatically makes it a success. What I've heard is that software development is no walk in the park. Scrum or no scrum.

The diluted mobile phone

Being Swedish, I'm of course happy that Sony Ericsson has a mobile with Windows Mobile. But the name is taken: http://en.wikipedia.org/wiki/X1!

And to make things worse, X1 is a term used in homeopathy: describing the least potent concentration of a mixture. That is the one least diluted. (For you who do not understand the principles behind homeopathy: the more you dilute something the stronger and more potent it becomes. I've often found this true with alcohol...)

It's hard to find a good product name but if something already has ten or so entries in wikipedia, you might opt for something else.

You get what you measure - so how to create key values on bugs

Bugs are elusive. Not only that they occur, but that it seems that most key values which measures bugs is contraproductive but reading about Yahoo and their transition to agile, I've found a new interesting metric: number of critical bugs found in X within Y days after placed in Test/Production/etc. For example if you have the metric "The number of critical bugs found in production within 5 days of production".

Why is this interesting? Well, if it took the users less than five days to find the problem, the software development team should have found it as well.

The same type of metrics should be applicable in the different stages of a sprint, for example number of critical bugs found the first day of acceptance testing.

There is probably a downside to this metric but so far I like it

Linking tasks in Microsoft Project

In my series on how to use Project as a product owner blessed with Team system, I've come to links!

Everyone that have ever used Microsoft Project soon discovers that you can link task. The first method used for most users is probably dragging the bar of one task to the bar of another task.

What happens when you do so is that the field Predecessor becomes filled in. And for the more advanced users there is also a Successor field.

• Predecessors
  The ID of tasks which affects the current task
• Successors
  The ID of tasks which are affected by the current task

When you double click the link between two tasks, the Link Task dialog box becomes visible and in this you can control the link. Let us say we have task A and task B. You can find the ID of A in Predecessors of task B

• Finish-To-Start
  The finish time of Task A affects the start time of B. This is the default link and can be translated into "The finishing of The foundation of the House controls when we can start the work with The Walls"
• Start-To-Start
  The start time of Task A affects the start time of B. This can be translated into "We cannot start testing before we've started developing".
• Finish-To-Finish
  The finish time of Task A affects the finish time of B. This can be translated into "We cannot stop testing before we've stopped developing".
• Finish-To Start
  The finish time of Task A affects the start time of B. This can be translated into "We cannot stop using the old system before we've started using the new system".

When you changed the link type you can see this in the Predecessors field: 3SF means that a task cannot start until task 3 has finished.

To make it a bit more complicated you can also add a gap. A link with a gap can read 3sf+3d. Observe that if you're using gaps you need to specify link type. Remember that all units possible on Duration is also valid on gaps, including Elapsed. And gaps can also be given in negative numbers (3SF-3d) But just to give you an example on the most common settings:

• 3FS+3d
  The task cannot start until three working days after 3 has finished.
  "Three working days after delivery, operations can start upgrading."
  
• 3SF+3d
  The task cannot finish until three working days after 3 has started.
  "We need to have the old system functual three days after the new system is operational"
  
• 3SS+3d
  The task cannot start until three working days after 3 has Started.
  "Three days after we've started developing, we can start planning for new sprint"
  
• 3FF+3d
  The task cannot finish until three working days after 3 has finished.
  "Three days after we've finished developing, we can finish testing"

But why not simply drag the tasks in the calendar and not link? I'll get back to that!

Specifying duration in Microsoft Project - working with elapsed time

One of the errors newcomers to Project do is that they do not grasp the difference between Work and Duration. Not so strange, since only the Duration column is visible in the Gantt chart. But Duration is the calendar time between a task starts and the time it finishes. Work is the man hours spent on the task. You could say that work affects the costs of the project and duration the length of the project. On my post on task types you can see how these fields works together. But back to Duration.

Duration is the calendar time and when you set this on a task you type in a number and a unit. The units can be minutes, hours, days, weeks and months. How you print in the unit depends on which cultural version of project you use. For example you can type in t for hours in the Swedish Project but you need to print h in the English. Also, remember that m is minutes and yoy need to type something longer (for example mon in the English project). Be sure to check the metrics used in your version!

If you set the Duration of a task to 7 you can see that there will not be 7 calendar days between start and finish. There will probably be 9. Why? Well, by days Project means working days. If you go to Tools-->Change Working time you can see that Saturdays and Sundays are non working days. This means that the tasks will proceed during these days but no work will take place. If other days are marked as non working days in the calendar, they too will be skipped. And remember that if you mark days as non working for a specific resource, they will be skipped on the tasks where the resource is set.

But then there are tasks which work will commence independant on if it's working time. For example, I want to give a customer 14 days to think something over. Or concrete dries in a specific time. What I can do is that I can add a e in the English project before the metric. For example 14 ed. Remember that the e is dependant on which version of Project you are using: in the Swedish version you type in a t instead. The e stands for Elapsed and means that work will take place 24 hours a day, 7 days a week.

Working with part time resources and focus factor in MS Project

I dislike UI and programs which are not working in a predictable way, but then: who doesn't. What I can't stand is when the built in help doesn't help or gives me the wrong information. And Microsoft Project on part time resources is a good example on this. So how do you work with part time resources and focus factors under 100%?

Getting started - setting up the project
First, when you start up a new project file: go to Tools-->Settings and activate the tab which specifies working time. There you can set the number of hours on a day, the number of days in a month and so on. Change these to your likings but make sure your calculations work together: Project will accept settings that does not make any sense together. So, you also need to set the default start time and default end time. This specifies what start time and end time a new task will have when you create it. This is by default set to 8:00 to 17:00. So an example of good settings are:

• Hours per day: 6
• Default start time: 09:00
• Default end time: 16:00

If you only change the hours per day setting to 6, you will see that linked tasks will start behaving strange. Since a task consisting of one days work leaves 2 hours every day the next task will start the same day as the previous. Believe me: change hours per day and default time.

After the changes have been confirmed, it's time for a visit at Tools-->Working time. Here you should select the headings for Monday-->Friday and change the settings to the same settings you set on default start time and default end time. Why? Well this settings is when the resources CAN work, the default start time and default end time was how the tasks where created.

So, now you've specified the default focus factor of the resources and your project. Now it's time for the separate resources.

Setting the focus factor of the resources - part time resources
When you view the resource list in Microsoft Project, there is a field called Max Unit, and when you read sloppy documentation on Project, they state that this can be used for setting if a resource work part time. Well, not part time as I know it. Here's how it works:
When you choose Tools-->Working time, you can use a drop down and select your resources calendars. All resources have their own calendars and this specifies their working time.
What the max unit settings under Resource list specifies is the max value of unit on tasks (see my post on task type for info on unit) on a specific moment a resource can have before he becomes over allocated. This is when his post in the resource list becomes red. For example, we have two concurrent tasks with the same resource allocated:

1. Unit: 50%
2. Unit: 50%

This means that you have two concurrent tasks which the resource spends 50% each on. If the Max Unit of the resource is 100%, this will not be an over allocated resource, but if the Max Unit is 99% he will be over allocated.

This far, it seems like a good solution for part time resources but the problem is that Microsoft Project does not care if the tasks are 5 minutes long or a month. In other words, if you have a resource with max units 50%, he can only participate in a 1 hour meeting with a focus factor of 50%.

So, what do you do with part time resources? Well, you need to change their working time using their calendar. For example, you can set that they only work afternoons if they're working 50%. And you keep Max units as it is since Max Units sets percentage of the resource's calendar. If it becomes hard to visualize which resources work part time, you could take the time creating calendar templates for part time resources and setting those on the resource.

So, how do you use Max Unit? Well, if you have a resource group with interchangeable competence. For example if you have a group of three testers. You are not interested in assigning them to specific tasks, then you can create a resource called Testers and set Max Unit to 300. By doing so, you can say that we can assign three individuals at one specific moment.

Task type and Effort driven in Microsoft Project

I usually do not do Microsoft Project any more, but since there is a Project integration in TFS, I sometimes get some questions. And since people use MS Project, they fall into the task type hell.

When you work in the task views like Gantt Chart you work with the task table in the project database. In this database you have three, connected, fields, namely Work, Duration and Unit. Connected by a formula. Namely:
Work=Duration *Unit
Work is most of the cases have the metric Hours, Duration have the metric Days and Unit % (even if these are settings found in the wonderful Settings dialog box under the Tools menu). So one example can be:
80[h]=10[d]*1
Which means that if one person works full time during ten days this results in 80 hours work. So the definitions of the fields are:

• Work = man hours to be spent
• Duration = number of working days between the start of the work and the finishing of the work
• Unit= Percentage of time spent on the task

If you question my using the 8 hours a day, this is the default setting in Project. And yes, you can change this too.

If you want to try all of this stuff, you need to show all the fields in the view: the easiest way is right clicking a column name and inserting a new column. Select Unit and Work (you need to do this one column at the time) and since Duration is visible by default, you now get the complete picture.

So, now you can start playing around with the figures. (One tip though, never add Work before you set a resource on a task, then you're in for a real challenge. And also, never set a resource on a task with sub tasks. But now, back on track).

When you start changing the values in one of the columns, you can see that the other values change. But how do you know which one? Well, on the task table there is also a field called Task type and this value specifies which column should not change when you change the other values. This means that if you set this column to Work, the Work column will not change if you change Unit or Duration. Get the picture? If not, e-mail me.

What you also can remember is that there is another column: Effort driven: if you set this column to Yes, adding new resources will divide the current work on the task between all the new and current resources. But is that not always true, you think? Well, imagining creating a task for a meeting. If this task has Effort driven set to yes, adding new participants decreases the length of the meeting...

So, what should you choose? Well, you choose depending on task:

• Work
  When you know how much work will be spent. Often used for development tasks when you have an estimation in hours (this will take me 40 hours to program)
• Duration
  When you know how much calendar time a task will take. All meetings for example. And tasks where the estimations are in the terms "it will take us three weeks to be ready". Should always be set without Effort Driven
  
• Unit
  When the focus factor of the participants cannot change. When you have a resource on 40% and this will under no circumstances change.

When creating a project file, be sure to have these columns visible so you know what you're doing. And if you know that you will only use one setting, please free to visit Tools-->Options to set which setting all new tasks will have.

Changed behaviour - why why why

As I've discussed earlier, I prefer talking about expectable behaviour rather that usability. And today, I found yet another example of why there is a difference.

Having used Microsoft Excel since like forever, I thought I knew which behaviour to expect. For example double clicking in a cell makes it active. YES! I know that you can press F2, and I do that too, but sometimes I see an item in a list and wish to change it. So, I double click the cell and I expect the cell to become active.

But no. Someone decided that changing this behaviour to moving marked cell to next empty cell was the thing which had highest business value.

Both behaviours has it's usability thingies but I don't expect the selected cell to move from a cell which I double click.

Lean software development

My favorite guy from the backside of Sweden, the Hexmaster of Faktoider.nu, posted this picture today.

He posted it tagged as something funny and as a joke, but it actually catches the principles of Lean Software Development in the best way I've seen until now: do not add functionality until you've gotten the the stuff you've already to work.

Then, if you want to call fix defects "mess around" is probably another question.

The failing product owner

As Henrik Kniberg at Crisp already stated: who cares if you fail using scrum as a methodology. Independant on which method you use: if you get the wrong stuff too late and at a too high cost, your project has failed. And I do believe the reasons for any software development project are roughly the same: independant on which method you use.

And at the very core is the order of the system. The one who can say if the following has failed: the stuff built, the time spent and the resources spent. If that person does not exist or no one feels really responsible for that role: there is a good chance the project fails.

I do not believe in mediums but I sometimes wished they existed. If they did, I would hire that person to a software development project so we could build the right stuff. But mediums and Santa Claus does not exist, and the persons responsible for software development project should realize this. Unfortunatly, there are too many people out there who wants power and a nice title, but does not take responsibility for placing the order and following up during delivery. Giving the right feedback right through the project.

Mike Cohn says it so well and simple: a single, wringable neck. You cannot blame someone else and you cannot delegate responsibility. You can give others oppertunity to have their saying but that does not lessen your responsibility. It should only increase your possibility to take responsibility.

I do not take pride in a title on a business card: I take pride in the work I do. And being a proud product owner is being a participant and a partner to the development team - independant on method used. If I cannot say if the right stuff is being built to the right cost and on time: I should start calling myself something else and let someone more suited take the job.

Getting input on UI

Most of the developers on my team likes getting feedback from users about usability and functionality but I've found a problem. I probably do the same mistake. Let's say you have a new function for registrating costs. What's the difference between these two scenarios:

1. Developer goes to user and shows the new functionality and the user gives feedback.
2. Developer goes to user and asks him to register a new cost.

The difference lies in the response: in the first case the user gives response to the developer's demo. In the other case the user tests if he can use the functionality.

In real life for the real user, there will be no developer doing the chores. The user have to do it himself. So, of course the second method is preferable. If your expert users cannot find their way around the UI, how will the ordinary user do?

Sprint backlog items of type Bug and Work item type Bug on Scrum dashboard /Conchango work item template

As I've discussed earlier, we're using the episerver scrum dashboard and while testing today, I've found a small issue for my team

If you haven't used the dashboard, it's based on the conchango work item template and it have a number of work item types, for example product backlog item, sprint backlog item and bug.

Product backlog item: stuff on the product backlog

Sprint backlog item: tasks to be performed during the sprint

Bug: bugs or defects

When you set the sprint on a product backlog item, this becomes visible on the scrum dashboard (the column on the left side). You can do the same with a work item of type bug: it then becomes visible on the left column)

You can then click a product backlog item or a bug and select a number of tasks: one of these being create related bug. But here is the trick: this is not a work item of type Bug, this is a sprint backlog item marked as a bug. So if you use the reports over active bugs these bugs will not show up. Why? Well, if the bugs are a result of defects during production you will probably not that those show up in release notes and should not clog up the statistics: when you look at the bug reports these are bugs in production. In other words:
* If the bug never makes it to production, it will become a sprint backlog item of type bug
* If the bug is spotted as a part of delivered functionality, it should be reported as a work item of type Bug.

Hard to understand? Well, I know my way around the work item types by now so I can understand it but how can I possibly explain this to a new acceptance tester. And how should this person be able to know if it's a Bug or a Sprint Backlog item of type Bug? Another problem is that you cannot report Work items of type Bug using the Scrum dashboard: you have to use the web access or ordinarie Windows client.

And also, if you have reported a sprint backlog item of type bug during the sprint and the problem is not addressed, you must remember to create a linked work item of type Bug.

(And don't hit me, I didn't come up with this solution)

Team goals

Goals and objectives are important. For me, anyway. When making up a product backlog, I find it important to have a product vision or product statement: how can you otherwise specify business value.

Having read about team goals, I've come to think the same about teams and impediments. If you hold a retrospective and for example use Prioritize with dots to decide which impediments the team should work on, how can you do this effectively if you lack a team objective?

Scrum team size

Having worked with education and teams for more than a decade, I know something happens with a group when it becomes bigger and when it becomes smaller. I've seen some dramatic changes when you move from three to four and when you are more than eight. Then there are some gaps at 15 and if you're over twenty: there is no way you have one functional group. You probably have a number of unoffical groups.

The reason for me coming to think about this was a collegue stating that he'd experienced a successful scrum team consisting of 30 team members. I do not doubt they were successful, but I doubt they worked as group in the sense I see a group. And for example Jeff Sutherland have the same experience: larger groups works less well or has informal divisions. What is kind of funny is that when I gave class, I said the best group is more than two and less than seven: and that is the same size Sutherland recommends. And the similarities are many between education and scrum: the discussions and the group dynamic.

So, why do people want large groups? Division is hard: you like the guys and don't want to miss them. And it's easier to hide behind others. In a small group it's easier to see if someone doesn't understand or does not pull his weight.

Go, small groups!

And no, two developers are to few: I like the old arabic saying on why you should have four wives:
If you have one, you love her too much
If you have two, they will fight all the time
If you have three, two will take sides against the third
Four is optimal
You will probably not afford five

Some Q & A on retrospectives

How do I select a time for a retrospective?
When it comes to sprint retrospectives, I want to have the retrospective on the same day as the demo. People going home and coming back the next day don't have that sprint in mind anymore. Most people forget how they felt the day before and that feeling is important to catch.

When it comes to a project retrospective, it's a good idea to have that on a separate day, but if the new project is up and running the day after, try having the retrospective before the other project starts.

Who's holding the retrospective?
The first rule is that the person should come prepared. The person should also understand or be able to read the participants. And the person should have the time and the personality to document the result and present it to stakeholders.

It's also easy to get lost during a retrospective. People can get into these long discussions and the rest of the crew get unintested or you don't have the time to finish the meeting. You need to be able to draw the line. Here I believe it's important to "park the question" instead of just dropping it. I tell the persons having the discussions that they can bring it up after the meeting or at a time that fits them. Of course this must be treated with care: some discussions are such as they cannot be dropped and have to be solved.

Who should participate?
This is a tough question. Of course, team members should participate but should other stakeholders participate? Depends on how free team members feel to take up their issues if for example a boss is present. The experiences of the participants should also be connected - it's no use drawing a time line if none the participants understands the other one's notes.

As a product owner, I've participated and I've been there just listening. Now I participate but stuff that does not involve the team's tasks are not presented. That should also go for part time resources - talking about details in the other project is of no use but if the other project affected this one - write a note which says "Other project".

Should you come up with solutions during the meeting?
This is also a tough one. Sometimes the solutions are easy to find but it's often easier to get into a long conflict driven discussion which ends with a really bad solution. If there is nothing obvious pops up, I tend to give people in pairs the task of coming up with one or a few solutions on a subject. It's best if everyone gets a task, but the most important thing is that the solutions should not always come from the same persons.

We have so many meetings, I don't think the guys wants more meetings...
There are few meetings that are directed at solving problems for the team as such, not the company, not the product, but their situation. The retrospective is for the team. Therefor it should be fun and there should happen something with the result of the meeting. If there are ideas and solutions from retrospectives which are never implemented, then out goes the retrospective.

My suggestion is start with a short, active meeting. Perhaps just drawing the time line. Then, always act on the suggestions of the team. The most important thing about retrospectives is that if the participants don't believe in them, they are a complete waste of time. And then having a beer and getting people to chat on can be a better option.

The true story of software development

As I've pointed out on several occasions on this blog: it often amazes me how many seem not to get the long time consequences of their decisions: if you cut on quality, there will be bugs. If we do something in a way we don't believe in, we'll have to redo stuff. If we have to focus on several other tasks outside the project, the project will suffer. I think it's simple math. But clearly it's not.

I think I'll post this wonderful list from Marios Alexandrou on the stakeholder's walls on the start up date for all my coming projects. It's no surprice to us, hope it stops being a surprice for them in the future.

Value stream mapping - the downside

It is of course important to map how long time it takes from an idea being put forward to a development project until it's in operations. For example the time from a critical bug being reported until the fix is in place is crucial. But it's also important to remember that it's not good if you get to eager as well when implementing new functionality.

Of you're into Lean software developement, you know that building extra features is something to be avoided: it increases the overall costs in all future releases and it clutters the solution for the users: you cannot see all the useful features because there are so many useless ones in the way. And the easiest way to build extra features is looking at an idea, finding it neat (and perhaps easy to implement) and just build it. Without thinking if it's easy to test and uphold in future releases and if it really is as good as you originally thought.

It's easy to get carried away. And if you on top of this measure how fast you react to user input, it becomes even easier.

If I'm unsure of a request, I simply listen to it and let it rest. If it's important and really good, the stakeholder will come back again, perhaps give more examples and ideas. And if it's really a good idea, other stakeholdes will probably come forward with the same request. And two persons coming with input on an idea is ten times better than one: with two stakeholders you can have a good discussion on different implementations and the risk for a not thought through solution is lessened.

I use the same method when my son is interested in an expensive toy: if he really wants it he'll remember it and ask for it again. And now he's been asking for that green car with Buzz Lightyear since this summer. So I guess he really wants it. And he will probably appriciate it better now that he has been longing for it for some time.

But do note that this method should only be applied on new functionality: bug fixes is a completely other story...

Retrospectives

If you're not improving: you are getting worse. So, you should always strive to improve. That does not mean that you should always change: an improvement can derive from continuing on a path already stricken. I've seen multiple examples of stuff going wrong and people feel an urge to change stuff, just to make themself feel better - at least we're doing something.

But I'm getting off track - I was going to talk retrospectives. Why do you hold retrospectives? Well, to know how to improve you need to know the current status and how people feel and think about that. Hence, end different periods with retrospectives. The periods can be anything from a meeting to a whole project: if you're having a retrospective over a meeting the retrospective should not take too long while the retrospective after completing a whole project should take it's time.

If we turn to the classic sprint retrospective, I've found that a one hour meeting is appropriate. I make a mental note of 1,5 hours if it was a troublesome sprint.

Then I come prepared: Agile Retrospectives is a good cookbook when selecting stuff to do. But selecting tasks can be a hazzle. My rules are: make sure there's a flow. That you use the stuff from one exercise to the next. This rule may not apply to the check-in exercise.

There are a number of exercises published online but I do recommend the complete book: even if you shouldn't change the exercises every time, you need som change too. I have the rule to only change one exercise at the time. This way there is something new but you don't have to explain everything before each exercise. Explaining an exercise takes away from a much needed flow.

I also include exercises where people are up and running: for example placing postits using Timeline or Prioritize with dots.

And finally: use the last exercise for something positive. Appriciations is the best exercise for me. - ending with everyone saying something positive is wonderful. But make sure that there is not apprications for everyone but one (if it is not called for) - being singled out as the only one not appriciated is not the best way to end a project.

My first agile project, not that I knew that it was a project or that it was agile

Looking back at my career, I find that my first agile project started back in the year 2000. But I never saw it as a development project. Nor did I see it as agile. But looking back, it had lots of agile feeling, even if it was somewhat extreme.

It started when I was working as a computer trainer and project manager at a computer training company here in Sweden. One of our sales guys came and asked me if I knew a program which was called FileMaker. Being born and bred from the Apple world, of course I had. Well, he had this course that needed to be held on using FileMaker. I hate those two day courses in database programs - either they are to superficial so that the advanced users don't get their answers, and the beginners never get enough to be able to create their own useful database. But that is another story. A consultant never says no, so I went to a big hospital here in Stockholm and met this science nurse, who was conducting a study and who needed this database. She had a database, but she needed to change it, so I was going to teach her.

I studied the system while we were talking and I soon realised that the model used didn't fit her needs, she wouldn't be able to answer simple questions as a patient's latest sample result on a specific test. That is kind of crucial.

We had to make radical changes and so my first agile project was on the road. But we didn't call it a project, we called it an education. I rebuilt the foundation of the system back at work but we decided to meet once a month to teach her a little bit more on how she was going to be able to change the system. At the same time I showed her what I've been doing during the previous month. You could call it a demo. During the demo we discussed which changes I was going to do until the next time we met and what she would be doing. You could say we had a sprint planning meeting.

We always worked from the use cases, or in this case: the study that was being carried out. She explained which statistics she wanted and I asked some questions back about special cases.

I was very lucky having this as my first agile project. First: she was an excellent partner (if you have a good product owner, you see that person as a partner or team member). Second: I didn't see this as something as hard as agile software development. I simply worked they way I found worked for us. And finally, I learned a lot and had so much fun. And that is not to be forgotten either.

The Dian Fossey way - treat your users as monkeys

After a comment and a blog post on Peter Lundholm's excellent blog, I decided to give some more ideas on how you track your system's usability.

Everyone who hears the story on Dian Fossey are amazed. How much time she spend and that she gave her life for these gorillas. Her struggle is kept up by others and we all have something to learn.

Working with requirements, I can sometimes think about what Dian Fossey can learn us about how we watch behaviour. Because what was so special about her methodology? Well, first, she watched the gorillas herself. She did not use any go betweens. She went there herself. Then, instead of barging in there with a camera thinking that the animals would behave as they usually did even if there was a human there with a camera, she realized that they had to see her as something/someone normal and that they could see her as a part of their every day life. Only then could they start functioning normally. When you watch a show on Animal Planet or Discovery, much of the scenes are staged or special because normal animals does not behave that way in the wild. You can see the same fenomena in real life soap operas: many participants act in ways they wouldn't normally if they weren't lifted from their normal social surroundings and if they didn't have a camera pressed up their face.

What I'm trying to say is that if you expect users to let you share their every day work process, you need to be a part of their every day. They need to be able to feel safe surrending information about their lack of knowledge, how they by pass stuff in the system and that they don't have to act in front of you. You are there for them. And hopefully, the risks of you getting killed are less than they are for the heroes watching out for our endangered gorillas.