Archive for the ‘ Agile ’ Category

40 Hour Guideline?

For some the notion of a 40 hour week is too difficult accept, deeming it too short to really achieve anything. But the rationale for this working principle is built on sound thinking. Working long hours at fever pitch will not only stress a team out, but will induce mental fatigue to the point that silly mistakes are made, and the team will actually work slower and do less than if they were energised everyday and doing less. Obviously when a release is coming up or other such important deadline, then the amount of work the team does must be as flexible as possible, and working more should be acceptable.

I think there is something important to consider that supports the 40 hour week “guideline”. In a team that is energized and running at full-steam, the amount of things going on at any time could be quite large, with the whole team busy coding, designing or talking. Even when a team member is working on something, they will be actively engaged in ensuring they are aware of what is going on around them while they go about their business. Many people who truly engage with pair programming say they like it, but it can be draining. When we work alone, it is easy to take a “breather”, to sit back a little and reflect. But when a pair is engaged, theres no real breather to talk of – its a continual every rolling train of design ideas, forward thinking, code-reviewing and programming to carve the features into the system. When this process hums along like a spinning top, the energy required by the participants is greater than when working alone (certainly in my experience). This is all worthwhile because the idea is that the features that are being implemented are moving along at a productive steady pace and the quality of that work is second to none.

Even when pair programming is not used, there are other practices that actually support this steady train of relentless progress throughout the day, such as TDD (test driven development).  TDD as a practice and a design process can with experience become a profound tool to develop a system with, but its impact on the way its followers think and work, alone or in pairs, should be considered when reviewing the 40 hour guideline.  Just like a spinning top, TDD is difficult to get right, difficult to get it humming along.  But when it does, the level of delivery and progress can be just as profound as the practice itself, creating the well known “flow” state quite easily, and generating extended periods of high concentration and focused work – times this by at least two if this is being done with pairs.

Sometimes these periods of high productivity are like streaks of lightening across the sky, and the amount of progress in a working week might feel small and unproductive. Ignoring the human element that causes the daily mental, emotional and phyisical states of your workforce to fluctuate, a well running team should be able to accommodate and self-organize to help maintain its steady momentum, and the troughs should be less acute.  And this steady pace is built on the high focus developed from the XP practices and open working environment.  When things are truly rocking, it is not uncommon for me to arrive home absolutely exhausted.  But its a positive exhaustion, because its the effect of a causation that itself is positive.  I can wake up the following morning bright and early and be 100% ready for a day riding the development train, and this is part of the point behind the 40 hour guideline.  Happy people are more productive.  Being more productive further fuels happiness and well-being of the team, because they are riding on a wave of positive steady delivery.

The 40 hour week guideline is in the end just a guideline, and it should be appropriately changed to suite your environment.  But its a worthwhile principle of XP and other agile practices because if things are going well, progress will be steady and moving and theres no need for fever pitch.  If this isnt the case, if productivity is not as high and you’re thinking of increasing the hours to get more work out, it might be that other parts of the process arent working like they should be.  Increasing pressure to work longer hours might seem like the easiest approach, and in some cases it can be.  But there should be no need when the team has developed the steady pace.


Applied Abstraction (part 3)

Quick Review

I have raised quite a few points from just a small section of code. It is clear a failure to apply abstraction well has subsequently allowed the misplacement of system responsibilities within the AssignmentForm class. The business policy details belong not on a user interface class but on a domain class or something similar. The domain model has the role of representing the business domain, its relationships and its policies. Centralising business logic in the domain model keeps all of the important details in one place, and it should be through abstraction that these details are exposed to the rest of the software in a way that keeps the how hidden behind the what.

Continue reading

Estimation Smell

Sometimes it seems there are dependencies in user stories, and the dependency can cause confusion on how to proceed with the estimates, and like many things estimation isnt an exact science. A number of times over the past year this problem has cropped up in some form or another. One approach I like is to think of the stories in isolation, because it not only keeps things simpler for everybody during planning, but it also works very well with the principle of change – the customer is allowed to change priorities.

Continue reading

This is what we do.

There is a lot of debate about what technical work should be promoted to a story, and indeed I am presenting my own paper at Agile 2007 regarding this very topic in August this year. Work that arises and challenges us on a normal day to day basis does not need to be framed as a technical story. One particular area requiring technical stories seems to be in cleaning up code, but it is my belief that the team can deliver business value whilst cleaning up the code – because this is what we do.

Continue reading