tag:blogger.com,1999:blog-12948038.post524841430719204631..comments2023-07-29T09:15:17.416+01:00Comments on allan's blog - Agile & Digital Business: More Agile failure modesallan kellyhttp://www.blogger.com/profile/06262139490250478379noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-12948038.post-5050198933513001792009-09-18T23:42:51.780+01:002009-09-18T23:42:51.780+01:00Allan,
You point out a genuine issue for new ag...Allan,<br /><br /> You point out a genuine issue for new agile teams. Some projects will have more than others of these impossible-to-estimate tasks, and they can derail agile progress if they are not handled appropriately. <br /><br /> I work a lot with engineering teams that have to cope with unknowns during development (I coach agile teams and managers). Ideally those unknowns are investigated & understood before development begins - at least that is the aim in traditional processes. But that is getting more difficult to achieve as projects become more complex. So we need to handle this kind of uncertainty within the development period, without allowing it to blow our commitment to stakeholders.<br /><br /> What I have advised teams to do is first, recognize when your estimate is really just a guess. That's a sure sign that you have an R&D task, not an estimatable task. (You could call it an investigation task or a discovery task - there isn't an agreed term.) For R&D tasks set a time box, and schedule that task a couple iterations before you need the knowledge it'll yield. <br /><br /> If an R&D task has been given a time box of 8 hours, then you'll devote up to 8 hours to it in the iteration, and no more. That may or may not complete the task's goal, but it will yield information - you'll have a better idea of what is really needed to do the job. Then you might be able to carve out some estimatable tasks for next iteration. Or you might still have more mysteries - if so, write up those R&D tasks and schedule them.<br /><br /> In this way you stay in control of how the team's time is being used. True, you cannot force discovery of new knowledge to occur at a specific time, but if it is really important, you can choose to devote a big part of the team's effort to the time-boxed R&D work in a given iteration. This isn't a guarantee but it increases your odds. Best of all this is explainable to business stakeholders. If other agile tasks are proceeding as promised, those stakeholders are much more understanding of the situation with R&D tasks.<br /><br /> I've had even brand new agile teams use this technique successfully, and stay in control as they safely dug up new knowledge while delivering on the work they understand well enough to estimate.<br /><br /> - Nancy Van Schooenderwoert<br />nancyv at leanagilepartners dot com<br /><br />Agile coach for embedded and safety-critical systems<br />http://www.leanagilepartners.comNancy Vhttps://www.blogger.com/profile/08506802380551811891noreply@blogger.comtag:blogger.com,1999:blog-12948038.post-48593276632638509352009-03-02T23:02:00.000+00:002009-03-02T23:02:00.000+00:00I translated this article into Japanese language. ...I translated this article into Japanese language. You can find it on http://d.hatena.ne.jp/masayang/20090226/1235702314<BR/><BR/>日本語にした記事を http://d.hatena.ne.jp/masayang/20090226/1235702314 にて公開してます。Anonymousnoreply@blogger.com