Team rooms

Do you remember those old "computer rooms" in school. You remember the smell? Well, sometimes agile smells just like that. I don't know how many times I've heard about agile teams being referred to small conference rooms just to be seated together. Rooms not adapted for so many people for such a long time. I wonder how many failures of agile projects are the results of bad working environment...

Our team moved into our room exactly a year ago. We were so happy that we finally got our team room. The previous tenants had used the room for two guys. We were four and I believe the room is adapted for a group of that size.

When we max our resources we are now 9 guys and a girl. And the room both smells like and looks like that old computer room in High School. So, my highest priority is now: project Exodus. Moving out from the team room. There are larger rooms, but I guess the problem crept up on us. Now, it must change. Team rooms are nice, but adapted team rooms are brilliant.

And today, the new sprint was off

Today, we started the new sprint. It's a short sprint due to Christmas, and to visualize exactly how short the sprint is, I draw a calender on the whiteboard. Then they realized.

This sprint start was very concrete and for the first time I felt we had a good flow through the sprint start. We started with a rather lengthy retrospect, really taking the time to print down all the ups and downs of the sprint. And then we printed down all the suggestions and simply voted on the different suggestions. We decided to start to use our own application for the sprint backlog and that everyone is responsible for updating the sprint backlog before the daily scrum. We'll move back to the whiteboard for the daily scrums instead of hanging around the computer and updating the backlog at the same time. Focus!

We also decided to try estimates again. But updating the estimates better every day. And I've already made clear to the guys what has high priority and what haven't. We've also better discussed what is dependant on what so the things we can cut is planned in the latter part of the sprint: we now better know which tasks are suited for the last crucial week.

A day off, in between sprints

Today was our day off. We use to have one day between the sprints and then the guys are free to do what they think is a good task for the day. So, if someone thinks that is fixing that annoying thingy then they can do that. Or if someone think that's the small bug that got introduced but not fixed they are welcome to give it a try. And if someone wants to do some research or read, what is also their choice.

The effect is happy developers and increased quality. Why? Well, since most of the guys have already thought up something to do the start up time is minimal. And they feel very motivated to get it done. And the quality: well, since it's their own pet project, of course they put their pride in as well.

And sometimes rewarding is that simply: just give some slack!

The purpose of the demo

After today's demo, a very unplanned session due to the absences of some key resources, we've come to discuss the purpose of the demo. Is the demo just a presentation of new, implemented functionality, a presentation of what we have worked with, or a presentation of work flows made possible after this sprint?

The problem is that different viewers have different needs: the sales person is not really interested in what is new: he wants to know how and what he should include in a demo while our operations division wants to know what we have changed. And our integration department want to know how their integrations are affected.

One solution is to try to meet all these needs but then the demo becomes to long and some parts become boring for some of the viewers. Or worse: it's unclear if something is of interest to them so they stop listening. Another option is to hold several demo sessions. But then you miss the discussions between different types of users. The solution. Well, I don't know. I'll have to think this through. The same goes for the product owner and other stakeholders. If they don't know what they want, how could I?

The delivery curse strikes again

Yesterday, when I wrote my posts, I realized that no one was sick. If you followed my blog this spring you might recall that I always complained that on the day of the sprint, someone or perhaps most of the team was very ill. Well, yesterday, everyone was well.

Then, before leaving for daycare. The first e-mail arrived. And then the first SMS. And the next. So, it's going to be a really decimated scale performing today at the demo session. Let's hope that there will be more viewers on their feet.

Dropping a sprint

We've actually finished the sprint. Well, the demo is tomorrow, and we're dropping the release to operations tomorrow. But I think everything else is running. I tested our clients tonight and just finished that task. Long day, in other words. I know agile means no overtime but since I'm taking the morning off I wanted to make sure that I know the quality of the release.

What is new for our demo session is that we are filming them. We might be an on site team but the company work on multiple sites and all are not be able to attend the demo session. So, we're making a film and all team members should attend the demo. That has not been the case before. First, we wanted all to attend, but the guys asked "if they could work instead". So, finally I and perhaps one more guy held the demo while the others continued coding. Well, if we don't take the demo's seriously, why should the viewers?

