I stumbled upon a blog entry from Jeff Langr today in which he challenges the concept of »chickens and pigs« in agile development.

His line of reasoning: Having a rule which forbids communication is not agile at all. He suggests to sustitute an other agile value instead: courage. Simply ask people who are not helping in the daily to stop. And talk about it.

You can read his full view here.

I like his suggestion for dealing with chicken-rule-fetishists:

The next time someone calls you a chicken, let them know that there is a new animal in agile. It’s the ass. The ass is the person who dictates how things must be. They are stubborn, controlling animals. Perhaps the best thing to do with an ass is to give it a good swift kick.

I think Jeff has a valid point there. Nothing is more tedious than being constantly remembered by a Scrummaster(tm) that something »isn’t following the Scrum rule book«. On the other hand these rules are necessary scaffolding for beginning project managers without a lot of experience under their belt. Maybe the truth is somewherein  between again. If you need this rule, use it. But get rid of it as soon as possible.

What do you think of this rule? Do you use it?

No special reason for this post. I just found this photos documenting the result of a two day agile retrospective session we facilitated some time ago and wanted to share the »agile beauty« ;o)

Day 1

more »

Lets begin this post with a rant: I really really hate it if people try to turn agile principles against the customer. The mission: Mask laziness by gaming the system.

The sort of situations I talk about look like this:

A: »Do we have to refactor this code? It’s really ugly and may or may not break somewhere in the future.«
Variant 1:
B: »Don’t bother with this, the Product Owner didn’t say anything about quality.«
Variant 2:
B: »Let’s ask the PO! PO, what is better quality worth to you? Prioritize! You can have more features or quality for the ones we already implemented.«

Oh yeah?  It’s unfair and plain nonsense. Don’t get me wrong here: There are cases where bargaining over different qualities of service (QoS) has its right and is essential. But most of the time it hasn’t and isn’t. Especially if the code implemented is brand-new.

In all agile methodologies I know you promise the PO to deliver a baseline of quality from the start. It should be clear that »just getting things done« in guerilla combat mode is not enough. As a member of an agile team I implicitely promise to do things like e.g.:

• Planning the architecture
• Weighing my options
• Communicate
• Deliver the best code I can
• Test it
• …

without asking the customer every time: »What is it worth to you?«. Cope with it: If you don’t consider this activities as included and mandatory a priori you are not an exceptional doer churning out code like the Chuck Norris of development. You are just lazy.

From the perspective of the customer this behavior looks like an eternal loop of terror:

1. Deliver crap.
2. Whine over how you need a whole full-time month to remove technical debt.
3. GOTO 1

The Manifesto for Software Craftmanship explicitely addresses this by postulating to commit to the following principles:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration,but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

© 2009, the undersigned. this statement may be freely copied in any form, but only in its entirety through this notice.

Bravo. Software should be seen as a craft. Get over it: Every time we deliver crappy code and apologize with »I had no time to plan!«, »The PO didn’t want quality!«, »You wanted results: you got it!«, we already lost the cooperative game. Why? Because of two things:

1. What the PO asks you to do is to implement her ideas as simple as possible (YAGNI, KISS) but not simpler. What this minimal effort looks like is up to you and can only be judged by you. The PO can’t know this!
2. If there really is a trade-off between time and quality we should have presented the PO the options beforehand. If she doesn’t seem to care: just don’t commit to it! It’s all  about nuts-in-advance versus whining-after.

FTW: Yes I’m an craftsman, too.

If you are interested in more views on the topic be sure to check out this InfoQ article.