Open Space Notes: Building Ownership, Accountability and Urgency in a Scrum Team

Topic

Building Ownership, Accountability and Urgency in a Scrum Team

Discussion

  • Incentives, treats, misc. - Several discussed how they use anything from food/drinks/misc to other various gifts to help motivate team
  • Positive focus – Mention of making sure that during hard or stressful sprint retrospectives to make sure you ask the question “What as a team CAN we be proud of from this sprint or project”
  • Outside feedback – Discussion of sharing customer-level feedback with team directly. Team is often sheltered from a lot of this feedback and it makes a lot of sense to start to pull them closer to the clients and let them hear the direct feedback.
  • Break redundancy! In any way you can. Couple 'fun' ways mentioned were anything from throwing a football around to shooting nerf darts. Anything to break the redundancy and pull away from the stresses. 
  • Balance – make sure tasks are staying balanced. Hard to do for teams that are pre-allocating tasks in the beginning of the sprint, but make sure that the star developer isn't taking ownership or being given all of the larger more complex tasks. Recommendation of assigning tasks during daily stand-up to prevent overload or bad balance.
  • Protect from failure – watch all of the daily road-blocks. ScrumMasters or product owners have to remove these. A team can't be led to fail because of roadblocks out of their control. The more they feel they are in control of the development results, the more they will own it and feel responsible for it.
  • Focus groups and client involvement – get clients involved with initial planning (not necessarily the actual planning meeting) but for the retrospective demo they can play a great role in providing feedback.
  • Product owners MUST stay involved in the day-to-day to be available for questions and maintaining the backlog. Sort of understood, but we re-emphasized the importance during our discussions.
  • Code sharing during sprint – not necessarily true code review, but at least basic peer review.
  • Assigning vs. Volunteering – HUGE difference and make sure your team members are all volunteering for tasks NOT BEING ASSIGNED THE TASK – it is up to them to pick whatever task off the board they want to take regardless of effort or skill required. If they pick something out of their league it will encourage pairing up to complete the task which produces both cross-training and confidence in the team!
  • For those teams having trouble getting to the team mentality vs. cowboy coders, one group member recommended silence until it hurts. :) Force them to make the next move and not look to management to 'make' the next decision. Let them throw out ideas and decide as a team. It is critical they have the ownership to make and commit to their own decisions and are ALLOWED to do so as a team rather than dictating what each person needs to do. Encourage team meetings to let THEM hash it out and come to a team decision. Do not attend as a business manager or even sometimes as a scrum master unless it gets to a point where the team feels this is needed.
  • Off-topic – but an interesting one. How to handle individual performance goals in a corporate environment?? - Some suggestions were allowing the team themselves to vote on percentage at the individual level and come to an agreed percentage for each member. This has resulted in some mixed results (i.e. each quarter resulting in the next in line getting larger percentage or evenly spread), but there is potential to make this work. Another suggestion would be to let them silently participate in allocating percentages for performance ratings to each team member which would be applied somehow to the individual performance goals.
  • Burn-down only, do not track hours at the task level! Look at remaining hours only left in the story tasks to calculate/present the burndown chart.

Tags:

Visibility: Everyone