A story of growth

My son really loves baking. From an early age, he loved hanging around me in the kitchen, eager to help. Of course, in the beginning his help was of no help to me in my baking. Then, I had three options:

• Since it took less time, I could have done everything myself
• Even if it took longer time, I could involve Peter is different tasks, having him learn the stuff.
• Combine the two strategies
  

I went for the last strategies: I involved Peter in tasks which he could learn to master and explained to him which tasks were not suitable to him and then he could only watch. Of course it took longer time and I chose bakery which weren't too complicated.

As time has progressed, so have Peter, and on Sunday, he was finally making a net value. We baked some cinnamon rolls and 3 kg of home made lasagne to a friend who is giving birth this week. Peter took care of melting the butter, taking out the forms and placing the rolls in the forms. He made his own rolls and he really helped me making the lasagne plates, including fixing the dough.

Imagine his pride when he could serve his father his very own cinnamon rolls and guess how much better he eats when he's cooked the meal. Giving responsibility is enabling confidence.

Are you accountable?

Mike Cottmeyer discusses the combining of the "traditional project manager view" and the "agile leader view" in his thought worthy blog post on accountability.

One very interesting part is when one of the team members says the following to Mike (then new to the agile mindset):

"you just get what you get when you get it."

This is of course true. In all projects it's important that the participants do their best to make the "what" as the right stuff to the right quality and that you get the most right stuff to the right quality as possible. In other words; people do their best to increase the product increment.

What Mike was really worried about was that people didn't do their best, perhaps slacking, perhaps working on other projects or just the wrong stuff.

In other words, he wasn't sure that he count on the team doing their best on his project. Why do project managers feel like this: that they cannot count on people doing their jobs? Are they evil not believing in people or are the participants not to be trusted.

Trust does not come automatically. We all know that. But in agile projects, trust is a necessity. The business people need to trust the developers knowing how to build stuff. Developers must trust that the business people tell them which problems they need solved as soon as they know themselves and that they say when they change their minds.

Managers need to trust their groups doing their jobs. Because everyone on an agile project need to be someone you can count on. That does not mean that managers should stop managing. That just mean that a good manager does not need to scare people to work and they people with a good manager work independently if he's checking on them. He's making sure that things run smoothly and that the team know what they're supposed to do.

Before going agile, make sure the trust is there and otherwise make sure to build trust in your organisation. A good start to get some ideas on the subject is of course reading Five Disfunctions of a Team by Lencioni.

And no, trust is not confiding in someone. Just because a team member told you something personal in confidence does not mean that he trusts you or that you trust him.

Another thing to remember that trust is not absolute. I trust my son being able to make the different exercises at gymnastics but that does not mean I trust him driving the car. You must have reasonable expectations and not give unwarranted trust in someone.

Finally, an important question is how well you have trust in yourself. If you don't trust yourself doing the job, how could anyone else trust you? An interesting insight in this situation is the personal account by Dan Kennedy describing his career in the music industry in the book Rock On.

Go ahead and build some trust: be the person others can trust. Make people wanting to be trusted by you.

When technology rule the development

I guess few people in the industry are uninterested in technology, gadgets and things. I guess the interest in system development in many cases derive from an early interest in the gadget Computer. Embracing new technologies, tools and versions are often good for the creative process, and for productive environment, but this must be prioritized like everything else. The costs must be calculated as well as the benefits. A software project is not about letting the developers have a nice time playing with the newest toys on the market.

This is perhaps best illustrated in the story of The Works. The Works was supposed to be the first computer animated film. Ten years after the project started, they were still not done and one of the main reasons was that the developers too often got new tools and versions and felt that they had to start all over. When the project was canceled in 1986, only a few minutes of actual film had been completed. Another reason for the project failed was that the technology was not ready for what they wanted to do. And that is also an important lesson: only build what you can complete.

But don't forget that most developers are interested in the new things and don't say no to everything. But estimate the costs and benefits and put it on the list. Also, introducing the "new stuff" can be an excellent reward for a hard working team after they've accomplished something grand.

Thanks Hexmaster of Faktoider for sharing the story (here in Swedish).

Bright lights in a sea of darkness -are bright developers really so rare?

Yesterday, Mark Levison posted a very interesting blog post on the less productive developers. His post is as always thought worthy and I was already planning on writing about it today. He stresses the importance not starting the blaming game directly but looking at the reasons for someone not performing as expected.

This morning I also read two other posts on the subject of under performers, but from another point of view. They discuss the bad programmers. The bad developers might be productive, but what they produce is garbage. Jay Fields and Soon Hui both gives a rather dark picture of the state of software development. The good developers are like the bright light in the picture; few and shining in a sea of darkness. Is it really true that only 20 percent of developers can be considered good and the rest is crap? I hope not.

In a time of recession, the demands will increase the stress on teams and these issues can be the killer of a team, a project and a company. But before labelling someone as bad, consider reading Levison's blog first.

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

Division of labor - scaling up the product owner role

There can be only one. That is, there can only be one product owner for a product backlog and a team. You can split teams and have people part time on different teams (even if this is hard) but you must have one person responsible for the product backlog. Mike Cohn says 'one, wringable neck'.

How cute isn't that. But how do you combine a constant presence with developers to be able to make those immediate decisions with being out with the users to know what should be put on the product backlog?

One solution is the division of labor. The product owner takes responsible for stuff that is placed on the product backlog and can be up for developing. Let's say that the product owner is responsible for having stuff on the product backlog which covers about three sprints of development. The work consists of taking responsible for that the stuff describes what the users wants and is enough so that the developers can start building the stuff. Stakeholders should be able to change their mind and change the priority between this stuff without it having a huge effect. The product owner is responsible for the priority in that sense that the most business value can be built for the least cost.

But what qualifies for making it to the product backlog? In my organization, we call that role the product manager. You could say that he pushes in stuff from below. Of all those big chunks of stuff that are "in the future", which do we want to build in the coming quarter. The stories are bigger (sometimes called epics) and they are not exactly the stuff we want to build right now, but they are getting close. You can also say that the product manager is responsible for the road map for the product or the project.

What is important is that the product owner still owns the product backlog - if the epics and stories presented by the product manager isn't of sufficient quality (you don't know what he wants or the business value is unclear), the product owner must say no to taking up the stuff on the product backlog. If you have a role like our product manager, this must be seen as guidance for the product owner. For me to be able to do a good job, I need to know if that big chunk is worth more than that other big chunk. I don't have to think too much about the future, but there is someone who does.

Of course, to make this work, you need clear rules and suitable people. For our organization, the title product manager gave many an idea that this was a role "over" the product owner. That should not be the case, but the opposite is not true either. It's the perspective that differs: a product owner should reside in the present, the product manager should aim for the future.

There can only be one

Mike Cohn said that he seldom participate in a project where he'd found any use for digital tools for handling sprint backlog, sprint burndown and product backlog.

I've heard the same on multiple scrum seminars and even heard the phrase 'Oh, you have so much post its, you must be really agile'. As if there where some kind of corralation how many trees that need to be killed and how agile you are.

But the strangest thing is that the same persons who talk so warmly against our forests are often good at showing burn downs from Excel. I do not understand that. If the horrible truth isn't that many using postits also keep the info as a list in excel.

My experience from keeping double records of lists that changes all the time is that one copy is never up to date. And there is something that is more dangerous than lack of visualization and that is visualization of old or wrong data.

There can be only one! That is true not only in the 80's block buster. I want my stakeholders to be able to see the one and only product backlog or burndown. And since my boss wants that diagram in Excel and since we have developers who needs to work from home from time to time we can't keep postits visual to all users. Well, we could place a web cam in our team room but that does strike me as a really weird solution.

My team's main reason against using Team Foundation Server for keeping the backlogs was the visualization but the introduction of Elektropost's Scrum Dashboard even the most stubborn has accepted the solution and we've also started an interest in our services organization. I would really like our consultants tracking their project in such a tool and also visualising it for the rest of the company. And why not the customers?

Changing the TFS template

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

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

Daycare again and a move

Again, I spent a day at daycare. This time, I spent the whole day there. As I said last time, I don't understand how the staff copes. It's amazing. And it's also fun getting to know these wonderful three-year-olds. They are already little very different personalities. I'm exhausted. Station Bed is next..

Tomorrow, we're moving to another team room. At last. Well, things won't be perfect, but at least we'll have air to breath. And the ceiling height is higher, which in accordance to a report should affect our creativity positively.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.