Inspired by the work of the Limited WIP Society and kanban community, I set on my journey to create my very own kanban process for my team of me and my subject matter expert/product manager/QA.

First we identified the stages and queues of our development process. We decided that the process starts with the Analysis of a work item. To be quite honest some informal analysis and some preparation work to clear out dependencies takes place before that but we did not formally include it in our process. Most of it is tracked at the road map level. The analysis yields one card, trimmed to a manageable size with the acceptance criteria expressed as a few BDD-style scenarii.

Then there is an Analysis Complete queue. It buffers developers.

Then there is the development in progress stage where cards are again actively worked on. We try to follow best practices for the most part. A card cannot leave this stage until the tests pass, the reports are fine (no cyclic dependencies, no significant PMD or FindBugs warnings, enough coverage) and the acceptance scenarii have been automated with cucumber (and the awesome cuke4duke maven plugin).

Then there is a development complete queue. It buffers QA.

Then there is the QA in progress stage. This is about verifying the scenarii manually and verifying their automation. Any issue or concern raised is immediately addressed. If the issue needs tracking, an issue card is created and attached to the card.

Then there is the closed stage which is the exit of our process.

We do not track statistics internal to the process aside from the cumulative flow diagram. The administrative cost of that seems too high for such a small team. We do track the cycle time of each card in our process.

I will write more on the observations from the first month in an upcoming post.

Some organisations, or parts thereof, have a development process that lives squarely in chaos. Worse, many members of those organisations believe it is a normal, sometimes even desirable, state. The others have left.

What I have noticed in those environments is that new techniques and technologies do not get adopted. Instead a passive-agressive attitude exists, whereby the change is not supported and when things degrade people are quick to use it as proof their old familiar ways are superior. Any attempt to introduce any kind of methodology that is “not invented here” is doomed in this context. I am quite convinced that any change is actually doomed. I may get the opportunity to observe this in the introduction of a “waterfall” process in my current company.

Worse however, while many would think that an agile methodology is more appropriate for those organisations (and they are probably right), it is almost impossible to successfully introduce it. In most cases members of the organisation lack the practice of self discipline necessary to support an agile process. And building that requires in turn a full cultural change where, initially at least, the disciplined application of good practices is valued more than the result.

How would you go about it if you are not the CEO ? Do you have gardener’s tip to successfully grow agile seeds ?

César has been a good friend and a great mentor for me. He is resourceful, dynamic and energetic. As it happens he has also contributed ideas and comments to this blog.

If you do have a vote in the 2009 Agile Alliance board election, please take a moment to review César’s position statement and then vote, for him preferably !

Last week the Bay APLN had a great meeting where Chris Sims offered some of his agile learning games. The games offered the opportunity to feel and illustrate what has long been published (and is still thoroughly ignored by a large chunk of managers and workers). The first game we played was to illustrate the effects of multitasking. I have come to realise two things at the end of the game.

First what we call multitasking really is an interruption driven work process. That process is a consequence of our overall work organisation. Instead of having cadence, we usually expedite. THe way we expedite is also grounded in the idea that we should not be idle and we should be “utilised’ all the time.

Second the downside of multitasking really is the time it takes to resume a task after an interruption. It is a set up time or a transaction cost.

A couple of things were illustrated. I offered that the pomodoro technique was a great help to handle multitasking. Essentially the pomodoro technique provides cadence and thereby suppresses the interruption driven work style. In exchange it provides predictable windows to address urgent requests. In this way it forces triage between urgent and not urgent while preserving the ability to adapt the work stream. It also enforces the idea that it is good to have idle time. Other signalling techniques were offered to prevent interruptions.

It was interesting to witness that the default attitude we had to resolve the problem of interruptions was to increase the batch sizes to avoid them. Essentially the same idea as reducing the set-up time in the industry. Importantly the discussion turned to techniques to reduce the transaction cost (context switching time) associated to multiple tasks. This is the realm of getting things done techniques (to-do lists to boot). One interesting remark from David Chilcott is to note down the next step in your current task before switching to another task.

To summarise, multitasking is good. Interruption is evil.

What techniques do you use to cope with interruptions ? What do you do to facilitate context switching ?

Today I am starting a new job. Different company, different title, similar role. So I thought I would try to describe why I am moving on.

I am going back to a software vendor I left it a few years ago. I left because I was missing direct contact with the business users. I left because I felt I had reached the limits of my influence and growth there. I am going back because I am given a great opportunity both in terms of career and personal development. I have a chance to further the changes I helped introduce back then. I get a chance to apply innovative solutions. That is the bottom line for me. In my previous role, despite all the great people I met and worked with I was not getting to apply innovative solutions. And therefore I was not learning as much as I would have liked. This is the deep reason why I felt dissatisfied. The other elements that took part in my decision were only the back breaking straws.

In fact I strongly believe turnover is beneficial for companies and employees alike in the software engineering world. As long as the turnover aligns with project duration it is not overly destabilising. The company gets to hire new people with fresh ideas. The employee gets to learn new things. I wonder if knowledge workers could be classified in the same way as open space participants: pigs, bees and butterflies.

What do you think ? What kind of worker are you ?

I have already mentioned that, in my opinion, configuration is often the result of a lack of design. In other words we introduce configuration as a substitute for a design decision. There are some cases however when it is desirable to make things configurable. For example, when a software vendor needs to enable clients to plug in custom behaviour without a restart of their system.

I would contend this is a rare scenario and that in most cases injection of dependency addresses the actual need (think assembly with Spring for instance).

I imagine cases when that is not enough and I was wondering at what point does the configuration parameters start to form a DSL. I was also wondering when it becomes more efficient to create a DSL to program the adaptation to local conditions. An initial guideline could be that it is as soon as you thing of storing the configuration in an XML document.

