Category Archives: Agile

Tracking hours worked on a scrum task is counterproductive

Leave a reply

Right now I’m reading “Agile Data Warehousing Project Management: Business Intelligence Systems Using Scrum” which I can heartily recommend. This article is about one quote in particular:

Unfortunately, tracking actual hours spent on the individual tasks is ineffective, aims at the wrong objectives, and drowns the developers in detail while undermining agile’s pillar of self-organization that is so crucial to a team’s velocity. Tracking actuals should be strongly discouraged.

I would go one step further and say tracking actuals can end up having a negative effect on your scrum project. Before I get into why its worth pointing out that for short periods of time it can be useful particularly if you need to gather data on where you are spending your time (see the second point below). Once you have the data though – stop recording.

So why is tracking actuals so counterproductive? Primarily because it subverts the iterative estimation method.

One of the key activities in a scrum process is to update the remaining time estimate every day. From this estimate a burn down is calculated and the burn down is then used to monitor and adjust the sprint in order to deliver.

Consider what happens when scrum team members are logging the amount of time they worked on a task. Simple maths tells the remaining time is the current estimate minus the hours worked so there is a temptation to skip the re-estimating step. As a result a sprint burns down at a constant rate (ignoring task completion as a backup progress indicator) and inevitably it is not until the end of the sprint that underestimation is discovered; too late to do anything about it.

This second point can be good or bad depending on management and team culture – if you log time correctly and in detail you will know where you are spending time including interruptions, meetings, etc. There are two types of response from the team:

  1. Look at all this waste activity we are doing – how can we remove it and spend more time on value add work?
  2. How can I possibly deliver on my sprint commitments – look at the other work I had to do during the sprint.

Obviously you want the first response.

Finally, overshooting sprints is something to be avoided but often there are additional constraints on time logging that cause you to miss estimate future sprints as well. I know of many organisations where team members are required to log a fixed number of hours a day; no more, no less. You can imagine the havoc this causes – if you work 5 or 15 hours during one day on a task but have to log 8 then you create an inaccurate data set from which to base future sprint planning on.

 

Using an open source committer policy in the enterprise

Leave a reply

Southbourne BeachHow would you change your behaviour if the person reviewing your code had the final say on whether it makes it into the source repository?

I often see code reviews done in principle but not practice. The workflow goes something like this:

  • Developer assigned a new feature
  • Developer designs and codes up the feature
  • Developer checks the code into source control
  • A reviewer is found/assigned
  • The reviewer reviews code and finds a bunch of issues – a lot to do with the design
  • The developer fixes a few of the easy code related issues
  • Time is running out so the remaining issues are left
  • Developer moves to the next feature

Contrast this with the usual open source workflow where the reviewer is the committer and not the developer; the reviewer is responsible for the final code quality and it easy for them to refuse your code.

If you were the developer in this situation what would you do? Would you discuss your design with the reviewer before you started work? Would you keep the reviewer updated with your progress and any decisions you made? Would you make sure there were no surprises for the reviewer when they finally saw your code?

If you did then the reviewer feedback should be minimal and relatively easy to fix, more importantly code quality is maintained and without an expensive rewrite.

Programmer Personality Type

Leave a reply

My programmer personality type is: DHTC

You’re a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.

You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.

You work best in a Team.
A good group is better than the sum of its parts. The only thing better than a genius programmer is a cohesive group of genius programmers.

You are a Conservative programmer.
The less code you write, the less chance of it containing a bug. You write short and to the point code that gets the job done efficiently.

 

Third time perfect

Leave a reply

For some reason when I’m developing something new I always end up changing my design twice. Note, I’m not talking about architecture here. Architecture is a higher level concept and as such isn’t killed by implementation detail the way a design is. I think there is a reason for this multi-version development though.

The first design is basically a prototype exploring possibilities. At this point I’m not sure what the best solution is or even what techniques might be best to use. It only just does the job and is probably not very elegant or efficient. Not something to be proud of.

The second is usually a great design but, more often than not, flawed with a super hero style weakness. It will be elegant, efficient and cover every requirement imagined. The only problem – it will never be finished. This second iteration is usually complex, over designed and would take an eternity to implement.

After a good dose of reality, the third version takes shape. It’s much more practical, easier to maintain and solves only the requirements that are actually needed. These three designs are usually quite different. Not what the XP crowd would call iterative implementations but the end result is similar.

I think it’s important not to get too attached to any one way of doing things. I see some who start coding and stick with their first design to the bitter end no matter what. People often complain that a v1 product is OK for early adopters but not general consumption. Iterative design like this enables that sought after v3 product in your first release. Just don’t take three times as long to implement it…

Coder Block

Leave a reply

OK, I’m a little embarrassed to admit but I’ve suffered from coder’s block this week. It’s a state similar to writer’s block which is “a usually temporary psychological inability to begin or continue work on a piece of writing”.

