Posts Tagged ‘project management’

Naked Planning – Arlo Belshee from Agile 2008

November 11th, 2008 No comments

There is a nice pod cast (Agile Toolkit Podcast) by a guy Arlo Belshee on Agile Toolkit Podcast, Naked Planning, Promiscuous Planning and other Unmentionables (sorry don’t have a url). He has a couple of points that are interesting (around 17-23mins). He is basically using Lean-type queuing for planning. I am interested in his ideas around prioritisation and estimation. He is basically arguing that in prioritisation having estimations creates a selection bias. That is, the business does not necessary choose the options that are best for them (ie delivering business value in the form of cash or a long-term differentiator). He argues against a traditional cost-benefit analysis. This analysis is a 2 × 2 grid – cost (x) by value (y) as scatterplot as below:

high   |                                    long-term value (market differentiator)
       |    short-term value (cash)
       |    low-cost/low-value (death march)
low    |                                       never done (expensive and little value)
           low                    (cost)                 high 

In this approach there are four main positions: (1) top-left is the short-term value options that are cheap and easy to do but provide high value. These tend to get you cash in the market place. But competition can also copy and innovate at the same rate. So they are valuable only in the short term and are also known as cash cows. (2) top-right are the long-value options. These are the market differentiators that you want to build. Because they high a cost, they are harder for the competitions to create. (3) bottom-right are the low cost and value. These are the items that we tend to think of as quick wins. He points out that they are the death march. They merely distract from delivering value. (4) bottom-right are normally thrown out and not a problem.

He argues that we need to remove, the x axis, cost. Prioritisation should only be about business value and lined up in order. In fact, he points out that when you take away the cost, his group opts for high value propositions. This mixture of short and long-term value propositions is a better product mix. But if you leave in the cost, people do tend want to include the death march items.

Therefore, do value-based analysis. Rather than cost-benefit, do benefit-benefit analysis. This approach hide costs, or in fact never does the estimations in the first place. Because having an estimation is a negative business value proposition and actually has a positive cost. It is negative business value proposition because it creates a selection bias that people select non-business value options. It has positive cost because someone has the make up the estimations. It has the other cost that the made up part is just that – made up. Better to work with a queue of real wait time over the duration of the project.

He continues on to talk about estimations as wait time before starting the next MMF.

Categories: Uncategorized Tags: , , , ,

Inviting people onto projects – and giving them an exit strategy

August 29th, 2008 No comments

In my work life, I’ve been running a couple of projects lately where I had choices about who to include on the project team. Historically, I have been unhappy with the approach used by my company. People are essentially an interchangeable resource although each resource should have the right set of skills. Individuals are in fact asked whether or not she/he is interested in the project and willing to join. This all works well enough when there is a match between projects and people. But it assumes that the resource really knows about a project and vice versa that the project knows the skills (and attitudes) of the worker. But what happens when there is a “lack of fit”. Often both of us are stuck with each other. In some cases, you do get to get off the project – often quietly, and in my experience is often undermining. At best you get to get off an ongoing project when you go on extended leave. Thankfully, I go on leave often! Therefore, I want to think about ways which build in inviting people into a project that allows for an exit.

Luckily, I have friends who think about group processes. One friend is a clinical psychologist working with dialectical behaviour therapy (DBT). He’s been having a similar issue. He works in a small group of 6-8 people. It is a stable team but still requires new people at times. The success of that team is each person’s fit into the team and not just their skills – and they tend not to be able know in advance how well the new person will work out. His approach is to give someone 4-6 weeks on the project before reviewing suitability. Within that period it is outlined that the person needs to:
  • read certain materials
  • observe and participate in meetings
  • raise concerns
Central to this approach is to allow both sides to gather knowledge about each other and the environment. They are really looking for the new person to make a commitment to using particular skills and methods. Because, it is the actual using them that is essential. Sound familiar? We need well-functioning, small teams. Here’s what I have been attempting to do over the last couple of projects. This is the basic process I use once we have decided that a person is going to join the team (so this isn’t a recruitment strategy):
  1. Have an initial meeting outlining that I would like to invite them into the team and that I feel it is important that they get a chance to work out whether or not the project is for them.
  2. I outline that once they join that we will have a review at the end of two weeks.
  3. I outline the three points above.
  4. I outline that what we are looking for are people who can contribute to the project (and to me that is contributing to the code as a measure of success)
  5. I outline that these types of projects are not for everyone and that wanting to leave is okay – being stuck is not. I also outline the sorts of struggle that I have had in the past and why I think what we are doing is going to try and work against those problems.
How well does it go? To tell the truth, I haven’t used with enough people to really know. I have noticed that with the people who have been inducted through this process, they tended to contribute well and early. The others that were really given to me and just started have tended to be more of a struggle.

What could I be doing better? I think that I could do the review better. The review isn’t as formal as the initial meeting. It is more of a touching base. I check out with other team members how it is all going. I haven’t had anyone leave yet either – but then again those that I gave the induction approach to tended to well out better!

I’m not surprised that it might work well. It is akin to setting ground rules for small groups. My problem though is that I tend to set the ground rules rather than make them shared and in practice that doesn’t give much of a chance to the new person.

A final point my friend made after I was explaining the agile principles and trying to draw some parallels in our work. He agreed with the agile principles. He could see that a focus on individuals and interactions over processes and tools would be important; or customer collaboration to get working software. But he pointed out that DBT for him helps him think about how to do personal relationships. Now that’s an important point that I don’t think we are addressing in software development models. We might say that people are important and that they interact but we aren’t talking too loudly about its qualities. I’m not reading a lot around what happens when there is difference, such as gender and race, within interactions – is this will become more apparent if outsourcing across national borders increases. At best the discussion is relegated to the level of psychological-based soft-skills – for example, the pragmatic programmers series, such as, retrospectives, project management or management books.

Categories: Uncategorized Tags: