Monday, February 8, 2016

Agile Score Card

After baselining my teams – making sure that they perform all the standard ceremonies and that they utilize all the standard artifacts – I was asked by my management, "Now that you've established that our teams are Agile, how well are they doing at being Agile?"

After sheepishly answering, "I don't know.  I don't have any way of measuring that.  Let me get back to you." I searched around online for a way to measure a team on their Agility.  I found a few methods that had elements that I liked, but nothing that I could just grab-and-go with.  So I created my own – borrowing heavily from the examples I found online.  The end result is what you see here.

What I do is:
  1. Print out the score card template – one for each person on the scrum team (the delivery team + the Product Owner + engineering management).
  2. 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.
  3. 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.
  4. Then I analyze the data in two ways:
    1. 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.
    2. 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."
  5. I work with the PM, EM and the PO to prioritize the Areas to Address, then follow the following steps:
    1. Circle back with the team and share all the data / results and determine the scope of each Area to Address
    2. Establish a commitment from the Delivery Team to address each area
      1. 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?
      2. By answering this question themselves, the Delivery Team will determine their level of commitment.
    3. Create a plan, with specific and measurable milestones, to address the highest priority area
      1. This will vary based upon the specific area needing to be addressed.
      2. 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.
    4. Measure progress by having the team complete another score card every 3-4 months, consistently.

Thanks and regards,

Patrick Lamasney

Agile Coach – The Lodging Service

Expedia, Inc




Friday, February 5, 2016

Irish Music and Dance!

Session Host: Aki Namioka

With a short video!

The video is here:

Agile Transformations: Are They Agile?

Host: Linda Fane
Friday, February 5, 2016, 10 am

#NoEstimates Mini Workshop

Subject: #NoEstimates Mini Workshop
Host: Woody Zuill 
Time: Fri 11:10 - 12-10

Notes. Good luck with this:
Inline imageInline image
Inline image

Sent from Yahoo Mail for iPhone

NoEstimates Q&A

Subject: #NoEstimates
Host: Woody Zuill 
Time: Fri 10-11

Notes. Good luck with this:

Inline imageInline image

You can agile anything, the agile house experiment

Thursday 1:00pm Requirements in an Agile World


Sent from my T-Mobile 4G LTE Device

Code Cooking

Reluctant/Resistant Stakeholders or Team Members

Host: Jay Vandewark
Friday, 11:10 AM

Lifehacks: tools to make your life easier

Sent from my iPhoneHosts: Sara Sell and David Bernstein
Friday at 11:10am

YAGNI & Solve Tough Problems Early



YAGNI & Solve Tough Problems Early

Friday, February 5, 2016

9:48 AM

Last responsible moment

YAGNI - You Ain't Gonna Need It


Consider emotional state of the team



Increase revenue

Decrease cost


Customer satisfaction (higher costs into call center)

Team satisfaction (higher turnover)

Decrease time to market

 Principles of product development flow



Be market driven not deal driven

Product owners could  assign Fibonacci # to each story for business value



Created with Microsoft OneNote 2016.

Social Models for the Agile Organisation

Additional material:

"Why Agile Companies are filled with incompetent employees"

Succesful Social Models for the Agile Organization

NAME: Succesful Social Models for the Agile Organization
Date:    5th feb
Time:    10am

Irish Music Session

Time/Date 10:00 am - 11:00 am, Feb 5th.

Aki Namioka

Here are the types if tunes played.

Agile Family sessions

Agile Family - Friday @ 10

Solve tough problems early.

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.

Getting Things Done In One-Tenth the Time

Michael J. Tardiff
Seattle US
@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: