I’m seeing a lot more burnout at work for many reasons, all of them very disturbing. It’s bad for the employer because people become disengaged, productivity suffers, stress increases all around, sickness levels increase and retention suffers. It’s clearly bad for the individuals and their families and it’s also bad...
I recently read an interesting blog post from Gartner summarising the results of a study that they undertook into why projects fail. The results aligned nicely with my own views: Our recent Gartner Research Circle survey asked clients about project failures. No respondent chose “technical skills” as the cause of...
The Creating passionate users blog has a great post on the need to challenge assumptions, so many times I come across assumptions that everyone knows are invalid, but are used because people assume they isolate a project from risk. Of course all they really do is defer the risk. Personally...
A long time ago now I read the Mythical Man Month, and I remember two things from it: On a large activity conceptual integrity is really difficult to achieve and maintain In the sixties IBM seemed to do a better job at managing large development programmes than we do now...
I often see programmes fall into the trap of over reliance on certain individuals. Unfortunately the more effective and useful a person is the more that person seems to be branded “Super Man” and burdened with commitments that make it ever more difficult for them to do the things they were valued for in the first place.
When I started thinking about this short article I had in mind a few examples:
The Programme Director who takes on too much Programme Management because the customer and account teams except him to have programme management detail at his fnger-tips. Solved by a combination of excellent management information, setting expectations and not being afaid to re-inforce those expectations. Fall into the programme management trap and you won’t be there for the team when they need you, won’t have time to manage the key relationships and won’t be able to see the wood for the trees, the classic “programme is red – suprise!”.
The Chief Architect who forgets that his job is to preserve the conceptual integrity of the solution and to nurture its evolution through logical and physical development stages. Solved by having a very good definition of the concept initially, making sure that the architecture …
This is a great interview with Tim Marsland who is a distinguished engineer and CTO for the Operating Platforms Organization in Sun Microsystems. In the interview he talks about the approaches Sun takes to the process of test, integration, compatibility and shipping Solaris. It gives some great insights. I particularly liked these sections.
First they use daily builds and eating your own dogfood (but don’t use that term), I really like the daily build concept as I have described in previous posts:
We also use the previous night’s build to build today’s system, and every two weeks we put the latest build on the shared file- and mail-server for a large proportion of the operating system development group. We deliberately hold our own feet to the fire. Developers quickly got used to running their stuff on their own desktops and their build machines before integration.
Next a section to use when your manager asks you “why do we need to install the beta”
A few months later, we came up with another interesting idea: the Platinum Beta program. This is an idea where we say that we think our beta software is good enough for the beta tester—not just to kick the tires, but to put it into a …
I have just been reading an article on the importance of scheduling and bug and feature tracking in software projects. Its a good article and worth a read, but its basic stuff really. However its often the basic stuff that gets neglected so don’t dismiss it on that basis. Anyway the article prompted me to think a bit more on the benefits of eating your own dogfood and regular/daily builds.
The key thing I missed in the previous article was the importance of the process to managing compromise, and often that compromise takes the form of cutting or dropping features in order to deliver to time and budget. The daily build/dogfood approach helps with this as follows:
The last post has got me thinking more about the whole concept of daily builds. I mentioned in passing that the concept is not just applicable to software development but I did not explain the comment. I went out for a walk and started to think through how the concept could be applied to a systems integration project. The one I chose is quite topical for me at the moment, a Windows XP desktop refresh and desktop management project.
So first let’s look at some characteristics of this sort of project:
So let’s look at the daily, (or perhaps regular), build process and …
Joel, writes up an interesting example of NOT eating your own dog food, (ie using the IT solutions you are developing yourself), until it was almost too late:
Eating your own dog food is the quaint name that we in the computer industry give to the process of actually using your own product. I had forgotten how well it worked, until a month ago, I took home a build of CityDesk (thinking it was about 3 weeks from shipping) and tried to build a site with it.
Phew! There were a few bugs that literally made it impossible for me to proceed, so I had to fix those before I could even continue. All the testing we did, meticulously pulling down every menu and seeing if it worked right, didn’t uncover the showstoppers that made it impossible to do what the product was intended to allow. Trying to use the product, as a customer would, found these showstoppers in a minute.And not just those. As I worked, not even exercising the features, just quietly trying to build a simple site, I found 45 bugs on one Sunday afternoon. And I am a lazy man, I couldn’t have spent more …
Project status reporting tends to focus on progress, cost and time. These are the hard measures of a projects status and I’ve described some of the issues with them in this recent post. This post is concerned with the soft issues. Although projects are made up of people it’s rare...