Archive for the ‘Management’ category

« Older Entries

Beyond Budgeting at LESS 2011

January 20th, 2012

One of the things that attracted my interest to LESS 2011 was the Beyond Budgeting track. Having read the book a couple of years ago, it is definitely a topic that catches my interest. And it was even better that the first keynote was presented by Bjarte Bogsnes, talking about how beyond budgeting is used at StatOil

As any presentation write-up, this is just my understanding about what was presented, so please don’t hold the presenter on to what I’m writing here :)

Why ?

The first question Bjarte addressed was why the need for something different. And I believe this sentence explains it all

January-December is artificial for business and just works for accounting. But this is not accounting

He followed by explaining that StatOil is always trying to get the best performance they can (who isn’t!), and coupling everything they do to an accounting mechanism (the budget) doesn’t make sense for them. He illustrated it with a comparison between the use of traffic lights and roundabouts. While the first is easier to use and provides more control, the latter actually provides better results because it relies more in the current situation than on statistical analysis.

We need to find more self regulating ways to manage a business, and beyond budgeting is one of them.

Bjarte used Douglas McGregor’s Theories X and Y to explain how we traditional management doesn’t usually trust people and relies on a stable environment to succeed, but in a dynamic environment in which most companies are inserted today, we need to start trusting our employees much more, and that is where beyond budgeting stands.

He had a nice example to show the lack of trust some companies impose, about a friend who is a SAS pilot, and even when he is trusted to fly planes full of people around, if he wants to change his shirt more often than it’s stated in the company’s policy, he needs a written authorization for it.

How does it work ?

According to Bjartes, the problem with budget is that it’s a single tool used for three separate purposes: Setting targets, creating forecats and allocating resources. Since these results are usually different from each other (targets are what we want, forecasts are what we expect to get), we won’t get an optimal result from using it.

In StatOil they have developed an alternative format of planning called Ambition to Action. These are a few principles that are used when cdefining it:

  • Good performance is being better than those we compare ourselves with
    • It could be external companies or even ourselves, which means we are learning.
  • Do the right thing
    • Every new joiner receives a StatOil book (a thin one!) with some of the principles that guide the company, so they can all use their business judgement and make decisions when needed.
  • Resources are made available and allocated on a case by case basis
    • Bjartes compared having an yearly budget to having a bank that opens for only a month throughout the year. How can anyone make timely decisions with that ?
  • Business is forward looking and action oriented
  • Performance measurement is holistic, and composed by 50% results and 50% behaviour

These principles are used to define what to do in the company, in a process that goes like this:

1. Strategic Objectives -> 2. KPI’s -> 3. Action & Forecast -> 4.Individual goals

So the company is going to set strategic objectives which are then converted in KPI’s. These are used to define the things that need to be done (Ambition to action), which reflect on how performance is measured for everyone in the company.

Some interesting thoughts he shared when explaining the process were:

  • The perfect KPI doesn’t exist, since not everything that counts can be counted.
  • StatOil creates around 1100 Ambition to action plans, and these are not a reporting tool, but more a guidance on how you as an employee should manage him/herself. Apart from that, everything is open, so everyone can see everyone’s else goals.
  • Performance measurement is usually based on teams and, as said before, divided between results and behaviour. Assuming that the environment very often changes, how someone behaved in that occasion is as important as the results he/she delivered.

The last point that was made during the presentation is how StatOil is moving from a calendar-driven model to a business-driven one. There are no more annual versions of Ambition to Action being created, and they can be changed at any time. The performance review is still happening annually, but Bjartes mentioned they are currently revisiting it now.

Overall it was a great introduction to Beyond Budgeting and how it is applied at StatOil. If you are interested, there is more information here and here.

Bjartes is speaking in the Thoughtworks Live Australia event. If you have a chance to go, don’t miss it.

No comments »

Posted in Agile, Development, Lean, Learning, Management, Presentations

Tags:

Running a Small Distributed Retrospective

October 4th, 2011

As many projects out there, my current one has participants in a few different cities and countries. We usually have most of the people co-located, but a few weeks ago we needed to run a retrospective with people in Sydney and in Melbourne, so I thought it would be worth sharing the experience.

Our team is quite small (around 9 people) and Im sure a lot of what we have done would be impossible to do in a larger team (I guess the next question would be why do you have a larger team.. :P), however just wanted to share the tools used and how it was all done.

