On TechTalks Mind: New Podcast Episode

Check out our new podcast episode. This time Claudia talks with Willy about requirements gathering in Scrum projects. This is a german episode.

Visit "On TechTalks Mind" or subscribe in iTunes.

follow me on twitter, I need some friends :-)

 

Cassandra Syndrome: Knowing that failure is inevitable, but nobody is listening

Cassandra's doom was to predict what others refused to believe.
While Cassandra foresaw the destruction of Troy, she was unable to do anything to forestall these tragedies since no one believed her.

[Wikipedia]

In death-march projects the developers are often suffering from the cassandra syndrome: They know that the project is doomed to fail, but they gave up on trying to change anything long ago.

In several big enterprise projects I have been in, developers just stopped caring, they gave up on craftmaship.

This is the typical No pigs, just chicken antipattern. The courageous pigs left, the coward pigs broke, the chicken remained ...

A typical pattern for dysfunctional projects I have come across is that there are several layers of hierarchies between the stakeholders of the project and the developers.
These intermediate layers have absolutely no interest in communicating any problems to the stakeholders above. And the stakeholders are completely content with being lulled in the comfort of getting smilies or green traffic lights in their high-level status meetings.
Usually at the point when the smilies stop smiling or the traffic lights get yellow it is too late. The project has gone completely off track and is doomed to fail badly...

Recently I came across another name for this symptom:

The Green Effect:
The higher a status-report goes in the organzational hierarchy the greener it becomes.

The following Dilbert strip illustrates this brilliantly:

When I voiced my Cassandra analogy on twitter, Scott Ambler replied to me:

@jbandi if developers learn to communicate effectively with the business they don't need to be Cassandras

- Scott Ambler, on twitter

Well, in my experience it's not that simple. I consider me as a developer that can communicate (more or less) effectively with the business. But I find me repeatedly on projects where there is absolutely no process established for effective communication between the developers in the trenches and the stakeholders. And establishing such a process is not feasible because of several organizational layers between the trenches and the stakeholders.

follow me on twitter, I need some friends :-)

Quotes of the Week

If you build software from diagrams, it will likely follow good diagramming principles, but rarely follows good software principles.

- ampgt on twitter 

Nothing makes a software system more flexible than a suite of tests. By an order of magnitude more than good architecture and design.

- Uncle Bob, QCon 2010

Speaking at See#Party

I will be giving my talk about Behavior Driven Development and SpecFlow on the See#Party in Konstanz-Kreuzlingen next week (August 28th).

I am looking forward to an interesting conference program.

follow me on twitter, I need some friends :-)

Self enabling teams: a demonstration.

One of the most impressive memories from my Certified Scrum Master course last year, is the experience of growing a self enabling team.

The exercise was simple:

• Given was a bucket full of tennis balls.
• The team was about 20 people.
• Only one team member could take balls out of the bucket. He could take out as many as he liked at any time throughout the sprint.
• The team would score a point for each tennis ball that was touched by every team member and then touched again by the first team member, he who took the ball out of the bucket.
• The team would do 10 sprints. Each sprint is 2 min. Between two sprints is a break of 2 min for retrospective and optimization.
• Before each sprint the team announces the score it expects to achieve.

Before the exercise I thought that the main challenge would be figuring out the optimal formation of the team members. I expected that after that there will not be much improvement possible.

I was wrong! This was the result (second column: expected, third column: achieved):

I am still amazed how the team was able to optimize and improve in each of the ten sprints. This improvement was rooted entirely in the team itself and is a perfect demonstration for a self enabling team, that was given the chance to inspect and adapt.

Some of the optimization steps included:

• Finding out the optimal formation for the task: a circle.
• Optimizing the formation into two circles of people. The outer facing inward and the inner facing outward, this way we could pass the balls to a person in front of us and not besides us.
• Ignore dropped balls, continue with the flow.
• Not throwing balls to your peer, but dropping them into his cupped hands.
• Passing two balls at a time to your peer.
• Sitting down on the floor reduces the danger/consequences of dropped balls.

Quotes of the Week

Learning from mistakes is overrated!

-Rework

If we could only learn the right lessons from the successes of the past, we would not need to learn from the failures.

- Tony Hoare

Code that runs on first write is an idea from the past that we should forget!

- Keith Braithwaite, Nothing New under The Sun