Part 1 | Part 2 | Part 3 | Part 4 | Part 5
I realized today that there was something else I learned that failed to make it into part 5.
The lesson I learned: don’t change the purpose of a meeting in order to suppress bad news.
During the course of the project, we had a daily 10-15 minute stand-up meeting — the “daily scrum” that was supposed to be a short and pointed discussion in which each participant would state:
- What they did yesterday (since the last scrum)
- What they’re doing today
- List any roadblocks stopping them from moving forward
This matches up pretty closely with other definitions of the daily scrum that I’ve seen, including this one.
“All team members are required to attend the daily scrum. Anyone else (for example, a departmental VP, a salesperson, or a developer from another project) is allowed to attend but is there only to listen.”
During the first few weeks, we were pretty disciplined about the content of the call. We’d each take a turn stating what we did yesterday, what our plans were for the day and if we had anything blocking our progress. If there were questions or major issues, we’d table them and deal with them *after* the scrum and only pull in people that needed to be there.
The emphasis in the quote above is mine and it highlights one of the major problems we had during the project. Since this project was done remotely, our scrums were done on a conference line with the PM being the moderator. Lots of times we’d hear people join the call, but because they chose to not identify themselves when logging in, we were never sure who was on the line. Sometimes we’d learn that a certain person was on the call after the fact, and to be honest, that sucked. The PM got into the habit of going to the conference menu and selecting the option to list the current participants. Sometimes we’d resort to saying “who just joined?” until they either logged out or identified themselves, but most of the time we just had our meeting. It always bugged me that people would join but not say who they were. :-\ As it turns out, sometimes the CEO would join, sometimes one of the managers, but a lot of the time it was the client.
We quickly learned that we had to be careful about we said during these meetings. It’s not that we were joking around or trash-talking anyone either. What was getting us in trouble was the truth. We’d scrum on a particularly bad day where there were lots of project-related issues and whoever was listening in on the call would freak out (NOT on the call with us of course, but afterwards) and all of a sudden we’d be in massive “fire fighting” mode because of the person/people that were hiding in the conference call. It got to the point where the team decided as a whole that we’d actually have a “pre-scrum” meeting to filter out any bad news beforehand. The normal scrum would simply be fluff, performed only for the satisfaction of those that may be listening.
Of course, sometimes we’d have people join the call who wanted to hijack it for other purposes. The client was a huge violator of our “no issues” rule during the scrum, but there wasn’t much we could do to stop him.
Hindsight being 20/20, I should have stuck with telling it like it was during the official scrum. But as I said in part 5, I would have done a lot of things differently.
Hey, I was lead on that same project, funniest part is that it was an EMR project, and no, I’m not Stan.
I just got done reading all 6 of your posts. Sadly I’m seeing some similarities on my project and I work for the same ‘consulting company’ (at a different client). My projet is getting ready to either ramp down, or ramp up for phase 3, and there is some ridiculous politicing going on to remove and place blame depending on how the next couple weeks go. I’m going to have to remind myself not to be the hero.
Thanks for the great insite
Kevin,
I hope things get better, although after a chat with another “alumni” of this firm, I get the feeling they may not be around too much longer.
good luck.
It’s amazing how similar this project is to the one I am working right now. Long hours, high expectations to client given by the PM. Not enough requirements. Funny thing is that the current project I am on, the lack of quality requirements is being blamed on agile development.! Yeap, we dont need no stinkin’ requirements, we are agile…
btw, I love the whole series of your posts. I might get some cojones later and write my saga as well…