Pairing before a sprint finish

One of the most seasoned, solo working developers has come to appreciating pair programming during these two last sprints. He can just say:
- Hey, come over here.
Sometimes he just smiles and says pair programming is really really nice and fun. And that is nice to watch. It's really true that 1+1 sometimes become 3.

What also is fun is that different constellations are created, dependent on task. I thought that a big risk was that pair programming meant that the developers found their partner and they stuck together. But perhaps that is because I'm female and that pairing in the female work means just that. Excluding, rather than including.

One good new thing this sprint was that today, the last day of the sprint, resulted in all the developers turned to pairing. Without anyone saying so, suddenly everyone was working in pairs. Just to make sure that these last check ins had high quality.

So nice to see: that we don't need a manager telling us how to work. We need a manager for "manager tasks". But deciding which methodology the guys are using is not one of those tasks. They can manage that so effectively when they are given the option of taking responsibility themselves.

Dumped by Peter's mommy

I just zapped through the channels on the TV and suddenly saw a familiar face, Shannen Doherty. I don't know why I started watching. The show, called Dumped by Shannen Doherty, must be the most stupid idea on this planet. As I started watching about ten minutes before it ended, I perhaps didn't get the complete picture but when I started viewing there was this guy, dreaming to be a screen writer.

He´d been fooled into believing that he was doing a film with miss Doherty. But then she sat down with him and said it was all a scam and that this was really a TV show and his girlfriend was dumping him. But the girlfriend didn't want to make him sad. Yeah, right. Like he'd be much happier if he'd been fooled into believing that his dream had come true. But instead he was dumped by an actress on TV. And this is a running series. Not being to much into watching TV, I'm sometimes amazed at all the weird ideas that seem to attract both viewers and TV channels. But for me it's not a problem dumping ms Doherty and her show. I have more fun watching the arms of my clock moving.

In for a real change? Get rid of that project manager

I guess they've said that on all sessions on Scrum that I've attended. I've also seen it on blogs, in articles and in books. The scrum master is not a project manager BUT if you've been a project manager you can now become a scrum master. So, we switch the project to scrum and the manager to master but keep the same guy behind the mask. Or?

I believe there is a risk to migrate the project manager into a scrum master. Because people generally turn to a comfort zone and if there is a role that on the surface is very similar to another role that you are familiar with and it's the same person, this is a clear risk.

Also, I believe that not so few people turning to project management love all those plans and Gantt charts and diagrams that they just go for the artefacts in the form of product backlogs, burn down charts and sprint backlogs. They cling to them like they are the sole purpose of the project. I actually saw that there is a scrum template for Microsoft Project now. I used to be a really good Microsoft Project teacher and coach. I even wrote books on using the programs. To be frank, I learned how the Project database calculated it's fields to make me understand things in the program. But I cannot for my world understand how Project in any way can help a scrum team.

Project can perhaps make a project manager calling himself scrum master feel really valuable. But I hope that is not the point. So, kick out that project manager from his comfort zone and give him some other chores. Perhaps he'll turn into a really good scrum master after a couple of months.

Color it!

When I studied, my teacher in planning said that people generally want different options for a development project (I was studying physical planning). So, what you do is that you use nicer colors and more trees and green stuff on the alternative you like. And no people on the ones you didn't like.

In a software development project we have different options due for prioritizing. So, what do we do? Well, of course if I'm creating storyboards for something I don't believe in, I don't put as much effort in it to make it sellable. And if I know that there will be a debate on an issue which I value high, I put in a lot of effort. We are all humans and I guess everyone does that.

But it's important to know that and don't over do it. Like an old colleague of mine. He always made sure there were multiple options where all but the one he was in favour of meant death and destruction to our company, all our clients and all our clients clients (and probably their cats too). I do believe it's better to tell up front that you are in favour of an option rather than being the Domesday guy. We all know what happens to those guys in the end.

a new language

I just read a message to my boss and two colleagues. Even if it contains no code or domain specific word I guess my mom could understand about a third of the words. I use words like scrum, scrum master, product owner, product owner proxy, backlog, product backlog, sprint objectives, increment, storyboard, use case. Well, this gets me thinking. My mom could be a user, or a customer. What if I went out to her place of work using these words while talking to her:

