Monthly Archives: September 2008

Standing Up For Agile – Continuous Change

In my previous post, I pondered whether the overwhelming marketing hype surrounding the Agile movement has tainted its early success and diluted its purpose.  I don’t believe this is the case.  Agile methodologies are very much at the forefront of software development and should continue building on this early success.

In part two of the Standing Up For Agile series, I’ll present the key elements behind Agile’s success in the early 21st century.

Thriving on Change

Agile’s success is rooted in its ability to embrace change and thrive on it.  Agile teams act as ‘engines’ whose fuel is the continuous feedback loop coming from daily meetings, changing stakeholder needs, continuous testing, and continuous integration to name a few.  In his book, Becoming a Technical Leader, Gerald Weinberg defines an effective MOI model for leading change and solving problems.  This model is built on Motivating and justifying action, Organizing to support action, and Innovating towards the desired outcome.

In some respects Agile methodologies represent an instance of Weinberg’s model.  Let me explain how.


Constantly changing stakeholder requirements can certainly demotivate team members.  How does a software development methodology promote change while keeping managers, developers, and testers motivated?  The key seems to be in minimizing the time required to discover and react to change.  Agile methodologies promote:

  • Daily Meetings – motivate through accountability
  • Continuous Integration – synchronizes parallel efforts and  keeps the system buildable at all times
  • Test-Driven Development – provides quick pulse on progress
  • Frequent Customer Interaction – keeps everyone focused on the right set of needs
  • No Overtime – keeps team members productive, lucid, and motivated.

These elements help mitigate the risk that progress will get too far off target, and more importantly that team progress is always visible and focused on addressing the true needs of the customer.  The same cannot be said for the heavyweight upfront planning that occurs in predictive methodologies like Waterfall or RUP, where the lack of frequent stakeholder feedback only increases the probability that the plan is not aligned with the most relevant needs of the customer.

Changing scope and requirements can demotivate team members if they conclude that a large portion of completed work was time wasted.  Agile prevents this by collapsing the time required to discover and adjust to change and instead motivates by ensuring team efforts are always addressing the most relevant needs of the customer, which only increases the chances for customer satisfaction.


Agile promotes small self-organized, self-empowered teams for good reason.  They represent and efficient and effective organization of disciplines that can best satisfy customer needs.  Agile represents a branch of Nonlinear Management and thus inherits similar criticisms including:

  • Only works with senior-level developers
  • Requires too much cultural change to adopt
  • Can lead to more difficult contractual negotiations

These are legitimate concerns that reinforce the notion that implementing agile software development requires a lot of work.    Both Agile and nonlinear management implicitly tell us that in this era of knowledge work, where no hierarchy exists between managers and programmers, managers must adapt and evolve to promote and empower self-organizing teams within their organizations.


Weinberg MOI model also suggests that innovation depends on the flow of ideas, understanding of the problem, and ensuring quality.   Agile’s promotion of daily meetings, frequent customer interaction, no overtime, pair-programming, moving people around, continuous integration and test-driven development all effectively address these aspects of innovation.

With daily meetings and moving people around, team members are continuously challenging and stretching their individual and collective understanding of the problem and solution domains.  With frequent customer interaction, the team members are educated on the subtle characteristics in the problem domain, knowledge typically locked in the heads of domain experts,  which increases the chances for an effective solution and overall customer satisfaction.  Promoting no overtime is a good way to keep team members lucid and motivated during productive hours.  Test-driven development promotes higher-quality deliverables by focusing developers and testers to the solution’s ability to satisfy requirements at any point during the project lifecycle.

With these elements in place, agile teams are empowered to continuously address the most relevant functional and non-functional requirements in most creative and effective way.

In part 3 to the series Standing Up For Agile, I’ll cover the criticism of agile methodologies as well as the emerging challenges in software development and how Agile can effectivley address them.

Tagged , , , , ,

Standing Up For Agile

The Techdoer Times is going global, Buenos Aires, Argentina to be exact.  I’ll be giving a presentation at the first ever Latin American conference on Agile Software Development Methodologies in late October.


It takes a lot of effort to be Agile, yet the whole notion of a conference dedicated to Agile software development first caused me to raise dubious questions over its continued importance.  Did the Agile movement only rebrand common elements that had already existed and should be part of any software development approach or did it pave the way for a new way of thinking about software development?  I’m sure I’m not the first software development practitioner who has tuned out to the nauseating hype and misguided support for Agile methodologies in recent years.  During this time, businesses and individuals used its popularity as a marketing tool to promote their reinvention and ability to keep up with the times.  It was only a matter of time before these organizations confronted the reality that stand up meetings alone couldn’t bring the success sought through Agile’s adoption.

Agile Manifesto

Seven years ago, the thought of teaching the benefits of Agile software development would have evoked real passion from me and perhaps many of you as well.  Back then, the The Agile Manifesto provided a much needed antidote to the fear that the dot-com collapse would also bring with it the return to less-empowering and less-effective software development approaches.

New Era of Software Delivery

The reality is that the Agile movement identified and continues to promote key elements that are extremely effective in this new era of software delivery.  This new era is defined by three key characteristics.  First, software delivery attracts a wider audience composed of creative and business disciplines not just the traditional engineering/management specialists.  Second, software standards and technology have evolved to permit rapid assembly and delivery of “mashups” as we’ve become accustomed to in the Web 2.0 world.  For better or worse, many non-internet related software schedules are held accountable to this standard.  Third, the historic failures of software projects remain fresh in the minds of practitioners.

Agile software development may have rebranded long-standing good software practices, but it also introduced many of its own, and more importantly, clearly communicated them to a wider audience.

This three part series will present the benefits delivered by Agile software development methodologies in recent years and suggest ways it can continue to address software development issues in the near future.   Part 2 will cover the importance of embracing change in the agile development lifecycle and part 3 will address the criticisms of agile development as well as restate the key elements of agile moving forward.

Tagged , , ,