http://niksilver.com/2006/07/07/is-it-agile-check-the-fixed-points/ Mostly about the management of software development Thu, 04 Dec 2008 19:50:22 +0000 http://wordpress.org/?v=2.6.3 http://niksilver.com/2006/07/07/is-it-agile-check-the-fixed-points/#comment-23 Nik Tue, 18 Jul 2006 08:37:42 +0000 http://niksilver.com/2006/07/07/is-it-agile-check-the-fixed-points/#comment-23 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. 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.

]]> http://niksilver.com/2006/07/07/is-it-agile-check-the-fixed-points/#comment-21 bryan Tue, 18 Jul 2006 07:15:53 +0000 http://niksilver.com/2006/07/07/is-it-agile-check-the-fixed-points/#comment-21 <b>Inter-iteration regrouping</b> When: 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 What: <b>regrouping</b> 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. How long: 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. Advantages: 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; Disclaimers: 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. Inter-iteration regrouping
When:
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
What:
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.
How long:
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.
Advantages:
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;
Disclaimers:
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.

]]>