Search This Blog

8 December 2011

Understanding Bureaucracy

Bureaucracy is a form of organisational structure.  It is not the paperwork and busywork we see in large organisations.  That is something different.  It is waste, inefficiency and an inside out view of dealing with customers.

But they seem to go together, don't they?

In the next few weeks I want to go through some of the ideas about what a bureaucracy really is, where it came from, what it's strengths and weaknesses are, and what we should do with it when considering the design and creation of new workplace systems and structures.

And why is it they are so frustrating to deal with?

Here is a tentative roadmap for the discussion.  I'll update it with links as I write the posts.

  1. What is Bureaucracy
  2. Origins of Bureaucracy
  3. The Evolution of Bureaucracy
  4. Organisational theory on Bureaucracy
  5. Alternative Models for  Bureaucratic Organisations
  6. The future of  Bureaucracy

6 December 2011

Case Study: Problems with Estimating

Mann Street Gosford, mid-late 1950s

On an application development project I had problems with estimating the details of software projects and managing feature creep. We were tracking okay to the high level estimates we had put together pre project, but on a story by story there was very little accuracy in estimates.

As we know from Kailash's blog post delphi planning (e.g. planning poker) amplifies estimating capability.  If your skills are good, the group approach makes it better.  But if your skills are poor you'll just amplify your error rate. We seemed to be stuck in the second category.

 Watching the cumulative flow and cycle times on stories gave me the right cues to take information to the plan with a recommendation.  I could see the average story size was also the threshold for estimates breaking down. So, on average the effort to fulfil a story was going to vary substantially form the estimate. The threshold was a story of about 5-6 days of effort.

I put it to the teams that we target a 2 day maximum effort story size as a threshold, and if stories were larger we break them down further until they fit into that threshold. This was generally accepted (but not consistently applied.) The additional effort in breaking down stories increased flow and yielded improved results (which still needed further improvement.)

My role was in the analysis of the team’s performance data and linking the problem of large stories with size limits. The team were able to adopt this change and the positive results were shown in future performance reports.

This led to me generally advocating the “count the stories” mantra alongside the Kanban method community. I’ve also combined it with the Requirements Traceability technique to good effect. (see more here.)

3 December 2011

Why you guys suck at estimating

Planning poker

Kailash wrote a great blog post on estimating. It gives the maths behind why you guys suck at estimating.

Go read the post here.

Kailash tells us that essentially your success at estimating is amplified by doing it Delphi (blind group) style.  This includes Mike Cohn's planning poker approach to estimating.

That means that your estimates increase your capability if you get many people involved.  Unfortunately, if your team's average estimating capability is poor you'll be amplifying poor estimates (ie moving further away from the eventual truth.)

His post comes with disclaimers and it would be neat to test this out with some experiments, but it is one of those ideas that 'feels' right.

This post is my response to the ideas he presents and some additional thoughts on the problem of estimating.

It's timely for me right now because I have been doing some estimating work for my team's 2012 portfolio and I have been pretty much ignoring all recommended best practices for estimating and instead guessing most initiative sizes using my instinct.

What makes me think I should be doing this rather than using a consultative, and in particular a Delphi approach to estimating projects?

Why am I more reliable than many other people who have worked here longer?

First and foremost I believe that most in our team are not particularly competent at estimating.  So I trust my judgement more than theirs.  I've been around and educated myself about estimating. I have also been around and gotten a feel for how much effort things both 'should' and 'do' take in organisations of various maturity.  I have a breadth of experience.

Additionally, in my current estimating work I looked back at historical performance and looked at sizing next year's projects against last years.  This gives me a feel for the capability of the organisation.  Relative sizing works for me.

Additionally I don't actually do it alone.  I have asked others to estimate in some instances.  But again I have gone to individuals rather than the whole team that is to do the work.  (Some teams aren't even hired yet.)

So Kailash's post gives me confidence hat I am not doing something stupid and there is some theory that stands behind my instinct to keep the estimating activity to a small group of people.

There is a better way.

You may suspect that  better way could be developed by giving everyone experience participating in estimates so they can build their competence.  We could do that, and should for a handful of people for the occasions we do need to estimate things.

The better option is to gather historical data and use that to forecast the future.

In the course of next year I'll be working the team to gather data so we can get better historical numbers.  In the next annual planning cycle I hope we'll be 'counting cards.'

1 December 2011

Dave Gray on Gamestorming: Design Practices for Co-creation and Engagement

Dave Gray talks on using games to help design products and work. A key point I liked was that by involving users and clients in the creation of products (and knowledge artefacts like user stories and requirements) you get them championing your project efforts in a much more engaged way. Enjoy.