Since we use skype for video communication, sharing a whiteboard would be impossible. The simplest solution found was TypeWith.me, an online collaboration tool that we projected on the wall.

We started by having everyone spending some time writing their ideas/observations on post its, but then instead of attaching them to the wall, we went around the table and everyone dictated their concerns, that were scribed in on TypeWith.me. After sharing ideas we went around again and everyone voted on ideas, which were noted on the online document again. Some reshuffling was done on them based on votes, and the we continued with the standard retro time-boxed discussions.

In general, I believe the retro had a good outcome. We didn’t lose too much time with the communication overhead and having the topics projected on the wall made it clear enough to both sides what was being discussed. Not trying to claim this was revolutionary in any sense, but if you are interested in running a small distributed retro, this might solve your problem.

 

1 comment »

Posted in Agile, Management

Tags:

Managing Dependencies – The Simple Way

July 20th, 2011

One of the common problems software teams face is that they are not alone in the world, and usually depend on other teams to deliver functionality to the end customer.

When the two projects are happening at the same time, it gives both teams the advantage that they can communicate with  and adapt more often to each other’s needs. It does bring a question on how to synchronise two independent streams of work, since not doing it might bring a lot of headache in terms of stories being blocked because dependencies haven’t been met, which ends up being a lot of waste.

In my current project, we have been using a visual technique to managedependencies which has been proven successful in terms of identifying dependent stories with minimal overwork.

  • All stories that rely on external teams receive a red dot, which represents they can’t be played before the dependency is verified.
  • Once the external team finishes their part of the work, a blue dot is written on the card, specifying the dependency can be tested by our team
  • An integration test gets written against that feature, and if everything works as expected, the story received a green dot, showing that it is ready to be played

So far, the technique has reduced the feedback cycle between us and the external team on which we depend. Testing the stories just after they have been developed means that we can give early feedback about if they are working or not, and avoid starting to work in tasks that cannot be completed.

 

No comments »

Posted in Agile, Development, Lean, Management

Tags:

Which side to pick ?

December 13th, 2010

What would you suggest should be done with a software development team where there is a significant difference in skill levels, let’s say up to 10x difference ?

Jason Yip shared this question he proposed to Takeshi Kawabe, who answered as follows:

Set the best performers as the standard. Pair people with the masters in a master-apprentice model. Find other suitable jobs for those without aptitude. Like professional baseball players, you need to practice every day to be a professional. Software development is a team activity an team are only strong as their weakest link.

Couldn’t agree more with it, but unfortunately is not the reality in most of the companies, that seem to be trying the opposite, setting an anti-productivity policy, which could be summarized as:

Set the worst performers as standard and create rules around everyone to avoid them making big mistakes. After that, just wait for the ones with aptitude to leave for a better place.

No comments »

Posted in Agile, Lean, Management, software

Tags:

Simple Planning

May 4th, 2010

What is necessary when you need to plan the next sprint/iteration ?

The picture above is the result of a chat with Lasse in my current project, and it was enough to set the expectations for the two weeks of work we had to plan.

Each post it is a story and time goes from left to right. Stories that are in the same vertical line can be played at the same time, and that big pile on the right means that those stories are dependent on each other, but can still be played simultaneously if developers are careful and communicate enough with each other.

This wasn’t anything planned, but it was simple enough for what we needed, and since we were working in a distributed team, taking a picture and sending it around was they way we had to share it with everyone. Worked just fine : )

4 comments »

Posted in Agile, Management, software

What’s the Tech Lead Doing Anyway ?

August 11th, 2009

Some days ago when having a discussion at work about the responsibility of the tech lead in an agile team, I’ve realized that this is not a so simple subject as I thought it was. Therefore, good subject for a post : )

But before being dictatorial and just writing my opinion, I ran a small twitter poll asking about this subject. Fortunately, most of the answers matched what I think in some level, so hopefully I will be able to cover it all here.

Before starting, a last note. I was reminded that the term tech lead might not be so used and known as I think it is, so if you don’t use this term at all, sorry : ). You can replace tech lead for architect, technical manager, master jedi, whatever you feel like…

Giving an introduction, the tech lead (TL)  term is defined here as a person who has the technical overview over a specific project. Some people disagree about the need for a tech lead at all, but that’s the topic for another post, and here we will assume that the tech lead exists and is a single person. Ok, that was the easy part.

