Tuesday, February 9, 2016
Monday, February 8, 2016
- Print out the score card template – one for each person on the scrum team (the delivery team + the Product Owner + engineering management).
- Have them read through the list of 20 characteristics. For each characteristic, establish how you feel that the team is doing and vote (with a check or an X) either green, yellow or red. I provide information on what green looks like and what red looks like. I tell them that if they feel the team lies somewhere in between, to mark yellow.
- Then they turn in the papers and I tally the results. I count the number of responses for each characteristic color so that I have totals in each color in each row – even if it's zero.
- Then I analyze the data in two ways:
- I choose the "winner" for each characteristic. For most it's pretty straightforward – one of the numbers in either green, yellow or red will be the clear "winner." However, sometimes you end up with numbers like this: 4 green responses, 4 yellow responses, and 1 red response. Subjectively, I choose yellow as the winner. Then, for each color-column, I count the number of times that color 'won' and write that number in the appropriate totals box at the bottom of the 2nd page. I then take the number of green winners and multiply that number by 2; I take the number of yellow winners and multiply that number by –1; I take the number of red winners and multiply that number by –2. Then I add those three numbers together and put the sum in the Score box at the very bottom. That score will fall somewhere in the scale to the left of the Score box – and the team then has a color that represents their overall health.
- Additionally, I take the data from step 3 above, and populate the attached spreadsheet. Then the data can be graphed and shared with the team. The lowest bars on the graph become "Areas to Address."
- I work with the PM, EM and the PO to prioritize the Areas to Address, then follow the following steps:
- Circle back with the team and share all the data / results and determine the scope of each Area to Address
- Establish a commitment from the Delivery Team to address each area
- The team will need to speak to: what would the team look like, or how would the team function differently, if this particular area was working well?
- By answering this question themselves, the Delivery Team will determine their level of commitment.
- Create a plan, with specific and measurable milestones, to address the highest priority area
- This will vary based upon the specific area needing to be addressed.
- Areas like code ownership will have to be driven by Engineering management, but I can work with them on coming up with plans and milestones.
- Measure progress by having the team complete another score card every 3-4 months, consistently.
Saturday, February 6, 2016
Friday, February 5, 2016
YAGNI & Solve Tough Problems Early
Friday, February 5, 2016
Last responsible moment
YAGNI - You Ain't Gonna Need It
Consider emotional state of the team
Customer satisfaction (higher costs into call center)
Team satisfaction (higher turnover)
Decrease time to market
Be market driven not deal driven
Product owners could assign Fibonacci # to each story for business value
Created with Microsoft OneNote 2016.
Solve tough problems early.
[ ] Make critical decisions early.
[ ] Pressure to deliver something fast? Resist.
[ ] Time box experiments.
[ ] Appropriately prioritize.
[ ] Deliver economic value... Revenue up, cost down, time to market down.
[ ] These are market differentiators.
[ ] Prove it is valuable.
[ ] Make an architecture you can expand on. Pluggable. Build this facility early.
[ ] Do in now or do it later.
[ ] Evolving an architecture over time is a skill.
[ ] Use your creativity early.
[ ] What if the team is new to a technology? Learn it early.
[ ] Last responsible moment.
[ ] There is a business need to not paint yourself into a corner.
[ ] Focus brains on the right problem.
[ ] Trust that the team knows how to avoid painting themselves into a corner. Do we have the right 'brilliant' people on the team at the right time.
[ ] Option based approach.
[ ] Reduce risk because we don't know the future? Mitigate by what?
[ ] What is the hardest problem this person can solve? Everyone should be growing.
[ ] Incremental execution.
[ ] Prioritize the unknowns.
[ ] Value based prioritization.
[ ] Green - we know this can work. Yellow - we are currently proving it will work. Red - we need to prove it can work.
[ ] Put work into the backlog / sprints that gives us experience in design skills.
[ ] Take a user story, which reds are effecting this tech?
[ ] Choose user stories which force us to tackle the reds.
Michael J. Tardiff
@mjtSession host: Michael Tardiff
We had a reduced and condensed last-ever version that incorporated all the
learning that has resulted from two years of doing this workshop.
Well, workshop? It was 2 minutes and 35 seconds long. The first time. We did it again for folks who were late: two minutes. And once again, for more latecomers: 35 second. Used one-tenth the time (6 minutes, compared to session length at AONW2016 of 60 minutes) to do the session *three times*, for three groups.
Then, after the season was over, did it three more times when people stopped in the hall and asked: 17 seconds, and 2 minutes 15 seconds.
This is not to brag. This is just to say: we can do enough in less time if we aim for "The Simplest Thing That Could Possibly Work" instead of everything.
I have 11 pages of notes gained from doing this session for over three years. I have learned enough to make this a 90-minute session.
I haven't. The one-tenth of the time is enough. Sufficient. It works.
Missed the session? Go to
and read the Vin d'Amico post that started it all. It's all there.
Pics, to prove it happened: