Archive for March, 2007

Dealing with unexpectancies

March 27, 2007

Nuno writes that “Why shouldn’t we try finding out find a model to deal with unexpectancies instead?
The thing is that if you by some cosmic accident find too much unexpectancies along the way your iteration plan will become a baby monster.”

Well, we do assume change will happen and most times it does. We also try to build some slack into each iteration, so that things can go wrong (because they always do) — that’s what velocity is for. But in the end: you’re right. There is that worst case scenario where everything falls apart and all the high-level estimates are wrong and we have to update all the planning just like it was a classicly managed project — i.e. update the project plan and re-do all the resource planning. From my experience this worse-case rarely actually happens.

There are some underlying assumptions:

  • Features are independent, negotiable, valuable to users, estimable, small and testable
  • We can easily move features from one iteration to another
  • We can use the same resources for each iteration

We know that in reality these assumptions are either wrong and at best partially true. However, we can turn that around and make that a roadmap for our business and IT, e.g.

  • Spread the knowledge between BA and developer resources so that it becomes easier to use the same resources for a number of different iterations (hitting different systems)
  • Make the technical architecture more modular (there are some pretty standard ways of approaching this for legacy systems)
  • Teach the business how to take thin enough client-valued strips of features across systems so that they are small enough for a few to fit into an iteration

Technorati Tags: , , ,

Six Month Review

March 27, 2007

Mr Anderson has some impressive results in his Six Month Review:

  • An average of a release to production every 9.5 business days
  • Zero escaped defects this year

I am getting on to being about six months into my new role and I would love to be showing results like this. I guess we are on different journeys…

He also points out that he does not have that many good old fashioned agile processes:

  • No test driven development
  • No pair programming
  • No continuous integration
  • No burn down charts

His conclusion is spot on: there are many way of being agile. You need to take a close look at what is not working where you work and find ways of improving. But one size does not fit all. The process of discovering what works and what is stopping you can be consistent. David suggests four ‘golden rules’: focus on quality, reduce work-in-progress, balance demand against capacity, and prioritize. These are great starting places to start.

At World Directories, I have been starting from a philosophy of Thinking Processes: identify the systems of cause and effect that determine how the organisation works (here: how the Online & Search business works with IT, Operations and our partners); identify the few variables that determine the performance and work out how to improve things in a way. This has led to a number of agile best practices that we are now introducing across the different countries, including: iterative time-boxed development, simplifying the metrics we use, effective prioritisation and focusing on quality.

Technorati Tags: , , , , , ,

Boomshine

March 23, 2007

I have playing the wonderfully addictive Boomshine instead of blogging about our latest agile developments. I have not passed above the mythical level 12, but I have found that deep Zen-like meditation of the general patterns actually does help. A tip from my wife: look out for patterns that move from the centre to the corners or form the corners to the centre. The insight is to realise that balls bounce off the sides, which gives the sides a greater concentration of power than the centre. See more games of this ilk.

(via LinkBlog)

Technorati Tags:

Less formal, more rigorous

March 11, 2007

In conversation with our head of audit, I was explaining how our agile methodology is actually a lot more rigorous than old-school project management. We are also less formal. The two are hard to distinguish at first. Let me give a couple of examples.

We are more rigorous. If we start to move our timeboxes around, our whole paradigm falls apart. If we unexpectedly discover that a feature is going to take too long to test, we push it to the next iteration instead of moving the iteration end date out. If we don’t do this, we need to re-write the release plan, re-estimate tasks, re-do resource plans and (where I work at least) replan priorities for other projects, as well as generating the same set of documentation for these other projects. This is all waste work: work that does not bring us closer to client-valued features deployed and working in production. It’s also typically the thin end of the wedge: pretty soon our teams spend more time on documentation that on getting value-adding software working flawlessly in production.

We are less formal because all documents that we use are supportive not directive. I don’t demand people use a certain Excel template for a release plan. Thinking about certain attributes for each feature and for each iteration add value in our experience, and in teams that are starting up I strongly recommend (and yes, even enforce) this. But I don’t really care how our teams record this information. I have been down the path of only checking that everyone is using the same Word template or Excel sheet and mistaking that for real value — and I won’t be going down that path again.

Technorati Tags: , , , , ,

What is the breakfast of champion agile development teams?

March 11, 2007

Feedback is the breakfast of champions, or so the saying goes. The more I peer into our methodology for getting more projects done faster and more successfully, the more I think that great early feedback is the key to its success. In software development methodologies, feedback is called testing.

The phrase “working client-valued software features” contains two types of test: that the software works and that it adds value to a client. Client wishes change over time as does the software landscape that the new business features are released into. The world is moving on as we develop software. The more frequently each test is repeated the more quicker the project can react to these differences. Unit tests and functional tests help us discover what is required to get the features working. End-to-end tests and frequent releases are required to discover what is required to get the features adding value. The later a mistake is found, the more work that needs to be re-done in order to correct it

Each type of test requires work, so there will be a trade-off between testing and development. A key component of agile is flipping the script so that we bake tests into the development lifecycle. This makes tests so easy to execute that it becomes inexcusable not to test. Feedback comes baked-in every day.

You can see this from the Top Ten Agile Best Practices. Of the ten, four are ways of introducing feedback earlier:

  • Code regression testing
  • Continuous integration
  • Test-driven development
  • Database regression testing

How do you get earlier feedback in your projects?

Technorati Tags: , , , , , ,

Seasonal Blogging

March 11, 2007

I will freely admit it. I did not actually like reading Seasonal Blogging . It made me think of all the things I dislike most about my blogging when I can’t really think of much to blog about. I’ve been ill for a couple of days: not ill enough to take time off work, but ill enough to mope around the house feeling down in the dumps. I read a lot, but couldn’t think of anything to post about. “Seasonal blogging” is about exactly this.

But the blog that it linked to, Ben Yoskovitz’s 6 Steps To Getting Back Into The Blog Saddle, is great. I am not a post-a-day kind of blogger (as regular readers will have seen). It’s often tough to get to a post-every-couple-of-days. But when i haven’t posted for a week or two, knee-jerk survival instincts kick in and I find myself pondering what exactly i can blog about.

Ben’s suggestions boil down to:
– Invest your time wisely. The best investment returns through a number of great posts.
– Go for quality not quantity

As you’ll see from last post, I steadfastly ignored both rules (with the minor excuse that I had not actually read either of them at the time), but post a link: what Ben calls “content filler”. Ah well, obviously that blew my fragile readership. I can only hope that as my health improves, so do my posts!

Technorati Tags:

An interesting blog…

March 5, 2007

I haven’t posted for a while, because I have in my spare time been
a) watching my investments plunge downwards and wondering whether I shouldn’t have diversified a little more
b) getting my head around yet more of the Cocoa Foundation framework and Core Data basics. Learning to love that whole Next Step Object thang.
c) reading too many new blogs to mention
…except i’ll mention a couple over the next few days. Mr Anderson’s Agile Management is my main source for these links. (Off topic thought: does David get many The Matrix jokes after it came out; and, what is it that makes us believe we actually know people well enough to make these kind of comments after reading their books or websites a few times?)

I enjoyed a number of articles on Projectized. The English is not always perfect (says my subconscious proofreader) and YMMV on a number of the posts, but there are some good ones in there too.

Technorati Tags: