Adding complexity

When I this week was trying to understand, analyze and then present a problem, I realized that many assume that all complexity is created equally, in other words it’s like just adding a new field to a table:

But in the case of my problem, the wanted new complexity added a new dimension to the system:

The increase of possible scenarios would rise exponential would we include the required functionality. The stakeholders hadn’t realized this, since they just saw the requirement as just another field in a table. This became clear to the stakeholders when I described the current scenarios and how many there would be after the inclusion of the requested added complexity.

I could also use the 3D model to visualize how this would work and then the stakeholders could evaluate if it simply was worth it.

I’ve realized just how important It is to clarify for stakeholder if added complexity means a completely new dimension or just added complexity in the current dimensions and how I better can visualize this to stakeholders. Without a picture and hard facts this becomes too vague for many to grasp.

How some piece of software started a very bad habit

I’ve never been a person who’d been late for meetings. I think I was late once to school and is the kind of person who really makes sure that I’m on time. We’re always first arrivals at parties.

But when I started working for my current employer, I started missing meetings and becoming late at occasions. I even have double booked meetings in my calendar. After having worked for nearly 15 years, one cannot help wondering what started this bad habit.

And it boils down to software which does not help me in the most fundamental way. When I’m invited to a meeting it is crucial to know if I’m already booked. I guess that this is just not me; most people have a problem being at two places at the same time. So, a calendar for professional use should probably warn me directly if I’m invited to a meeting when I’m already booked in my calendar.

Also, if I make a booking, it’s good to know if the participants are available or not during the time in question. And again, this is hopefully not just me but a universal need for everyone.

So, what happened was that I started using the calendar in Lotus Notes, and who ever is responsible for this system does not find this to be a fundamental need: I need to do some clicking before I learn if I’m already booked or if I try to make a booking when people are already busy. And if I accept or suggest a double booking, I’m not prompted or warned. I guess the product owner at Lotus Notes is a super hero with the power to be at several places at the same time, so I guess that is why he haven’t seen this need as a universal, fundamental need for the booking process.

So, what has sneaked into my habits during the months past is that I’m always double booked for meetings. Since I can accept or book meetings without this being flashed in my face, I’ve started to see it as less of a problem. But it is a problem and a bad habit.

But the lesson is more important than so. If we just imagine the product owner of Lotus Notes being that super hero who can be at many meetings at the same time, he can either realize that his reality is a bit different from others, why a need that he doesn’t have is really important. But one cannot wonder how often you just disregard a crucial need just because your reality is a bit different from everyone else.

Don’t forget to harvest the passion of the developers

Most of the software developers I’ve worked with want to solve the problems of the users. Many are real professionals with the attitude of a craftsman. Many are innovative about different solutions. And most of them love to write code.

If you take a developer who wants to solve problems, is a craftsman, innovative and loves to write code you are sure to hear loads of good ideas of what he could do, if he only was given the opportunity.

Many times, his suggestions are not highest on the priority list from the business people. And then you run into the situations when his stuff is never done. Yes, I know that there are other stakeholders who’s ideas never becomes a reality too, but this guy stands there with his hands deep into the code every day, thinking about those things he could do, given that he get the opportunity.

So, you should leave some room for that in your plan. For example, if you’re using scrum or another iteration based method, let the guys pick one thing if they are successful in a sprint.

If you’re doing kanban, you can be a little bit more spontaneous. The other day, one of the developers came up with a great idea. I could see the passion in his eyes. He really wanted to do it. And I could hear that he’d given the thought a lot of thinking (this proved to be correctly later). Since we’re in a situation where the next stuff on the list cannot be completed due to lacking resources of a specific competence, I was considering what we should do next. So, why not? So, I said to him to go ahead. Given that the stuff in progress is done, this will be next.

I think we’ll get so much more code/function/quality out of this than we would have if the stuff had been done with someone who didn’t think this was his stuff, someone who wasn’t thrilled about the idea. And this joy about his work will probably continue after his work with this is done. Just because now it’s done.

But besides from sometimes prioritizing the stuff the developers have passion for, one can also help developers becoming more passionate about all the other stuff. And that is best done (I think) by including them in discussions, requirements and story writing.

Do you use the Spoilt Brat Pattern?

One of the reason for why I started working for TUI Nordic was the view of the customer. Not that the customer’s always right but the customer must feel like he’s right.

All too often do people think that their customer is wrong or should blame himself for not being satisfied. He made the wrong choice, picked the budget alternative and still he has the nerve to complain about it. And when he do complain how many strive at making the customer go away/stop complaining instead of making him content. Sometimes it does not cost you anything. More often than not simple words and explanations can make the customer feel that his issues has been noticed and validated. Yes, you feel that your hotel is too far from the beach and that is why you paid less than the others. Do you want me to check if we can upgrade your reservation? That’s an example of what I mean, instead of making the customer feel stupid you can recognize his problem and find solutions.

And the same goes for development teams. You have a feature developed and when you deliver you find that the customer is not satisfied. In some cases they tell you that you got it all wrong, load and clear. In other cases they don’t use the functions. In both cases there can be frustration that you didn’t understand them but I guess there is also a sense of guilt. Perhaps they helped during specification and testing but it wasn’t until production they realized the problem. So what do you do?

Many turn to the Spoilt Brat Pattern.

Before I got Peter, I used to hate spoilt children. I still hate it, but now I have a better understanding. So, what is a spoilt brat? That’s the kid who gets what he screams about and he’s still not happy. He complains, screams that you got him the wrong one or that he just want something new now.

If you as an adult apply the Spoilt Brat Pattern you turn to the child and say “Hey, you asked for that one. You got it now, so don’t be so spoiled and be happy about what you have. Think about the poor kids in X, they would be thrilled about that one. It’s no fun giving you stuff, because you’re never pleased.”

Spot on, isn’t it. Hm. In software development this would sound like “Hey, we built it like the specification and you did approve to this during testing. Now you have what you wanted. Think about the guys in finance, they have been waiting for their features for a month now. Why should we develop things for you, you’re never pleased with anything.”

Well, yesterday an incident got me thinking. My son Peter really wanted a scooter after testing one at his cousin and a month ago, we went out and got one. I went to a toy store and there it was, blue and Peter approved of it. It wasn’t quite like the one his cousin had but there were no others like that one in the store, so we got this blue one. It looked something like this:

At home, Peter started using the scooter but soon, I realized he wasn’t pleased with it. And he stopped using it. I couldn’t understand why. So, yesterday we started talking about in a store. He saw another scooter and he gloated. So, I asked why he didn’t use his own scooter. This one was just the same, or?

                

But, he finally confessed, you cannot slide with his. Stupid mom as I am I stated that they were the same. No, said Peter. Mine has three wheels, so I can’t slide it when I brake. If I were a better mom I would probably hinder my son from sliding at age four, but instead I realized our mistake. Peter hadn’t understood that the third wheel would hinder him from making that daring stuff he wanted to do and I hadn’t even bothered to learn the difference between the two types of scooters.

If I had played the Spoilt Brat Pattern on Peter, I would have just said that he should be happy about his scooter. But instead I got him the right one instead and gave the other one to another child, whose parents wouldn’t afford one and who won’t do any sliding. Both Peter and I made a mistake by picking out the three-wheeled scooter in the first place and forcing him to use it would be of no good to anyone of us. But, and this is a big but; hadn’t he acknowledged that he himself made the original choice, this story would have had another ending.

So, next time your users are not happy about the features you’ve built, think if you’ve built them the three-wheeled scooter they didn’t really have any use for and try to fix the problem.

Kanban & estimates

Estimate or not? Using kanban is focusing on delivering completely done items and having as few items as possible in progress at one given moment. So, should you estimate?

When you discuss estimation, independent if you’re doing scrum or kanban, you have objectives (scrum term product backlog items). And to accomplish these, you have tasks leading up to the objectives. When using scrum, a relative value should be used for estimating the objectives (so called story points) while an absolute value is used for tasks. These are separate estimations which are also done during different occasions. You estimate product backlog items (or user stories) during release/product planning and you estimate tasks during sprint planning meetings.

Before you answer the question “estimate or not” you need to understand why you estimate and if that applies if you are using kanban instead of scrum.

The main reason for estimating user stories/product backlog items in scrum is to be able to plan your releases and to be able to prioritize. When you know the relative size of a story, you can more easily set a priority and if you know your velocity (the avergae number of story points completed during sprints) you can plan for approximate deliveries for your features.

The main reason for estimating tasks is to be able to decide on an appropriate work load during the sprint. During the sprint planning meeting, the team estimate how big tasks are and when the work load (estimated task sizes) matches the available resources, the team commits to the sprint backlog.

So, how about kanban?

Do we still need to plan releases and prioritize? Well, yes you do. These needs remain, so I do think you should keep estimating your product backlog. You cannot use the same definition of velocity, since you don’t have the sprints but you can calculate velocity as story points/week or story points/months.

Do we need to estimate tasks then? Well, since you don’t have the committing to the sprint backlog, this need is actually not there anymore. But another need has arisen. You can in many cases put in everything from very little effort to a lot of effort into a task and before you get started, you need an indication of how much work is to be spent. But you don’t have to be as specific as in the case of scrum task estimating.

Project objectives – how to use commander’s intent

In an earlier post, I discussed the importance of a Commander’s intent. Since I was introduced to the concept, this has brought me lots of insight and the power to ask the right questions to the project sponsors.

Let’s say that you have a project which has three objectives: one clearly operational (we need feature X), one clearly strategic (all our solutions should be Y) and a third which is somewhere in the middle. This is perhaps not that uncommon but often you don’t clarify that. But do think about if there are both long time and short time objectives, strategic or operational, etc.

And then, what you do is that you print these three objectives in front of the project sponsor and ask which of these matches the commander’s intent. That is if everything else goes wrong in the project: what is the one objective that we need to accomplish? If all plans fail, which objective do we turn to and work to meet?

In other words: is it better to miss the feature if we live up to the strategic objectives? Or can we disregard the strategy if we have to in order to get that feature.

It’s important to clarify this to all stakeholders from the beginning. There are always those who thinks that the strategic objectives that are most important and there are always those who thinks the features (functional or non functional) that are most important. But the one to make the call is the sponsor. He might not know this but if he don’t, you shouldn’t start the project.

Product Owner part of the team?

During the previous week, there has been an emotional debate concerning if the product owner is part of the scrum team or if he’s not. These are examples of things that talk for viewing the product owner as part of the team and things that talk against that.

Why view the product owner as part of the team

• Answering questions concerning the stories and requirements are part of the sprint and those tasks should be a part of the work.
• If the product owner does not see himself as part of the team, he will not participate in team activities as daily scrum, etc, and will therefore not be an active part of the daily life. Which result in developers making decisions since the right person is not available to answer the questions.

Why not view the product owner as part of the team

• To be able to make priorities, the product owner must be out with customers and users. He therefore does not have time to be availble on site and in the daily activitites
• If the product owner is there constantly, he will micro manage the developers

I’ve not covered all the arguments in these views, but I think that this catches a bit of the problem: to be able to make the right decisions, the product owner must spend his time outside the team room but to make the decisions come true he must be on site so that the developers don’t make daily decisions which contradicts the objectives.

So, how do I think you should solve this? For myself, I solve the problem with sore arms. What? Well, we have three floors and on each floor we have these heavy doors. So, I try to move between the floors as much as I possibly can during the day. I come to the developer’s room every day, to chat, to look on progress and if it’s possible: I try to help out with what ever I can. It can be arranging a meeting with a technical guru from a supplier, it can be testing, fixing with the scrum dashboard or just hang out with the guys. I want the scrum team to view me as part of the crew. A part of the scrum team.

And it’s the same with our users and customers: I try to take part of their every day activities. Just listen in on their discussions, frustration and happiness. And to help out in their daily work when it’s possible. Help out with small tasks, find out what is possible to accomplish, formulate a change request or something like that. To make the business people understand that I’m part of their team as well.

