Taking care of people and business

It is for a good reason that the agile movement should be based on the agile manifesto – I think it’s a sign of strength to be able to state what basic principles you base your work on. But why do I find this so important?

Independent of if your process is packed with rules, artifacts or roles or if these things are kept to a minimum and independent if you use agile or waterfall, situation arise when the process and the rules make more harm than good. If you then have shared values, these can guide you so that the rules don’t become more important than the outcome. “This is by the book” is in my world a sorry excuse for not having good arguments for why you act as you do. Even if something is in a book, you should not hide behind that. Of course there are corporate rules which you must decide to follow as being part of an organization, but values can be helpful in stopping people using these rules for their own purposes, that being laziness, fright, power lust, uninterested, uncertainty or what ever is behind hiding behind books and regulations.

It is my opinion that processes and rules should help us reached the highest sustainable productivity in order to reach corporate objectives. In order to do so we need to take good care of our business and very good care of the people which are a part of this business: customers, partners, employees, etc. Not that we should be afraid of hurting their feelings and therefore tiptoeing around problems (this is in my opinion quite the opposite of what you should do) but every time you hit someone with “this is by the book” they will not reach the highest sustainable pace. They still don’t understand. There is also a good chance you kill their spark. Therefore People over Processes. In the agile movement we care about the people. That is why I agree that we should stop using the word resources and this is why we have loads of habits in the agile processes. But they are not there because they are in a book, they are there for a reason.

This is perhaps also why I now here so many complaints about methods like scrum. I hear more and more getting the feeling that many scrum implementations have lost touch with People over Processes and are holding on to habits which are not the best for the long term or the short term productivity and seem to be there just because they are in a book.

But I’m not working for checking off that we’ve followed all the rules in a book. I work for making holiday dreams coming true. What do you do?

Calculating the need for resources

Most of us need to calculate the need for resources but the question is what you calculate.

One thing you can calculate is how much resources you need to complete a task. The first question is of course what do you mean by completing a task. If you’re working with software development, is it the coding, or does it include all the things you need before and after the coding (branching, getting to know the code, writing tests, merging, validating test environment) and does it include stuff that other people do. Another question is if you say something takes 10 days, do you mean 10 days of actual work or do you mean days between you start with a task and when you end the task, the latter concept is what we call Duration in Microsoft project.

In other words you need to know
* The definition of done
* Decide if you calculate Duration or Work

The next thing is that you need to start thinking about the difference between cost of delivery and cost of creating. Lets say you have a task which takes 40 hours of hard labor to complete. Lets say your resource actually completed the task in 40 hours. But chances are great that he will bill you more than 40 hours. People take breaks, the help other resources with their tasks, they do other stuff. Do they report these side things on your project? You bet! Imagine the opposite! Two resources are working on different tasks but on the same project. First one of the resources want a second opinion from his team mate. So he strolls over and they talk things over for 15 minutes. Would you want all resources keeping track on stuff like that. This is one of the reasons we want team rooms but it also gives us a situation when tasks cost more than the cost of their delivery.

As we are budgeting our projects, I must surely keep this in mind. In my budget, I must take into consideration that this happens so even if I use the scenario that 60% of time is spent on tasks, I need to calculate that they work 100% anyway. So I need to take into consideration:
* The number of hours tasks take
* The number of hours tasks bill the project

In other cases, thing become more complicated. Take the product owner role. That person should sit 100% of his time with the team but he doesn’t have to work 100% on project tasks. He can do other stuff in the team room (as long as he can be pulled from these tasks whenever someone needs help and that the other stuff doesn’t bother the other team members). If you do have a product owner who works 100% in the project that is perhaps more of a warning sign: you might have a product owner proxy or someone who’s not involved in everyday business work.

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.

Creating a mindmap specification

In one of my projects, one of the lead developers asked me for a flow chart, describing the things we’re building. Far from the scrum product backlog, yes, but I decided to give it a try.

I downloaded XMind, a free software with a PRO version with really useful functions, but since I’m just testing the concept as a product owner, I decided to test the free version.

The result, many hours later, is a number of connected flow charts which all looks something like this:

I started with setting up the basic flow chart, and identified the main steps. All these main steps were given their own page in the workflow workbook and then I started drilling down. I looked at all steps and identified which functions I wanted to be available from that step and if there were any special scenarios. To help me out, I have the work from our user interface designer, so all I had to do was translate his work into this flowchart and identify these special scenarios. Well, “all I had to do” is perhaps to simplify the task. I will not hide that it was hard and sometimes gruesome work. For each step I covered, I identified more special cases which I need to find solutions for.

But after a while I got to really like this approach. I focused on one step at the time. Took a good look at that step and tried to think about if I’d really seen all the ways to which one could come to that step and I tried so see which steps were possible from there. The nice little note functionality made it possible to add all those special scenarios and questions.

