Agile Management | NOOP.NL

New Site for Agile Managers and Team Leaders

Together with several other people I have been busy preparing a re-launch of Management 3.0. It is a site for (and by) agile managers and agile team leaders.

Like my own blog, this new site will have absolutely no information about technical practices or cool technologies. Instead, it will be about leading technical people, with blog posts about motivation, hiring, competence, knowledge, improvement, and fluffy bunnies.

And unlike my own blog the Management 3.0 site is open for submissions by everybody! Yes, it is the perfect place to do a guest post and show off your writing skills! If you do well, you can draw billions of readers to your own blog or book. I think.

The site already has guest posts in queue from Israel Gat and Pawel Brodzinski, and I have blackmailed at least a dozen other well-known authors to deliver a contribution in the next few weeks and months. So don't be afraid and submit your own blog post at Management 3.0. Have a look at the guidelines if you need a little help with it.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Make a “Social Contract” with Your Team Communicate Your Goals! People Motivation: Target Intrinsic Desires

In Defense of Scrum (Please Stop Pissing on It)

Last week Uncle Bob Martin wrote about seven “serious flaws” in Scrum. I usually agree with Bob, but not this time. Actually, I might even feel a bit sad about all the <method>-bashing I see happening in the Agile world, where all too often <method> = Scrum and the bashing comes from either the XP side or the Kanban side.

Here’s my take on the matter…

“Scrum has no technical practices”
The lack of technical practices in Scrum is a strength, not a flaw. It means Scrum can be (and has been) applied successfully not only in software development, but also in design, marketing, and several other creative domains. As far as I know Scrum has always been presented as a framework, meaning that it must be augmented with domain-specific practices. True, some software teams forget about the technical practices, and they are idiots! But is it a “flaw” of the script writer when the director forgets to use stunt doubles when filming the dangerous scenes? Or is that a failure of the craftsman who apparently doesn’t know how to do his job? If you call it a “flaw” that Scrum has no technical practices, then you can only conclude that Lean and Kanban are seriously flawed as well! Obviously this is a bit silly. To me this flawed reasoning seems like a bad case of tunnel vision. There’s more happening in the world than TDD, Continuous Integration, and Pair Programming. Really! (BTW, it is interesting to see praise on the Lean side for Bob's criticism of Scrum, while Lean and Kanban have no technical practices whatsoever! The few described in Lean books are simply copied from XP…)

“The Scrum Master arrogates project management powers”
Maybe, but it’s a risk worth taking. A much bigger problem I see with teams without a Scrum Master is that they are usually an undisciplined bunch of mandrills. XP requires and assumes that teams consist of self-disciplined, competent, and communicative people. Unfortunately, many software developers don’t fit this description. Scrum at least acknowledges that most teams need some help and assistance in getting their processes and communication in order. I find it particularly strange that people who call for craftsmanship on the technical side should point out the dangers of positioning a master on the process side! Honestly, I would rather run the risk of a Scrum Master taking up PM powers than a dev team completely ignoring their responsibilities. What is worse? (And yes, the sooner a team can do without a Scrum Master, the better. I don’t have one in my own team right now. For us there's no need.)

“Scrum provides insufficient guidance regarding the backlog”
See the first issue above. A backlog for graphic designers probably looks quite different from a backlog for developers. And marketers print their backlog horizontally and call it a road map. What’s wrong with keeping all the options open? Scrum is a framework, not a by-the-minute recipe!

“Scrum carries an anti-management undercurrent”
I don’t get it. How is that different from XP? Management has always been underrated in the Agile world. True, management has done badly before Agile. And we should be glad for the Agile movement and its self-organizing teams. But self-organization without governance is anarchy. This is not a flaw in Scrum, it is a flaw that began with the Agile Manifesto itself, which completely disregarded the role of management. And guess who co-wrote that? :-)

“Scrum doesn’t say anything about multiple teams”
True, and again: how is that different from XP, or any other agile methods? Allow me to quote John Gall here:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. – The Systems Bible, John Gall

Scrum is a small system. That’s why it works. It is specifically designed not to cover technical practices, complicated backlogs, multi-team projects, etc. They tried that with RUP, and they failed. Because a complex system designed from scratch won’t work. A big working system has to start as a small working system. This is not a flaw. It is common sense. And now that we know that (small) Scrum can work, we can learn how to make it grow...

And that's what I had to say in defense of Scrum. I really hope that people would stop pissing on it. No agile method is perfect. But I think there’s a world of difference between imperfect and "flawed".

Please note that I am not a CSM, and will never be one. I like XP and Kanban just as much as I like Scrum, because I believe no single model or framework is enough when managing complex systems. Anyone who favors one method and pisses on another is just showing off his ignorance of complexity thinking.

That's it. I hope to have entertained or annoyed you.

I will be speaking at the Scrum Gathering in Orlando. Hope to see you there!

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Management 3.0: The Era of Complexity ScrumButs Are the Best Part of Scrum The Complex Manifesto for Software Development

10 Principles of Agile Project Time Management

Project Time Management is one of the nine knowledge areas of the Project Management Body of Knowledge (PMBOK). It deals with the definition of activities (what are we going to do), the sequencing of the activities (in what order are we going to do them), and the development and control of the schedule (when are we going to perform those activities).

Agile Time Management
Over the past couple of weeks I have been trying to find out what the main principles of time management are in the case of agile software development. I was able to distinguish 10 principles so far, and I will present them here for your convenience. With each principle I also include a reference to an online article that (as far as I can tell) nicely describes the ideas behind it. If you don't agree with my list, or if you know some better reference material, feel free to add your thoughts!

1. Use a Definition of "Done"
How? Define what "Done" means and only count the activities that are Done.
Why? Prevent the build-up of hidden tasks ("technical debt") that cost a lot of time to fix down the road.
See: The Definition of "Done"

2. Use Timeboxes to Manage Work
How? Set a start- and end date for a collection of activities, and don't allow changes to those dates.
Why? Timeboxes keep people focused on what's most important. Don't lose time to perfectionism.
See: Time Boxing is an Effective Getting Things Done Strategy

3. Don't Add Slack to Task Estimates
How? Don't use scheduling and buffering of tasks. Add one buffer to the end of the timebox/project.
Why? All safety margins for tasks will be used ("Parkinson's Law" and "Student's Syndrom'").
See: Critical Chain Scheduling and Buffer Management

4. Defer Decisions
How? Make decisions only at the latest responsible time. "No Decision" is also a decision.
Why? The environment may change, making earlier decisions a waste of time.
See: Real Options Underlie Agile Practices

5. Reduce Cycle Time
How? Iterative cycles should be as short as possible.
Why? Speed up the learning feedback loop, and decrease the time-to-market.
See: Lean Software Development: Why reduce cycle-time?

6. Keep the Pipeline Short and Thin
How? Limit the amount of work-in-progress, and the number of people working in sequence.
Why? Improve response times, speed up throughput.
See: Managing the Pipeline

7. Keep the Discipline
How? Prevent expensive rework by doing some processes well, right from the start
Why? Solving problems late in a project is more expensive than following proper rules early.
See: The Power of Process

8. Limit Task Switching
How? Prevent unnecessary task switching between projects, and prevent interruptions.
Why? Tasks get completed faster on average, and the human brain is bad at task switching.
See: Human Task Switches Considered Harmful

9. Prevent Sustained Overtime
How? Disregard (sustained) overtime as a way to accellerate progress.
Why? Lost productivity, poor quality and bad motivation among team members.
See: The Case Against Overtime

10. Separate Urgency from Importance
How? Urgent tasks and important tasks should not be done at the same time.
Why? The important stuff will usually not get done, costing you more time in the long run.
See: A 10 Second Guide to Smoother Projects: Urgent vs. Important

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
FREE Copy of The Software Practitioner
Three Levels of Acceptance Testing
Rubber Chicken Management

Can Refactoring Grow Out of Control?

In a recent talk on architecture and agile development, Philippe Kruchten told his listeners that refactoring can grow out of control when people decide not to do up-front design and instead decide to let the "architecture grow with the code", as many agile software developers like to see it.

Let me repeat his (real-life) example:

Agile Development by the Book
On one big project, where Philippe got involved in, the teams were doing agile development by the book: one-week iterations, daily stand-up meetings, iteration planning with user stories, retrospectives, and regular refactoring to change and improve the design of the code. However, despite the fact that the teams were doing just about everything that the agile gods have prescribed, one problem just got bigger and bigger:

The time needed to do refactoring grew with the size of the code.

It appeared that, while the code base grew over time, so did the time needed to refactor the code to accommodate new features. Apparently, the teams were unable to stabilize the architecture. Halfway through the project the iterations had to be lengthened to three weeks just to be able to finish refactorings. And in the end the project simply ground to a complete stop.

What went wrong there?

Should We Not Grow Architecture with the Code?
Philippe Kruchten's interpretation was that it is not enough just to do refactoring and let "the architecture grow with the code". He told us that some work in up-front architectural features is essential. He does not believe you can go on by just adapting all the time. Philippe says that the principle of deferring decisions does not hold true in every case. You also have to anticipate, or else in the end you will spend much of your time reworking everything.

However, my own interpretation is a little different. (This might not be a surprise to my regular readers, as I rarely seem to agree with any of the experts. I can't help it. It's just a gift, I'm sure.) I believe that, most of the time, people simply use the wrong approach to the idea of "deferring decisions". Let me give you an example:

How to Defer Decisions
When I'm building a new application, I will have to decide whether my application is going to be multilingual or not. However, it may be better for me to defer that decision. But if I do, then what shall I do with all those form labels, button texts and abusive error messages that I need to put into my code now? I believe the wrong approach in this case is to simply use static strings all over my code base. Because if I do, I will not seriously have deferred the decision. I will have (unconsciously) favored one outcome of the deferred decision over the other. Because I can be certain that it's going to take a lot of effort to refactor my code later, when the decision finally falls to make the application multilingual. In fact, chances are that it will be too costly to change later, and I will have painted myself into a corner.

To properly defer a decision requires you to (consciously) keep all options open.

What you could do in such a situation is to create a simple factory method that provides strings to the entire application. All button texts, form labels, page titles and silly easter eggs will get their strings from that simple function. Of course, it would still be a single-language static-string solution. The implementation might be one huge ugly motherf*** of a switch statement concealing 10,000 strings! But at least it would be an easy monster to refactor later on in the project.

Philippe explained that...

"Architecture is any binding decision in your code that is hard to change later on."

To that I would like to add...

"The choice not to plan for a deferred decision, is also an architectural decision."

Deferred Decisions vs. Architectural Decisions
I don't know the details of the big project that Philippe was referring to. But I wouldn't be surprised to learn that most of their ever-growing refactorings were a result of not properly applying the principle of deferring decisions. Choosing not to hide the details of string construction from the rest of the code is an architectural decision, that will make it hard for you to switch to multiple languages later on. Choosing not to hide the intricacies of the data layer is also a decision. It will make it almost impossible to add versioning to the data later. And choosing not to hide the implementation of user notifications will mean that a switch from email to SMS or paging is also going to be a lot of work.

The choice not to safeguard your code against the outcome of deferred decisions is an architectural decision in itself. What's interesting is whether you're making those decisions consciously or not!

It Takes a Decision to Defer a Decision
So you see, I agree with Philippe that refactoring in itself is not enough. You have to anticipate and make conscious architectural decisions to let refactoring work for you. But I don't agree with Philippe that "growing the architecture with the code" is somehow not enough. Sure it can be enough.

The problem is not lack of up-front design. It is lack of planning for deferred decisions.

If you understand how to keep your options open, and make the necessary architectural decisions consciously, then I think all should be fine!

Afterword: I just got an email from Philippe Kruchten himself. According to Philippe we're actually "in furious agreement". But I worked on this bloody post for at least two hours, so I'm definately not going to delete it...

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
Architects vs. Agilists (1 - 1)
Top 20 Best Agile Development Books, Ever
The Virtue of Junk Code

Architects vs. Agilists (1 - 1)

Some software architects think that agile development is an irresponsible way of creating (badly structured) software, hyped by a bunch of undisciplined hackers. Some agilists think that software architecture is a relic of waterfall-style development, defended by a bunch of bureaucrats in an ivory tower.

Both are right. And wrong.

This week I saw a presentation by Philippe Kruchten, author of The Rational Unified Process Made Easy and The Rational Unified Process: An Introduction, positioned on #60 and #96 respectively in the Top 100 Best Software Engineering Books, Ever. It was one of the most inspiring talks I have attended in a long time. Allow me to try and convey Philippe's message here, in just a couple of paragraphs.

Software Architecture is Imperative
There is no such thing as "not doing software architecture". When you start writing your first line of code, you have already made some architectural decisions (like platform and programming language). The very act of starting test-driven development also requires that some architectural ideas have already been agreed upon. And when you're setting up multiple teams for one project, Conway's Law tells you that your (implicit) architectural decisions will match your (explicit) organizational decisions.

Agile Development is Imperative
There is no such thing as "not doing agile development". (Well, in practice there is, but there shouldn't be.) The architectural decisions need to follow experimentation and proven concepts. Assessments have to be carried out to see what works and what doesn't, and architecture must be adapted accordingly. And possibly most important of all: nothing should be built that is not going to be used. This applies to both functional and architectural requirements.

Good and Bad Software Architects
Anyone who is creating a big up-front design (BUFD), using lots of bells and whistles, that constrains rather than facilitates agile development, is a bad architect. A good architect knows that he needs to spend a lot of his time among the software developers, how to document only what's really important, how to change the architecture using the developers' feedback, and how to make things as simple as possible, but not simpler. That means... being agile.

Good and Bad Agile Developers
Anyone who writes code without thinking of possible consequences, without keeping all design options open, is a bad agilist. A good agilist knows that, in order to defer design decisions, some crucial thinking has to be done in order to keep the code and the project adaptive. He knows that the code must be able to scale when the project needs to scale, and that code must be partitioned when the organization is partitioned. In short this means... creating architecture.

There is no conflict between architecture and agility.
There is only conflict between bad architects and bad agilists.

People vs. Principles
It's simply a matter of people vs. principles. The principles of architecture and agility are sound. It's just the bad (stupid, naive or uneducated) people that give either architecture or agility a bad name. I would prefer to say that architects are complaining about caricatures of agile developers, and that agilists are caricaturing software architects. But I'm afraid I wouldn't be doing them justice. The caricatures actually exist, which more-or-less defies the concept of caricatures.

There really are bad architects and bad agilists among us!

Note that I'm only talking about roles here. In many small projects the architects and agilists are the same people! They are agile architects, or architectural agilists, or whatever. No matter who does what, architecture and agility are part of every project.

Philippe Kruchten explained that there's nothing wrong with the principles. We just have to take time and educate the people on how to do it well.

My next post will be about Philippe Kruchten's criticism of refactoring, and why I think he might be wrong. Stay tuned...

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
Five Agile Competence Levels
The Agile Blind Spot
AINO: Agile In Name Only

Three Levels of Acceptance Testing

At the Agile Open Europe conference I participated in a discussion on the subject of acceptance testing. One of the open questions was how to match "traditional" customers with the agile idea of delivering a potentially shippable product every few weeks.

Different Types of Customers
While some customers are delighted to receive a new release every month, there are others that don't even want to see or know about any of the intermediate releases. Some customers simply insist on working the traditional way. They hire a team of testers for a couple of weeks before the intended release date, and they require the development team to deliver one release candidate, just in time for the test period, and the team should then stop working on the system until the test team has finished testing.

After fifteen minutes of heated debate about expectations, responsibilities and mindwiping customers, it dawned on me that the participants in this discussion were using three different meanings of the term acceptance testing:

1. acceptance testing performed by testers in the project team, who try to read the customer's mind and attempt to represent him by checking if the delivered product is likely to be acceptable;
2. acceptance testing performed by testers on the customer's side, who need to verify on behalf of the customer that the budget was properly spent, and that there's no urgent need to sue the vendor;
3. acceptance testing performed by the users of the product, who might not even want to touch the new system with a long stick, despite the fact that twenty testers told them that the system is fine.

Forget the Words, but Check the Meaning
Depending on the type of organisation, type of product, and type of customer, a project will face one, two, or all three of these forms of acceptance testing. In our discussion at Agile Open it took a while for us to realize that some people were not agreeing with each other only because their ideas of acceptance testing followed different levels of definition. Once we identified that problem, communication (and agreement) seemed to be a lot easier.

Now, don't get me wrong, I have no intention to redefine acceptance testing! The testing community itself already has many fine definitions of all kinds of testing activities. But some people correctly pointed out to me that exact terms and wording are irrelevant as long as people agree on meanings. I have noticed similar confusion among development teams and customers leading to miscommunication about expectations and responsibilities.

Let's Understand Each Other
So... I advise you to check each of these "levels of acceptance testing" to see if all stakeholders agree on the way they are implemented in the process. It doesn't matter how you call it. Just make sure you're talking about the same thing.

The Single Best Source Control Model

Some best practices are so evident that nobody seems to be bothered to write about them. Just have a glance at the software development books you have. Does any of them explain how to properly use source control system? I'm sure they don't.

However, I know first-hand that most software developers finish their studies with not an inch of knowledge regarding source control techniques. That's why managers need to be technically savvy. We have to tell them about it!

Now, it doesn't happen often that I keep silent about anything. Whatever the subject, my opinion is usually formed before I have finished thinking about it. However, with source control techniques, this is apparently not the case.

Two Great Articles
I know two very good articles on source control that every software developer on the planet should read. OK, I admit that is an opinion. But once you've read them, I'm sure you will understand why I feel that way.

Version Control for Multiple Agile Teams (Henrik Kniberg)

The Importance of Branching Models (PDF) (Chuck Walrad, Darrel Strom)

Both articles agree that there are good and bad ways to organize version control of your code. Both offer more-or-less the same advice on what the best branching model is, and I couldn't find any flaw in their reasoning. I had nothing to disagree with. (And that's a rare experience to me.)

For agile software development, a good version control model is essential!

Release Software Any Time
Agile team need to be able to release software at any time, while working on new iterations, and (usually in my case) sorting out a few bugs from the previous one. The branching model promoted by these two articles takes care of that, and much more.

I am actually surprised that source control isn't covered in the books on agile development methods. But then again, maybe this is the only subject on which Schwaber, Beck, Cockburn, Poppendieck and De Luca all agree as well.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
Blog Post #100: Your Feedback Please!
Book Review: Agile Project Management with Scrum
How to Create a Pre-Project Document

How to Create a Pre-Project Document

How Do You Initiate a Project?
Do you just organize a kick-off meeting? With a friendly pat on the back by the customer, wishing your developers all the best? I'm sure you don't. The agile principle of verbal communication over written documentation is applicable when a project has already started. But before that, when a contract still needs to be signed, and when the customer is still reluctant to trust your shiny blue eyes, at least something has to be written down and agreed upon.

Let's call this the Pre-Project Phase. It's the only phase where you're not sure if it will be followed up by anything else.

The Project Proposal
Until this day we have initiated projects in our company by writing Project Proposal documents for our customers. Such a Project Proposal usually contains an outline of the project, a vision of the intended solution, the planned phases, milestones and deliverables, the budget, pricing details, a description of our agile processes, licensing and maintenance stuff, and promo's for other products and services. And every now and then some business unit manager adds another standard paragraph to this ever-expanding nightmare of a document template. Our Project Proposals have become so big that some of our customers complained of risking a repetitive strain injury just by leafing through them.

Something had to be done!

Software Development Methods to the Rescue
So, I checked a number of books and methods to see what the common approaches are to documentation in the pre-project phase. These are the results:

• Scrum has... nothing
• XP has... nothing
• FDD has... nothing

Well, isn't that a pity. The best-known agile methods leave the initiation of a project completely up to your own imagination. Fortunately, there are several more methods to choose from, and I quickly found some useful advice.

• DSDM tells us to create a Feasibility Study (check if the project is worth doing) and an Outline Plan (set some high-level project parameters).
• MSF tells us to create a Vision/Scope Document (to define project direction and boundaries) and a Project Structure Document (team, process and budget).
• Prince2 names the Business Case (the customer's reason for doing the project) and the Project Plan (schedule, milestones) as the two most important documents in this phase.

There is a significant overlap of subjects addressed in the different documents suggested by these methods. As a person who likes to keep things simple, I decided to create just one new document template for our organization, aggregating the most important topics I could find in several document templates. Here is the outline of my new Pre-Project Document template:

Business Case
The Business Case is the chapter that defines why the project is needed.

• Current Situation
  To understand the project, every participant needs to understand how things are working now.
• Problem
  Make it clear to everyone that you really understand why the project is needed, and what the problem is in the current situation.
• Vision
  All stakeholders in the project need to be aligned so that they share the same vision of the future product.
• Options
  Document why a certain direction was chosen, and from which available options.
• Benefits
  Make sure that everyone has the same idea of business value for the customer.

Project Scope
The Project Scope is the chapter that defines what the project will produce.

• Scope
  Define, in broad terms, the size of the project by explaining what activities you will perform, and for how long.
• Out of Scope
  It's also very important to mention explicitly what you will not do, so that there will be no misunderstandings.
• Solution
  Give the customer an idea of the (sub)systems you will be delivering, without details, on the highest possible level.
• People and Roles
  Name the stakeholders and their roles and responsibilities in the project. Make sure that everyone knows who can take which decisions.
• Quality Criteria
  Name any quality requirements that are applicable, and assign priorities in case of conflicts among the qualities (like performance vs. security).
• Standards
  Name any technological standards and business standards applicable to the product.
• Risks
  Be sure to mention any risks, so that any re-planning (when some of the risks turn into real problems) doesn't come as a surprise later.

Project Planning
The Project Planning is the chapter that defines how/when we intend to do the project.

• Process
  Mention the process you will apply, either by referring to a defined method (like Scrum) or to a document describing your own custom process.
• Milestones
  Name any specific dates and (if known at this stage) what you expect to be delivering. Regular iterations/releases might be mentioned here.
• Dependencies
  Name any dependencies, like the involvement of third parties, that are beyond your own direct control.
• Assumptions
  Make any assumptions explicit, like the availability of a customer stakeholder, or the availability of graphic designs.
• Change Management
  Define how you're going to cope with changes during the project. This is part of the defined process, but it deserves to be mentioned explicitly.

That's it!

This outline is simply the result of me stealing generously from various examples in DSDM, MSF and Prince2, and wrapping up all topics into one simple document. Hell, I even matched the outline with the objectives of the RUP Inception Phase, and everything appears to be neatly covered. Now, it doesn't really matter whether you call this document a Project Plan, an Outline, a Project Vision or a Pre-Project Feasibility/Scope Plan Outline Document. Just make sure that your ass is covered and all this stuff is agreed upon with your customer before doing that first daily standup with your team. Because, after the project is started, your Pre-Project Document will be the basis against which your project, and the resulting product, will be measured by the customer.

Finally, a couple of tips:

• Don't include the budget in this document. Reserve that for a separate (small) contract or proposal. The customer might want to share your stunningly insightful document with other stakeholders inside his organization, but he might be reluctant to share contract and pricing details with his own subordinates.
• Use the same template for your own internal projects. You might be your own customer, but that doesn't mean you don't have to answer these questions to yourself.
• Present the document during the kick-off meeting with the team, and let them ask questions to fill any holes and blind spots in the written document. The agile principle of verbal communication should be able to take it from there, and your standard development processes can finally take over.

Want to read some more?

Why Managing Small Projects is Harder

AINO: Agile In Name Only

The Cone of Incompetence

 

Lesson Learned: Automate Project Evaluations

Jurgen! We can never find the time to evaluate our projects. How do you manage your evaluations?

Project evaluations (or retrospectives) are a nuisance. Everybody knows they are important, but nobody performs them. With at least ten new projects starting every week in our company, how can I instruct our people to get all project stakeholders together (in ten different settings) and construct a "lessons learned" list of the ten projects that were delivered the week before? Nobody is available for such meetings because they are all too busy making sure the new projects are initiated properly. Sure, this is no excuse. But it is reality.

Automate the Process
To get around this problem I have decided to automate the evaluation process. Everytime a project is deactivated in our project management system, a notification message is sent to each of its stakeholders: the project manager (or ScrumMaster for some), the business consultant (or Product Owner for some), the technical lead, the technical manager, the financial department and the quality assurance manager. Each of them is asked to rate the project on a scale of 1 (Bad) to 5 (Excellent), with the option to add some comments and lessons learned. It is similar to Amazon asking you to rate a book after you've purchased it. (Only in our case people don't rate value-for-money but satisfaction-for-energy.)

No Secrets
The nice thing about this approach is that we are now starting to accumulate a queryable history of evaluations that will enable us to drill down to customers, teams and individuals. All ratings are open for everyone to read and respond to. We have no secrets. (If someone messed up completely, everyone usually already knows.) This makes sure that people's ratings and comments are honest as well as constructive. In fact, I just posted the monthly report of our April's ratings on our company intranet to share with everyone.

From Feedback to Action
Browsing through these evaluations regularly, I am able to pick up what the most common problems are and I can check if they are already covered by some of our quality improvement steps. In some cases the feedback still requires some face-to-face communication, as I walk up to people and ask them to elaborate on something, or to respond to someone else's somewhat critical findings. And in some (but fortunately rare) cases, when I hear of something that makes my hair stand on end (or my jaw drops to the floor, or my brain passes out) I organize a face-to-face project evaluation meeting. And believe it or not, it turns out that these are now easier to organize now that everyone knows that these meetings are only reserved for the most serious cases. Nobody wants to miss out on a bit of flame and mud throwing. All in good fun of course.

Lesson Learned
Sometimes you have to run a process the unconventional way, or it will never run at all. For years we never could get people to organize project evaluations. But the automated project evaluation looks to be reasonably successful. In April the number of automated evaluations climbed to 117, as compared to 65 in the month before. And in the meanwhile I do my best to make people see that the evaluations are actually being read and acted upon.

Of course, automation of an important part of a project workflow can only be done for the most mundane of processes. If you cannot get people to perform their daily stand-up meetings, I wouldn't dream of automating it!

Interesting? Not? Tell me about it! Or check out some of my other favorite articles:

Make It Simple vs. Do It Simple

AINO: Agile In Name Only

The Ethical Software Engineer (Not French!)

Edward Lorenz (1917 – 2008)

Edward Lorenz has died on the 16th of April. Many of you probably don't know whom I'm talking about, so I will explain.

Lorenz is the man behind chaos theory (in the 80's), which has later (in the 90's) transformed itself into complexity theory. He is the one who coined the term The Butterfly Effect. This entails the idea that a global network of terrorist butterflies might be able to trigger tornados in the USA, just by flapping their wings. (It doesn't matter which book on chaos theory you read, and where the butterflies are, for some reason the tornados always end up in the USA.) The Butterfly Effect explains why little things can have a huge impact in a complex system. For example, adding one "small" requirement to a project can sometimes inexplicably have a tremendous impact on the scope and the deadline.

He also discovered strange attractors. This is about the fact that many complex dynamic systems, whatever their initial configuration, have a tendency to end up in only a few stable states. For example, strange attractors have been used to explain why there are only a limited number of basic forms of organisms in biology. (You don't often see species with five feet sticking out of their heads.) Strange attractors may also explain why there are only a few patterns of successful software projects lifecycles.

I think chaos and complexity theory are essential in understanding the complexity of software projects. And that's why the death of Edward Lorenz is worth mentioning on this blog. I'm sure you don't mind.