Being Agile is more than just Scrum or not being waterfall.

Being Agile is more than just Scrum or not being waterfall.

If you were a developer from the 1980s or early 1990’s and traveled in time to attend most Agile conferences today, you would probably take away the idea that Agile was all about Scrum and kicking sand at project managers. Unfortunately MANY organizations have same stilted perception. The perception that Agile is just another form of project management is EXACTLY wrong. If an organization only embraces the parts of Agile that address team organization and project control they are not truly Agile. In order to deliver the most value from adopting and embracing Agile, organizations and teams must understand and adopt Agile technical practices. Just doing Scrum is not going to cut it if your goal is improving the quantity and quality of functional software you deliver.

Tools, processes and techniques that facilitate the development, testing and implementation of functional software are technical practices. A very abridged list of technical practices includes:

  • User Stories
  • Story Mapping
  • Test Driven Development (including variants such as Behavior Driven Development)
  • Architecture
  • Technical Standards (including Coding Standards)
  • Refactoring
  • Automated Testing
  • Pair Programming
  • Continuous Integration

Implementing a combination of Scrum with Extreme Programming (xP) is one of the most common methods of addressing both the technical and management/control aspects of delivering functional software. xP is an Agile software development methodology originally conceived by Kent Beck and others in late 1990’s. There are many other techniques, frameworks and methodologies that support the technical side of Agile. These techniques directly impact how effectively and efficiently solutions are designed, coded and tested. As importantly efficiency directly impacts the amount of value that is possible to deliver.

You Are Not Agile . . . If You Do Waterfall described some of the attributes of organizations that get stuck transitioning to Agile from a process point of view. Similarly, many organizations begin an Agile transition by adopting Scrum perhaps with a few techniques such as User Stories; however, they never quite get to addressing the technical components. The issues of the business analysts, developers and testers don’t get addressed.

Allan Kelly, in an interview on the Software Process and Measurement Cast 353, stated that if you are not “doing” the technical side of Agile, you were not Agile. This statement is probably somewhat of a harsh assessment and perhaps a bit hyperbolic, but only a bit. Developing, enhancing and maintaining software (or any product) requires more than short iterations, stand-ups, retrospectives and demonstrations. Far be it from me to say those techniques don’t help and even alone are certainly better than most waterfall practices, but they do not address the nuts and bolts of developing software.  In order to deliver the maximum value we have to change how we are developing designs, writing code and then proving that it works because that is the true heart and soul of software development.

In the long run Agile has to address management buy in, changing the whole development life cycle or and the technical practices, or you won’t get the whole value that Agile can deliver.

I would be interested in your thoughts!