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.
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.
Interactive Planning Status
to 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 meetings
Meant 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.
via 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 change
Planning & Sharing
Story 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 board
we 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.
- What do you think about the goals and process generally?
- Should communication be open to all? Pig and chicken idea from Scrum.
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:
- make funny faces
- take notes loudly
- communicate in any way
- How long should iterations be?
- How do we deal with "unknown" time commitments which is the reality of community source?
- How do we create the status board in digitally so we can share across our distributed world?
- How do we do planning distributed? My experience has been to place index cards in a plan/calendar and manually move them around as we talk about trade-offs, etc.
Resources About Agile UI Design