Wednesday, October 5, 2011

Daily meeting blues? How about shaking it up?

Whether you've just started agile with your teams or you've been doing it for a while, at some point people may question the value of the Daily Stand up, Daily Scrum or Daily meeting.  People start missing the meetings, arriving late, taking calls, the meetings go over the 15 minutes or start sounding more like a status report instead of the format that Scrum advised us to use.  Jason Yip blogged in August about how to reevaluate the format, watch for patterns and offers some techniques on how to improve them.  There are some great tips here if you want to keep the same format.

This has been the standing Daily Stand up format:
  1.     What did I accomplish yesterday?
  2.     What will I do today?
  3.     What obstacles are impeding my progress?
If the meeting isn't working for the team anymore, it should come up in the retrospective.  But, if it doesn't, the scrum master should probe into this directly to get the team to find out WHY it's not working.  Before revamping meetings or canceling them, always always always find out why first.  There may be a totally different reason than you know and asking the team may be a revelation to you and to the team on how to fix it.

If you've ruled out basic things like attendees, room location, tangents and the format just doesn't work for your team. I'm here to suggest a small simple change.

As each person speaks, they state only the following:
"Today my plan is to _______."  and if needed followed by "and I will need ____ today to do it."

This captures their responsibility both for the work they will own today and help they need today.  It's a simple change but as their Scrum Master, you should listen for ambiguity, overlapping work or people without clear direction so that you can follow up with them to offer help and/or their manager with feedback.


Friday, August 19, 2011

Timeboxing the Sprint Review, Retro and Planning in a Single Day

Prep work for the Project Manager, Scrum Master or the like:
  1. Break the meeting scheduled in calendar to explicitly time box the Sprint close from the Retro (maybe two separate meetings in calendar)
  2. Have a set agenda posted along with detailed descriptions as noted below (Customize as you like as a team) for the Sprint Close out and Retro sessions as a reminder of the flow of the meeting.  Posters or even a wiki page with the info is good.
  3. Move any retrospective item that you accomplished in the last sprint from the improvements/retro poster to a “completed improvements” poster so you can reference things you did and agreed to do over time.  
Sample agendas for the last day of the sprint:
  • Team Prep Night before Sprint Close out
    • Remind the team to close out any task(s) that they completed in advance so that all you have to do during the Review meeting is do the QUICK CLOSE on any stories with zero remaining hours at the story level. This will set status to Done and zero out the remaining hours of the task in one click
    • Confirm any unfinished tasks/tests that are not done, update the remaining hours, make the task estimate the same number as the new remaining hours number (this helps with capacity planning for the next sprint)
  • 930-10am Sprint Review and Close out
    • Confirm which story and defect is complete (QUICK CLOSE the story)
    • SPLIT any partially completed story to move the unfinished tasks/tests to the next sprint and then
    • CLOSE SPRINT
    • After everything is done (sprint closed and new sprint activated), this is when you can move into the RETRO section to talk through why the team is completing more or less story points each sprint.  If an idea comes up during this discussion, this is a perfect time to slide into the Retro portion of the day
  • 10am-11am Sprint Retrospective
    • Review the VELOCITY TREND report on the  Sprint Planning/Sprint Scheduling section and discuss what the team is doing that is causing the trending to be what it is. Are there some improvements they could be making to improve it? Are there some things that the team is doing that is making a positive difference to the trending?
    • Look at the Retro poster (or wiki) to see what improvements the team has talked about in the past. Are there new ideas to add? Has the team completed some of the items already? CELEBRATE them!
    • Vote on which item(s) the team would like to tackle in the next sprint. Maybe there is more than one that can be accomplished?
    • Add a story card to your sprint backlog for each item the team agrees they want to add and assign the owner(s) that will be responsible for doing the work it will take to make the improvement and/or providing updates on it throughout the sprint as requested.
11-Noon Product Owner/Scrum Master Prep Session
    • Add new stories to the sprint backlog that should be considered in sprint planning
    • Remove stories that should be moved out of the sprint
    • Review any blocks, issues or impediments to resolve them or pull stories out of the sprint if they are not resolved yet
    • Prioritize the sprint backlog (will review again with team at the sprint planning session)
    • If time permits, plan out the stories a few sprints ahead as a “request” to the delivery team and to assist with forecasting/scheduling
•    1-4:30pm Sprint Planning (entire team include Product Owner)
  • 1-1:45pm – Story walk through and Estimation
    • Product Owner walks team through the stories they would like to consider for the sprint, should include the story description, user acceptance criteria and stop to add more detail or to explain any new stories that need additional information so that the team will be able to size/estimate the story
    • Team members “sign up” for stories they would like to work on (add themselves to the OWNER field on each story)
    • Team sizes each story after all have been reviewed based on relative sizing technique (“smaller than this, bigger than that”)
  • 1:45p-3:45pm – Story Detailed Planning
    • This time is informal and time to self-organize!
    • People tend to group together as needed by story to detailed out the tasks that each person will be doing on each story, entering the tasks/tests as they discuss and then estimating the hours for their work
    • Each team member should look at the Sprint Planning/Member Planning page to see who is over allocated based on their assigned work against their offered capacity.  Talk to other team members to help them out by discussing how to spread the work more evenly across the team.
  • 3:45p-4:30p – Sprint Plan Commitment and Kickoff
    • Review the Sprint Planning/Member Planning to ensure no one is over allocated
    • Review the total story points planned for the sprint – Is it higher than the trending velocity? It’s ok to go a little higher if work was partially finished in the last few sprints but the completed story points were low because of splitting.  Just remember to keep your new sprint somewhere between what you did and what you planned last time so you have a better chance of doing it! 
    • Do a fist of five vote on the final sprint plan and you are ready to kick off the sprint!

Fist of Five Voting for Team Consensus


Fist to Five is quality voting. It has the elements of consensus built in and can
prepare groups to transition into consensus if they wish. Most people are accustomed to the
simplicity of "yes" and "no" voting rather than the complex and more community-oriented
consensus method of decision making.  This moves a group away from quantity voting to quality voting, which is considerably more informative. Fist to Five can also be used during consensus decision making as a way to check the “sense of the group,” or to check the quality of the consensus.

First, a member of the group presents the details of the proposal. This individual will then answer "clarifying questions" until all such questions have been asked and answered.  If appropriate and helpful, the group may then open the floor for discussion or break into small
groups for discussion. (If small groups are used, when the large group is reconvened, time should be allowed for any clarifying questions or comments members would like to include before voting.)

The Initial Vote
Once the proposal presentation is completed, the facilitator will direct each team member to vote by holding up 0 - 5 fingers.
  • Fist: No support--will work to block proposal. "I need to talk more about the proposal and require changes for me to be comfortable with it."
  • 1 Finger: No support, but won't block  "I still have strong reservations and want to discuss certain issues and suggest changes that should be made, but I agree not to block the proposal if approved as is."
  • 2 Fingers: Minimal support"I am moderately comfortable with the proposal as is, but would like to discuss some minor issues."
  • 3 Fingers: Neutral  "I'm not in total agreement but feel comfortable to let this decision or proposal pass without further discussion."
  • 4 Fingers: Solid support "I think it's a good idea/decision and will openly support it.
  • 5 Fingers: Strong support "It's a great idea, and I will do all I can to promote it."
If there is not a full consensus, ask the individuals that voted differently than the majority to state their concerns to the entire group including what it would take to get them to vote with the majority. After each individual has shared, the floor will be opened for clarifying questions, comments,  and discussion. The facilitator may choose to set time limits.

Once each minority voters has stated their case, another Fist-to-Five vote is held for the final version of the proposal.

Thursday, July 28, 2011

If Scrum "isn't working" could we try Kanban?

If your team is currently struggling in their Scrum practice, you may be ready to give up or try something else.  Kanban is becoming quite popular and I'm recently a Kanban convert so I can understand the allure especially having seen it work so fantastically for teams.  However, as a coach, it's my responsibility to find out the root cause of the team's problems with Scrum first.  Sometimes it's a simple change that can get them back on track and well worth the cost savings of another training expense.

