Better software through software architecture and devops


Category Archives: agile

  • 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.

    This entry was posted in agile  and tagged #estimation #scrum  on .
    Discuss this on Twitter or LinkedIn
  • Southbourne Beach

    How 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.

    This entry was posted in agile  and tagged #code-quality #code-reviews  on .
    Discuss this on Twitter or LinkedIn
  • My programmer personality type is: DHTC

    You’re a D****oer. 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 H****igh level. The world is made up of objects and components, you should create your programs in the same way.

    You work best in a T****eam. 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 C****onservative 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.

    This entry was posted in agile  and tagged #personal-development  on .
    Discuss this on Twitter or LinkedIn
  • 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…

    This entry was posted in agile  and tagged #iteration #personal-development  on .
    Discuss this on Twitter or LinkedIn