I think probably everyone suffers it from time to time and, although I haven’t had a case for a several years, this has come at a most inopportune moment because we are on a very tight schedule with our current release.

I guess it’s a little like depression in that you can’t just mentally “fix it”, you need to work through the cause. In this case I don’t think it’s an inability to write code, it’s more a case of too many possible solutions to the problem in question. They are all good but none are perfect. In particular one of the requirements is to allow additional code generation (note – not just an add-in, this is adding to the system) post release by our professional services engineers. This is hard for me because my brain prefers to work spatially – I need to see the design animated in my head before I code it up; not something that’s possible if an unknown chunk of code if going to be added by someone at a later date. Talking with other developers didn’t help because all that did is give me more good solutions to consider.

The other problem is that a number of very intricate details have to be thought about or the implementation won’t meet the requirements. Completely overwhelming if you look at them together so on Friday I decided to take a leaf out of the extreme programming book – baby steps. I started by ignoring the mass of requirements and implementing a really small section. By lunchtime I was back in the flow, I managed to check-in something yesterday evening and things are looking to be back on track.

So if you are suffering similar then I can offer the following advice:

  • Take a break and do something completely different like go for a walk, however doing this too often is just procrastination
  • Try and work out what is causing the block and fix those issues one at a time
  • Take small steps to get something (anything) working
  • If all else fails, see if you can swap your feature with another developer

Surgical Team Development

Leave a reply

Sometimes, when you have to get a lot done in a ridiculously short time, you need a different approach. As a case in point, we need to replace all the remaining ASP code in our product with ASP.NET before we add some essential new functionality. If we don’t we will be stuck with the old code forever. This new functionality has to be delivered in a matter of weeks. It could be implemented in classic ASP but it will be much easier and faster using .NET.

What is called for is a few days of pure implementation. No “discussion”, no “difference of opinion”, just code. It’s risky – probably only a 50% chance of success but if it works then we could save days in the immediate future and extra weeks down the line.

There is a way this could work; by modelling the team on an operating theatre. In this setup, there is one person who does the bulk of the work backed by a second to give help and support. These two make the core pair – everything goes through them on the way into the product. The rest of the team are assigned packets of work by the core pair on an as needed basis. When the packets are complete they are given back to the core pair to stitch into the product. Effectively, one feature at a time is worked on by the entire team.

The main benefit to this style of team is the minimal communication needed, resulting in a higher code to comms ratio. The packets of work are usually so small that they can be described in a couple of sentences. If the result is not quite right then the core pair make whatever changes are required saving the time usually spent explaining extra work to the developer.

There are two key points to note before you embark on a development style such as this. Firstly, the core pair has to have a very strong shared vision of what the result should be. If not then you won’t be on a straight line to goal and too much rework will kill the efficiency of the method. Secondly, it can be a bit ego bruising to the non-core developers. They are told exactly what to produce, they have no real opportunity for free thought and the code they return may be modified or even not used. Nearly everyone can put their needs and feelings on hold for a week (even developers) but I wouldn’t push it beyond that. This is only for tiger-team style development.

Customers don’t care about requirements

Leave a reply

They only seem to care because we, as software developers, make them play the requirements game. In reality, the only thing that matters is how the product matches up to their expectations. The big problem is that you can’t capture them in a document to use as the blueprint for development. There are some things you can to make sure your customer is happy with the result:

  1. Write a short “Vision” document describing the key features to get everyone on the same page early on
  2. Program by feature to produce functionality early, don’t spend too much time on infrastructure
  3. When you’ve completed a feature, show it to the customer and get feedback
  4. Allow the customer to change their minds

These points will only work when both you and the customer share the project risk; either with fixed rates/variable time or fixed time/variable functionality.

If it’s a fixed price/fixed functionality contract then you’d better start writing those requirements…

Agile Project Management

Leave a reply

I’ve just started reading “Agile Project Management” by Jim Highsmith and it’s looking very promising. Whilst reading chapter one the point slapped me like the Tango Man – it’s the way agile projects are different to others.

Traditional project are all about deciding what you are going to build and then carrying out your plan whereas with agile projects you have a plan but it’s about how, not what, you build. In fact the key point made by Jim is that agile projects are all about experimentation and adaptions.

He cites a comparison with the pharmaceutical industry which makes things very clear. A few years ago they used to sit down and design molecules for a specific task whereas now they synthesise thousands of molecules at a time and use automated testing to screen for desired properties. The results are fed into a database which the scientists use to make their next steps. This rapid experimentation enables them to generate new drugs much faster even though they don’t know  final until it presents itself.

Consider this in the context of software development. Rapid cycles of experimentation with unit tests to screen the results and ensure forward motion. These two concepts enable a project to progress in a more efficient way than if a solution were “designed”.