Two years ago this month, Lucidus started down the path of applying SCRUM to our development process. At the time, we were struggling mightily with a number of goals that we talked about a LOT and never seemed to make progress on. One particular question we always wrestled with was "Where are we on each project?"
We had a tradition of our meeting length swinging on a pendulum. First we'd go for a while with no meetings because people were heads down working. In a few weeks when folks started complaining that no one knew what was going on, we'd insist on weekly (sometimes daily) status meetings that seemed to chew up an hour a day.
Think about that...we had a team of 12 meeting every day for an hour. 12 people x 1 hour x 5 days. We were losing 60 hours / week in productivity. We'd talk about site architecture, the latest Drupal module, etc. It was exciting for the first three days and then we'd swing the pendulum back the other way to no meetings.
In addition to being inefficient, it was frustrating. We just couldn't solve it. That's where SCRUM came to the rescue. Thanks to Mick McGuire, SCRUM was just what we needed for a lot of things but, in particular, it solved our issue with status meetings. Now, I will preface this with we've tailored our flavor of SCRUM to our needs. We hold pretty close to the tenets but leave flexibility for our own business process.
In SCRUM, we meet every day for 15 minutes via web conference. In general, it's recommended to meet in person but with people spread to Oregon, Arizona and New Hampshire, that's just not realistic. For us 1:30 has settled in as the right time that everyone can get a good morning of work done and then report in.
In the Daily SCRUM meeting, each team member reports three things:
- What they completed since last meeting
- What they're doing for tomorrow
- Any impediments they've run into
The team stays connected and knows what each other is doing. Developers are held accountable by each other to get stuff done. If you tell your teammates that you're going to have something done for tomorrow and it's not done once, that's ok. After three days of saying the same thing, people start "looking" at you weird and you feel the pressure. Moreover, it's an opportunity to gain praise from your peers on delivering work. It really helps everyone pull their weight and be excited to contribute.
A couple of our lessons learned / best practices:
- Concrete reports - Reports should be concrete, not vague. Vague reports are a smokescreen to work that wasn't done (or at least it can be perceived that way).
- Discussions happen afterward - Any follow up questions specific to how something is being done is pushed until after the meeting
- Keep it to 15 minutes - this lets folks know that they're going to get back to their work quickly.
Obviously, longer conversations are necessary but we leave those to Sprint Kickoffs (every two weeks) and Sprint Retrospectives (also every two weeks). We've hit a point now where even our retrospectives are only half an hour. By meeting every day for a short, time-boxed period, we dramatically increased our team communication and developer efficiency and provided an opportunity for problems (impediments) to be reported early and dealt with both in terms of development and customer expectations. It's made a HUGE difference for us.