Most agile teams use “stories” for agile planning, but there’s still some confusion as to what a story really is. This becomes a particular problem when a team is asked to estimate some grand feature which takes one bullet point on a marketing slide but might take several iterations to implement.
It can be tempting to fall back on traditional project management techniques and start a process of eliciting “requirements”, then splitting the big story into a slew of sub-components and tasks (all mandatory, of course) with a rippling gantt chart of dependencies and timescale. For an agile project, though, this is the “dark side”. and can easily distort the rest of the development and delivery process beyond all recognition.
What we need is a more agile way of digesting such large chunks of work and somehow turning the a single big “must have” into an iterative, evolutionary, adaptive prioritisation.
Marty Haught has some thoughts and suggstions on this topic (Handling Large Stories in Agile) but it seems to me that the core solution is to remember that the project as a whole is essentially just a large story, and so the large story may be approached in exactly the same way.
This is an important, but under-emphasised, aspect of an agile process. It is “fractal” and “self similar” in that it should have the same fundamental structure regardless of the level at which it is viewed.
There are lots of approaches to estimation for agile projects, but not all of them include estimation of risk. Some approaches deliberately ignore risk, preferring to work from hindsight and averages.
For the others, a consideration of levels of risk for each estimated story or task seems a good idea.
InfoQ: Agile Risk Management.
I know it’s a funny time to be writing about hiring with so many layoffs, but any company which can afford to hire needs to hire the right people more than ever. We have spent a lot of time and effort on the traditional CVC/resume and interview process, and still managed to reject the great majority of applicants. So I’m always looking for a better way to do things.
The “extreme interview” process described in this article is an interesting step along the way.
Hiring Software Developers: The Agile Aptitude Test
Coping with difficult times is a topic of the moment. Jared from Agile Artisans writes about optimising a team.
Agile Artisans::home.
For some time I have beem mulling over the posibilities of deploying applications to low-cost wireless routers to provide hyper-local services to wi-fi surfers. One thing which has always put me off is the apparent need to dig deep into low-level Linux hacking. It’s a *long* time since I last did any significant C development.
However, it seems that there are ways to support a small footprint Java virtual machine on some of this class of devices. This in turn opens up opportunities for deploying some of my own small-footprint java software here.
Wolf Paulus’ Web Journal:PhoneME, a JavaVM for the Fonera FON Router.
Kathy Sierra is always worth paying attention to. This 30-minute audio is Kathy doing her inspiring, thought-provoking, energising thing at an O’Reilly conference.
Kathy Sierra on How to Kick Ass | IT Conversations
I sometimes have to suppress a shudder when people use the term “best practice”. Despite a positive sounding name, the idea of “best practice” is almost always used in a way that is restrictive rather than enabling. Declaring one approach or solution as “best practice” by implication shuts out other answers.
I will admit that for some (very narrow) fields there can be a common understanding of the one best way to do something, but this is often so well understood that it does not even get a name. Walking on your feet is generally better than walking on your hands or knees, for example, but I have never met anyone who referred to foot-walking as “best practice”.
In my world of software development, where the landscape changes at a moment’s notice, naming something as “best practice” is tantamount to declaring it obsolete. Yet large numbers of software developers still numbly follow the its lead.
James Bach tackles a similar issue in testing James Bach’s Blog » Blog Archive » The Great Implication of Context-Driven Methodology.
There are lots of online communities, filled with active and passionate people – exactly the sort of people TV would like to court, both as consumers and as providers of (cheap?) media content. However, most attempts by TV companies to engage and participate in the on-line culture have been pitiful.
How is it that organisations with such marketing power have continually failed to make sense of this opportunity?
Scott Stead has written a thought-provoking article on the subject, and (in the manner of on-line communities) visitors have enhanced it further with their own comments.
Television and Online Communities
For a variety of reasons, this morning’s stand-up meeting was a bit of a lifeless affair. I can recall times in the (relatively recent) past when such meetings were an invigorating start to the day.
Sarah Taraporewalla has some suggestions for adding a bit of energy to morning stand-up meetings.
Sarah Taraporewalla’s Technical Ramblings » Improvements to the usual stand up meetings
For years Frank Carver has been paying attention to the strange world of convergent technology. During that time he has discussed and researched broad subject areas, come to some surprising conclusions, produced and distributed digital media, scattered ideas and opinions like sparks from a firework, and above all consulted for businesses both large and small to help develop and deploy successful systems, services, and products in this highly complex arena.