And what a joy it is to transfer experiences between these groups! How rewarding it is for a developer to learn that Robert can work more effective now with the new release. And how rewarding it is for a user to hear that Lisa could fix that problem so easily thanks to that really good formulated change request.

So, my answer to the question is yes and no. You should as a product owner have the mind set that you’re always part of the team. But you work on all the teams.

So, what do I cut? I try to work my own product backlog and try to do what brings the most business value to the product: in this case my work. Which means that what is most often cut is those long off site meetings which are probably very nice but which in reality brings very little value to my actual work. Which is to make sure that we do the right stuff in our projects. This can also mean that I don’t participate in whole meetings. People don’t have a problems if I from the beginning say that I actually don’t have the time but I can be there for 30 minutes or an hour. OK, I probably miss out a lot of nice trips and lunches but what is that really worth. Really?

The decision you didn’t know that you took

If you’re like me, not sitting directly with the developers, you might not think that you have the time to be there physically. Working for an international company, we have that issue to deal with. I wouldn’t call it a problem, it’s a challenge to have a product owner who never sees the developer’s during the actual work. One way to handle the challenge is that we who are available take the time to be physically on site.

You might just sneak into the room on the way from lunch or take that cup of coffee and drink your coffee standing next to a developer. Most of them don’t bite.

Every time you miss the opportunity to go into the developer’s room you should see that as an active decision, which you unknowingly left to a developer who probably wasn’t sure which option was correct. Perhaps it was just a small thingy, so he didn’t bother to call anyone. So he guessed and chances are that he chose the wrong alternative. Or perhaps just a not as good option. If you’d been there, the better option would have been "free" but a later change always cost more.

So, make the choice, take the opportunity when it presents itself and go and spend the perhaps most valuable minutes of your day. How many times do you have the chance to make so many decisions which are carried out at once in just a dew minutes?

A successful meeting

I took over another project the other day. The project hasn’t started and the problem was that we were waiting for some technical specification from a supplier. I was told that we’d been waiting for a month to get some information, but we still hadn’t gotten it. The business people are really eager to get going, so, you know…

I talked to the guy who’d been in contact with the supplier and asked him which information we needed. It turned out that we needed a specification for a certain function (X) so he could ask the operations team how much time this would take. It turned out that he hadn’t talked to the supplier, but a lot of e-mails had been sent between him and the supplier. He’s no technician and neither am I. I can admit to that I really didn’t understand what X was. So I asked if our techies had spoken to their techies. The answer was no. So, I called the supplier and asked if they had a techie to spare during an hour telephone conference. I sent all the e-mail conversations to our operations and then turned up on the meeting.

We discussed first and I asked what X was all about. And then the guys said that they thought it was something I actually know what it is but since I hadn’t seen this in other systems, I was puzzled that it had stopped the project. I asked if X was a requirement in our solutions. It wasn’t. Then we called the supplier and asked if the previous e-mails had been about X. It had. We then asked who had asked forX in the first place. Then it turned out to be that the supplier had asked if we wanted X. And there had been a huge misunderstanding that X, which we don’t want, was mandatory.

The meeting was over in five minutes.

Something are not suitable to discuss in e-mails and sometimes it’s better to leave the techie stuff to the techies.

Frustration over having to explain ALL the details

Have you’ve ever been in a situation where you think you’ve written a requirement or something like that and thought that no one can misunderstand or misinterpret what you’ve written and been completely wrong. It’s amazing how one word can be interpreted by different people. And when it comes to sentences. And many sentences. So, what happens when you’ve been in such a situation? Well, you try to be more clear the next time. And there is a good risk that you add more words. And the risk for misunderstanding just rise even more. Perhaps that will take gigantic proportions, like in this example from a technical manual, where the writer obviously have been misunderstood by a mechanical contractor in the past. You can just feel the frustration from the writer. "If he won’t tell the difference between a long and a short pipe now, I don’t know what I’ll do"