Chapter 4. Story
OVERVIEW
It is Monday, January 2. The government Border Information Group (BIG) needs a biometrics tracking system for non-citizens entering the country, the Biometric Recording Or Tracking Hazardous External Radicals (BROTHER). BIG has a long list of requests, and Martin, the development manager, has convinced BIG management to use timeboxed iterative development and timeboxed evolutionary delivery. Thus, they will deliver the highest priority features possible by October 1. There is a wish list of features for the first release, and everyone has agreed it may vary, but the release date will not vary.
The plan is that after one or two months in operation at two low-volume airports, feedback from the border guards and travelers will be used to help decide refinements and features for the second release six months later, with a wider rollout. Following a Scrum practice, Martin and his team of seven developers also commit to demo to the Minister of BIG "running, integrated and tested software every three or four weeks, starting next week."
The project will use a combination of practices from Scrum, XP, and UP that Martin and the developers have decided make sense for the team. They organize their physical space: Rather than separate offices or cubicles with dividers, they take over a large room at one of the test airports, FooBarKhan International, near the border guards' office area. Four cubicles are set up near the project room that people can use when they need private time. The common project room is a Scrum and XP practice.
All furniture against the walls is removed. Tables for computers are placed near the center. The walls are covered in giant whiteboards, and whiteboard-like static-cling sheets are used as wallpaper elsewhere. This will support the practice of Agile Modeling.
The responsible BIG manager, Domina, moves into the project room, along with Itchy, a long-time border guard. Itchy will be dedicated full-time to the BROTHER project, and Domina agrees to be around "most mornings." This is the XP practice of onsite clients.
On Thursday, January 5, they get together and hold a two-day requirements and planning workshop, a UP practice. In addition to receiving a 20-page wish list from senior BIG management, many "agile requirement analysis" techniques are applied the first morning. After lunch (beer and cake, FooBarKhan's national foods), Martin poses this request: From the high-level requirements we've generated, choose the 20% most architecturally significant, risky, and valuable items. They use dot-voting to prioritize the items.
They spend the remaining afternoon and Friday morning analyzing the 20% items in detail. For functional requirements, they apply the UP practice of writing a few use cases, in the Cockburn style. For the nonfunctional quality requirements, they apply the Evo practice of clearly quantified and measurable goals; the vague "fast response" and "easy to use" goals in the original BIG wish list were not acceptable.
On Friday after lunch, Martin moves the team on to planning, even though some of the team want to spend more time detailing and clarifying specifications. Martin poses this challenge to the group: "We start developing next Monday, January 9. By Thursday, January 26, in 13 working days, we need to have a partial running system hooked up to at least one of the biometric readers. There will be a demo that morning to the BIG minister. What should we realistically do in the next 13 days from the 20% list we explored in detail? And, no overtime." No overtime or "sustainable pace" is an XP practice.
The group picks a common "happy path" scenario from one of the use cases that will force them to touch on many architectural factors and components (a UP practice), some other features, and spends the afternoon analyzing and estimating the related fine-grained tasks in an XP-style Planning Game. Note that the manager does not create the work breakdown structure, schedule or estimates; the team does this. Eventually, they discover that their first set of goals is too much work, so they scale back some of the features until the estimates match their available Ideal Engineering Hours budget (an XP practice). They wrap the meeting. Martin enters the task items into a Scrum Sprint Backlog spreadsheet.
On Monday, January 9, the first iteration starts.
On Monday morning at 9:30, and all subsequent mornings, they hold a 20-minute daily stand-up Scrum meeting. Martin reminds the team of the overall vision, and the specific goals of the iteration. They are standing beside the whiteboard where all the iteration tasks are written. After the Scrum questions, team members start volunteering for tasks, writing their name beside them.
Afterwards, the entire group listens to a presentation by Rebecca, the chief architect. Having a chief architect is recommended in UP. Rebecca spent the prior week investigating and considering architectural issues and designs, given the basic information she had. She lays out her vision of the big pieces and problems, to provide a starting point for decomposition of work by large components. Group discussion refines the ideas. Mid-morning, three subgroups head for the walls, doing Agile Modeling for different subcomponents, reviewing the written use case. The team reserved all of Monday as creative "wall time" to explore and coordinate design ideas during this "fuzzy front end" exploratory phase. Rebecca spends time rotating through all the groups, building a synergy of ideas. Digital snapshots of all the wall notes and UML-ish sketches are taken.
On Tuesday, January 10, teamwork starts at 9:30 with the Scrum meeting. New tasks and impediments are written on the adjacent whiteboard. Martin reminds the team of the vision and iteration goals. More tasks are volunteered for. As previously agreed, they will start programming this morning, even though many design points and coordination issues are fuzzy. Most of the developers decided they didn't want to try pair programming, so that XP practice was bypassed, although Martin encouraged pairing by anyone who wanted to try it. However, they all agree to the XP practices of test-driven development and continuous integration. The team is using an IDE with great refactoring tools, and Martin frequently encourages the team to not just cut code, but keep it clean and simple by regularly applying refactorings, another XP practice. The developers occasionally look at the wall sketches or printouts of the snapshots for some inspiration. Some developers head for the walls for 30 minutes to UML-sketch some design ideas, then back to their development stations.
As the day progresses, questions about the features and happy path scenario arise, and Domina and Itchy talk with the developers to clarify and decide the requirements. These two also work with the developer Girija to create acceptance tests an XP practice.
As developers complete their classes, they check them and their unit tests in to the version control server. Girija checks in completed acceptance tests. A separate build machine is running these tests within a continuous integration service 24/7, every 15 minutes. Thus, bugs and integration problems are quickly surfaced and resolved. Continuous integration is an XP practice.
Girija also volunteers to be daily tracker, another XP practice. So, each morning, she takes a few minutes to sit with each developer to learn the remaining estimate of effort on their tasks. She updates the Scrum Sprint Backlog spreadsheet with these estimates, and crosses out completed tasks on the whiteboard.
The first few days are rough and confusing. But, by being forced early to develop a very small amount of code and integrate it with the other developers coordination emerges and a small seed of the overall system starts to take shape and be integrated. Hour by hour, more unit and acceptance tests and production code are added to the build. Fast forward to mid-iteration, Wednesday January 18. The team meets in a sanity check to discuss if they can really meet their original goals by the end of the following Wednesday (in preparation for the Thursday morning demo), or if they need to scale back. Following the timeboxing practices of UP, XP and Scrum, they won't extend the deadline or work longer hours to meet the deadline, but may defer work until a future iteration. However, things have gone well and the Sprint Backlog shows the total remaining effort estimate is within budget. So, no changes.
Next week on Thursday morning, January 26, the BIG minister shows up for the end-of-iteration demo, a Scrum practice. The iris scan demo doesn't do very much, but it runs and doesn't crash. The minister has never seen an iterative project before and is impressed that three weeks into a new project, the team has some software to show. She's used to waiting six months. In addition to encouraging the team with future efforts, the minister shares this: I just attended a cabinet meeting where the Prime Minister enthused about a TV report she saw on automated face recognition in crowds, being used in Grepland. She wants it, as soon as possible! This is a matter of national pride; we FooBarKhans can't be outdone by the Greplanders! Thursday afternoon and Friday are reserved for a second requirements workshop and iteration 2 planning session. Multiple requirements workshops across early iterations is a UP practice. Since the team is applying the Evo, Scrum, and XP practice of adaptive planning, they had not previously decided what to do in iteration 2, although they had some likely ideas based on the iteration 1 planning session. Rather, they deferred the decision until this time, using their latest information to decide what would be most valuable. With the unexpected overhead and novelty of buying, learning, and integrating a third-party face recognition system, the team decides the next iteration needs more slack and should be four weeks rather than three. The team is very clear what should happen at the iteration 2 demo.
|
EAN: N/A
Pages: 156