Excerpt |
---|
Agile development is a software design and development methodology that advocates having many, short iterations throughout the life-cycle of the project. Fluid's agile planning process uses 2-week iterations, where all the work is planned at the beginning of the iteration. At the end of the iteration, how much work was actually completed is compared to what was planned (velocity), and this information helps determine how much work to plan for the next iteration. |
GoalsTransparent status both within the design team and across the community Encourage & enable frequent conversation about status of work, priority, roadblocks, what we are learning, what has changed, etc. Reflect on what we know & priorities through the "planning game" that kicks off each iteration Focus during iterations new requests, needs, changes, etc. become part of the next iterations "planning game" to allow us to stay out of reactionary mode Make mistakes faster we learn from mistakes so the sooner we know about them the sooner we can build our depth of knowledge and correct where needed Create a comfortable place to share ideas no idea is a bad one; we want people to feel comfortable sharing design ideas with early and often and know they can expect to get the right level of feedback. The PlanCommunicationInteractive Planning Statusto kick off each iteration, the team gets together to: - write and estimate new design tasks
- re-estimate tasks not completed in previous iteration
- prioritize tasks for current iteration
- assign tasks to designers
Design team stand-up meetingsMeant to be short & simple meeting. This meeting happens everyday (or at consistent intervals) at the same time. In a shared environment, everyone stands to remind people the meeting is short we can decide if this makes sense for us. Each participant has a chance to answer to 3 questions as we go around the room. The questions are: - What have you done since the last stand-up?
- What do you plan to do before the next stand-up?
- What impediments are in your way?
Any other questions are typically handled outside the stand-up in follow-up conversations as-needed. Open communicationvia phone, IM, breeze, email between team members Show and Tell Presentations- at the end of an iteration, team members have an opportunity to share current work with the rest of the team to get feedback, share status, etc.
- design work will be presented to the community - how often or is this loose? over confluence & email?
Stability in the midst of changePlanning & SharingStory cards drive our work and are the plan- tasks are represented on story cards (need to figure out how to do this digitally) and assigned to a high level project.
- each story card gets a time estimate by the team. Estimates can be no longer than an iteration. If they are, they should be broken down into smaller chunks of work.
- during the planning game, story cards can easily be moved around in order to play "what if" games and talk about trade-offs. So, if a new story card needs to come into the iteration than something that was already planned must go. This forms the plan for the iteration and beyond.
- story cards are assigned to a designer or a set of designers whatever is appropriate based on the amount of Fluid design time they have for an iteration. If a designer is working 100% on Fluid, 80% of their time could be assigned to story cards for instance (that 20% is for administrivia, email, and fires that just can't wait).
- the current iteration's plan is pretty set in stone, the next iteration is pretty well understood except for surprises that come up during the prior iteration. As we move out into time, the plan is less and less concrete yet there is still a plan.
The status boardwe will maintain a "status board" to demonstrate work progress to ourselves and the community. The board includes: - Tasks assigned for the iteration
- Who is assigned the task
- What tasks have been started
- What tasks have been completed
- What tasks are blocked
How do we do this in the digital world? My experience has been with index cards hanging on the wall and colored dots to show status. Additionalfrom http://www.implementingscrum.com/cartoons/implementingscrum-20060911.html  A Pig is someone who has skin in the game. Mike Cohn aptly refers to the people in that role as, "Having their Bacon on the line." Pig roles are considered core team members. Performers. People who "do" work. A Chicken is someone who has something to gain by the Pigs performing, but in the end, really do not contribute day to day to "getting things done." Their "eggs" are a renewable resource, and many get laid.
- At the daily stand-up, only pigs can talk. Chickens can come to the meeting to observe and learn, but they cannot:
- talk
- make funny faces
- whisper
- take notes loudly
- communicate in any way
Resources About Agile UI Design |