One of the problems with agile development is that it’s subject to changes, so means you’re in danger of changing it into something which isn’t agile. How do you know when you’ve gone too far?
This isn’t a problem for seasoned agile practitioners, but it’s a concern if you’re just starting out, or working with people who are. It’s certainly something I found looking back at my early agile days. There are some non-obvious or difficult agile practices which one might omit, but which make a big difference. How do we know what to watch out for?
My suggestion is to ensure there are some fixed points. Then you can evolve the process without straying from the ideals. My rule of thumb for creating fixed points is this:
Could I stand up at an international conference and be sure that my process would be generally indistinguishable from that of any of the speakers?
With that in mind, here’s what I’d want to be sure I did before I stood next to my peers…
Daily stand-up meetings at a set time
There are three things here: daily, stand-up, and set time. Making the meeting daily can be difficult, but having spoken to people who hold weekly meetings it’s pretty clear that they take up the same time in the end. In addition, daily communication keeps people veering too far off the track.
Insisting the meetings are stand-ups might be difficult and there’s no clearly tangible gain — after all, if you keep the meeting to 5 minutes, who cares whether you’re sitting or standing, or bouncing on one leg? But this important to me because it instills a sense of urgency. A sit-down meeting fails to distinguish us from our document-heavy, procedure-driven colleagues. It’s entirely psychological, and all the better for it.
Making the meeting at a set time can be difficult, particularly if the lead has other responibilities. But this is important to me because it forces people to focus on the project. It says “The train’s going at this time — be there or get left behind”. It tells people the project won’t wait for them. It keeps the team to a rhythm.
Iteration kick-offs and/or close-downs
It’s surprisingly easy to get away without these: some of last iteration’s story cards might not be finished, so the team just carries on; new story cards become available when the old ones are done, which could be any time. Iterations blur.
But a formal meeting to mark the iteration boundary again ensures the project and the team keeps to a rhythm. Coming up to the boundary it ensures people know ahead of time that they’ve got something to aim towards, and deadlines always focus the mind. Entering the new iteration it gives people the chance to think afresh and renew their goals.
Mid-project retrospectives with the whole team
An end-of-project retrospective is good, but mid-project retrospectives are agile. They ensure the team really is seeking to improve not just for the next project but for the current one. It can be difficult to see the benefit of retrospectives (another time-consuming meeting), nor do I think they’re not very obvious. I certainly don’t recall them cropping up in the Extreme Programming Explained or in Agile Software Development with Scrum. One way to keep retrospectives effective is to ensure any actions are (a) objective and (b) assigned to named individuals. This way improvements will be much more tangible.
Continuous integration and testing
This is certainly an obvious feature of agile, but it’s also difficult. If the project is anything more than a few days long it’s worth spending the time up front to get the continuous integration and testing working. This ensures rapid change and frequent delivery. Otherwise it’s very likely that features and fixes will regress, that this won’t be discovered for long periods, and fixing the regression will take a long time, too. Agile is about frequent delivery and constantly moving forward at a regular pace. That can’t be done without continuous integration and testing.
Frequent customer demos
Again, not necessarily obvious because while agile talks a lot about on-site customers it doesn’t often talk about the common case of customers not being around as much as you’d like. Frequent mid-project demos are the next best thing — at Guardian Unlimited we call them “show and tells”. A customer demo has two benefits. First, it steers the team towards feature-driven development rather than architecture-driven development. (It’s very hard to impress a customer with a data object layer.) Second it encourages prioritisation of the next batch of features.
There’s much more you need to do to be sure you’re being agile, but to my mind the things above are easily missed. So next time I create a team for an agile project I’m going to make sure we start with some fixed points, and evolve round those.
2 thoughts on “Is it agile? Check the fixed points”
if your iteration and planning run synchoronously then
>>between the end of the iteration and before the next planning session starts
if your iteration and planning run asynchoronously then
>>between the end of the iteration and before the day one of the next iteration
regrouping is a fixed and intentional period of time where developers on the team can explore the changes to the codebase either individually or in pairs, preferably. because a pair might not work on a particular area [for n reasons], knowledge of that area, and the changes, need to be assimilated and absorbed. not *always* possible in a pair situation becos of the time-last-seen and number-of-changes could require half a day in itself just updating the other pair as to what’s going on before starting on the story=> estimate is already out and may change becos of fresh insight “new” developer has on the story.
as long as you can afford and dependant on what the team needs. ask the team: are there areas you would just like to touch base with before we forge ahead? usually not more than a single day is required, and half a day should suffice for when it is needed.
team has more input [more certain knowledge even if they’re not recently actively involved in an area] when it comes to planning; ideas and solutions are more prevalanet [the more heads the better]; and team members are less reluctant to jump into stories they might feel they lost touch with;
doesn’t have to be EVERY iteration- it’s agile, so when and if needed, but the space for it needs to be created.
weight up the time lost in communicating changes to codebase as you need to versus having that knowledge more intentionally before starting the story. it’s not linear maths and YAGNI doesn’t apply in this case. the impact of knowledge upfront can be critical.
Nice idea. That sounds to me a little like tackling technical debt as a team, rather than as individuals. Sort of like retrospectives on the codebase.
Comments are closed.