Last year I met Rich Sheridan, CEO and Chief Story Teller of Menlo Innovations and author of Joy, Inc. I heard him speak at Agile Singapore and got to interview him and Linda Rising together after that conference. Both of their presentations from that conference can be viewed here. Linda’s interview of her visit to Menlo can be found here.
I found his story inspiring and wanted to hear more – does the company really operate that way, is there really a culture of joy in the workplace, are teams really that empowered and are management really that transparent? If they are then what makes it work, what is the secret sauce that allows the organisation to function like that, can other people learn it and will it take in other organisations?
To try and answer these questions, and to see what I can learn and bring into my own classes, I’m attending the Menlo Innovations Deep Dive class this week. 5 days of deep immersion into the culture, working practices and skills that it takes to be a Menlonian.
The story of Day 1 – The Menlo Way™ can be found here.
Day 2 – Project Management the Menlo Way™
The second day of the class was a deeper look at the Menlo approach to managing projects. This class was led by a pair of project managers who talked about the role and activities based on their own experiences.
The Menlo approach is that every project is done in iterations, iterations are five days long and the beginning/end days are based on what works best for the customer representative who authorises the work in the planning game and attends the showcase at the end of the iteration.
Iterations are strictly 40 hours long, with 32 hours available for working on stories and the remaining 8 hours allocated to the activities needed to keep the process moving forward.
This fixed structure applies to every project, which makes planning and scheduling predictable.
All work is done in pairs and time is tracked against the stories allocated to the pair. A simple rule is rigidly enforced – no story card, no work. Team members track their time very accurately, down to 15 minute blocks.
Effectively every iteration is treated as a complete mini-project – work is selected, estimated, prioritised, planned and performed with the goal of finishing all the story cards played this iteration to a Done state. Estimation variances are allowed for and the team compares estimates against actuals. Since work is done in pairs and all work is associated with cards, the focus is on completing the work with as few distractions as possible. No manager can approach a team member and ask “can you just look at this for me” – the response will be “please put that on a story card” and the card will be prioritised at the next planning game. Even work for internal projects and supporting activities is treated in this way. The people teaching and supporting the course had story cards assigned to them for the classroom activities. At lunchtime on each of the first three days of the class a group of Menlonians joined the group to answer questions – they had story cards assigned for the activity.
Since employee and contractor remuneration is based on the actual work recorded and all work recorded must have a story card reference the team enforce the rule themselves – it doesn’t need external oversight.
Two important parts of the iteration are the Estimation activity and the Planning Game. Time for these is included in each iteration, on the 4th and 5th days.
Estimation is where the set of cards coming up over the next few iterations is looked at by the technical members of the team and the time they are likely to take is estimated. Estimation is in hours using a simple binary numbering range – 1, 2, 4, 8, 16, 32 & 64. No card larger than 64 hours is estimated and 64 hour cards are broken down into smaller stories before being played. (Playing a card is including it in the iteration for development).
The people who will do the work estimate the work – estimation is a whole team activity and includes all of the work to get the story to a completely Done state. Technical standards are high, technical practices strictly followed and the delivery activities include peer review and QA testing.
For estimation the whole team will come together and all the pairs discuss the card to forecast the number of hours they feel the story will take to complete to the Done state. Each pair gives their own estimate with a consensus estimate being recorded on the card. The individual pair estimates are recorded as well as the consensus figure. The consensus figure is what is used in the Planning Game activity the next day.
Estimation is timeboxed to two hours and typically covers the next two-three week’s worth of stories. As the project progresses the estimates will get closer to the actuals as the team learns more about the project, but there is no expectation that estimation will be accurate (the likelihood of a single story taking exactly as long to deliver as estimated is 2% - 98% of the time the estimate will be wrong, 49% over and 49% under). This approach to estimation means the teams do not feel pressure to “come in on time” for every story and avoids many of the dysfunctions that are seen in organisations where people are penalised for missing an estimate. (Padded estimates, project management pressure to make estimates lower, etc) The Menlo culture of safety and trust is evident in the approach to estimation.
Once the stories are estimated the Planning Game can then be played. This is where the customer selects what work will be undertaken in the next week and the priority order of that work. The estimated story cards are laid out on a table for the customer to see and they get to select the cards to be added to the iteration by putting the cards onto planning sheets in the sequence they want them worked on. Each planning sheet has space for 32 hours of work by one pair. The number of planning sheets is the number of pair the customer is paying for in the next iteration. The ability to move pairs on and off projects makes this a very flexible approach as the customer can decide to get more work out simply by increasing the spend for the next iteration, or if their budget gets tight they may choose to reduce the number of pairs working on their initiative.
The planning sheet has space to put the cards to fill a total of 32 hours work. Cards are folded to show the number of hours estimated against the card, as can be seen in the images below.
The predefined blocks on the planning sheet are the standard overhead activities undertaken every iteration – daily standup , estimation, show & tell, planning, communication. These are baked into the working week and are not optional.
The plan is confirmed by using sticky tape to fasten the stories to the planning sheet (these are photocopies of the master card which has been filed).
After the planning game is completed with the customer, the project manager prepares a work plan for the week. This is where the cards are assigned to the pairs to work on, taking into account the pair’s individual estimates from the estimation session. The amount of time a pair estimated is what is allocated to them, not the consensus number. This is a bit of a balancing act and the project manager needs to understand the pairs who will work on the stories. The reality is that the over/under aspect of estimation will work in the team’s favour and most of the time the stories selected do get complete. Occasionally a pair will complete their cards early and can either assist another pair who are falling behind.
The cards are put onto a story wall, with each pair’s cards in a column. This is the record of the state of work, which is shown by the coloured dots attached to the cards. The position of a card is related to the day of the iteration it is expected to be completed, so a 16 hour card will show in the second row with the first row empty, as can be seen in the image below.
A yellow dot means “this card is being worked on now”, an orange dot is “ready for a review by QA” and a green dot is “tested and shown working by QA”. A red dot means something is wrong – either the card is blocked or testing failed. Where the testing failed a card is attached to the wall with the details of the failure (and the QA pair tell the developer pair what they found).
The beginning of the next iteration is the Iteration Kickoff, during which the whole team look at all the stories planned for the iteration and agree the approach, undertake any architectural and other design activities needed and come to consensus on how to build this aspect of the product.
Pairs take their estimated time into account when working on a story, and if they discover that their estimates were too small they tell the project matter, along with a revised estimate of the amount of time needed to complete it. Another simple rule is “as soon as you know you will exceed an estimate let the PM know”. This ensures that nasty surprises don’t come late – as soon as a blowout is identified it will be assessed and if needed the customer called to discuss the issue. So, for example, if a card was estimated at 4 hours and after an hour the pair discover that is should have been a 32 hour card the let the project manager know so they can discuss the value/cost of the card with the customer. If the customer is happy to complete the story they know that other stories will be dropped out of the iteration. Small variations are not as important but significant variations could have an ROI impact and they are addressed as soon as possible.
The last ceremony of the iteration is the Show & Tell in which the overall state of the project is looked at with a focus on the user stories completed in this iteration. The product is fully built and installed onto a server for the customer representative to work with. The completed stories are shown and the customer uses the product to see for themselves how it is working. Often this will result in new ideas coming to light which are written on story cards for the next estimation and planning sessions. Uncompleted stories are discussed and the approach to addressing them agreed with the customer.
After the Show & Tell the customer gets the complete working product – source code, data structures, library files, documentation and whatever else constitutes the deliverable package. In theory the project could be closed at this point and there would be no more integration or other work needed. Hence each iteration could be considered a project.
Shortly after the Show & Tell the team will move into the next planning game with the customer and the iterative cycle repeats.
The keys to this approach are the simple rules which have been referred to a number of times. One of the most important is that a pair works on one item at a time and that the next piece of work a pair will work on is always the most important one in their queue. Pairing results in higher quality work, better conformance with standards and less distractions. The billing approach reinforces good pairing practices and the overall culture makes it safe to ask for help, acknowledge if you were wrong and focus on customer outcomes, not busyness.
About the Author
Shane Hastie is the Chief Knowledge Engineer for Software Education a training and consulting company working in Australia, New Zealand and around the world. Since first using XP in 2000 Shane's been passionate about helping organisations and teams adopt Agile practices. Shane leads Software Education's Agile Practice, offering training, consulting, mentoring and support for organisations and teams working to improve their project outcomes.In 2011 Shane was elected as a Director of the Agile Alliance.