In a couple of hours I had documented all those discussions we’d had in the project group and I would say that what we have is a number of user stories, but in another format. I can better see the links between stories, and it’s easier to track what the story applies to, without having to write too many X:s under “As a X” if I’d used the user story format.

Also, the diagram does something that user story cards don’t: it puts the story in a context. Yes, a user story does say why we do the story, but it does not show what happens next and what we take for granted has happened before.

So, what about the output? There is a HTML export function which exports not only the image but also the comments and pictures.

WHat about the next step? the next step is to see if the developers like it or not. And if they do, we have to find a way to build using this. But the first step is to see if this is the way to go. What do you think?

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.

Are you consistently bad?

We need to be consistent! We need to be reliable!

Aren’t that nice?

But then consider Sanjiv Augustine’s wonderful statement from APLN:

(Source Jesse Fewell)

A team can be consistent and reliable and still deliver garbage. If you always deliver garbage, you’re pretty predictable, aren’t you? You can truly rely on them delivering garbage. Business as usual.

I have a childhood friend who works with a supplier who he really can count on. He can count on the system failing after each upgrade. He can rely on the support functionality not being able to fix his problems after the delivery and he can be sure to have a lot of angry users on his back. After each upgrade.

What bugs my friend the most is not the individual problems. It’s that no one seems to care that his company loses money every time they upgrade the system. He’s annoyed by that nothing gets better. He feels like the supplier sees the problems as normal. Well, they are since they are consistent, he laughs with panic in his voice when we talk after an upgrade.

I’ve told my friend that he should abandon the supplier, for his company’s sake but mostly for his own health’s sake. And this my recommendation: if you work with a supplier who sees garbage deliveries as the normal state, get out. And if the supplier thinks there are different problems each time and blames this and that, well that is no excuse. If the process consistently produces garbage, it does not matter if the garbage is of type A one day and B the other. It is obvious that the process allows the garbage.

If you instead work at that supplier, you should do something about it. The competition is hard out there and blaming this and that does not help. Look back at your latest deliveries and figure out how many critical errors your company has introduced to your users lately. And no, don’t blame the integrators or the installation guys or even the users. Look at the end product.

Are you proud or are you lining up arguments why you were not to blamed for these incidents?

Jesse Fewell have on his blog presented how Sanjiv Augustine has described his idea of an Agile PMO and how such a solution can fuel continuous improvement.

This is just one take on the problem and it’s handling. Because this is not a problem what can be solved, it’s something you need to work on all the time and on all levels. So what if you have 90% code coverage, work test driven, use scrum and have continuous integration? These are great tools among other tools but if you still work in the garbage spreading business what’s the use of you mixing the garbage with some fine wines?

The agile leader – a master or a servant?

I guess Depeche Mode didn’t think about Agile leaders, product owners or software development when they wrote the lyrics for Master & Servant:

There’s a new game

We like to play you see

A game with added reality

You treat me like a dog

Get me down on my knees

We call it master and servant

But when you have titles like “scrum master” and “product owner” you might think that people holding these positions are the masters, trying to squeeze every drop out of the developers.

The example from Ester Derby’s blog about such a manager is probably not that uncommon. A new manager, eager to “cut costs” killed her team in the long run:

People who were confident in finding new jobs left. The people who were afraid they didn’t have the skills to face the job market hung tight. There were rumors of layoffs. Fear lead to people to choose CYA over do the right work the right way. Competition undercut cooperation and collaboration. The VP to an ax to department budgets. The balance sheet looked better (in the short term), but costs went up.

It is always tragic when you here these stories. What we need is leaders who wants more. Leaders who takes pride in the team. Leaders who don’t have to be the master but leaders who can be the master (no, don’t whip your scrum master, I never said that ;-).

When I and Sally Elatta started discussing leadership during an e-mail conversation yesterday, she introduced me to the concept of the Servant Leader. The term was coined in 1970 and described as [cite from wikipedia]

The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature.

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society? Will they benefit or at least not be further deprived?

The idea is older, for example Chanakya wrote 400 BC. [Cite from Wikipedia]:

“the king [leader] shall consider as good, not what pleases himself but what pleases his subjects [followers]” “the king [leader] is a paid servant and enjoys the resources of the state together with the people.”

We’re pretty far away from The Prince!

The key question for any manager is : Are they there for you or are you there for them?

The servant leader knows that he’s there for the team. The whole scrum idea of removing impediments is based on this idea.

It is therefore so interesting that more agile leadership trainers like Sally Elatta are talking less about certification, the techniques of method A or B, and more about these key character traits of the successful leader. If the introduction of agile methods have revolutionized software development, I believe the introduction of the servant leaders will be an even bigger win. How many “agile” projects fail because of failing management?

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!