- Well, this use story is not in any storyboard I've seen on the sprint backlog for this sprint. I don't think I've even seen it on the product backlog. I can ask the product owner or the scrum master what the status is.

These words separate the ones inside the agile scrum sphere from all the others. You actually have to read quite a bit of literature before you can understand the difference between all these terms. So, using these terms should be banned outside the scrum sphere. If the customer and user had not been included in some kind of scrum education or workshop, they cannot be expected to know what they mean and using the terms is therefore in basic insulting. So, next time bite your tongue and simply say:

- Haven't thought about that. Haven't seen that on any lists so it's probably not planned. I can ask someone who should know.

222

I've always missed the even numbers. Oh, I've written 50 posts. Or a 100. Or 200. Well, 222 is even isn't it? Well, since I like the number 2, I've decided that 222 is an even number. So, hurrey for me and my 222.

Blame it on the guy with spectacles

After chatting a bit with the owner of one of my favourite sites, faktoider (some of the material on this sea of knowledge in the most peculiar of fields is in English), I was corrected in stating that Grace Hopper's moth was the original computer bug. Well, she probably FOUND the first computer bug. But it was probably Thomas Edison who first used the term and good old Ada Lovelace discussed in her papers the risks of bugs. All this is wonderfully documented on Wikipedia. Well, the historical aspect is good. But I can't agree that

"Bugs are a consequence of the nature of human factors in the programming task. They arise from oversights made by computer programmers during design, coding and data entry."

In fact, it makes me sour that this is so integrated to our western society to "blame it on that computer guy. He looks so geeky it must be his fault." Blaming the developers for all that is wrong in computer software is as absurd as saying it was "the soldiers" fault that Operation Market Garden" failed during WW2. That is a stupid statement which means nothing. That does not mean they/we make mistakes. We all do.

But everyone involved in a software development project is responsible for the bugs. From the guy who didn't get enough sponsoring for the project, via the gal who didn't make an effort to respond to questions about how the d*mn thing should be implemented and the tester who though Na, tested that last time, won't bother this time to the guy who actually approved the delivery without checking everything needed to be tested.

What is a bug?

When searching for the definition of a bug (picture showing the first computer bug in history - it was a moth), you can find so many definitions as there are encyclopaedias, but they all sound something like this one from Techweb:

A persistent error in software or hardware. If the bug is in software, it can be corrected by changing the program. If the bug is in hardware, new circuits have to be designed.

A persistent error in software or hardware. Then it's the question of error. What is that? This is taken from Wikipedia:

Error refers to a difference between actual behaviour or measurement and the norms or expectations for the behaviour or measurement.

The key to bugs in the user perspective is the word Expectations. What you can expect. Users classify something as a bug when it doesn't meet their expectations. But how does the developer or programmer conceive it? Well, if it doesn't work as the spec (in the form of documentation, use cases, storyboards or what ever means of communication is used), then it's a bug. It doesn't work as they thought they designed it or should have designed it.

For me, working with requirements, I meet these both types of "bugs" but I also meet process bugs. People who do things they ought not do, for legal or other reasons. Loop holes, we call them. You're not supposed to be able to change customer on a case which we've already billed. And the system was not designed for that, and suddenly the data looks weird. If we upgrade the system and remove that possibility, the user's think that this is a bug: we can't change customer anymore!

So, what is important in these cases is understanding why the users use those loop holes. It's not that they are evil: they are most of the times trying to do their work. And that is why it's important to sit down and listen to these users to figure out the real use cases and how they are going to work. Sometimes their work method is the bug: they are doing stuff that is not legal and then they need to be informed. And in those cases there are bugs in the processes. So, bugs don't have to be in the software or the hardware (if you don't include humans in that definition).

But most of the time they are performing their duties but no one has bothered to find out their needs and included their needed functionality into their systems.

Hidden places