What is your take ? Does it help to rethink configuration as a DSL ? What is your experience ?

I recently had a pressing need to return to one of my youth’s favourite pass time: the jigsaw puzzle. I, shamefully, never realised that this was related to the basics of problem solving. So here are my observations from the latest jigsaws I did.

You need a big picture to build a mental representation of the problem. This enables to make sense of the various pieces and enables to organise them in groups. The big picture also drives the resolution strategy such which elements to tackle first, the big groups and how they relate to each other.

You have a frame. That is a given constraint of the problem. It is usually useful to build the frame first but it is not necessary. The simple knowledge it exists is fundamental.

When I am assembling a puzzle I typically go trough iterative sorting, producing finer and finer sub groups with the pieces. This is enabled by the big picture and by the knowledge that is acquired over time of how the pieces relate to the big picture.

I proceed to the assembly in groups that are easily identified. I do not force the issue of finishing a group though. If a lot of pieces are missing, it is an opportunity to iterate on pieces sorting. If only a few pieces are missing, I will opportunistically gather them in a future sorting operation.

Sometimes I build small groups without knowing exactly how or where they fit in the big picture. Such groups are attached to other groups later on, after some more overall progress has been done.

Sometimes I misplace a piece. This usually happens in uniform parts of the puzzle, trying too hard to put pieces with little correlation from the neighbouring pieces. This leads to rework. It happened to me recently that I discovered the misplacement when trying to put the last piece. Resolution requires a careful inspection of how the other pieces fit together.

When a group is too difficult or proves elusive (such as a large area of a single colour), I alternate pointed and organised attempts at finishing it and pauses to resolve other parts. This usually means that they are the last parts finished. Usually at that point a spectator would be able to relate the puzzle and the big picture.

Although puzzles are significantly better structured and simpler than real life problem, I find that I apply a lot of the same strategies in my daily work. What do you think ?

The Bay APLN was kind enough to enable its members to beta test the Group Coherence workshop that will be presented at Agile 2009 by César Idrovo and Joanna Zweig. And it was really good. I would not go as far as life changing (as others have reported) but it certainly helped make sense of what lies beyond team dynamics.

I will avoid spoiling the experience of future attendees by describing the workshop. The process and the tools you will be building through the workshop will help you facilitate the apparition of group coherence. And it is far from being an exact science for now.

My personal highlights were:

people need to know their roles,

heroes and martyrs are an obstacle because they do not leave enough space for others to contribute,

the normal ‘good’ team dynamics must exist,

some sense of purpose and pressure must exist,

practice is needed to transforms practices into reflexes.

This eventually led me to form the metaphor that group coherence is a crystallisation process. The chemicals (people) are at some temperature (group dynamics) and under some level of pressure (deliverable, urgency, social pressure). When temperature and pressure align (and unfortunately that alignment depends on the chemicals) a crystal is formed. It could be a snow flake or a diamond.

Now some may prefer the cuisine metaphor but in the end, it is all chemistry anyway.

This is a rebound from the openspace session I hosted at the BayAPLN event on April 21 2009.

III started by noting that it is not your money. I initially interpreted to mean that therefore we do not have to care. Except if you have been entrusted to manage it and you have a fiduciary duty to make the most of it. Which lead us to the two main themes that informed the question which we essentially held to be the two sources of technical debt. One was the managerial impact. The other is the professional integrity of the team.

Lack of planing, disregard for appropriate buffering on delivery dates, inability to motivate the development team are all very heavy contributors to the increase of technical debt. The primary reason is that they tend to strip the development team members of their professional integrity, part of which is the pride people put in a work well done. In essence those managerial attitudes are akin to asking team members to break the windows of the building they are making. Or to cut on the cost of material while building in a seismic zone. To that extend technical debt resembles more a ponzi scheme than an actual financial debt.

We found hope in the professional integrity of the team. This professional integrity means, in my mind, that a developer should leave the code in a better shape than he found it. Pushing further in that direction it means that repaying the technical debt is a deliberate opportunistic activity. In other words technical debt should not be repaid for the sake of it, but only when it causes friction in the current work. Its repayment becomes continuous and integrated in the work stream. However, a lack of professional integrity (whatever the reason) will let entropy creep into the system and burden it with technical debt.

The conclusion, for me is three folds. First I changed my definition of technical debt to “things that could be done better” (now not, not things we could have done better). Second, you should not have to care about technical debt. If you have to reserve time to address, something is broken and should be fixed first. Third some debt is good and even inevitable, don’t try to eliminate it for the sake of it.

I was reading Neal Ford’s excellent articles on the benefits of TDD, part 1 and part 2.

One thing that struck me however is the attempt to limit TDD to test first and how this lead to a somewhat dishonest presentation of the test after approach. In the first of these articles the test after approach is stopped before the refinement phase that is made explicit in the rest of the articles and is well worth reading.

It is unfortunate because the real benefits, in terms of quality, from TDD come from the feedback loop that is created between code and test. It is the iterative refinement of the test and the code that provides the real benefits. It is a chicken and egg thing. Neither comes first, what comes first is an initial design idea based on the problem statement. In Neal Ford’s articles, one of those design ideas is to extract the set of factors whereas the problem does not require it (it requires the sum of factors and in many cases only a partial sum).

Testing before or testing after is an axiomatic decision that provides its own set of benefits. First it emphasises that the developer has to think about the design separately from the code. To a large extend this opens creativity as the design will be less constrained by the existing code. It is an explicit permission to re-factor as needed. The second (maybe the biggest) benefit of testing first is, in my opinion, that it is a clear signal that tests are not considered as a second class deliverable but as a scaffolding and design tool.

So to summarise, TDD is a design method in which tests are a design tool (regression testing is a perk). Test first is a process element that helps initiate and sustain TDD.