Trimming Meetings
The changes to our estimation process have been a huge hit. The project manager has been nothing but pleased with the new methods. She used to fear estimation meetings and no longer does. The team all has an idea what is happening now when previously they did not. The business feels they have a better handle on what we can get done in any given amount of time. It has been a good fit all around. With this initial success it was time to look at what else in our process could be improved within the limitations we have to endure.
As a by-product of a failed Scrum implementation a few years ago we work in two-week sprints and have daily status meetings. We had a lot of other meetings though. There was a planning meeting that was attended by one developer, one person from SQA, and both business analysts. (In fairness, one of them is the project manager as well.) These meetings were long and painful for everyone involved. They went through the requested work trying to define what exactly it was. They picked what would be done next. They broke it down to tasks and times after which they assigned it to a person. After these meetings would be another meeting we called a kickoff in which the whole team was invited.
In this meeting the rest of the team was basically told what had come out of the previous meeting. This was not a feedback requested meeting. There would be some discussion at times, but generally none was encouraged. The various developers and SQA members would agree to set up a time to go over requirements with the BAs during this time. At some point there was a third meeting added in-between them which basically mirrored the intent of the first meeting with the result of the second. It was added without any changes to the other two meetings. The goal of it was to get the whole team working together again, but it failed.
Finally there were a lot of “hand-off” meetings. In these meetings the BA would go over the requirements for a user story with a single developer and an SQA representative. Sometimes another developer or two would be present, but not normally. For complex requirements there would also be a functional review meeting. These consisted of the same group that were at the hand-off meeting. No more, no less. It was a chance for the BA to verify that the requirements were properly met.
Obviously this is where we decided to make our next set of changes. The project manager and I started to look hard at the purpose of each meeting and what it was actually accomplishing. We also asked the rest of the team for input on the meetings. This is a process that had never been done within our team before. We had at least one member that had a certain disdain for meetings that felt purposeless. We had another that liked to spend as much time as possible in meetings. What we didn’t have was a narrative as to what each meeting was supposed to accomplish.
The first thing we did was cut the daily meetings from 30 to 15 minutes. We set the agenda to be the standard “What I did, What I’ll do, and What’s stopping me” set of questions. The first of these new meetings did have the full 30 minutes allotted so I could explain the how and why of the new format. The rest of that week I allowed for 20 minutes as we settled into a new pattern of taking problem solving offline.
With our new estimation meeting process we replaced the original planning meeting. Instead of a the BAs meeting with a single DEV and SQA person it was replaced with the BA’s (proxy product owners in our environment) and I meeting. My input in this meeting is not as a developer, but as an Agile Coach. It is essentially a product owner meeting that would be handled by a single product owner in most environments. We look over the order of the backlog and verify the top items are estimated. We also verify that what is estimated goes at least little larger in story point value than historical velocity. (This is a new part of the process as we are just getting useful historical data.) For our environment we do not have a team full of multi-functional people, but have to fit everything into separate Dev and SQA teams making this a little more difficult. Finally we draw a soft line where we expect the team to be done committing.
The middle meeting was dropped completely. It had failed miserably in the one purpose it had. The kickoff meeting was changed considerably. Going into it everyone has an idea what the requirement (stories) presented were from the estimation meetings. Tasks are assigned and estimated by the people who will be doing the work. For us that means the developer, maybe two, that will work on the requirement does their task estimates and the SQA person does their test estimates. Everybody has input into task creation, whether they will do the tasks or not.
Finally we added a retrospective meeting. The goal here is a more formal way for every team member to get involved with improving our processes. This incidentally also means they get involved with our transformation to Agile.
Now each of our meetings has a purpose. We spend less total time in meetings over an average week. The people who need to be in one are there, and management is invited to them to see how we are changing the way work whenever they would like. The team feels less frustrated by meetings and we are able to accomplish our work a little more efficiently than before.
Do all of your meetings have a defined purpose? Does everyone in them know and understand that purpose? Are they all on board with it? Is it time to revisit your meetings, or at least re-state the purpose behind them?
