the least valuable activities in Scrum. However, if you do them properly, retrospectives could be the only activity you really need. Come find out why in this interactive session about how we can truly learn from our experiences and take real action. We will explore several variations of retrospective techniques for inspecting a team’s process, product, teamwork, and technical practices. Participants will leave with a set of tools they can put to use in their very next retrospective.
SVP, Microsoft Technology Practice former Microsoft MVP for C# creator of the AgileDotNet conference @tmgirvin http://www.linkedin.com/in/tmgirvin http://tmgirvin.com
experience • Cofounder, Jef Newsom, was my Scrum Mentor & first Scrum Master • Started Improving to bring agile methods to IT • Consultant and mentor to agile teams • Worked with teams of all sizes and growth phases
went with regards to people, relationships, process, and tools. Example Questions: • Did we meet the Sprint goal? • Was the PO engaged in the Sprint and Demo? • How do you feel about the Sprint? • What did we learn in this Sprint?
Mnp: Having the online tool (onTime) tool to have a limited list of work items to select from • LS: likes ability to see documented tasks visible and assigned so we know what everyone is working on. Can share product knowledge, but also communicate with others on priority • Sbab. Liked the transparency and how much effort remaining on each story/issue. • Sb: online tool helped offsite developers plug in. Also they have advanced in their product knowledge to create their own test files. Like the burndown chart. • Jacob: online tool really helped. • Cathy (production implementation/development); was very helpful now seeing what is going on in development. How my items as field rep is prioritized. • Davito: likes daily scrums driven by Jacob. Likes “minute 16” concept which takes items offline. Likes online. • Marcelo: likes scrums and ontime software. • Chris: like tool • Ned: liked ontime better than past products.
we conducted Sprint 2? • Team Commitment • Jacob: done is done seems like too much of a stretch. Plan to review later. (1) • Chris: feel like we did not make the committed release as part of our initial commitment to the stakeholders. (2) • Ned: lack of time to fully code and test stories at end of same sprint, particularly with ACA product. Release specific stories in particular. • Mnp: Task list grew during sprint adding sub-‐items on the fly during the sprint based on private demos to PO group. • Jacob: trying to administrate OnTime tool. Users adding stories/issues during the week for assumed behavior that is not a part of a story, e.g. 2013 license authorizing 2014 version! How should we address in scrum meetings. Bring up and throw on the backlog. Have team discussion to review. (1) • Jacob: would like to know better what stories are demonstrable and will need to be reviewed at sprint review. Locking down builds so we know what product we are even GOING to demo from. Too many moving targets for what is expected. (3) • Sbabin: Acting on PO behalf caused him to take some of the heat for working on things not necessarily agreed in sprint planning. • Self-‐Organizing • Ned: got assigned or assumptions were made that I would pull tickets for work that would be done by me. (1) • Tooling and Automation • Mnp: would like combined backlog (one list) with both Stories and Issues on combined list. (2) • LS: would like to not have tiny tasks have to be written if they are minor changes. (1) • Davito: need build number for each of the two components in the combined product. • Marcelo: would like a way to log into OnTime that he has coded the unit testing and they have passed. A single story with multiple acceptance criteria might require multiple • Multiple Roles and Responsibilities • Wearing too many hats (9)
many hats (9) Responsibilities to multiple roles. • Define how much time is available for the role. • Share with management the conflicting responsibilities and cost to the team. • Hire outside help, more resources. 2. Different developers have specialty areas, TSL only or Revit only expertise and no crossover. So we add tasks for multiple products in the sprint. Multiple products in single sprint. (5) • Pairing up to share tasks. • Create build process that anyone can trigger so anyone can dev/test. 3. Need others to step up for certain jobs. Domain knowledge challenge. (4) Learning new domains (not roles). • Expect team members to test others’ code. • Expect team members to write documentation or others’ features. • “Lunch and Learns” to share knowledge across the team. 4. Would like to know better what stories are demonstrable and will need to be reviewed at sprint review. Locking down builds so we know what product we are even GOING to demo from. Too many moving targets for what is expected. (3) • Work on highest priorities first – as a team. • Plan the demo early. Get priorities from PO(s). • Setup shared VMs? 5. Feel like we did not make the committed release as part of our initial commitment to the stakeholders. (2) • Make better estimates. • Need finalized sprint plan exiting the planning meeting. • Better communication across the team adding significant tasks.
Sprint • Especially SM • Team member can, or send notes to SM • Look for signs of dysfunction in burn-‐down, story board • Ask: “What can we do to be more productive?” • Come prepared for the Retro: process artifacts, pictures/screen shots, questions, observations
Your Podcast. Everywhere. Effortlessly.
improving
signer
magnolia
sciencetokyo
otsuki
juanmartin2026
kaityo256
mfcabrera
laurawilsonbseo1
yasslab
masakiokuda
.png){kind=avatar}
codeforeveryone
inesmontani
zakiyama
tamaranovitovic
michaelherold
eileencodes
frankvandijk
brad_frost
honzajavorek
asonas
cassininazir
michielstock
greggifford
![Speaker: Todd Girvin [email protected] Cofounder, Improving Enterprises](https://files.speakerdeck.com/presentations/ae21cac0eb35013088d56eba71b23d61/slide_2.jpg){kind=link}
