Dean Leffingwell, author of Scaling Software Agility, recently posted a series on the ongoing debate over "Feature Teams" versus "Component Teams" in the Agile community. Over the course of three posts, Dean does a great job of digesting the underlying concepts and considerations, and he ultimately recognizes there's likely not "one right answer"... That like most things in software, we're dealing with various shades of gray, and arriving at the right answer depends on smart people with good judgment.
As he puts it:
"Given the advantages and disadvantages to each approach - essentially the balance of immediate-value-delivery vs. architectural focus and potential for reuse - the agile enterprise clearly leans towards the feature team approach, as there can be no question on the immediate value delivery velocity benefits and the focus of the teams."
"However, ... the answer is not that simple, and it's likely that a more balanced approach may be required."
Whichever way you slice it, make sure your teams clearly understand the results they are accountable for - be they intermediate components or full-fledged product features.
And for what it's worth, I strongly recommend you recognize the importance of organizing around the architecture. The alternative is allowing the architecture to organize around the organization, and that invariably leads to unintended consequences.
Check it out at Organizing Agile at Scale: Feature Teams versus Component Teams - Part 3
Tuesday, July 28, 2009
Organizing Agile at Scale: Feature Teams versus Component Teams - Part 3
Sunday, July 19, 2009
Software Engineering: Dead?
Over on Coding Horror, Jeff Atwood pointed us to a recent publication by Tom DeMarco titled, "Software Engineering: An Idea Whose Time Has Come and Gone?" As Jeff points out, DeMarco is someone who has shaped the thoughts and minds of the software world for a couple of decades, and when he unabashedly claims that "software engineering" is dead... well, that falls under the category of "things that make you go huh!?"
Jeff does a nice job of putting DeMarco's comments into perspective and gives us all some things to think about. In particular, he encourages the focus on the "craftsmanship" aspect of our profession. This "passion for the craft" of software development is something many of us are enthusiastic about and spend a great deal of energy fostering within our organizations and teams. Jeff wraps it up nicely, concluding, "The guys and gals who show up every day eager to hone their craft, who are passionate about building stuff that matters to them, and perhaps in some small way, to the rest of the world -- those are the people and projects that will ultimately succeed. Everything else is just noise."
I'm not one to abandon the engineering disciplines - and I'm pretty sure that's not exactly what Jeff or Tom are suggesting - but it's high time we all recognize that much of what we do is a "craft." Crafts are performed by people who care about what they do. When engineering attempts to take the place of heart and passion... we fail.
Check it out at Software Engineering: Dead?
Posted by Brian Sondergaard at 3:40 PM 2 comments
Labels: change-management, leadership, software architecture
View blog reactions