Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Sunday, August 13, 2006

Small Teams Make Better Software

For the better part of two decades now, I've been in the software industry as a developer, engineering manager, product manager, and now as an entrepreneur. Over the last six years, I've been leading software development teams using so-called Agile techniques.

When I first started with Agile, the bleeding edge literature was on Extreme Programming, which at the time I found a bit too, well, extreme for my projects, but with a lot of useful ideas that resonated with my experience. Later I discovered Scrum, which added some project management principles that really helped solidify my thinking on the subject.

What really sold me on the concepts of Agile methods was the emphasis on rapid feedback and people over process. My experiences up until that point told me that various methodologies I had tried (Information Engineering, Strutured Development, RAD, Rational Unified Process, etc.) only seemed to work as well as the individuals on the team.

I saw that a small team of good people seemed to outperform the most disciplined process, toolset, or philosophy. A bad team usually failed to produce a good result, regardless of what magic process was applied.

But what I also noticed was that even a great team that wasn't focused on delivering a solution incrementally could also fail.

About 10 years ago I was on a team with outstanding developers building a workflow management product. We built a solid architecture, complete with a portable persistence layer, cross-platform GUI widgets, and cutting edge object-oriented design.

As months went by we were making great progress from the bottom up. The widget set was portable across Windows, OS/2, and Motif platforms. The data store could be hosted in an object database, Oracle or DB/2. We had the coolest "smart object" framework for managing memory. Even the basics of a GUI modeling tool for designing interactive workflows, and a workflow runtime engine and API.

But as time passed, management started getting nervous. Where was the product? Did it really make sense to keep working on this stuff when Web development was becoming the new hot topic?

Since we were so focused on building the rich, robust infrastructure and frameworks for what we "knew" would be needed, we didn't have much to show when the VP of Engineering and CTO would come by looking for a demonstration. It probably didn't help matters that my manager at the time would aggressively refuse to demonstrate incomplete software.

Now, we were all experienced developers with project successes under our belts. But we were determined to not repeat the problems of previous development efforts. In hindsight it's easy for me (and probably for you) to see what we did wrong, but it seemed perfectly reasonable at the time to design the system up front, complete with a fully portable, flexible, robust, cutting-edge infrastructure design.

Ultimately the project was canceled after about nine months of work. Purportedly this was due to the desire to focus resources on the then emerging "Internet fad." In truth, I believe that our failure to demonstrate consistent progress in the form of working software was the death blow. It's not that we were necessarily wrong for wanting to build great software, it's more that we forgot about the need to DELIVER.

But what's all of this have to do with methodologies and small teams? Simply this - methodogies are no good without talented people. And talented people alone can flounder without some structure to guide their efforts.

Agile methods embrace individuals and interactions, while providing easy to understand structure and practices to guide a team. For example, frequent releases for feedback might have saved my workflow project from the chopping block. Certainly it would have focused the team on prioritizing things like working software over world-class engineering infrastructure.

The combination of small teams with lightweight, disciplined process is a force to be reckoned with. Even large projects can benefit from dividing the work between small feature teams, as long as the work is coordinated.

Over time, I've noticed that as small teams become proficient in delivering software, sometimes the process scaffolding gets torn away, and to an outside observer, it seems as if the team isn't using a process at all. In reality, the team is operating so efficiently that informal communications, minimal documentation and impromptu meetings are good enough.

This is where teams just starting with Agile methods can get into trouble. An inexperienced team may well be served by using a little more structure to get started, and adjust as needed later based on real world feedback. A professional circus performer can walk a tightrope without a net and make it look easy. But would you bet your life trying to do the same?

As Agile methods go mainstream, I'd hate to see projects try to adopt the techniques without an awareness of the original context - small teams working with frequent feedback, close communcations, and respect for each other and their customers.

This doesn't mean that Agile can't be scaled to large organizations - I've personally been involved in doing this successfully. But methodologies are only part of the story - we can't forget about the human side. Smaller teams of about 3 to 8 people are a better way to collaborate.

And given a reasonable degree of structure, it is the people that ultimately make the difference between a successful project and another disappointing statistic.

[Digg this article]

For more on agile tools and techniques:
(Tags: , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • This is great. Thanks!

    I work in a small company.

    Our CEO is very much feature-driven and bases his plans very much on predictability.

    We in Development/QA have moved to Scrum for the last two 30-day cycles.

    Although the CEO seems to embrace the general concept of agile (in that it focuses on frequent releases and focus on customer) he doesn't seem to be interested in what he calls "the details" of the whole method (e.g. sprintlog, backlog, stand up meetings, etc.).
    We are therefore struggling to having him on board of Product Owner.
    At the last company meeting he gave a speech on the importance of predictability. ;-(
    Do you have any suggestions/experience on this?
    Thanks a lot.

    By Blogger Marco, at 4:01 AM  

  • Marco,

    If you don't have anyone else in the role of product manager, and you don't have direct access to customers (I'm assuming you don't), I'd suggest sitting down with the CEO to tell him exactly what you need.

    It may be that you just need him to prioritize your features based on the estimates that you provide, or to clarify what can be "thinned" out of a story when time gets tight.

    It's not required that a Product Owner attend daily standups or speak Scrum terminology, but I think it's critical that he participate in clear prioritization of the feature set, and maybe appoints a deputy or proxy to be more involved in the day to day questions and interactions.

    I've been in this situation before, and actually the CEO was the absolute wrong person to play Product Owner. Is there anyone else in the company that's customer and market focused (not development focused) who could do this?

    By Blogger David Churchville, at 8:46 AM  

  • That’s because is hard to find Good Software Management, so is more easy to find technical talented guys then a good manager, I truly recommend use Prototypes, always use prototypes and BTW I also recommend Software Project Management O’Reilly Ed.
    This as truly keys to a succesfully software management, WBS, Milestones, Prototypes, etc

    By Blogger Efrain 67z, at 2:04 PM  

  • & thx for the Scrum tip...Regards

    By Blogger Efrain 67z, at 2:05 PM  

  • Hi Dave, thanks for your thoughts.

    Yes, our Product Manager is very good, with good understanding of dev. as well as customers.

    What are your thoughts about predictablity of software delivery? Can it be improved (as required by our CEO) and if so, how?

    By Blogger Marco, at 6:15 AM  

  • Re: Predictability of software development

    Hmm...I don't think it's very easy to make software development predictable, but you can make it hurt less when you're wrong about estimates.

    By delivering software frequently, getting quick feedback, and using the discipline of fixed size iterations, your CEO will always know where things stand.

    If your iterations are 2 weeks long, and you commit to finish 10 things, at the end of that period, you'll know how much got done, and therefore how much is likely to get done in the next iteration.

    By Blogger David Churchville, at 8:39 AM  

  • Well..I kinda agree with you when you say, small team make better software. More so, because they're better manageable, easier to kept motivated, and much better in terms of intra-team communication. It's definitely not to say that Agile teams can't scale out to handle larger projects, but in those cases I've seen sub-teams work quite well. Although, there is less cohesion which needs to be handled with care.

    I liked your article have linked it from within my post as well.

    By Anonymous Tech n Fun, at 5:36 AM  

Post a Comment

<< Home