Two weeks, ago, with the launch of a new look for the FastCompany.com homepage, I wrote about our company division, Mansueto Digital (FastCompany.com, Inc.com, and IncTechnology.com) and its adoption of agile software practices as a metaphor for business strategy.
Here’s an update: we’ve been running one of the most complex projects ever undertaken in business journalism, called the Inc. 5,000, using a variation of agile known as a scrum.
Scrum is a rugby term — it’s the clutch of guys on the same team “binding together” around a ball. The heads of one team are literally interlocked with the heads of the opposing team. Great way to communicate fast and efficiently — but every once in a while someone gets pummelled in the crowd.
Scrum’s a pretty complex metholodogy and we’re newcomers, so we scaled it down to start — we kicked off with a weekly meeting to determine our priorities, then ranked them for the coming two weeks. (The “Sprint Backlog” in Scrum terms.)
Small blue index cards recorded each task. After three hours, we dispersed to do our own work. Management (me) signed off and promised not to interfere until the next weekly meeting. In the meantime, every morning, the team gathers for 15 minutes with our Scrum Master — (David Grossman, Director of Business Development) for a standing meeting. The team literally stands so we can keep the meeting short. We ask only three questions of everyone: What did you do yesterday? Is anything getting in your way of what you’re expected to do today? and, What are you doing tomorrow? Wikipedia has a nice summary of how the process works for software development.
So far, no problems have arisen, but I’m sure they’ll come up sooner rather than later.
Ironically, our agile methodology hasn’t worked out as well this last week with a major software development project. The core of agile, as I see it, is a trust-worthy team. Managment can afford to give staffers great freedom in executing a project (with only intermittant opportunities to review the work in progress and change course if need be) if, and only if, they really trust their people.
Which is not so easy when you’re hiring a group of expert developers to build a complex software platform. Since we’re investing a small fortune to get this project done, we’ve had no shortage of great vendor choices.
That said, the world of open source development, and in particular the Drupal community we’re working with in building our social network, is filled with both great creativity and big egos. After all, why would someone choose to become an open source developer, giving away much of their work for free, if they didn’t have strong faith in their own abilities?
How is the average non-techie manager (like me) supposed to tell the difference between bluster and genius? It’s not easy.
The agile process can help you catch weak performers early and correct their mistakes. The fewer mistakes that emerge at the weekly or bi-weekly show and tell for management, the more trust you build. And the more rope you can give the developers during the next “sprint.”
We’re not there yet with our social networking scrum process — partly because the team is still in flux. We’re nine months into a project that’s probably going to run three or four months to get to where we’re happy. It’s exciting stuff — our readers will love the end result, I’m sure. And with any luck, we’ll build the trust with our software vendors that’s necessary to run a great scrum. I just hope to not get too badly pummeled in the process.