Helping a friend moving today, I came to know the recycling centre of Vanadisberget. Situated less than 2 km from central Stockholm (the recycling centre is marked in the top and the cery center of Stockholm is where the text Kungsholmen is, it felt like being transferred to a Domesday film and there had just been a nuclear war. The drive down under the mountain was like driving into an ordinary garage, but well under ground, we had to drive a minute or two before a large cave opened and there were all these people throwing away their stuff in huge containers. The light was barely enough and the sound of the pressing machines preparing the garbage for burning all helped turning the place to something from a film.

The staff sat there on their chairs, waiting for someone asking if the doll is burnable or not and where to put that old couch. We all had terrible headaches when leaving. Amazing but still horrible place.

A nice site, and a bit strange name...

My old employer just changed their company name. From the very Swedish/Lithuanian clinging Jönsson & Lepp to Addskills. I can't help reading it as Adds Kills, but that is a whole other story. I visited the web site and was in for a nice surprise. They've actually changed their graphic look and feel as well. I like the upper third. But then I start to look closer. A lot of capital letters. The kerning of the font is not OK in all the places. And the white boxes. Well, there is room for improvement.

But what was good was my first thought: hey new! New NEW! Perhaps I'm just comparing with the company site of my current employer. Not so much new but a large space for improvement.

When Sharepoint's doing it's work

Since I've given you some inside into how we're organizing the use cases: how about the sprint backlog?

Well, we've turned back to Sharepoint and what really makes it worth while is the possibility to use different views. So we only use two actual sharepoint lists:

1. A list of objectives
2. A todo-list (aka the sprint backlog)

This is all visible on the sharepoint site like down below. In the upper left corner you can see the objectives list showing which objectives we're focusing on right now. In the upper right corner I've created a list which shows which items have status In progress.














Lower left list is the complete sprint backlog for the current sprint, and the lower right list is the items on the sprint backlog which are labeled as bugs with priority 1, aka critical bugs. Same list, different perspectives. All visible when everyone starts up the Intranet.

Back to basics

Working with two different platforms (Windows and Mobile client) and two modes (Online & Offline) creates two dimensions to every problem: let's say create new contact. Is it offline or online? And which clients are we going to use? As a requirements analyst, it is easy to overlook these dimensions when creating storyboards and it's even easier for a developer to choose one track. If he sees the storyboard for "Create new contact" and implements that in the Windows application, designing for the online mode, has he forfilled the task. Well, yes. And no. And sometimes. It depends on how the storyboard looks. The problem with user stories in our case that a user story can read:
"An offline windows user can create a new customer".
And this does not even take personas into account. So, after some long discussions, we decided that we do need a list of user stories in the short form "Create new contact" and a list of scenarios where we connect the user stories to the two dimensions of mode and client. So, I made an Access file with a bunch of tables and started building up my list. When I looked up, I said: hey this looks a lot like the use case list I created after reading Mike Cohn's book on Use cases. So, we're back. So, what is my tip for a use case list:

Figure out which dimensions are the most critical. For us it's client and mode, not personas

First create the list of use cases. We just add the use case and keywords (the latter you can select many.








Then create a scenario list adding the dimensions to the use cases. In our cases, I also added the possibility to connect new keywords, how the thing is to be tested and if it has been implemented yet









What I also got was a test list for the manual testers so they can see which features has been added.

When I was finished, I uploaded the lists to our Sharepoint site and will now connect this to the sprint backlog so we keep track of which use cases we're working with.

What is the sprint backlog?

I believe that many of my issues with the sprint backlog is that it's very unclear what is consists of. Is it user stories, or objectives, or is it tasks? We are going to try to make that more concrete so we all know what we're talking about. And what we're working with. We're now leaning against making the sprint backlog a list of just tasks. A to-do-list.

Andy Hunt on how hard it is

Andy Hunt gave, not all unexpectedly, a very interesting and thoughtful presentation. One of the most interesting issues are of course complexity. How hard is it? Well, one thing might not be hard, but many things are. And complexity build exponentially. And therefore it's important to know when to add complexity, or features, or documentation. Or what ever you want to call it.

Is it difficult to write English? Well, I can use a dictionary and translate word after word and each and every word is correctly translated. But the sentence will not be correct. It is often like that with features: it is easy to translate them into code, but when we add more than one feature, they have to work together. So, what do you do when you learn a new language? well, you probably don't start with the most complex sentences, you start small. You start simple. Try it and see if it works.

I can't help thinking about Robert, in the Swedish classic the Emigrants. He wanted to learn English and got a book. He saw the spelling and the phonetics. Guessed which he would use when talking and guessed wrongly. He spent all that time learning all that. For nothing.

Thanks, Valtech, and thanks Mr Hunt, for a wonderful evening and many thoughts to bring home to the guys.

The dream world of estimations

Do you commit to estimates? well, I don't.

Let's say you have a developer. Let us call him Joe. Joe is not the sharpest of developers. He's not bad, but he's not the best. During the sprint start, there is a party of planning poker held on a user story. Implement Donkilidoldi in the Windows application. Joe says it's a three. The other guys a one. They say it's really easy and go on about how easy it is. Well, thinks Joe. Perhaps it is.

The very next day, Joe starts with Donkilidoldi. And perhaps it was a one for one of the others. He can do it in a one. But it won't be a very nice solution. It will be dog ugly. "But they said it was a one, so perhaps is what they meant" Joe thinks. And how can he say that it is complicated when they said it was easy...

So, what was the end to this saga? Next month, another developer. Let us call her Linda, takes the task of making version 2 of Donkilidoldi. The estimate is a three, and that is of course based on the assumption that version 1 of Donkilidoldi was done as the fastest of the developers had thought. But this is not the case. So, Linda thinks: is THIS how it's done? Well, then I have to do this ugly workaround just to make it work. Because she only have a three to work on. And she feels really stupid having not read the check in e-mails properly to know how Donkilidoldi worked.

This is one easy way to create a technical debt. I don't believe in collective commitment to an estimate. What I can commit to is an estimate when I've started working with a task, and concentrated on just that task during that timespan. Joe could only commit to an estimate when he was given the responsibility. Linda when she saw first hand what she had to work with.

For more on this subject, read Serial Seb!

First winter run

You who live in a colder climate but don't run during the winter might have reacted to my latest post on winter running. She didn't mention that it's icy. Well, I've never fallen while running. I believe that I can feel how icy it is and try to run where it's not too icy.

This morning was really icy but if just keep up the pace, I don't have any problems. I often move my heel back and forwards to feel how icy it is. Or perhaps I'm just stupid. I felt like that when people having problems walking straight saw me running this morning.

But, how was the run: fun, because icy also means I have something to concentrate on while running.

Valtech's seminar on Scrum

Today, I and one of the other developers went to a Valtech seminar on using Scrum in software development. In January, I'm taking a scrum master course, but it's always interesting to hear other's experiences and questions. I found, as expected, that some of our biggest problems can be derived from the following facts:

1. We are developing a product for a large number of customers. Our present customers are part of the concept customer, but they will (if all goes well) be a small part of our customer basis. So, meeting the customer's need is difficult: we know what the present customers want but we also want to meet the needs of our new customers.
   
   
2. The business value is hard to track when you work with many and different customers: what is good for some customers are worthless for others. Our smallest customers have under 10 users and the large organizations have more than 300. Since we are working with process support, this is a huge challenge.
   
   
3. We have no fixed architecture: we want the architecture to be selected from the business and the user stories. So, we need to experiment. Experimenting is hard to estimate, introducing new architecture is hard to estimate. And spikes are hard to commit to. When they say committing to the sprint backlog: are we committing to the objectives or the tasks?
   

Well, it was a nice seminar. And tomorrow, the evening will be spent on another Valtech event, in the form of a Andy Hunt seminar.

It's winter

I can't believe it's less than 3 weeks since I wore shorts while running. Today it's winter. And tomorrow the first morning winter run is due. Running during the winter is a little bit colder, wetter and means a little more clothes. The upside is that winter running is one of those little things that constitutes the difference between a runner and a guilty conscience. So, here are my top tips:

1. wear good clothes. I actually like the clothes for nordic skiing and cycling better than the stuff for runners. Except the padded pants. Remember the wind and use wind stoppers.
   
2. when it's really cold, wear a face mask made for sporting (yes, you look funny, but when it's below -10C, it means all the difference). I've been out running when it's been below -25C and wasn't affected at all.
   
3. buy some cotton gloves. I buy mine in a store for worker's clothes. they cost almost nothing so I can buy many
   
4. just keep up the habit, running during the winter is no difference than during other times, except in your head
5. run to work. take a change of clothes the day before. it's the best way to start a new day and then you won't have to think about it
   

Easy listening

My IPod Nano took a splunge for a couple of weeks ago and was soon after pronounced dead. The guys tips and tricks didn't work. My first thought was going out buying a new one. Being a satisfied customer, that felt like a good choice. But my needs are dual: in the evenings I listen to audio books while falling asleep. And when I'm out running I listen to music. Well, I can use my Touch for the books and the Nano is actually a bit clumsy when running. I have to wear the arm band and the hazzle with the cables. So, I bought a Shuffle instead. I'm a very happy runner. I keep it just under my chin and there is almost no weight, no cable and no arm band. I feel free like a bird.

Sometimes you go for the more expensive solutions, trying to meet two different needs and you end up with something that doesn't really suite any of the use cases. Both in development and buying stuff.

Belgian chain and the weekest link

In cycling, there's a concept called Belgian chain. It's based on the concept of the effect of drafting. It's estimated that when you lay directly behind another cyclist, you only need two thirds of the effort compared to laying all alone. If you're part of a large bunch of cyclists, the effect is dramatic.

Sometimes during a professional cycling event, the pulse of some of the riders is displayed on TV. The guys riding up front may lay on the border of what they can cope while they guys in the middle may have a slightly higher pulse than you get from ordinary walking.

So, what do you do if you're ten guys out cycling: well, if the conditions are right, you might try the belgian chain. The guys in the left lane work themselved upwards and when they are up front they spend about 15 seconds there before moving right and the downwards in the right lane. Why: you don't spend so much time in the front to get exhausted. All share the burden of the wind.

I can sometimes see a good agile team as a team trial cycling team doing the Belgian chain. Beautiful to watch. Effective and building trust.

And like with development you might say this doesn't work if not everyone is as good as the next. Well, if one or two of the guys can't cope they stay in the back and just rotate there. And if it's a good team, that's OK. Everyone is entitled to a "bad day" or perhaps the Belgian chain is not their cup of tea. Those guys repay some other day. And that is also important in the agile team: understanding that "good" and "not as good" is a question of task and day. But of course, if someone is always lurking in the back, perhaps they should find a more suitable sport.

Andy Hunt's in town...

On Thursday, I'm going to a Valtech seminar by Andy Hunt. It's really fun because his book on pragmatic programming was the first book which started to change my view on development and developers. It also feel kind of strange: we're having a baby sitter and a dog sitter. We've been in that role for others, who then take the time to go to a party or the cinema, or a dinner. Or a vacation. Me and the big guy choose to spend our evening off listening to Andy Hunt.

One week without estimates

So, we're one week into the sprint without any estimates. The effect is double: the ones who like the estimations feel we're out of control. "No one is working on the right stuff. We have no control".

and those who don't like the estimate feel free to be creative and finish their work: with the estimations they've felt forced to stop working with an item when the estimated time is up. "Well, it's sort of finished". And now they feel that it's their responsibility to set a task as finished when they feel it's finished. You can't hide behind an estimation that didn't include a not estimated part.

For myself, well, the control freak within is sometimes stressed: what if they spend too much time on something... And the team member feels like we're giving the responsibility to the guys. In other words: the place where it's supposed to be.

So, for now, I feel working without estimations work best. But that is this sprint, and this team constellation. And these sprint objectives. I don't say: skip the estimations, I say: try working without them and see what you're missing. That might make you think twice about how you estimate and why.

Uncontrolled chaos - spending half a day in the forest with seven kids

Have you ever wondered how the do it: the staff at daycare? I spent Wednesday morning at daycare. They spend two hours in the forest with the kids. Two staff, 9 kids. Well, yesterday some of the kids were missing but I can't understand how they do it. When we came out, two off the children had rolled themselves in ice cold mud. Most of the kids weren't clothed for two hours in the forest with a temperature nearing the freezing point. One of the girls screamed for an hour and one of the boys wanted to go to the bathroom. And taking a leak in the forest was not an option for him.

After leaving Peter and the crew at daycare at lunch, I was exhausted. I don't understand how they can take it.

Uncontrolled chaos - working with a simple todo list

On Monday, I asked the guys if they wanted to do the estimation. Yes and no were the answers, and I decided not to push the issue. I want the guys to feel that the estimation is done for their sake so they know that they will finish on time. And the sprint start ended without an estimation. Well there is an estimation: we're going to do the functionality of a storyboard in two weeks. We did a todo list and prioritized everything on it.

So, the day before yesterday, everyone got cracking. At once we realized that we'd missed an very important feature, and this was included on the todo list. I think the guys are working very well, but I feel that I don't have any real control over what the status is. Today, I hope this will improve due to our holding a meeting on the storyboard. We go through every step and see what the status is.

Is this Scrum: not at all. It's just an experiment to see what the estimations give us.

Traditional goose from Scania, for ten hungry guys (Mårtensgås)

1 whole goose (5 kg)
Salt
Pepper
Thyme
200 g prunes
5 apples

Sauce
Thyme
2 table spoons of black currants jelly
2 dl fat from goose
4 dl cream
salt
pepper

How to do it:

1. Rub the inside of the goose with salt, pepper and thyme
2. Fill the goose with bits of apples and the prunes which should have laid in water for at least 10 min
3. Sew the goose shut using a cotton thick thread ( I use cotton yarn)
4. Bind the wings and the legs tight around the goose (this is to prevent them from being over done.
5. But the goose in an oven (170 C). But it on gratings over a pan. A lot of fat will drip from the goose, so this must be able to handle this.
6. Bake the goose in the oven during about 3 hours. Turn the goose once an hour and scoop some of the fat over the goose during the process. If the pan gets filled with fat, pour this into a pot: you will need this for the sauce.
7. The goose is ready when the temperature of the thickest part of the chest reads 85C.
8. Take the goose out of the oven and let it rest.
9. At the same time as the goose is resting, cook some potatoes and stir the ingredients of the sauce together.
10. Let the sauce boil for a couple of minutes.
11. When the goose has rested for 30 minutes, carve it.
12. Serve with the stuffing and some jelly. And red wine.
    

Mother Goose visits the scrum team, or vice versa...

One of my bigger problems is that I don't know when enough is enough. It gets really concrete whenever I invite people for lunch or dinner. Or in this case, a sprint start.

Inviting the guys for a sprint start at my home I realized it's soon the traditional Scanian (my husband's family is from Scania, in southern parts of Sweden) holiday when you eat goose. So, of course, the guys needed some goose and traditional goose blood soup, also called Black Soup. I ordered a goose for ten people and the corresponding soup from a good supplier and got cracking yesterday. Fixing with the stuffing, potato, linen, silver. You name it. And today I was up and started to fill the goose at about seven. I probably missed about half an hour of the sprint start, fixing with the food today.

You might say I spoil my developers, but I can't help it: if it's a planned dinner/lunch for more than four people and if there are no children involved, I tend to get out of control. My husband doesn't even react anymore. He was just happy that I saved some goose for him. But we're both grateful for the dishwasher, which has run six times today. Good food is silver, a dishwasher is gold.

Helping people not to endulge in illness

Electromagnetic sensitivity was the subject of one of my absolute favorite podcasts, Skeptoid. You often hear that there is not enough research in the area and I was amazed on Brian Dunning's extensive list of recent and valid research. Since this is an illness found mostly in Sweden and the UK, most of the studies were from these countries.

The podcast, which I really hope you take your time listening to, especially if you hear about this condition, also touches an important issue: strengthening a person's perception that somethings is bad for their health makes that true by increasing their stress. And long time stress can cause physical problems. In other words: if someone believe that they are exposed to something that makes them sick, they become just that.

We are sometimes tricked into concurring with someone making these claims (even if we know they are absolutely ridiculous just not to make them sad or just to be "nice"). Sometimes we hear someone saying that they will get the same decease as a near relative. And by enforcing that claim, we help making them sick. So, if someone says: I'm going to have bad knees because my mother has bad knees, they might stop exercising properly or start walking really wearily and in that way getting themselves some bad knees on their own. So, instead, what should you do? Well, in the case of the bad knees you might suggest a good exercise program to help them in case they do get bad knees. And if they start exercising they might feel some joy from that and might forget about those bad knees. And perhaps avoid them all together.

A good agile developer is a skeptic

You can often read about people referring to Scrum teams as a sects. Well, all close knit groups are in the risk zone of becoming a sect. And getting to stuck to an idea can make you almost religious in conviction, as Artima Developer points to in his blog. Being a skeptic and an believer in agile methodologies I concur: you must not forget the Agile Manifesto's statement:

Individuals and interactions over processes and tools

This means that you should never follow a methodology or a principle without the retrospect. And the retrospect is worth nothing if you're not a skeptic. If you're not willing to challenge the methodology or the principles, you will be stuck. And answering criticism of how you work with that's how you work using your chosen methodology is a no-answer unworthy of an agile developer. If you don't know why you do X, you should look in to that as soon as possible, especially if X is hindering someone or something.

I'm looking at scrum as a sketch and an idea or a concept, not a recipe to follow like a slave. If someone has a problem with the daily stand ups and the rest can't argue it's case, maybe we shouldn't do daily stand ups. If the team feel that the sprint backlog is hindering them and no one feels differently, the sprint backlog should be changed or removed. Now, I see the point in all these artifacts, but the important thing is to know why they are used, and that goes for all the team members: why should a team member take part of the daily stand up if he doesn't know the objectives of if and why should a team member use the sprint backlog if he thinks he works better without it?

Learning agile at day care

This Friday, in spite of the release, I took the morning off to spend some hours at Peter's daycare. The plan is to make a habit of it: been working too much and I want to spend more time with Peter. So, I want to see his everyday habits at daycare.
I've always wondered how they do it. Sometimes getting just Peter out the door during the cold/rainy season takes forever. And there are 14 kids at the daycare. And a staff of three persons.
Well, it all started with the personnel saying calmly: let's go out, everyone.
Some of the kids sprinted out the door and to their clothes. I went after, trying to help everyone at the same time. The staff didn't seemed stressed, but I was running all over. The kids spotted an eager helper and came to me.
After a while, an experienced woman said to me: just relax and go with the flow. What we do is that we let the most eager ones go out first. They are so eager that they put their clothes on themselves, if you don't help them. Then, when they are gone, most of the commotion is gone with them. And then we can ease out the small ones. With one in the staff out tracking the eager outies, the remaining staff can help the small ones. Then, when one in the staff has taken out the small ones, the remaining person help the older, not so eager ones.
So, what I did was that I disturbed everything. The eager ones saw that I was helping and instead of just putting on their clothes, they waited in line by me. The small ones got interested and came out to get some help themselves. So, everything took much longer time. So, lesson learned:

1. Don't multi-task
2. Don't offer help to people who can cope themselves. You teach them to be inactive.
   
3. Help the ones in need, but one at the time (not to break rule nr 1)
   

The release...

So, how did it go? Well, we weren't finished in time. And then we made the best of decisions: a feature we've been working about a third of the sprint wasn't included in the release. It wasn't tested enough. It included crash bugs. The guys worked like h*ll getting things done but when I went home on the release day, they were not finished. I had a faint illusion that I could test it when Peter had gone to bed, but I really knew that such attitude is not putting quality first. The decision was made easy when the new Resource Planning view didn't work on my computer. And then I did what I should have done a week ago: inform the Product Owner that the resource planning view would not be included in the release. After getting a late confirmation I e-mailed the team and informed them on the decision.

I really wanted the guys to exclude the view from the menu bar but the next day the guys got everything going at work they wanted to keep the menu. They didn't want to change the code so late. I agreed to this but said the resource view would not be included as a released feature but only as a visual proof of concept. As this is only an internal release this is a valid option. Now it seems like the bug is only visual using a Swedish XP Windows client.

On the demo, everyone was fine with the decision: they could see what we'd been working with but they all know that this is just POC. And this is an important lesson: fighting to include features which has not been acceptance tested or doesn't have enough quality is never a good idea. It's like putting in faulty brakes on a bike.