Iterative work is human

Having read several great articles discussing Agile and Waterfall recently (e.g. More Agile Claims, What Killed Waterfall Could Kill Agile), I decided to share some thoughts. These days I’m involved in internal projects for “the business” (as opposed to “the ICT”). In a sense that IT components are part of a project, delivered by a an internal IT unit or an external supplier — usually with a dedicated Project Manager (obviously, every project is a “business” project, as it should lead to business benefits). Agile management hasn’t come our way yet. I wish it had (I know it aims at software development though).

Iterations are human. “Linear action” is the domain of machines, rather than people.

Take a look:

(If ‘A’ is the beginning of a project and ‘B’ — its end, it might be that iterations bring the team closer to the final product as expected by the client and his/her understanding of quality. The picture is a huge simplification — having in mind expectations, constraints etc.) We love to have a clear picture of where we’re headed. Describe it (business case, charter), plan it (aka make a prognosis) and then control it (or in many unfortunate cases – be managed by it). Having all constraints in place, it’s easier to put the damn thing on an invoice. Problem is:

Project Managers need time to grow as practitioners, as leaders. There aren’t so many experienced ones as one might think.
We have the tendency to reduce cognitive disonance in many ways — when things go wrong, only few have the skills and guts to let the world know “the king is naked.”
Not every environment leaves ample space for error and change.

Bottom line — people are not computers. They err, they fool themselves (“I don’t think this is so much of an issue yet”), they don’t always respond well to outside pressure (“By when exactly did you promise to deliver feature X?”). That’s why lean embraces errors and man’s imperfect nature calling it “continuous improvement.”

“if your #lean efforts are struggling, ask how much fear is in the org: fear of trying, fear of failing, fear of blame or punishment?” — Mark Graban from @LeanBlog

This is why I like the idea of iterations in any environment. Agile recognizes it, waterfall — not exactly.

* * *

Additional links

Tom Wujec: Build a tower, build a team – http://www.ted.com/talks/tom_wujec_build_a_tower.html

Organizations aren’t good at doing projects

Organizations aren’t good at doing projects. The popular Chaos Report shows mediocre results at best. In short — only every third project is a success. The rest? Failures or challenged — breaching time, buget and/or scope constraints.

Source: The Rise and Fall of the Chaos Report Figures

Some argue the methodology used in the report isn’t correct. It’s good to consider this criticism (see bottom links if you’re interested in details), but as practitioners we can see for ourselves. After several years of project work, when it comes to projects and success, I am moderately optimistic. The good thing is… there’s plenty of space for improvement!

[1] The Rise and Fall of the Chaos Report Figures

[2] Quantifying requirements volatility effects

[3] Let’s say “No” to groupthink and stop quoting the Chaos Report

Updated — Nov 26, 2010:

[4] Standish Report

How do you organize meetings?

Whenever I organize meetings I can’t help thinking something is broken.

It’s not simple enough.

Either the tools I know do not support the process well, it’s the people who make it more difficult than necessary, or both.

People (incl. availability) + time + location is all it takes. Truth is, the algorithm behind this is not that simple at all. But the problem is not a new one either.

How do you handle this?

Helping others grow

As a father I remind myself that *my children are my guests*. My role is to support them in becoming the best they are capable of. My role might be limited to just that — them becoming remarkable in their unique way and supporting the generations to come.

At work, we help our colleagues develop their potential in a similar way. We don’t need to manage people in order to do that.

Don’t feel intimidated

If we are so knowledgeable, why is mediocrity omnipresent? If we consider titles, certifications and fancy tools, why do we still get more project failures than successes? Take a look at your own backyard — how are things going on there? Are projects on time / on budget? Are processes continuously measured and improved? Are you innovating? Does your company know what it knows?

You don’t need much to become better than the average.

Where’s the real value in using collaborative software?

I love software. I’m particularly fond of tools that aim to support teamwork, e.g. managing projects. Still, every now and then I ask myself: “Where’s the real value in using collaborative software?” — bearing in mind that geographically dispersed teams aren’t the most popular form of teamwork. Questions that come to mind:

Is software an excuse not to move people to a common location?
Are the business benefits related to buying the new tool sufficient?
Can my team do with a whiteboard and a good idea instead?
Is everyone ready to jump on the e-bandwagon?
What are the entry barriers for new users?
What if we decided to ditch the tool after some time?

Before getting too excited, it’s good to have the following in mind:

“To a man with a hammer everything looks like a nail.” (Mark Twain)

Cherishing one’s silver lining

One of the most important discoveries in my life was the importance of gratitude. Not as a response to a set of favorable circumstances, but a constant, proactive approach towards reality. A choice. If happiness is wanting what you have, then the key to that happiness is gratefulness.

Lately, I had yet another discussion on organizational change and mindsets. Obviously, you cannot force another person to change his or her mindset. You can, however, look for ways to help that person feel grateful for a particular job, for being part of one special team.