FC NOW: The Fast Company Weblog
June 19, 2007
An Agile Update for Mansueto Digital
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.
Ed Sussman is the president of Mansueto Digital, which runs FastCompany.com, CompanyofFriends.com, Inc.com and IncTechnology.com.
Posted by Ed Sussman at June 19, 2007 8:49 PM | Category: internet + web |
3 Comments
ADVERTISEMENT
FC NOW MENU
NEWSLETTERS
FC NOW CATEGORIES
FC READS
Ed,
I can't help but feel that although this is a well-intentioned effort, you're missing some pertinent points and making some fundamental errors.
1) If you're all new to Scrum, scale down the project, not the methodology. It's also generally agreed that one of the beauties of Scrum is that it's one of the simplest methodologies -- if your team views Scrum as "pretty complex", then I would assert that there are deeper organizational and experience issues that might need to be addressed as well.
2) There's definitely a trust/control issue that must be addressed here - you nailed that one. But management needs to have fully bought in to the process. Your description of "mistakes that emerge at the weekly or biweekly show and tell for management", "rope you can give the developers", and "Management ... give staffers great freedom ... review the work in progress and change course if need be" sounds strongly like a management team that (a) still has a fundmental lack of trust and (b) is far too used to dictating scope changes at their whim. I believe you have also not fully grokked the purpose of the end-of-sprint demonstration.
I salute your effort and hope for success, but too many warning bells sounded for me when I read your review.
Finally, you can take faith that "the average non-techie manager" is NOT "supposed to tell the difference between bluster and genius?" -- one of the beauties of self-managing teams (a fundamental tenet of Scrum) is that they are well equipped to police themselves if given the opportunity and authority.
-di
just wait until you get into the joys of burndown charts and velocity tracking ; )
we use scrum as our methodology for the application development company i work for. our existing customers embrace it, however the hard part is getting new clients on external projects familiar w/ the process and not having to firm requirements for the entire product or service as an initial phase at the outset.
our biggest problem thus far has been forecasting resource allocation across many projects. although you are supposed to have a dedicated team when using scrum, due to shifting priorities, that is not always the case. this is not a problem inherent only to scrum. i've had plenty of problems w/ this using waterfall as well.
congrats on the shift. i'm sure you'll recognize the benefit of an iterative development process and the flexibility it provides in allowing you to develop against current value, vs. what you expected to be needed at the outset of the project.
good luck!
just wait until you get into the joys of burndown charts and velocity tracking ; )
we use scrum as our methodology for the application development company i work for. our existing customers embrace it, however the hard part is getting new clients on external projects familiar w/ the process and not having to firm requirements for the entire product or service as an initial phase at the outset.
our biggest problem thus far has been forecasting resource allocation across many projects. although you are supposed to have a dedicated team when using scrum, due to shifting priorities, that is not always the case. this is not a problem inherent only to scrum. i've had plenty of problems w/ this using waterfall as well.
congrats on the shift. i'm sure you'll recognize the benefit of an iterative development process and the flexibility it provides in allowing you to develop against current value, vs. what you expected to be needed at the outset of the project.
good luck!