We are the knights who say [process artifact]

The other day on Agila Sverige, we discussed agile in an environment where Operations have implemented ITIL. The discussion moved to why ITIL is implemented. Operations want a stable production environment and all changes are a risk to that environment. By keeping that gate and requiring all these artifacts, chances are greater that no one just install something which doesn’t work.

Since it was also Monty Python Day, I couldn’t help thinking about this wonderful sketch  and I cannot help but recognizing myself when I’ve tried to get something done. I ask for something and someone shoves a process artifact down my throat. You said what? What did I need to do?

But the next thought was inevitable. How many times have I’ve been that knight who said Nii! in the eyes of a user, wanting some new functionality.

What I said: “No, you will have to wait because there is no product backlog item and the sprint has already started. Get it registered before the next release planning meeting and we can estimate how many story points it will require”

Interpreted as: “No, I won’t let that pass because I want you to bring me a shrubbery before I’ll get it fixed.”

We have all gates and artifacts for a reason but in too many cases we don’t explain this enough or perhaps really know ourselves so instead we just babble out one (or many) of those process artifact names in the face of the one making that requirement.

And the second part of sketch is also so telling. When the stakeholder finally got all that documentation ready in the specified form or formed the requirements as a user story, the process has changed and now they have adapt to that. Imagine all users getting used to scrum vocabulary now having to grasp kanban…

We might all this for a good reason but it is important that it doesn’t feel like everyone need to cut down a tree with a herring too.

Open agile = Scrum meets 7 habits?

After having experimented with waterfall, MSF for Agile, scrumbut, scrum and now kanban, I’ve still not gotten hooked on one of these methods.

What I don’t like with scrum is

1. the terms – business people don’t understand what a scrum master is, etc

2. Incapacity to react to quality issues, changes in the sprint. When I read Henrik Kniberg’s excellent work on Scrum and during Mike Cohn’s product owner training, it became all but too clear that scrum has a hard time reacting to bugs and quality defects. Not to mention sudden changes to priorities.

3. Problematic when the resources and the number of resources change. A key value is velocity, but which value does this have when the team changes every sprint or perhaps within a sprint?

 

When it comes to kanban, I can see that we address these problems but other arise. My team members have felt that they don’t see the long term objectives and there is no celebration of when we’re done. The sprint review makes a clear finish line and with kanban lacking this, many feel that they don’t know what we’re working with.

 

A couple of weeks ago, I stumbled upon Agile Advice’s description of the differences between Open Agile and Scrum.

Oh no. Not another methodology.

Not that I don’t think we should improve our processes and methods, but I’ve spent too much energy debating methods when the problems have been elsewhere: lacking leadership, quality focus and programming skills. I probably need to clarify what I mean. When the leadership has been failing, the quality has been poor and the programming skills have been too poor, people owning these problems have turned to pseudo discussions concerning the methodology and spent the energy on the method instead of fixing the core problem.

But back to open agile. I left the page open in my browser, trying to find the time and interest to read it and this morning, having woken up before everyone else but the dog, I did.

First, I felt that this was just scrum with other terms and even if I don’t like the scrum vocabulary, I would never consider a new methods just because of this reason. But there were some lines in the description which caught my eye. Especially the values and the ability to react to quality defects during cycles. So, I actually took the time to read the Open Agile primer.

Again, a positive surprise. After landing in an organization with active leadership and value driven objectives and strategies, inspired by 7 habits and Lean, I’ve found that there is more to a method than just terms, process diagrams and artifacts.

I’m not sold on Open Agile. Yet. Because I’ve never tested it and I my experience is that all methods have their flaws and draw backs. But perhaps I get a chance to test this is an upcoming project.

What’s up for 2010?

I’ve just completed the first two days of work for 2010. This is a hectic period for my company. Traditionally, January is a month for summer vacation planning, and this year we’re exceeding the previous year’s booking by a wide margin: last week we had 40% more bookings than the previous year. Great news and a real test of our web sites.

But it’s also a time to think about other challenges. On the personal side, my son is going to preschool this autumn. Myself, I’m planning to complete the short version of La Marmotte, a amateur cycling race in France. 76 km, 2500 m gradient will give me something to work to complete.

Work wise, I know I will be working with 7 habits, empathic leadership and our ongoing struggle to improve our business using our processes and software solutions. I will probably experiment more with kanban and behavioral economics. Finally, my line of business is of course struggling with the challenges of sustainability and the climate question.

