Pushing five

So, it's soon five o'clock and we still don't haven't stopped coding. Tomorrow will be a day of hard core testing. We've finally been giving some UI love, but that needs to be tested too. UI testing is hard. You never know what you will think in advance. There are so many things that make a good UI.

Release time, or is it?

The last few days I've been busy with the upcoming release. Today, two days before the demo, we're still not there and now we should have gone to phase code stop four hours ago. We are not ready. Not not not. Keep you posted.

Simply doing nothing

Being alone with the dog this weekend, I had lots to do. And yet, I did nothing. I didn't clean up the mess in the house. I didn't go exercising, except for a short morning run. I trained doing nothing. It was hard, feeling kind of worthless and derived of something. But there is a time for everything and nothing needs it time as well.

• Well, I did meet up with an old friend. Called him up and said let's meet and within half an hour we hooked up. I did that yesterday and today. Hey, he's better at that than my dog. Showing up when I call on him, that is. I also ordered some goose and black soup for the coming sprint start. I've decided on taking home the guys for a traditional feast from Scania. Goose and black soup (made from goose blood).
• Updating the channel list on the TV I found we have History Channel: Wow! My evenings are saved.
• Finally, I killed my IPod. I drowned it when taking a bath. That kind of spoiled the fun with the bath. To put it mildly. And I was in the middle of a book. Fortunately, I'm using Audible's wonderful service and could download the book to my Touch instead. I love them. (And no, I don't get payed for saying that)

So, now I'm going to grab a final cup of coffee and relax in front of the tv. In two hours the husband and Peter will be back again. Everything going back to normal. Except for the IPod. I think I'm going to bury him next weekend.

All inclusive...

Have you heard the story on the lady going on an "All-inclusive" trip and not bringing any clothes, explaining it was supposed to be all inclusive?
Of course you haven't, but we've all been on vacations where one or many travelers have been disappointed because their concept of what should be "free" or included isn't the same as the company selling the trip.
During estimations we have exactly the same problem; what is included and what is not? For example, if you ask your standard junior developer about an estimate there is a good chance he won't include testing, meetings, discussions, problems and any non-developer tasks. Sometimes I think the developers don't understand that my non-coding time also cost something.
The first sprints we spend ages trying to come up with a good estimate. But it's all for nothing. Of course you can estimate a simple story like include a new simple attribute to a concept, but anything more complicated than that soon turns into a guessing game. So, our focus on the sprint start is rather:

1. Which objectives do we have?
2. What is the exit criteria of the different objectives. If there are many exit criteria, which ones are mandatory (if we don't have that, the objective will be completely and utterly useless) and how are they prioritized.
3. What is the budget for each objective?
4. What is the initial estimate of how we're going to work?
5. Who will focus on the different objectives?
6. Who will be responsible for tracking the exit criteria?

Ok, this is probably not classic SCRUM, but we've found that getting an understanding in the team for what we're going to do is the important thing for a sprint start and guessing games are just waste.

Notes from a tool user... is he working on my team?

I fairly recently started reading Notes from a tool user, a blog from a Canadian guy, working with scrum on a distance. Sometimes it's spooky which problems he discusses: the same as ours. Yesterday's entry was no different - the problem with retrospectives and internal meetings. And the basic problem is of course not all those annoying little things, but really some basic issues.

1. If people don't know why the meeting is held they will not behave. Not having a good agenda is the perfect setting for people not understanding the meeting. Not defining the output of the tasks on the agenda is another.
   
2. If different individuals have a different concept of what is acceptable behavior, there will be conflicts during the meeting. If one of the guys thinks talking with the girlfriend on the phone on a non urgent issue some other bloke will loose interest (if this is less important than what's for dinner tonight, then...)
3. If we don't use the the output from the meeting and don't follow up on the findings, the next meeting of this kind will not be taken seriously.

The Toyota WHY WHY WHY WHY is so important. Stop being annoyed at the little things and try to figure out what really is causing the problems.

How cute isn't that?

Peter's best friend was over for a visit. They meet an evening every week and go to the same daycare. They started at daycare at the same time and they act, according to the staff, as siblings. The little girl doesn't talk much to us but she talks a lot to Peter. Telling him what to do and what he's not supposed to do.
Well, this evening they crept into a small tent. Peter placed his head in her lap, pulled a blanket over them both and she read him a story from a book. She "read" a page and then showed him the pictures. Then moved on to the next page. Did I say they are only three years old?
My conclusions from this? Absolutely none? I just wanted to tell a really really cute story...

Part time team member

Mark Levison descibes from his heart how it is to be an agile developer, working at a distance. The conclusion is straight forward: don't do it.
We've experienced the same thing with part time team members, in other words students working with us part time. With the best intentions we wanted them to be "full" team members but that is not reasonable. Not being there don't give you the same chance to have that collective responsible for team objectives. You can take responsible for tasks when you're there, but not when you're not. I guess it would be different in a completely distributed team where everyone is facing the same problems derived from physical distance.

Explaining agile development

We've now moved into the tenth sprint of our agile project. We have an internal release every month with working software but our problem is that we are building the product as a replacement of a product in use. So, our real users cannot switch until the built functionality meets the needs met in the current product.
So our "users" are our internal personnel until we've got enough depth and width to enable users to migrate to the new generation. So, what is "working software" with this kind of project?
Well, our problem is that it means one thing for me, another thing for developers and yet another thing for our staff. For the developers working software is software that meets their individual concept of "working code". For the sales personnel means software they can use during their demos. In case of the former, we have that. In the case of the latter, we don't have that. So, the sales people are waiting for what they see as the first "real" release.
I've more and more come to understand that agile methodology works best with software that is already in actual use: it will be much concrete when we have live software that our users use. Then we can every month decide if the new release has so good quality that it can replace the software the users are using.
Next week, I hope that will be a dream come true. And then I'll probably find the next problem with agile development. Not to say that I ever want to go back. It would be like turning your back on electricity.

The very best question asked in an agile team

One week away from code stop on the October sprint and we still have deadly bugs and cracks in the system. We've on a daily basis gone over what everyone is doing and focused the resources on the tasks that are the most "dangerous" from a bug perspective: if we have bugs in those areas the release won't work. In other areas, bugs are bad but no killer. It's like germs: you don't want them anywhere but if they are in your brain or in your heart they will kill you. So, kill the infections there first!
So, what is the best question asked? Well, we've borrowed a guy from our Services team. He's doing some minor parts and configurations that he will use as an integrator. But his constant question is:
- What can I do to help?
It's such a simple question. Everyone knows he doesn't do brain surgery but that instinct and that attitude is worth millions in this situation. And that spirit is the core of an agile developer.

Bugs...

One of the guys is staying late this evening. And my mail box is suddenly filled with bug reports. Should I be worried? No, this is awesome! We're one week away from code stop and we've identified a lot of critical bugs that we don't want to find next week. So, I have a hero in my team.

How many sprint objectives? Champions, captains and coaches

A couple of sprints ago we started to really focus on the sprint objectives. We put them up on the wall and discussed them all the time. That was the most successful sprint up til then. This sprint had its sprint objectives too, but doesn't feel as focused. We do have sprint objectives but there are to many. We thought splitting up bigger objectives on many sprints and cutting up the objectives in smaller such would be a good thing but having seven sprint objectives and seven developers makes people not remembering the objectives and they feel less important.

Next sprint we're going back to three objectives: two main objectives and one less prioritized. The third objective will only be reached if everything goes well on the other two. We will keep the model with one developer responsible for each objective. He will be responsible for watching that tests are written and are valid, budgets are kept and check the storyboard against code. He will also be the main guy for code reviews. You could call him the champion of the objective. Or if you're using cycling terms: team captain for the objective. But isn't that the scrum master's role you might ask? Well, yes and no. The scrum master is more the coach in our team while the captain is on the field and also coding. It's not a coincidence that both soccer and cycling have a captain role and a coach role. We need it so probably they do too.

Only create as much as you need

One important part of agile development is KISS. Keep it simple, stupid. But sometimes it's hard to see the difference between simple and stupid. We are starting to move into pricing and from start the task is simple: when you register an earned value it has a price. Independent on customer and other things can affect price. In other words: we have one price list and all articles has a price.

But we already know that this is not the case in our problem domain: the price of an earned value comes from a contract row: dependent on which customer and under which circumstances the earned value has been registered. For example, say that a window is broken. How much will it cost to get the guy to fix it? Well, it is not only dependent on which guy and the type of glass. Different customers have different prices and if you want the guy to come at once it will cost you more. Also, what broke the window affects who's going to pay.

But to meet the needs of today it's enough to have a price attribute on article. But it's wrong. And we know it. I guess the difference is knowing that it's wrong and building the stuff to ease upgrading in the future.

You get what you deserve

I can't stop being fascinated by little Pete's ever increasing insight into language and culture. It's not only that he can copy our speech, he also knows when some things are appropriate. Like yesterday evening. He didn't want to sleep and craved something to drink. This is what happened:
- Mommy, can I have something to drink? (nice and sweet voice)
- No, it's time for you to sleep.
- Now, listen, mommy. I want something to drink! (Harsh tone)
Of course it's someone grown up who taught him this behavior. And that is probably the most amazing thing: what ever the grownup was trying to force little Peter to listen to, he probably forgot the next second. But how he uses that language and tone, he'll never forget.

Lessons learned from extra release

Why don't you make a release in the middle of the sprint? Because it doesn't work. Today we finally identified a bug in the "extra release" which made it useless. So, the only good thing that came from that incident was us realizing two things:

• You never release during the sprint
• We need a certified scrum master

So, now I'm booked on a scrum master course in January and we won't make any more mid-term releases.

Lessons learnt from cycling, part 4

Looking at all the old movie clips from the Armstrong era is both fascinating and sad. I'm so happy to have followed it when it happened and I'm sad that we'll probably never see the likes of him again. So, I'm going to finish this series on lessons learned from cycling with yet another classic clip. Have you ever been skiing in the Alps? Have you ever thought about cycling up for one of those mountains? Or perhaps three or four in a day? And just be off cycling the next day or week, or weeks.

In the end, it's all about who can endure the pain and have the insight so see the possibilities. When it hurts like hell you can just stay with the others or you might excel. In this sequence, everyone was hurting. But one of the guys saw the possibility to win. For some, mediocre is just enough. For some, winning is everything. (And yes, the road in the end is the road the rode that day, and that was not the only mountain on that day...)

Lessons learnt from cycling, part 3

And we can't talk about cycling without talking about not giving up. Doing your job. Lance Armstrong had a guy on his team ho had financial troubles. He was whining about that all the time, and his capability was affected. You could really feel sorry for the guy: his former team had not payed him, and it seemed like he wasn't to get his money. So, he was not getting in time to his practice. Unacceptable to Mr Armstrong.
Armstrong talked to the guy: Get on your f*cking bike or I'll get someone else to do it.
And that how it is, it is not a fair world, and it's not about everything being good all the time. If you want to be the winner, sometimes you just have to get on your f*cking bike and get going. It's not like someone else will do it for you.

Lessons learnt from cycling, part 2

Agile. That is a good thing. And you never know when you're going to need it. The story behind this, classic shot, is that Joseba Beloki, multi time not-winner-of-the-Tour-de-France was trying to win the race. So, he attacked on a hot and steep decline. Everyone who saw it remembers it. Being a winner is being agile.

Lessons learnt from cycling, part 1

Why do I like cycling? As a sport, that is? Well, I believe it's the combination of individual achievement and team effort. And the tactics. And the too much tactics. And you can never take anything for granted.

In many ways the same values can be found in agile development.

Take for example, watching everyone else so no one wins. The situation in the film is this: four guys have been in a break out most of the day. That is really really hard. They have 700 meters to go and the pack is half a minute behind. They should be able to make it. But that means cooperating. The problem is that being in front is tactically a bad thing. So, this is what happens.

Another example: sometimes you just know that you're right. You've done the right thing. But it's all about delivering the right stuff and focusing on the right thing at the right moment. Don't take winning for granted.

More whining, DOES ANYONE USE GOOGLE DOCS???

I just gave up. Historical moment. I just stopped editing documents in Google Docs. I have tables in my document. If you have merged cells in tables in Google docs, you can see some magic. Not the funny amusing magic but the annoying irritating, hated magic you can see in applications in which they've built in functionality they don't support. It would have better if they didn't have the merged cells. Because now it took me some days before I realized that when I removed a cell at the far left, a column three steps to the right disapeared as well. Oh, I'm so happy just now. Not. Believe me, not.

Why Facebook doesn't work for me

I finally got it. why facebook, that is! It's the holy quest for old friends, collegues and ex:s that does it. How's life for the old crowd? So, why doesn't it work for me? Well, I'm lousy with names. Sickening lousy. So, the people I'm most interested in: I can't remember their names. And the gals might have changed names. And the guys as well, nowadays. And perhaps I'm not that interested, actually, how they are doing, that is. My folks gives me the news on all the friends and casuals from my home town. It is always the same story:
(Dad) Do you remember X Y?
(Me) No.
(Dad) Well, I met him the other day. He's got a new job and his cousin is also fine.

Well, there is a reason for me not keeping in touch with everyone. And some names are best kept forgotten.

So, why do I use linkedin? Well, that is another story. Perhaps it's not me having to get all the spam.

New picture

Just updated the blog picture. Me hugging Peter on Stockholm Marathon. Just by Fridhemsplan. Everything felt wonderful. Less than 100 meters later, a took a faulty step and soon it was all over. The race, that is. The hug still lingers.

More than words...

The other day we were discussing words at work. Being a business analyst I have a problem that words mean different things in different lines of business. Like Object, what is that? It's not as easy as referring to a word list because some words have a special meaning for a small group that is not perhaps aware of their special usage of a word.

In other cases the meaning can also lie in the mental image you project when you hear a word. Take martyr as an example. When you hear that word you can, perhaps unaware of the fact, think [be] a martyr or [act as] a martyr. And that first mental image says a lot about you and how you will interpret the rest of the conversation.

Me, being a sarcastic non romantic, visualize the "oh, feel sorry for me for I'm the martyr" characters who spend to much time convincing themselves and others that they are unselfish that they spend all their time thinking about themselves. Unselfish, naaa.

Someone else thinks about the stoic hero who throws himself in front of a mortal danger to save others.

These common words are the most dangerous during modeling and discussions on software development since you take the word and it's mental image for granted. Myself, I'm just happy that I don't have to build in some martyr functionality in our product.

The very abstract, and very concrete

Little Pete is in a real learning phase. He's finally grasping colors but are fighting with numbers. I can imagine it is hard. It is very concrete when we count his fingers. But at the same time very abstract when we say he's three years old.

Working with a semi-finished product is somewhat similar. We have some parts we can show and these are very concrete. But other parts are very abstract. For some, that is not a problem. But for others, this is very difficult. We have a contact list (like contacts in Outlook) and we have a list of customers. These two entities are related as you can have a contact in your contact list which you want to mark as a customer (if you have the customer Erland's Electricity and you have that as a contact with general contact details). But you also have individuals which works for a customer. (Jane and Steve who works for Erland's Electricity). The latter relation hasn't been implemented yet, due to priorities. For some of us, this is not a problem. You see the current relation and can imagine what is coming. But for others, this is impossible. They cannot fill in the empty spots in the picture. To work around this, we use a lot of "Photoshop programming". We take what we have and fill in the empty spots in Photoshop to make it concrete. This of course can also create confusion: what is real and what is not. And it's not for nothing that our PO find that is was so much simpler and cheap just to have the Photoshop programming

Facebook

I just don't get it. Of course it's fun to look up old pals and not-pals from the past. But all the applications. I've got a vibrating hamster. I click it when the guys at work are arguing. But the vampires and all that stuff. I asked a frequent user off that stuff: why? What's the point? He answered: "You fight. The vampires are awesome."
"Fight, how? And awesome, in what way?"
The silence in return was speaking. The point is that when I add an application my profile is stored by the creators of the application. Welcome, spam!
I do enjoy the groups, though. I don't frequent the group sites but I like the names. So, I'm part of the following groups:

No, I Don't Care If I Die At 12AM, I Refuse To Pass On Your Chain Letter. ▪ I Am Fluent in Sarcasm ▪ Brynäs ▪ Så funkar det ▪ C# ▪ .NET Programmers ▪ MSDN geekSpeak ▪ Jesus var en hamster ▪ Anonyma språkpoliser ▪ If You Can't Differentiate Between "Your" and "You're" You Deserve To Die ▪ I judge you when you use poor grammar. ▪ You know you're Gustavus Adolphus of Sweden if... ▪ I Secretly Want To Punch Slow Walking People In The Back Of The Head ▪ Älska löpning! ▪ for oss som ser på Tour de France ▪ After Lance Armstrong Quit the Tour de France I Lost the Will to Live ▪ Appreciation of Cycling shorts ▪ American Cycling Needs a Sponser ▪ Polhemsskolan, Gävle ▪ Högskolan i Gävle (HIG) ▪ Gävle ▪ Stora Sätraskolan ▪ Agile and Lean Development Community ▪ Sluta särskriv! ▪ Vetenskap och Folkbildning (VoF)

Stuff

Peter's got a lot of stuff. Today, when I organized his clothes again I found more stuff. Toys that he hasn´t grown out off but hasn't played with since we rebuilt his room. He never missed the stuff and I didn't either. I just let him seek through the box and pull out the things he's interested in. The rest will be retired today, (Yes, I've also seen Toy Story and the pain of retired toys but the clutter is horrible when a kid has too much stuff).

At Peter's daycare they changed staff this summer. The new gals said they were going to make it more cozy. That meant throwing out a lot of the stuff. The result: the kids got more relaxed and got to appreciate the remaining stuff more.

So, what did I get for little Pete on his birthday? Absolutely nothing, except me. And my time. The greatest gift of all for an emotional little guy. (My need for buying stuff was resolved by me asking the staff at daycare if there was something they needed, and of course there was.)

Autumn running

I had to wear two shirts this morning when I run to work. And I wore long pants. And gloves. And I had a winter jacket in the rug sack. It is autumn and it's cold. It's wet. And I just wish it was warm again. Why did my stupid ancestors have to walk all the way up here? Why not France? Or even Germany? Italy is nice. Wonder what they run from? Better not think about that anymore.

Week 2 with postits

If you wonder how the postit backlog is working, well it is. But I don't feel comfortable with it. I still don't get the overview I want and I have to do a lot of manual "head counting" of the postits. I do keep the breakdown chart updated but for us, having a team where half the guys work half time and the working days differ a lot between days and week, the chart doesn't say too much.

A good thing this sprint is that everyone is really working on the most prioritized tasks first. I can immediately see if a low prioritized task goes up on the On-going board.

So, what happens next month? I'm not sure, but I'm leaning towards renewing the trust in Sharepoint 2007. If this happens, I hope it will live up to my expectations. So, what are they:

1. The site works when I access it
2. The site works when I access it
3. The site works when the rest of the team access it
4. Our IT guy don't get burned out again
   

Microsoft Mobile ISV day in Kista - conflict handling with OCC

On Thursday, I and one of the developers went to Microsoft's event on Mobile development. It was a bit weird, both covering the very basics (see how easy you can drag and drop the controls to the form) and quite specific tricks (if you use this undocumented resource and X you can use this nifty functionality). Most of the participants were active mobile developers, though, so I believe the later kind of tricks were the most appreciated.

We were mostly silent, just listening to the tricks but also the questions: what are mobile developers fighting with?

One of the most important questions are of course conflicts. If you have (like we do) occasionally connected clients which works with the same data, conflicts will occur. When the question came up, the guy from Microsoft just said that conflicts on sync to the mobile device is no problem since the data comes from the server and the business rules on the server should fix all conflicts when the client syncs to the server. Hey, deleting the conflict is not handling it. You might say they didn't answer the question. But yet they did: you cannot rely on the standard tools when building a OCC solutions. You have to build for handling conflicts. If you're not satisfied with the standard solution: delete conflicting data.

The mind of a three-year-old

I can't stop being amazed at the development of little Peter. Just this summer you could see that he imitated the bigger guys but now it's his fantasies. This has also brought on fear. Since he can imagine stuff, he also wonder about things that are scary. A toy that have to be outside during night. A scary car during the evening walk with the dog. And you can't simply say something: he picks it up so fast and draws his own conclusions. Amazing.

Sometimes I wonder why some people seems to loose that imagination: they just think inside the box. The only thing that seems to be left from that three-year-old is the fear. I often meet people who are good at commenting and having all those opinions on different stuff. "Oh, no, that is all wrong." But they never come with the original idea, the fantasy.

Others never stop fantasizing. An old friend of mine has his imaginary friends. When he's bored he hocks up with them and spend some time in his fantasy world. He knows it's not real, but he think it's fun. Did I mention that he's one of the most creative guys I know?

The price of customization

An important feature of our case management system is the possibility of tracking key values. So to enable different organizations to track different key values the attributes on our concepts are customizable. Not only which fields and their data type, but also the work flow for the different fields and the possibility to set which fields are available to different user roles using different clients. In other words, we can set which fields a resource can view on a form and which fields a group leader sees on the "same form".

The cost of developing this is of course not trivial but the biggest cost will be to create business skins for our customer's different lines of business. With the current product not having this feature the consultants had X fields to play with and then it was easy. They just put the different values in the available holes. But now they get to dig their own holes. And planning which holes are going to be dug will be a great and exciting challenge for our dear consultants. It's no wonder that Microsoft only have a few skins for Team Foundation Server (eScrum and MSF For Agile 4). Lot of thinking behind those templates.

Asking why why why why

The famous Toyota four whys are a good rule. Take for example the critical bug we had in the latest release.

1. Why?
Well, it wasn't tested

2. Why wasn't it tested?
We tested it manually at the beginning of the last week, but not after the final critical check-ins.

3. Why manual test?
There are no automatic tests on that feature.

4. Why???


And here we come to the core of the problem. The problem is that we lack automatic tests on critical functions. And even if we fixed the bug now, we're open for the same bug next month. So, we didn't fix the problem. We fixed the acute bug. And that is the problem...

All the n*ked boys...

You who only have boys (or buy stuff for boys) have probably noticed it: when you walk into a store with clothes for children there are so much more for girls. It's strange, because when you go into a toy store, there are about 50% stuff for boys. And I do believe boys have the same need for clothes as girls. I desperately wanted to buy some underwear for little Pete this week. Him being almost three he needs a small size. Couldn't find anything. Same with gloves. But there are so much girly stuff out there. I don't care if I get to buy things for girls, Peter is wonderful in red but the little skirts and the sharp pink even I wouldn't wear.

Today I went to an outlet and found some winter shoes, half price. I didn't even reflect on color: just found his size, oh, red, and went for the cashier. He was helping another customer and I couldn't miss overhearing him commenting on the subject boy's shoes. Yes, they brought FOUR times as many girl's shoes than boy's shoes. And yes, they tended to have a little more girl's stuff left in the end but still, more clothes are bought for girls. Can anyone tell me why? I simply do not understand. Because I've not seen any n*ked boys at Peter's daycare. Or perhaps they all, in secret, like little Peter get to wear red shoes with flowers this winter.

Fuzz balls and tests

We just introduced a beer glass to our room. We get to put a fuzzy little ball in the glass every time someone writes a new automated test, helped someone else or perform code review. In other words, work for the team and testable code. We also have a thorn glass. If you don't update a test or create a new during refactoring, you get to put a ball in that glass. If there are balls in the thorn glass, you must first empty that glass before you get to put new balls in the beer glass. When the beer glass is full, we get to drink beer.

Release DURING the sprint????

Yesterday we released... During the sprint. After the sprint start a critical bug was discovered and the planned testing by our own Operations division could not work with the bug. The PO just wanted us to fix a new release. A new release costs. So I asked what we would cut from the sprint. He didn't understand. Finally he got it and we cut one of the new planned features.

It felt like I was the bad guy, not just handing him the fix, but in retrospect I should not have agreed on a release at all. You don´t release during the sprint. You just don´t. I googled it and I couldn´t even find someone writing on the subject. But now I know. And knowledge is king.

Our CEO and Ballmer

My CEO is giving a speech during Steve Ballmer's visit to Stockholm this Friday. He's going to give a ten minute speech on our SaaS. Very nice. I'll keep my finger's crossed for him! And for sales guy: keeping it to ten minutes.

First day using postits

So, first day of sprint (after sprint start). Back to the office. First day using the postits for the sprint backlog. One of the guys is really against it. Keeps looking annoyed. Doesn't think it's going to work. But I explained to everyone. All the sprint points have their own postit. So if a task consists of more than one sprint point there are multiple postits with the same text. When the guys divide it into smaller tasks they can print this on the different postits.

Why? Well, when you start the day you have to take a postit-note. There is some consumption and you have to know which budget you're using. So, if someone feels that something really needs to be done and it's not really on a postit, he have to discuss it with the others so we can decide if it's worth cutting something else to make it happen. The postits become a valuable asset. Of course there is bargaining. Of course there's discussion. But like for the PO discussing in terms of how much something costs in money, this makes it very concrete that we need to do the stuff written on the sprint backlog. And yes, if we during a task feels that the task is not correctly described, we can do it in another manner than discussed in advanced. But the use cases needs to be addressed and budgets held.

Sprint start with pain and suffering

We went to one of the team members on the sprint start. We've made this a habit and we all like being away from the office once a week. It really feels like we can concentrate.

Yesterday's training really hurts. The new guy at the strength work out did all the muscle groups in a fast pace, without stretching. I look and feel like an old woman. And today's team event was soccer. The pain combined with me being lousy at everything that includes a ball made it an interesting event. I got to fly when I tripped over one of the guys knee. It looked and felt awesome. Incredible that you don't hurt yourself in those events. I also tried playing hurt and it worked. Just thought about those soccer matches I've watched, laid on my back and looked really hurt. It worked.

Back to the sprint start then. The bad thing everyone complained about was of course the missing sprint backlog. We had it on the intranet, which has been failing for most of the month. And that was a nuisance to everyone. People liked the one page objective document: one page with really large text naming the sprint objectives, who's responsible for each objective and how many sprint points involved.

It was nice reaching all the objectives, but bad that one of the objectives lingered and was finished to late to be properly tested. A lesson for us all to this sprint.

Well, now I'm going to go and feel sorry for myself for a couple of minutes.

Collective ownership

What if we decided in our family that I owned some of the rooms, my husband owned some of the rooms and Peter the rest? Well, cleaning would be even more a struggle. And who would take responsibility for the plumbing or the electricity. And buying oil?

In all societies there are collective ownership. This is needed for common needs. But that doesn't mean there is no individual tasks. The difference in a situation of collective ownership is that the responsibility of the individual task is so much bigger. You can't only take your own task in consideration: if you also have collective ownership of the end result, you must also weigh that in.

We've always had the discussion of collective ownership of code in our team. Some of the guys literary see a red flag when the issue is up for debate and the references to socialist societies are easy to hang on to. But a team is more of a family and a family is a joint venture. And that means some kind of collective ownership. And that does not mean we want Lenin hanging around.

VS 2008 beta 2 installed

Today I installed the beta 2 of Visual Studio 2008. It was amazingly pain free for me. Of seven installations, half was completely pain free. But TFS 2008 will have to wait. Besides us developing the new product suite for our company, we still have the current product. It will exist for many years still and they won't migrate any time soon. So, before we move on to .NET 3.5, we need a new TFS server. We also need to verify that we can deploy on our clients, Windows XP, Windows Vista, Windows Mobile 5 and Windows Mobile 6. So, no migration on Friday. But we did create some test projects and found some nice features we're dying to implement. But for now, we just have to wait.