I took him literally and replied that I had; at first when they were installed and again when I first used them.

He wasn’t talking about the actual lockers where we store our bicycles at work. He meant the proverbial bikeshed that doesn’t get painted because everyone must have input on the simple decision of selecting a colour. The other part of the proverb is the billion dollar atomic power plant that is approved right away because it is too complex to grasp, and thus few feel that they must have input.

When I think about it, bikesheds occur far too often. In my experience, most of these are “it’s just” situations:

• It’s just another web page,
• It’s just another web form; or
• It’s just another link.

I’m not going to expand on these “it’s just” situations at the right now. They could be good topics for future posts…

I would say that it was more worth it than the Project Management: Essential Techniques workshop that I went on last November as it was about how to do the analysis part of a project, in particular the documenting of existing processes, rather that how to run the project as a whole which isn’t where we really fall down.

Of even more signifigance was the reaction of Nathan and Emily, two managers, to the concepts…

Despite this deadline the project has always been way under resourced and the must frustrating thing is that the allocated resources (basically me) have nothing to do. Over the past two weeks I’ve only done about a day of actual work…

Above all it has given me a lot to think about regarding how the ITSM framework could work together with Thomsett project management…

One thing that I am really concerned about is that there is a large project that has just started and we are already supposed to be creating screenshots and working out the backend database without any apparent problem definition or requirements analysis…

What I have just realised is that the Thomsett training gives ammunition to push us onto the right track, left bubble and right bubble. Thomsett states that you must think about the project management issues (left bubble) such as requirements, scope and objectives before you start thinking about technical solutions (right bubble).

• Almost all of the team has done the course so why don’t we appear to be using any of it?
• It brings up some questions reagarding the structure of our team. The client relations team is really anything that isn’t code, ie helpdesk, interfaces, testing, marketing, project management, etc. Doesn’t really fit with Thomsett’s seperation of management (left bubble) and tech issues (right bubble).
• During the course I recalled that Mythical Man Month, Pragmatic Programmer and Peopleware all talk about some of the Thomsett concepts.
• Mostly it just makes common sense. So why don’t we do it?

Earlier this week I finished reading XP Refactored and one of the final comments was about how Kent Beck said that Extreme Programming is about turning all the dials, on various development practices, to 10. The comment in question (I can’t seem to find it now) said something about how anyone who has a sound system at home knows what happens when you turn everything up to full…

The relevant point I am now getting around to making is regarding the Thomsett success sliders; aspects of the project (client satisfaction, objectives, budget, on time, add value, quality, team satisfaction) are assigned a value that indicates how flexible they are. ie if the slider is fully on for time then it must meet whatever deadline, but it the slider for budget is half off then there is a fair amount of flexibility there. The important thing is that no two sliders can be on the same value (regular spacing from off to on) because you can’t have everything fully on. This concept replaces the old theory of you can have any two of quality, time or budget.

The point I’m still trying to make is that XP says everthing should be on. As other people’s experience is telling us, that will not just work…

I wrote up a, what I thought was good, response that talked about how XP takes a subset of the software development practices and combines them into a self referential loop in order to totally ignore other established practices. See the Circle of Snakes in XP Refactored.

However that was not the response I submitted as I didn’t think that an XP critical response would not be taken very well… The response I did submit was regarding coding standards and how they were beneficial, in particular that they are not tied to XP…

So far there has been a fair amount of discussion related to environments that are conducive to the Mental State Called Flow.

Following that was a signifigant discourse on Methodology (capital M), it was interesting to see comments made about how blindly following the Methodology is often a more effective way for workers to get what they want from management as opposed to a strike or stop work action.