Do I need something else? Probably not. I guess I have stuff to do.

The most prioritized things

When we now move into 2010, I get to summarize my first year at TUI Nordic. It’s been a wildly interesting year and to be frank; I had no idea that I would change so my views, ideas and focus in such a relatively short period. To keep it short, I’ve come to believe that the main focus for product owners, project managers and such should not be in the techniques and methods of software development.

Yes, the product owner should be deeply involved in scrum or kanban and work daily with the team. The product owner should be as fluent as the best of the team members in the chosen methodology, but the methodology is not what brings the ultimate success. What brings ultimate success is understanding what brings business value, find ways to prioritize and to make developers, stakeholders, sponsors and customers understand why we prioritize in a certain way and how things will work. When I say that this should be the product owner’s main focus, I say that this is where his heart should be.

What brings business value?

In so many positions, I have after a while revaluated what the business is. Too many times, the by the management canalized  description of the business has not been the truth. Not that they lied, it was more like they didn’t understand this fully. Sometimes they don’t understand the complexity, sometimes they are way off the truth, focusing on the wrong stuff and things don’t bring business value. But the truth is often more complex than first perceived.

When I moved to the leisure travel business at TUI Nordic, I had no idea what the business was. Yes, I knew it is about people, free time and holidays away from home but I had no idea it would be so complex. Just before Christmas I was given a research assignment by my boss and while completing that task, my views were overturned again.

The road to learning what truly brings business value is empathy and social intelligence. Empathic listening to people outside your comfort zone can change your paradigm. Everyone can place a priority number besides a product backlog item but it’s only the empathic listener who can make the best priorities.

How to make propositions a reality

Software development is all about bringing ideas to life in the form of software development. Using a software development methodology is all about techniques to make things becoming built. But developers need to build the right things so that they do the right stuff the right way and everyone else involved need to understand what is built, why and how. Scrum and kanban gives you tools but no tool is better than the person holding it. Again, the leadership and empathic listening is in my view crucial.

It’s not about being the office clown

Don’t understand me wrong. I don’t think that product owners should be dancing about in the halls of the office trying to become the most popular guy on the block. I’ve had such a boss who acted like a speeded rabbit, trying to be cheerful and optimistic. Since he had no depth, it was actually more depressing to see his faked smiles and hollow laughs.

It’s about being like Gene Kranz, here depictured in Apollo 13. You’ve probably seen the movie, but even if you have, sit down and think about the leader in this short sequence. Wouldn’t you like to work for this guy and don’t you think he would make an excellent product owner?

Mistaking group thought for collective intelligence

Sometimes you become a part of tightly knit team. You seem to almost think the same things and solutions just comes flowing. What you probably have felt is something Daniel Goleman in his book Social Intelligence refer to as Rapport. It’s one of the most rewarding social connections and the ability to Rapport is a crucial part of social intelligence and well being. And often a team with Rapport can be very productive.

But there are also risks. As James Surowiecki points out in The Wisdom of Crowds, this forming of the tight, homogenous group gives ground to group thought in a negative sense. Surowiecki gives a lot of examples of when group thought stops innovative ideas from being realized or even thought or expressed. The fear of breaking the group thought is perhaps not obvious or even realized, but is there. If you break that precious bond, you lose that comfy feeling. We’ve all been in that situation too. We have that small, tight group and in comes the Outsider with the Outsidish idea. What an idiot. He knows Nothing. We’ve already tried that. But we are the experts. And so on. The outsider must in many cases chose between aligning and thereby just provide ideas which are in line with what is acceptable ideas within the group or stay an outsider.

What can be elusive is that the tight group might not be without conflicts or debates. The principle is that the alternatives are just within the acceptance range of the group. And thereby many great ideas are never explored.

According to Surowiecki, it is key to keep groups heterogeneous to harvest the collective intelligence instead of the narrow group thought.

These books really got me thinking about groups and teams. Agile software development is all about creating the most business value for the least effort and here is probably an important key factor. How to use the collective intelligence and still have the comfort and calm which Rapport brings. And how to minimize the negative effects of group thought. Working with the 7 Habits gives me a lot of tools but I will probably struggle with the Scrum team idea. Scrum teams are supposed to be cross border but how often are they really? And if they become true teams, how homogenous will they not become? Not that Kanban or other methods are better in this perspective.

