Tag: process

The benefits of planing poker

October 6th, 2009 · · Processes No comments - Tags: , ,

During spring I had the pleasure to work with Brjörn Granvik from Jayway as a mentor in development process. This was a very enlightening experience. I had previously defined a process for the team to work with but it lacked in some areas although no-one was able to pinpoint were the process was failing.

We found it very difficult to control the project and the time line. This had as a nock on effect that we lost credibility with our customer. And every effort we made to improve our estimates failed.

We were creating new functionality that would run on, and integrate to, the worst software I have ever seen (and this is not just my opinion). It would be easy for me to blame all the slips on the difficulty to work with the underlying application code but this would be a cop-out and a lost opportunity to learn from my mistakes.

When Björn came onboard he introduced planning poker as a way to measure the effort required to complete user stories. This is a great aid since it creates a tangible and useful abstraction that is not bound to time. The principles are simple and can be found here and here

Binding estimates to points rather then time improves the process and controllability of the project. The most striking benefits to me are the following (I will dig into each below):

  • It improves the accuracy of time estimates over the lifetime of the project.
  • It helps manage expectations that the customer has of the project delivery.
  • It empowers the team members and helps create an upward spiral building on success upon success.

When a team start working on a project, or new members join the team, tasks takes longer to complete. When a team have been working steady with a project for a period of time the team will complete the same tasks faster. This is due to what could be regarded as the teams fitness (as in physical fitness). It is therefor waisted effort to estimate tasks in how much time each will take.

First of all, as the team starts the project they will not have any awareness of the level of hidden difficulty in a task. This is only discovered through working with the project.

Second, if the team would accurately estimate the time needed to complete the task for the first couple of months this estimate will no longer be accurate a few month into the project since the teams fitness will have increased by then. Also the technical environment for the project will most likely have changed radically.

Using an effort estimate that is not based on time enables the team to measure project velocity. This is then used to create a time estimate that will, given that the team is kept intact, improve over time. This has serves all three of the above benefits.

Since the projects is not estimated in time the first real estimate of time will happen after the first sprint/iteration of development. This estimate is based on real experience, not guesses. We know that it will change. The next iteration may show that it will take longer. But the next three to four iteration will show that it will be shorter.

The customer is given the initial estimate and knows that this is a worst case estimate. Looking at how SCRUM projects velocity tends to develop the speed will increase.

Since the team is presented with a long timeline where they work through story points in a stead but slow churn it is a wonderful feeling to se this passe increase as each iteration is completed. This empowers the team immensely since it is a feeling of control and and success.

This fall I will again define a process for my team. It’s a new team this time and a new company. And there are other needs. But one thing is sure. I will learn from my previous mistakes and I will introduce planning poker as the means to estimate stories.

Lack of process II – Shaping up the process

January 13th, 2009 · · Processes No comments - Tags: ,

Follow up on Lack of process.

We have now worked according to the process described in the article Lack of Process for about seven months. It is starting to work well but there have been a number glitches along the way. I will go through each below. What was not discussed in the previous article is the planning and washup meetings. We have a planning meeting before each iteration, it’s about half a day where we discuss time estimates and plan what lays ahead. The washup is held after the iteration. We go though what have been accomplished in the form of a demo. We then discuss what we feel went well in the last iteration and what we need to improve during next iteration. Each team member needs to bring five good things and five things that needs improvement.

So far the main problems that we have had are:

  • Time estimation is very difficult for two reasons. It is a new team, the last two joiners started in December, and we are new to the code base we are working on. This makes it difficult to estimate how long it will take to implement each bit of functionality. The other difficulty is that the existing code base is a right mess so when we need to work with it it has untold side effects.
  • The backlog of work keeps shifting. This is mainly our own fault though. We underestimated the tasks that lay ahead of us when we started the project so the backlog we though we had was in fact much larger. We then only re-estimated what we though would go into the next iteration which lead to us not knowing what lay ahead.
  • The fact that we keep getting disturbed is very annoying. This should not happen. But since it does we will just have to plan disturbance time into the iteration planing. We have tried to communicate the actual loss to the management but there isn’t much more that we can do.

To solve the issue with estimates and backlog we are now estimating issues that span across at least two iterations, three if time allows. This is done by compiling a list of outstanding issues into a spreadsheet. Each issue is then estimated by each member of the team. The basis for the estimation is that the team member will solve the issue. Any time he/she needs help will count as double time since the person helping needs to be accounted for. We then meet during the planning meeting and discuss the estimates. If the estimates are similar from all team member this is agreed as the time it will take. If not the reasons why are discussed and a time estimate is then agreed. This give us a good backlog to take from as well as better estimates.

The disturbance is handled by lowering the actual time available for each team member. Normally we should be able to expect that every one will spend at least 35 hours a week on the project, possibly even 38, excluding email conversations, time reporting and such. With this amount of disturbance we can’t expect to be focused more then 25 to 30 hours a week. That is a lot of production waste on a 40 hour week.

Another thing that we have learnt is not to over plan an iteration. Never put in more then is absolutely necessary to deliver a release, even if it would only take half the planned iteration to complete. The reason for this is that failure don’t build a good team, success do. So if we guarantee that every iteration is a success, and that we will definitely be able to complete what is planned it makes us feel good. This makes the team want to work harder and do more. And so with half the amount of work planned the team can complete twice as much thanks to the feel food factor of succeeding every time.

I am sure that this process will develop even more when we get the chance to put into practise in the next project, but that is yet at least half a year away.

Bloging as a means to increase communication

November 27th, 2008 · · Processes No comments - Tags: , , ,

I listened to a podcast a while back, can’t quite remember which, where they were talking to a company that had started with internal blogging. The idea was that all staff got their own blog to write on and were encourage to do so whenever they had an idea or something else they felt could be interesting to share with others in the team, or across the teams. I didn’t pay much attention to it at the time though, just though it a bit over the top to be honest. But today it kind of struck me that actually, it’s a really good idea.

When everyone is busy with their tasks at hand ever so often someone gets an idea or finds something in their day to day work annoying but at the time there aren’t really any forum to communicate this to fellow colleagues so it gets forgotten. Instead this can be captured in a blog post. This will allow for the idea or frustration to be available to others as well as the poster for later when it may come in handy. And as for frustrations in day to day tasks, if enough people find that they share the same frustration this is the point where it’s time to do something about it.

So the long and short of it is that it’s probably a really good idea to encourage an internal blogging culture in order to identify all the potentially lost opportunities for improvement that disappears in our day to day work.

Lack of process

May 28th, 2008 · · Processes No comments - Tags: , ,

I started a new job a few weeks ago. The new company is a product and consulting house that target mainly the public sector. During my interview I was under the impression that they were trying to adopt SCRUM. I found out that this was not quite the case. The development team that I joined, at the time that I joined down to one from two when I was interviewed, and the project lead had tried to but without much success about a year earlier. When I started though, boosting the team from one to two, they said that it’s difficult to do a process with only one person there. This is true in a way I suppose but a process can help even when you are alone since it will lend some authority to the way you work when it comes to fend off requests for support and other tedious tasks that really don’t belong when doing project work.

So a few days into my new job I decided that I will have to try and sort the situation out. SCRUM had obviously not worked when tested and is notoriously difficult when you have to estimate the total cost upfront. I looked a bit at the ideas around feature driven development and also looking back at my experience at my last workspace. The process I defined is below.



It’s not rocket science, rather common sense and it should be fairly easy to implement. Only it requires some input and support from other parts of the organisation. Whilst working through the process I also defined eight roles that are essential to follow it through as well as to help with the estimates and scope creep that has a tendency to occur on fixed price projects:
R1. Product management
R2. Developer team
R3. Client
R4. QA team
R5. Application support team
R6. Requirement specification owner
R7. Front end architect (thanks to James McQuarrie for the title)
R8. Project manager

Seeing as the organisation I currently work in don’t have a clearly defined product manager for each product nor a QA team or application support function this ends up being the developers responsibility as well. We also lake a front end architect and requirements owner to that watches for scope creep in projects to there are some real chance that things loses focus in the tight client feedback schedule. This is not a good nor productive situation to be in.

I am going to meet with the top management to discuss this prickle and will hopefully be a good salesman for my opinion and escalate the issue to high priority. I’ll keep you posted on the development.