Last November, I was partially working on a "crazy" project. I say crazy because:
1- The initial scope of that project was presented as "Take this Excel spreadsheet and make it a web form.By the way, there are some macros"
2- 2 weeks in the project we found that the scope was much bigger. "By the way, we want to make some enhancements!". There was no Solution Designer looking into it, just developers. Nobody was doing anything to change the delivery date
While Business Analysts were trying to figure out what had to be done and trying to solve a lot of questions, Developers started coding. A lot of developers were contractors and we were paying them by hour. There was the need to keep them busy to justify their time. No matter what they were doing.
I asked the team to agree for a 3 days "developer hiatus" while Analyst could catch up with the requirements. My point was that developers were making technical and architectural decisions in a time when we didn't even know what was being asked. In the same time, we wanted to introduce Git as a new tool so, I thought, would be a good usage of the 3 days for developers to move the code to Git, set it up properly, get familiar with it and then pick up with what Analysts would have found.
It was a big NO from the Dev lead. Under the pressure to use the contractor's time on writing code for the project, he just couldn't accept the fact that developers would stop writing code. "They are developers, they write code, they don't wait for requirements. This is against being Agile!". Despite my argument that the decisions they were making now would create problems if the requirements would be asking for different technical decisions, despite the fact that Analysts asked for 3 days to catch up with where developers where, the "3 days hiatus" didn't go very far. What I was proposing (some sort of TDD) was never done before, was just unacceptable!
Fast forward, end of March, after pushing the deadline 2 times, having a lot of people joining that team and then moving on to other projects after a while, I was talking just the other day with one of the Analysts that has been on this project from the start. Here what she said:
-OMG Ardita, that 3 days that you asked for developers to stop, we should have asked for 1 week!! You have no idea how much trouble we have been going through. The requirements were not anymore what client was asking for, but what developers had already done. We were being pushed back and forth between client and developers to figure out how to get the maximum of what client was looking for on a feature that developers had already closed. They were so worried to spend some contractor hours, but they spent so much of our hours that were wasted in this ping-pong. We should not aim to be faster anymore, we should aim to be smarter on how we do things!
I thought my job was done!!
Yes, true, I did not really help them with that project, but, as far as I'm concerned, they now know how to think differently and sometime consider to Stop! TDD is the best Agile practice that my company needs now. It's not about coding fast, is about coding what is needed, is about being smart on what to code and when.
Last weekend I went to Agile and Beyond on Dearborn. Was good to go there with friends! Not just because it makes it easy to blend in the crowd with someone you know, but the road trip was fun too. I will talk a lot about the speakers here, but you should know I feel sort of hip to be friend with these guys (Jason Little (check out his LeanDog picture at the bottom), Andrew Annett and Sue Johnston). If there were sessions that I didn't vote high, it is their fault for being so up to date with things and make everything sound as something I had heard before. End Of Disclaimer.
(Here is us packed like sardines on a Mazda. You can see a bit of my shoulder here)
I want to write down some of the things I heard on the sessions I went, before I forget them.
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 :)))
I really enjoyed listening to him so I didn't want to lose focus by keeping notes. I had a chance to invite him to Toronto soon. Maybe will happen! ;)
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.
I missed most of his session on coaching. Went there at the end when he said that both coach and the person being coached should set some objectives when they work together, some steps to get there, what is next and by when do you expect to get there.
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?
Really enjoyed the energy from Renee and Carol.
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!
I got to talk with Cheezy and some other people afterwards for dinner (Maria Matarelli, Chris Gow and Paul from LeanDog). He let me have a picture with his hat. For all of you that know about LeanDogs, you should know about their hats!! :))
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.
