(Here is us packed like sardines on a Mazda. You can see a bit of my shoulder here)
Key note from Jim Benson rocked! I have to admit, one of the main reasons I went there was because Jim Benson was there :) I didn't expect him to be that tall!!And he IS like a puppet :))) He said a lot during the key note but here what I took away :
- Rules kill awesome
- Optimize don't standardize
- Be nice
- DONE means it never comes back!
- Metrics are temporary convenience to prove a point
- Subjective well being of people is a metric
- For any bad feedback, write to David :)))
The first session I took was Matt Barcomb and Diane Zajac-Woodie. Really enjoyed it! I think Matt is a supernova, so keep an eye on him (I mean follow him on twitter @mattbarcomb or something, not literally look at him). Some of the key takeaways:
- Fund capacity from past spending. 95% of the spending can be predictable if teams are stable
- Lines of Value (instead of Line of Business). They are multi-role groups and need to have a form of team identity
- You might get an IT guy on the line of value (Devops idea)
- MVPs are not just code written that does nothing. They are like Zombies! They move and function, not very well but they do! :)
- To decide which option to chose for the next project/product, line up ~4 key factors that are important for a choice. Put some weight into each. Then give a weight to each option per each key factor, do some math and you will get the option that scores the highest based on the key factors. The funny thing is that the option that will float on top, might not be at all what we want to do, so we might decide to go with the second option anyway.
- To size stories, line them up on a long line as per their relative size. Then divide them in groups. 7 is a lot of groups. 3 are usually where to start, but when you mature, you can move to Big and Little groups.
Then I did an hop'n pop between Bill Wagne session's and Carol Treat Morton and Renee Pinter.
From Bill Wagne:
- They decided to track these key metrics: Total cards, Current velocity, Average card siz. Start calculation on first iteration
- After 2-3 iterations they found : nr of cards X average card size is what was delivered by almost every team. Outliers are the 40/ and up
- Key questions to ask: When will we finish? What is the cost?
- Start see the nr of new cards added per iteration
- Get product owners to look at the new additions, the trend and the effect. Start the conversation based on those
- Let Business Owners own the goals: Keep budget or Keep Features?
Here is a picture of the exercise from their session
To understand this image, we first created a whole bunch of personas. Each card had a picture and some details about that person. Then, some of us pretended they were the client and decided to categorize which of these personas is the most important client to them. For us was Randy. From now on, every decision about the product is based on Randy's liking. If CEO comes and asks for changes, you tell them: Well, you might like purple font, but Randy doesn't!! It is a tool to keep focus and have everyone focused on the right outcome.
And then was Cheezy (Jeff Morgan is how the city of Cleveland taxes him and his boat). I have to say was the most animated session. He got 4 people (product owner, developer, tester and designer) all dressed up in fake hair, hats, glasses, boas and they got to play a bit of theater. They were boiling under all those accessories but you could tell they loved it!
- Product owner is there to take the team to the highest possible value delivered AND decide what NOT to do!
- Team is there to deliver what Product owner asked, continue improving (Kaizen) and make sure the code is clean
- What do we do when we find a defect? We put it on a big defect system? NOOOO! We FIX it!
- Put the weight of the Earned Business Value on the card and we see how much value we add when we deliver same amount of points on the same time
- Experiment: Business analyst to report to Product owner. Product owner stays with team and answers questions and works on the backlog. Analysts go to meetings and bring info
- Specifications in Gherkin help with testing
- Developer comes on Validation stage, after Testing is written. What we Validate is not the code that developer wrote but the test cases that tester and PO wrote!
The last session I could attend was Jean Tabaka. Loved it! She talked about the Mad World we live in (we actually heard the song), about the chaos we work at and Cynefin.
Two things I got from her:
- Are you a chef or a receipt follower?
- Abductive logic
Update: a picture of Jason with a LeanDog hat!