Host: Mike Lonergan
2016-02-05, 11am
Friday, February 19, 2016
Tuesday, February 9, 2016
The Agile Fluency Project: Putting the Agile Fluency (TM) Model into practice
Session from Wednesday
Fwd: Offsites & Retreats
Host: Jeremy Lightsmith
Date: Thursday 10a
Date: Thursday 10a
--
----
Jeremy Lightsmith
Helping software organizations through change
312-953-1193
http://jeremylightsmith.com/
http://facilitationpatterns.org/
http://www.linkedin.com/in/jeremylightsmith
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:
- 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.
-
Thanks and regards,
Patrick
Patrick Lamasney
Agile Coach – The Lodging Service
Expedia, Inc
plamasney@expedia.com
www.expedia.com
Saturday, February 6, 2016
Friday, February 5, 2016
#NoEstimates Mini Workshop
Host: Woody Zuill
Time: Fri 11:10 - 12-10
Notes. Good luck with this:
Sent from Yahoo Mail for iPhone
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
"Value"
Increase revenue
Decrease cost
Bugs
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
Aki Namioka
Here are the types if tunes played.
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
mtardiff@SolutionsIQ.com
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
http://bit.ly/one-tenth-time
and read the Vin d'Amico post that started it all. It's all there.
Pics, to prove it happened:
Subscribe to:
Posts (Atom)