Lean and Green

Developers build stuff, Testers break stuff

I've seen some recent posts in the user groups about eliminating the distinction between developers and testers on teams.  One word – Hogwash (that’s the polite version).

The best developers I've worked with create beautifully engineered and usually bug-resistant code.  They do this with passion and will commit every once of their soul to the purpose.  Now, if they're a bit more enlightened, they'll like the idea of unit testing and build out a [j|n]unit test suite for their component.  Often, here the passion dissipates and testing isn't quite as complete as you'd like it to be.  I've yet to truly experience test-first, but I am sure its out there somewhere.

Now testers are a different beast entirely.  They are devious.  They will take this piece of artwork, conspire with others, and meticulously commence punish it in every way conceivable.  They will do this over and over again with a fervor that it at times frightening.  They can't be stopped in their search and destroy quest.  And worse, yet, they will document and publish every last detail of their escapades.

These are two very different personality types that are very good at specific activities.  There is a difference between good testers and developers and good leaders will recognize and leverage this to build the best possible products.

Be agile about agile!

The democrats and republicans are doing a fine job of "fire bombing" the centrists in both their parties (I grabbed that quote from an article "It's not easy being George" in this months Vanity Fair).  And, as I scan the agile groups and blogosphere, it seems the methodologists are doing it as well.  Some of us take the "extreme" in extreme programming too literally, and others are holding on to some of agile developments long disproved stigma for far too long.

My approach always has been (and hopefully always will be, unless of course I turn out like my father, which all of us eventually do...) a pragmatic one.  There are many things I love about Scrum and agile - driving elaboration and development off the backlog, test-driven development, burndown charts, and much more.  And there are a some that I could do without (self-organizing teams, developers and testers are interchangeable,... I blog on these later).

An agile approach needs to be tailored to your people, process and technology.  You can start-off "by the book" but be sure to incrementally adjust your process in the same way you incrementally modify your products under development.  If you have a particularly gnarly architectural component to build feel free to build a UML-based design first.  It’s okay.  Really!  These are just items that are added to the sprint backlog and monitored along side all of the other demand that flows through the process.  And god forbid you build a Gantt chart to model out some complex project dependencies.  How will you be able to look yourself in the mirror?

Come on now; let’s be agile about agile and use the tool that works best for the job at hand.

Picking the right projects

One of the most important things I’ve learned from my recent stint in the project and portfolio management (PPM) space is that business success is not just about efficient and effective project execution (agile or traditional).  Success is more determined by making sure that your precious resources are working on projects that return the most value to the organization.  I can execute the hell out of a project and bring it in 25% ahead of schedule with a satisfied customer.  But if my competitors are delivering new higher value products that satisfy a broader customer base, then I will be left in the dust.  The irony is that they may have worst project execution and still beat me in the end if they’ve selected the right projects to invest in!

In the PPM space, determining what project investments to make is typically considered part of demand management.  Demand management considers inputs from a variety of internal and external sources including customers, analysts, partners, IT, business units, and more.  All of this demand needs to be reviewed and appropriate selections made.

If the incoming demand is not structured and managed, effective decision making will be impossible (garbage in, garbage out).  Each request should include a standardized business justification for the new “investment” that includes meaningful expected costs and benefits. The requests should also demonstrate alignment with corporate goals, compliance with technical architecture, and other measures important to the organization.  If a standardized structure to incoming demand is applied, a selection process can be realized that allows comparison of all incoming demand and with ongoing projects in enterprise portfolio.

There is a broader business context that agile projects need to exist in for an organization to succeed.  The larger and more complex the organization, the more standards and processes are required.  This may seem like blasphemy to us agile zealots, but its the cold hard reality of managing a successful business.  The key is to put in appropriate controls and at the same time leave enough degrees of freedom to foster an environment of creativity where agile teams can thrive.

"Demand Management" covers the front end of the funnel.  In a future post, I'll discuss the impact on the tail-end of the funnel and the impact of product release on the broader organization.  This has a whole other set of issues that impact agile teams.

Why be Agile?

I have been repeatedly asked why agile is better than traditional approaches.  The most succinct answer I have is that agile software enables you to build the right software at the right time.  Agile is not about in-depth analysis and design that leads to a detailed work breakdown structure that predicts on what day of the year eighteen months in the future a team will deliver a certain set of features.  Agile is about continuous prioritization and customer review to insure that meaningful features are delivered when they are ready and when they are needed.

The ability to make significant changes to design and behavior throughout the evolution of a system is perhaps one of the biggest differentiators of software development from other engineering disciplines.  And because we can, we should, and usually do.  This allows organization who embrace agile principles to have agility in how their business execute as well.  Being agile implies applying approaches and processes that maximize an organization's effectiveness in creating software.  Agility is not a chaotic undisciplined approach to hacking software.  If this is what you are doing, you are not being agile, you're being stupid!

Agile software development approaches promote high levels visibility, predictability, and quality.  Visibility is achieved through frequent, regular team status checks and product demos.  Predictability is achieved through continuous monitoring and updating of the project backlog and burn-down.  And, quality is maximized by embracing test-first approaches eliminating the "over-the-fence" paradigms of legacy software development methodologies.

An essential characteristic of agile software development is that barriers that separate people that work together are removed.  Legacy software processes and methodologies formalize these barriers as entry and exit criteria, documentation, and sign-offs.  Developers, testers and documenters are far removed from the actual users of the system and must often interpret documentation rather than directly ascertaining desirable system behavior.

Successful agile teams are collaborative and cross-functional.  All disciplines required to build the product are involved in all aspects of development.  The customer is pulled deeper into development and testers and writers are pulled earlier into design and elaboration.  The barriers to success are broken down.  Information is now instantaneously available to all who need it.  Errors resulting from interpretation can be resolved in real-time.

View this photo