Root-Cause

Root cause analysis is one of my favorite XP practices. Because it's so simple and so powerful at the same time. That said I very rarely use it. Or do I? It turned out that I might use it without knowing it, as the below described quick series of questions and conclusions sure do look like a root cause analysis after all.

We had the iteration demo yesterday morning and the very first story simply was not working. At all. We thought it was but it wasn't. We took our loss of 2 story points in stride and moved on with the demo, then with the retro and then the planning, then the team started to work on the tasks. In the evening when I got out of a long meeting the red bug-card was still on the board with a red magnet on it while many new tasks were already completed, one full story even. I knew something was fundamentally wrong I just didn't know what.

As luck would have it, ten minutes later I called my mentor/business partner and told him how much we need to work on those values were just discussing in that long meeting
because in our earlier projects people had to be stopped from debugging code during the demo.
So then we started to discuss how did we get here.

Why did nobody care this time?
The level of engagement/involvement of team members is very, very low.
(Why?)
The project scope is changing every week. Stories, epics get dropped, new ones spring to life. It's unclear what percentage of the project we have completed, and what is still to go.
(Why?)
The release plan became a living document in the extreme: due to unexpectedly low velocity and ever changing requirements and underestimated stories, the scope was negotiated and re-negotiated over and over in the name of agility.
(Why)
Changing scope, estimating new stories on the fly seemed like the obvious solution when the estimates turned out be way off.
(Why)
Not the whole team was involved in the release planning. This is also the reason of their lack of engagement.

The 'why's are in parenthesis because we didn't actually ask them. We were just discussing the important aspects of the past couple of months.

How we are planning to turn all this around is the subject of the upcoming posts.

Read full post...

TDR - Test Driven Review

We all did it a couple of times, but it wasn't until recently that I found out how useful and efficient it was. Our fresh hires start working on production code relatively soon after their first day. Nevertheless we want to review their work before check-in.
Getting up to speed
I always start with, "Let me see the tests". It is only partially to emphasise the importance of tests, the real reason is that for me it's easier and quicker to engage in the task he has just solved. And this gives me the chance to profoundly review the code itself and how it looks.
Defining
Sometimes we don't even continue to the code, because it turns out that he misinterpreted the task at hand, and solved something else. But that's okay too, for through the tests I can very easily and clearly explain what the real task is. If we were to do this via the implementation, it would be less unambiguous.
Demonstrating
Finally, I can show him couple of coding tricks, again without being too superficial, yet being quite quick. What I mean is I can quickly refactor his code on the spot, without saying things like "... and you can imagine the rest" - no, at the end of the demonstration we have a still working code(checked by the help of the tests), but with me already having made my points on coding as we know it: expressive and duplication free.
Read full post...

Really.Only.Very.Rarely.

The jawbreaker above is one of the most efficient half-sentence that a client could unwittingly ruin your day with. And usually alongside your day goes most of the model you have been building up. On top of all there is this huge chasm between the thinking of the customer("Really, it's no biggie. We only have like two cases a month where this and that..") and the cruel reality of software's unforgiving nature, i.e. if you want the software handle those two-times-a-month exceptions then that piece of the software needs to be developed just as well as another piece that handles all non-exceptional cases.

Laymen have a hard time understanding it, and for us it sure feels like trying to explain the colors to a blind man. No wonder, I mean we have learned software in school for years, have been around in the industry for even more. We spend most of our time in an environment where this unforgiving nature of software is self-explanatory and taken for granted.

It hasn't been till only recently that I realised how this problem is actually an opportunity. Why this jawbreaker is not something you should loath and fear -- on the contrary. This is something that can help you deliver quality software on time.

The answer is almost here. I just need you to take a second and find out on your own.
Read full post...