Skip to main content

Home/ Agilesparks/ Group items tagged pipeline

Rss Feed Group items tagged

Yuval Yeret

Alistair.Cockburn.us | Are iterations hazardous to your project? - 0 views

  • Simply using iterations, user stories and velocity doesn’t mean your project is agile – or on the way to success.
  • why “iterations” may be hazardous to your project: ‘’Danger grows when the results of the iteration are not directly linked to delivering the product to the end user.’’ Without that linkage, iteration results hang in the air
  • What gets in the way is that the project is set up as a pipeline, with programming put somewhere in the middle of the pipeline. In this project setup, there is really nothing the programmers can do to show how their work connects to deliveries, because there are work stations before and after theirs. All they can report is that “some new code is integrated into the code base.” They are doing incremental development but not agile development.
  • ...6 more annotations...
  • magine a project team of between fifteen and four hundred people. There are user representatives, analysts, programmers, database designers, and testers, arranged in a pipeline. The user analysts talk to the users, and then to the analysts, who write down user stories. The analysts write lots of notes on each user story, since it will be a full iteration or two before any programmer will pick up the user story. The notes are between one and ten pages long. Eventually, a programmer picks up a user story along with the supplemental details, code them up in an iteration, integrate them into the growing code base, and mark their velocity. In the same or a later iteration the database designers do the same. Eventually the integration test team comes along, runs tests on the whole thing, and feeds bug reports back into the programmers’ work queues. The users or project sponsors may see the outcome every few months if they are lucky.
  • The repair is simple: connect every activity to a release or delivery to real users (delivering to even one real user makes a difference). Evaluate the team’s work based on how often they deliver to real users and how long it takes a new requirement to reach the users. Replace the fuss around iterations with fuss around deliveries.
  • Break the pipeline, lengthen the iterations, lose the machismo, deliver the project.
  • here is no mechanism in the standard agile language that warns about this loss of touch. The currently standard language consists of ‘’iterations, user stories, ‘’and’’ velocity’’. By a perverse relationship between them, it is possible to equally shrink iteration length and story size, with velocity scaling accordingly. Thus, a team can feel as though it is become more agile, when in reality it is simply becoming more cut off from its user base and the feedback it needs to succeed.
  • Collocate the requirements gatherer, the database designer, the programmer, the tester. Lengthen the iteration period to one month. Give the requirements gatherer a week’s head start on the features coming up, but otherwise arrange that all of them are working on the same feature set in the same month.
  • As an afterthought, if your new iteration length is a month, you can still run one-week planning windows to make sure you don’t get off track during the month.
1 - 3 of 3
Showing 20 items per page