Here are some questions to ask when scrum "isn't working":
  • Are the timeboxes too short? or too long?
  • Is the backlog volatile? (many priority changes during a sprint or changes in stories planned)
  • Are there impediments consistently through every sprint that delay the work of the team that are either not resolved or outside the team's control?
  • Is team size larger than 9 people?
  • Is planning and forecasting of work being done and communicating?
  • How are the team's stakeholders reacting to the scrum practices?
  • Is management supportive of the scrum team and their practice?
There aren't right or wrong answers to the questions above, but they do give a good picture of where the pain points are with the team and their stakeholders so that you can take the next step which is to begin trying new techniques or refreshing old ones to get the team back on track.

So when do I recommend Kanban for a team?  It depends. Don't you love that answer?!  It happens to be very true regardless of how flippant it may sound.  These are the cases where I've seen Kanban "fit" better for a few teams I've coached.

  1. Team A had been practicing scrum for years and very poorly.  They had varied sprint lenghts, team members that would be borrowed by another team for an entire sprint, non-existent Product Owner and never did estimation or forecasting for future sprints.  There was such a bad taste in everyone's mouth for scrum that we decided it would be best to just try something new with less prescription and more adaptivity and a newfound energy to make it work with a strong agile coach.
  2. Team B had never done anything but Waterfall or organized chaos working with different team.  They were an operations team that had several stakeholders across the company so their manager was essentially operating as a pseudo-Product Owner/Intake manager.  Kanban was chosen since the work they received was a steady flow of changes deployed as soon as they were completed.  Kanban works really well for maintenance and operations project teams since the work is relatively small and steady for those teams. 
  3. Team C had been practicing scrum for over a year and they consistently met only 50-65% of their sprint commitments.  After repeatedly trying to get the team to accept less into their sprint plan (4 week sprints), reduce their sprint length to 2 weeks and getting their team members cross trained, I decided to show them how to implement Kanban flow and WIP Limits into their sprints; the ScrumBan approach.  We created more "states" on their sprint board from "Not Started, In Progress, Done" to "Ready Queue, Dev In progress, Dev Done, Test In Progress, Test Done, Demo and Done".  Then we updated the WIP limit for each state. These two small changes would allow them to see how work progress through each stage, limited how much they could do and also raised awareness across the team where work was not moving.
Some important things to remember with Kanban is to be diligent about keeping the ready queue current and populated for the team so they can keep moving through the backlog, and honoring the WIP limits and adjusting them as needed when you first start out so you can find that sweet spot.  Equally important is metrics.  Too many teams forget about this or use it just as a status report but don't take the time or know how to really analyze the metrics so they can explain the cycle time for outliers, make improvements or adjustments on the WIP to smooth out the flow and reduce the bottlenecks and watch the CFD (Cumulative Flow Diagram) to see trends so they can highlight success areas and recreate those situations to have more in the future.

Monday, July 25, 2011

Kanban Q & A with VersionOne references

With so many teams attempting to try out Kanban for the first time, I receive tons of questions.Here are a few of the questions I've received and the answers I gave at the time.  Keep in mind that as my knowledge of Kanban grows and changes, so do my answers so keep in mind these were from earlier this summer.


QUESTION:

1) what Story Points scale have you found useful with your teams?
  • we are considering using 1,2,3,5,8 with "8" representing the largest size of work (basically high unknowns, probably "XL") but wondering if this provides a broad enough range of buckets
  • also interested to know if teams have found that stories larger than perhaps the first 3 buckets, need to be decomposed further before going onto the board
ANSWER:
The numbers a team uses for story points doesn't really matter since they mean something unique to each team and should not be compared across teams. Just pick a set the team agrees to represent sizes relative to other stories. A "5" for one team does not mean the same story for another team should be a "5" and the choice of the numbering should be made by the team not management.

As teams estimates become more stable, they will see more clustering of cycle time metrics. This is true whether they are done by hand or through VersionOne. Teams should just annotate their metrics where significant changes are observed in the metrics to offer explanation and give themselves a documented memory of changes they made and the impact those changes made to their flow of work through metrics. 

We discussed a few of these scenarios at the last Agile Project Leads meeting and we'll be doing another session on it again at the next one. 
Oh and we NEVER change estimates for completed work. It's considered "waste", in agile, since we consider those instances where we estimated incorrectly a learning opportunity and a case where annotating our metrics will show WHEN we began changing the way we estimate and what impact it made to our flow, and by annotating changes we can see how long we tried something before we made another change. This can be especially helpful when teams realize they aren't making progress because they didn't give the "change" enough time to work before trying something else. Making changes too often, too frequent or just too many can be disruptive enough to keep flow from stabilizing which prevents the team from becoming predictable. 
QUESTION: 
  • If these stories are left open until next week what does that do to our burn down and other metric reporting in Version One?
  • Should we move the stories to the next sprint or put that them back on the back log?
  • Can a team continue to work on stories and tasks after a sprint is closed during the grooming week? 
ANSWER:
  • Move all stories that will not be completed by Friday/tomorrow to the next sprint
  • Close the current sprint tomorrow – this will also track the REAL velocity of what was actually completed from the original committed plan
  • Then next week while most of the team should be scheduled for quarterly grooming sessions all week, others not involved may get a jump start on the next sprint's stories.Remember that on Monday the 11th when the team does Sprint Planning, they will need to RESIZE the stories that were not completed this week and moved to Sprint 3.1 so that the size represents the size of the remaining work only.  This will also give a better picture of velocity at the end of sprint 3.1.

Friday, June 10, 2011

What does an Agile Team look like?

Thanks to some friends and colleagues at Rally for sharing this from Liz Keogh's work.


This is a great tool to use when trying to assess where a team is in their agile adoption.  It be used as a guide for periodic retrospectives and even goal setting for teams looking to move to the next level as they grow as a team.
 
Novice
  • We have a board
  • We put our stories on the board
  • Every two weeks, we get together and celebrate what we've done
  • Sometimes we talk to the stakeholders about it
  • We think we might miss our deadline and have told our PM
  • Agile is really hard to do well
Beginner
  • We are trying to deliver working software
  • We hold retrospectives to talk about what made us unhappy
  • When something doesn't work, we ask our coach what to do about it
  • Our coach gives us good ideas
  • We have delegated someone to deal with our offshore communications
  • We have a great BA who talks to the stakeholders a lot
  • We know we're going to miss our deadline; our PM is on it
  • Agile requires a great deal of discipline
Practitioner
  • We know that our software will work in production
  • Every two weeks, we show our working software to the stakeholders
  • We talk to the stakeholders about the next set of stories they wants us to do
  • We have established a realistic deadline and are happy that we'll make it
  • We have some good ideas of our own
  • We deal with blockers promptly
  • We write unit tests
  • We write acceptance tests
  • We hold retrospectives to work out what stopped us delivering software
  • We always know what 'done' looks like before we start work
  • We love our offshore team members; we know who they are and what they look like and talk to them every day
  • Our stakeholders are really interested in the work we're doing
  • We always have tests before we start work, even if they're manual
  • We've captured knowledge about how to deploy our code to production
  • Agile is a lot of fun 
  • Knowledgeable
  • We are going to come well within our deadline
  • Sometimes we invite our CEO to our show-and-tell, so he can see what Agile looks like done well
  • People applaud at the end of the show-and-tell; everyone is very happy
  • That screen shows the offshore team working; we can talk to them any time; they can see us too
  • We hold retrospectives to celebrate what we learnt
  • We challenge our coach and change our practices to help us deliver better
  • We run the tests before we start work - even the manual tests, to see what's broken and know what will be different when we're done
  • Agile is applicable to more than just software delivery 
 Expert
  • We go to conferences and talk about our fantastic Agile experiences
  • We are helping other teams go Agile
  • Business outside of IT are really interested in what we're doing
  • We regularly revisit our practices, and look at other teams to see what they're doing
  • The company is innovative and fun
  • The company are happy to try things out and get quick feedback
  • We never have to work late or weekends
  • We deploy to production every two weeks
  • Agile is really easy when you do it well!