Well, I have something to work with next year!

Kanban Kick Start

Simply wonderful description of Kanban. Thanks, Crisp!

Does the productivity decline if you don’t time box?

Having just read Dan Ariely’s excellent Predictably Irrational, I have a lot to reflect on. On my latest project, we’re using Kanban, which means that we don’t timebox, we don’t use sprints and we don’t estimate. But does research support the notion of excluding the concept of time boxes.

Dan Ariely made an interesting study.  He had three groups of students, which all were supposed to hand in three papers during a course in Consumer Behavior. He gave the three different groups different instructions concerning these papers.

Group 1:  They could hand in the papers at any time of the semester. The student would themselves set the deadline for each paper. If the self proclaimed deadlines were not be met, there would be a penalty. All students had the option to set the deadlines on the last day of the class but they could also use the deadlines to force themselves to start working earlier and work during the whole semester.

Group 2: This group would have no deadlines and they could hand in their papers at any time and there was no risk of penalties if they did hand in their papers before the end of the class.

Group 3: This group were given specific deadlines for each paper and there penalties if the deadlines were not met.

Which group do you think got the best grades?

The third group had the best grades. The second group got the worst grades. Ariely points at our tendency to procrastinate makes us delaying important tasks and the best way to avoid this is a formal figure giving us specific deadlines. But the study also shows that if we ourselves are given the option to set our own deadlines, this helps us to evaluate this risk and handle it.

If you look at the deadlines in group 1, the ones who spaced their deadlines did as well as group 3 while the students who placed their deadlines at the end of the semester.

So, what does this mean for software development? Does it mean that removing the iterations, independent if you work waterfall or kanban, increase the procrastination? I need to think more on this and this will for sure be a subject on our next team meeting.

The mandatory stuff

When I have a story writing workshop or some other brainstorming activity, one important task is of course to learn what is really important. Since I’m in the mental moving from scrum to Kanban, this has become more than important. It is crucial.

So, these are my phases of a story writing seminar:

 

The objective

During this part, we discuss the overall objective of the project. What we’re doing and why. I try not only to explain what the customer wants but I want the team to really make the objective theirs. I want them to form their own Commander’s intent so they not only know what the objective is but also what it’s not. We don’t have time for nice to haves. Most of the time…

 

Brain storming stories

This can be divided into a number of separate parts. If it’s a new group or the developers are not fully aware of the business, this should start with the discussion of the different user groups or personas.

Then we move over to the brainstorming of stories. Presented with the objectives and the user types, everyone gets to write their own stories. A tips here is not to push the user story format. When you make it mandatory, people will debate you, but if you instead say that you want to know not only what but why and for whom and that this is an excellent form for that, you get more in a story format. Don’t be afraid to see developers and operations as users. Some stuff you need for these groups too. And writing stories with yourself as user type makes developers learn how to use the format.

 

Grouping stories

After everyone has written their stories, I usually send two or three team members to the whiteboard to group the stories. I let them decide on groups.

After that we say the stories out loud. We select the stories we need, sometimes write some more and some of the stories are discarded after we explain why this is not necessary.

 

Highest priority

I then get everyone to mark on each story if it’s mandatory or not. Everyone get’s their saying.

We then sit down and I pick up the stories which at least one person said was mandatory. I then ask the following question about each and every story:

– If we don’t do this, the project will be worthless and unsuccessful?

This will make the number of mandatory stories much much smaller. When I was more junior as a product owner/project manager I thought the mere asking if the story was mandatory was enough. But the important question is if the story makes the difference between success and failure.

If a story is still considered as mandatory we look at the objective. And I ask the question:

– So, how will this help us reach the objective(s)?

A number of stories will lose their status as mandatory right there and then.

What is the first thing to do?

The next phase is to understand what we need to know where to start. If you have multiple sub groups, you should ask each group what they want to start with. Now the team often remember The Other Stuff, as development and testing environment, setting up build scripts and all that so be prepared for some extra story writing.

When every sub group has identified what they want to start with, they must say if they are dependent on another group to start with their first task.

If the groups depend on each other, use The Theory of Constraints to specify the priority. With that I mean that you should try to optimize the usage of the bottleneck resources.

Is this it?

This is an exercise which should be done regularly. As long as you have stories, you can focus on the next most prioritized items but you will need to go through all phases many times during a long project