Now the more subtle (and polemic) part comes here, so I will give my opinion on it (with the help from @dtsato and @flessa).

What a tech lead should be doing:

Have a technical overview over the whole project – As a developer doing everyday work, it is easy to lose the long term perspective about where the project is going and make decisions that will be better in the short term, but harm the project in the long way. It’s the job of the TL to keep that in the mind of the development team.

Make sure the project has a common face – Standards are important IMO, and making sure the project still makes sense as a whole, avoiding knowledge silos it’s the job of the TL. He shouldn’t have to enforce standards or ways to develop code, but facilitate the discussion within the team.

Remove technical impediments – As the most experienced person in the project, its natural that sometimes the TL will be the person in the best position to remove technical blockages that the team might have.

Bring people to a good technical level – If the team has different levels of experience, the TL should work to help people achieve a good work quality by sharing his knowledge and incentive others to do the same.

Write code. Write a lot of code – The TL is not a superior being that gives directions from the top of a mountain. Don’t know about your opinion, but if I can’t rely on the TL to sit down and pair with me when I have a problem I can’t solve, it’s no good to me.

I think that is enough for now. Now, for what the tech lead should not be doing:

Be the person responsible for the code – Being the tech lead doesn’t mean being the owner of the code, or the team’s boss. It’s everyone’s job to create high quality software, and the TL should only expose problems to the team and lead them in the right direction (emphasis on lead, not mandate).

Making all the difficult decisions alone - During a project, the team will be exposed to different technical decisions that will have to be made. Allowing the TL to take them alone just expose the team to more risk, since they won’t understand/care about what was decided. What we want to achieve is that Paulo exemplified here.

Impose his opinion – This is probably the most important point. Remember collective code ownership ? It is still very important. No matter how brilliant a TL can be, if he can’t share his knowledge/decisions and specially the responsability with the rest of the team, things will go bad.

9 comments »

Posted in Agile, Development, Management, software

Tags:

Empower

July 8th, 2009

Peer pressure enlists loyalty in ways that bureaucracy doesn’t.

John Mackey, CEO and co-founder, Whole Foods

This quote is true in so many different levels, but still quite ignored by the standard way of management.

The normal company, instead of making a good use of peer pressure, label it as a bad thing, and believe in the passive-aggressive affirmation of its values and rules as the way to better manage employees.

What they don’t see is that the only way to really generate a company with the  wanted values is to hire people who believe in them and empower them as much possible, making “good” peer pressure be the driving power fo your business.

It’s hard to accept that the employees define the values of the company, and not the other way around.

2 comments »

Posted in Management

Tags:

Dev Complete? No!

May 12th, 2009

Recently we’ve had a discussion in a project I was working on about the concepts behind dev complete and qa complete stories, which are normally in a lot of agile wall’s swim lanes, and how they affect the project’s flow.

The point here is not to discuss how to measure your goals, since this was discussed in previous posts, but what I wanted to explain is how (what I’ve realized during that discussion) I don’t like the term dev complete, and why it can affect your team.

First of all, development complete implies the idea that we don’t need any more development in one specific story, and as anyone who has been in an agile project might have noticed, this is less true than we wanted it to be.

What frequently happens is that stories which are in the dev complete lane come back to development when they don’t meet the QA criteria, and suddenly development has to be done again for something that didn’t need any more development.

And what I find most annoying is that development complete has the word complete on it, which has an underlying meaning that someone (the devs, in this case) have completed their job, and that they could feel good about it at this point.

What goes away when this assumption enters someone’s mind is the fact that the objective (for all the team, including those devs), is after the qa complete stage, when the story is actually delivered. And this situation just gives another motive to the always disturbing separation between developers and qa’s.

So if you believe in how measures affect the results of a team as I do (more info on that here, here, here, here, here, here and here), change all your dev complete stories to qa ready, or something similar, and enjoy a little bit more peace of mind.

4 comments »

Posted in Agile, Development, Management

Tags:

What is Your Goal?

April 21st, 2009

One of the best things about Agile is the introduction of software development as a system. Software stopped being treated as a sequence of separated steps to be seen as people with different competences working together to achieve one goal: deliver software.

This is not new in any sense, and it was exemplified by Deming on one of his books:

I could do a much better job (fewer mistakes) if I knew what the program is to be used for. The specifications don’t tell me what I need to know.

Despite this advance, most software development teams fail in really understanding this concept, and still normally don’t see the power of using one unique measure to manage the project, not getting the idea that the effort of the system should be only measured once, in what is its goal.

You must be asking what is the problem of having different measures to verify the sanity of the project. And that is what Peter Drucker explains in his Post-Capitalist Society book:

In knowledge work… the task is not given, it has to be determined. ‘What are the expected results from this work?’ is the key question in making knowledge workers productive. And it is a question that demands risky decisions. There is usually no right answer; there are choices instead. And results have to be clearly specified, if productivity is to be achieved.

What it means is that tasks cannot be fully specified anymore, the workers have to make decisions every time about how to proceed in certain situations, and they can just do it correctly if they have a clear vision of what is to be obtained, and what is the final goal of the work they are doing.

This concept is also illustrated in the draft version of Mary and Tom Poppendieck’s latest book (still in the draft version), when they are explaining the case of Southwest Airlines, which has as main advantage against the competition, the fact that its planes stay less time in the ground, thus generating more revenue.

Southwest maintains a systems perspective; it doesn’t let individual department measurements or increased revenue opportunities distract it from the primary objective of maintaining profitability. Southwest makes it clear to every employee – from the agent closing the gate to the baggage handler transferring luggage – what is important from an overall perspective. Everyone at Southwest knows the mantra: “Airplanes don’t make money sitting on the ground.” So everyone works together to get each plane in the air as fast as possible.

The important here is that we have one measure. One variable that everyone can rely on to make decisions during their work, and the ability to do it makes a whole difference in the overall performance of a team,  fact that often not considered in software development, where different measures distract people from the main goal.

As an example, a common situation I’ve seen in project is to track bugs within the iteration, and use it as a measure of code quality. Well, the goal of a software team is to deliver software without bugs, but it doesn’t matter at all if in the process of creating software bugs are found and solved prior to the software being released. If that is the way the team works best, so be it.

Another example is a case where a project had a problem with bugs creeping (this time, after iteration was finished and software delivered), and when discussing the fact we’ve realized that because of the pressure to deliver, we were delivering development complete, and not QA complete stories, so QA was actually done after the iteration finished, and yes, the team’s velocity was based on development complete points.

Well… if the goal you set to the team is to deliver dev complete stories, guess what you’re receiving in the end… dev complete stories!, it doesn’t matter how many times you repeat “Let’s focus on delivering quality software“. As Goldratt said, “Tell me how you measure me and I will tell you how I will behave.”

So, what is your goal?

5 comments »

Posted in Agile, Development, Management, software

Tags:

More!

April 6th, 2009

Since the advent of the industrial age, we have had a terrific word: “more.” It really worked for everything. When our roads became crowded, we built more roads. When our cities became unsafe, we hired more police officers, ordered more police cars, and built more prisons.

This is the introduction for one of the chapters of the book I’m currently reading, Information Anxiety, which talks about how to live in a world where we don’t have time to retain all the data that is thrown at us.

What I’ve found interesting about this sentence is how it can be applied in different areas, from police officers, like stated above, to software development.

It is surprising to see how many people that work in the area believe that a software project running behind schedule can be solved with a simple measure: throw more people in the team.

It is so appealing that nobody thinks it can go wrong, and they often forget to consider some minor points, like:

  • time it takes for newcomers to understand the project and its domain
  • time it takes for newcomers to know the people in the project
  • the decrease of communication levels brought by the addition of new nodes

and more than often, the same persons that believe in this measure forget to take a look at their team in order to really try to understand the root causes of what is happening, in a totally anti-genchi-genbutsu way of solving problems.

In a recent project I’ve participated, 4 persons were added to a 3 pairs team in order to try to increase velocity the team was delivering. Needless to say that in the first week we had a 5-pair team with 4 newcomers, and if you looked at the team room, you could see that in each pair there was one person trying to explain to the other how the system worked.

It is pretty straightforward to understand that the team was in reality less than half strong, and that in the first iteration we delivered…. guess what? Half the points.

So if you are thinking about ramping up, think again, and again, and again, and spend some time just looking at how your team works before you make any decision.

5 comments »

Posted in Agile, Lean, Management

Tags: