Skip to main content


Showing posts from April, 2008

Thought of the day: Why Projects Fail

I got a lot of good feedback to my inquiry about what makes projects fail - both here and on the internet-briefing blog. (Am also very embarrassed that I haven't followed up with the poll. It's coming - the answers were much more subtle than I expected).

On a different thread, I ran into another interesting analysis:
"There’s a lot of discussion about failed software projects. I’ll make a bold assertion here:"Most software projects don’t in fact fail because they’re over time and over budget, but because they implement poor solutions to poorly understood problems."— Jeff Patton, writing in his new book "Agile Development Outside-In"
Good point: Exceeding time and budget are symptoms of failure, not the causes.

This leads us to a lean practice at work: "the 5 whys". When something is going wrong, you ask "why?" But the reason itself has a cause, and you'll probably have to dig down 5 or 6 layers before you find the root cause and ca…

Digesting Change

Two different customers have recently raised the issue of managing (or rather digesting) change in organizations that are resistant to change. "Our company is over 100 years old and people get suspicious whenever you propose too many new ideas."

So how do we get people moving in the right direction without disrupting work and without provoking resistance? Brett Bernstein recently wrote on the scrumdevelopment mailing list.
"One challenge that I have continually come across when introducing new principals/practices is the flow rate. Too much flow and people start to choke. Too little, and they don't get to that "a-ha!" moment....
"I think your challenge is in part to figure out the right flow rate for your organization. It gets tricky since different flow rates might be needed for different levels (team vs. management) and different individuals...."So how much change can the organization handle? And which changes should you do?I have found the Sc…

Help! I'm Trapped in a Waterfall!

Back in February, I talked about Project Management being about the "Art of the Possible." Ken Schwaber invented this phrase and it really summarizes what project management, especially crisis project management is all about.

So what do you do, when the constellation of customer, schedules, partners and other third parties, and management makes a change of the fundamental working arrangements difficult or impossible? What do you do, when you are trapped in a waterfall?

I was confronted with this problem last fall when I took over a flagging project. It had serious organizational problems. It was a waterfall. My company was responsible for steps 2 and 3 of a 5 step process, but no one knew what really had to be done by when. People would start working on step n+1 before step n had been accepted by the customer. Even after formal acceptance, the customer would make changes to the graphics designs, so that nothing was ever really finished.

What to do? The problem was that there w…

Rational Scrum?

A query just came up on the scrumdevelopment list:
My work is a RUP based shop. My team has been doing agile development and lately our PMO office has asked if I was interested in publishing a white paper for the company on the two. I have a decent amount of info and experience but was wondering if anyone has written something similiar or could point me toward something that has already been published?
Googling for "rational scrum" produces some interesting results. Jeff Sutherland explains why there is no rational software process. IBM explains how to embrace Scrum in RUP. And Zacharias Beckman wrote a field report about getting a project under control using a fusion of RUP and Scrum.

Beckman writes, "Rational itself is an excellent methodology and scales very well.... However, for all that I like Rational, it does have some holes… and these are plugged most wonderfully by Scrum. In fact, Rational and Scrum benefit each other so well I’ve started referring to the combin…

Handling a Good Sprint Gone Bad

I was recently confronted with a sprint dilemma: At the start the sprint, the team committed to delivering a certain amount of functionality within the defined time period at the defined level of quality. Sometimes bad things happen. In this case, there was a heavy support load -- getting the previous sprint's functionality formally accepted. This was preventing the team from working on the goals for the current sprint. The Scrum-Master recognizes this in a timely fashion. What happens next?

Certainly the Scrum-Master should give early warning to the Product Owner. But what alternatives can he or should he offer? Theoretically one could:
Increase the staff
"Do what it takes" to finish the sprint
Prolong the sprintFinish the sprint at the date planned, completing less work than committed.
The right answer is almost always 4) Finish the Sprint on the date planned. But why?

Options one and three both break the sprint contract and raise the cost of the Sprint. Increasing the staf…

/ch/open Event: Scrum, Success and Quality

Yesterday I had the honor of talking to some 15 or 20 members of the Swiss Open System User Group. I like talking to experts because you always learn something from them, and yesterday was no exception.

As part of the introduction, we talked about why projects fail, which brought us to the question, "what is a successful project?" We talked about market acceptance, achieving the technical goals of the project, and customer satisfaction.But, as I learned from the participants, there is also personal success in the project. "The project is a success when I enjoyed working on it". This aspect is often severely challenged in the crunch phase before project release (particularly when management is standing around looking for someone to motivate). A motivated developer is at least twice a good as that same person when s/he is demotivated.
Afterwards we talked about numerous topics, including the quality in software. How much quality does a project need? How do you assure …

Market Survey: Agile in Germany

The latest issue of OBJEKTspectrum is dedicated to Agile SW development. In one article, they presented the results of a non-representative study on how widespread agile techniques are in Germany.Not surprisingly, Scrum is the most widespread agile framework, 21% of the respondants are using it, 17% have had first experiences with Scrum 12% are planing to introduce Scrum. Second place goes to XP at 14%, 35% and 7%, respectively. Other agile methods are largely unknown and not widely in use.Service companies ("probably" IT companies) at 27% and Financial Service companies at 25% provided the lion's share of the respondents, but Automotive and High Tech at 13%, Telecoms at 9% and Pharmaceuticals at 7% were all well represented.Where these companies happy to use agile? 97% were satisfied: 30% "very statisfed" and 50% normally "satisfied" und 17% marginally satisfed. Only 3% said they were dissatisfied.Which techniques were being used? Top on the list we…

May Scrum Breakfast in Zürich: Lean Software Development

Scrum is a successful project management framework, as the talks by Marcello Leonardi, Jiri Lundak and Patrick Weiss have clearly shown. But why? And what is the connection between Scrum and success as a company? The next two Scrum Breakfasts are dedicated to these questions.

On May 7, I will present Lean Software Development: the optimal Route from Concept to Cash.

The path from Concept to Cash can be long and risky. Delays, wrong decisions, budget problems, customer acceptance, bigger and faster competition. The list of risks seam endless but, it is in fact possible to develop successful systems and products.

Toyota developed what is now known as Lean Production and Lean Product Development. Properly applied, these assure optimal Fitness for Use and optimal efficiency in production. This combination of product quality, market fitness and low cost is largely responsible for Toyotas rise to the top of the auto industry.

This talk will close the circle between corporate agility and competi…

Thought of the day: The Lean Definition of Done.

Under Scrum, one of the first questions the Team has to answer is: When is a task done? A related question is when is the project done? This is the question the product owner must answer.

My lean definition of done: A project is done when the product or software created starts to bring value to the company for whom it was created. So the objective of a project is minimize the time required to get to done.

You might say "Wait a minute! That's not done, work goes on, even after a software is released." True, any useful software will need to be improved or enhanced. The question is, what is a reasonable delay between request from business and the availability of the desired function?

But the first release, call it 1.0 or XXX-Beta, needs to get out there. No release, no ROI. Someone needs to focus on achieving doneness. Under Scrum, this is the Product Owner's responsibility.

The longer it takes, the more SW development costs need to be amortized, the greater the chances or…

From Scream to Scrum

On Wednesday, Patrick Weiss, Director of eBusiness Solutions for Publiconnect, came to the Scrum Breakfast in Zurich to talk about his experiences as Customer / Product-Owner of two large projects which were managed using Scrum. As his talk was in German, I will summarize here.

He didn't start out to do Scrum. A change was necessary due to serious problems in the progress of his projects. Unhappiness was widespread and trust was down to zero. Without going in to detail, the problems were ascribed to "communications issues", which were corrected by changing the Project Leader and introducing Scrum.

Scrum was a suggestion of the contractor (well, my suggestion actually), and so it met with initial skeptisicm. Can it really be "agile" if we can only change our mind every three weeks? Will creativity and design suffer? It felt very limiting to only be able to react to changes at the beginning of a sprint.

The advantages soon became clear. Problems stopped accumulatin…

Agile/Target Process Course

Dates Changed

Due to a scheduling conflict with an important (and yet to be announced) Software Developers Conference, the course "Agile Project Management with Target Process" has been rescheduled to May 21 and 22.

Marketing Director Andrey Mihailenko and CTO Michael Dubakov of Target Process have confirmed their participation. (In honor of Messrs Milahilenko and Dubakov the course will be held in English, but explanations are available in German or French if needed).

The course is an Introduction to Scrum Project Management using Target Process. So you will get an understanding of the how and why of Scrum combined with practical, hands on experience using a proven tool for managing agile projects.

Early Bird Registration Deadline

The Deadline for Early Bird Registration expires on April 15. CHF 1296.-- including VAT. After that CHF 1496.-- Deadline for Registration is May 14, 2008.

You can download the flyer for detailed information or sign up online. I look forward to seeing yo…

What makes projects fail?

I needyourhelp: I'm workingon a talkaboutwhyprojectsfailandhowtopreventfailure. OneofmyfavoriteexercisesfrommyScrumtraining was listing all theways a projectcouldfail. I'd liketocomeupwith a listtopcauses. So pleasewrite a quickcommentwithyourcandidates (orbetter still, tellthestoryof a "favorite" failure).

Once I haveenoughcandidates, I'llsetup a poll, so wecanvoteonthebiggestcauses. All results will ofcoursebepublished in thisspace.

Thanks in advanceforyourhelp.

P.S. I'lladdmyowncandidatesafter I havesomeresponses. I don't wanttoprejudicetheresults.

Looking for an Agile Job or Contract?

One of the most frequent questions I get when talking to people about Scrum: do you know anyone who is looking for a job? Where can I find a freelance Scrummaster? Do you know where I can get a job doing Scrum or XP?

The only way I can know is if people tell me. (Seems kind of obvious, doesn't it). So, if you are looking for a Scrummaster or Agile developer, please drop me a line. Freelance, or full-time, up to you!

Or, if you are a Scrummaster or Agile developer who is looking for work in Switzerland (or even considering looking for work), again please drop me a line.

When a suitable opportunity presents itself, I will be happy to play matchmaker. Of course, all information remains confidential until I have your agreement to reveal your name to the other party.