Blog entries tagged with "project management"

After reading my conclusion regarding the Forms That Work training, Hamish asked me if I had ever posted about the bikeshed.

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…

Today was my third and final day of the Thomsett Business Systems Analysis: Essential Techniques worshop with five other people from work.

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…

Work is getting pretty frustrating at the moment as I am assigned to a project that must be in user testing by the second week in June. That means that coding really needs to be complete by the end of this month.

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…

Today was my third and last day of an ITIL Service Management Essentials course at work.

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

It looks like the need to have a software developement process at work is finally being addressed. The good thing is that I am going to be a part of working out what we need. The first stage will be reviewing how we can scale down Thomsett for our small (one to four week) projects…

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…

For a while now I’ve been thinking that, at work, we are trying to find solutions to our problems without first defining the problem, working out what is needed to solve the problem, and then looking for solutions that do what we need. The need to find the box before you can make something fit the box.

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).

Today was my final day going through the three day Thomsett Project Management: Essential Techniques workshop at work. I’m still digesting it – as a tech I’m not going to be applying Thomsett on a wide scale – but I did have the following thoughts:

• 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’m applying for a full-time position, I’m currently casual, at work and part of the application process is an online pre-interview questionnaire which I have just finished submitting. One of the quetions was Describe any one aspect of Extreme Programming that excites/intrigues you, and why. (hint: google for it)

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…

I’m a few chapters into Extreme Programming Refactored and it is very interesting. Significantly the breakdown of how XP goes wrong and the background of where XP came from…

Last night I got around to start reading Peopleware, like Mythical Man Month this book is about the management of software engineering projects, in particular the management of productive teams.

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.

I’m coming to the end of XP Explained and the car metaphor has been mentioned again. Basically the metaphor being used is that there are two ways to drive a car; point it down the road and then start it up, or start it up and continually steer so that it stays on the road.

Pragmatic Programmer talked about the same things but used a gun as a metaphor; to hit a target you can calculate the angle to aim the gun based on positions and environmental conditions and then fire a single bullet, or you can use tracer bullets in a machine gun and adjust your aim after you have started firing.

The thing that I keep thinking is that they are both talking about an old idea that even Mythical Man Month touched upon: Iterative Development.

This is again exposing the biggest issue I have with development strategies like XP (don’t get me started on ‘Agile’), someone has taken a variety of established (not necessarily utilized) ideas and wrapped them together as something new. The other issue is that because of this a lot of people now have an all or nothing mentality: “I don’t like XP so I will exclude all of the parts of XP as well.”

There is probably also a bit of fear of the unknown in there as well. The other day at work I sent around a link to WhyNotEnoughRefactoringHappens in response to an email. A comment was made about how it was good that there were all these related topics. However when I informed them that they were actually looking at a wiki their attitude instantly changed. To their defence they were introduced to wiki’s in the wrong way, basically “wiki is there, use it”. No introduction about what a wiki is, the benefits, and the disadvantages…