Posted on July 8, 2016
by Doug Klugh

There is more to Agile than estimating stories, collaborating with customers, and showing working software.  Agile is also about technical excellence.  And this is where many Agile teams drop the ball.  All too often, teams focus too much on process and not enough on technical practices.  If the effort, complexity, and risk is too great for your team to extend and maintain their software, they will struggle to deliver functionality to their customers at the end of each iteration.  They will struggle to deliver working software as promised.

Don’t get me wrong, process is important.  It is needed to propagate best practices consistently among team members and across teams.  But if it takes more than an iteration to extend simple functionality within your application or service, you will not fully realize the value of Agile.  This is one reason why methodologies such as eXtreme Programming (XP) have worked so well with Agile methods.  XP advocates technical practices that help teams test early and often through test driven development (TDD), improve quality through pair programming (PP), develop features just in time (JIT), and deploy frequent releases through continuous integration (CI).  Software engineering principles, such as the SOLID principles, help to build software that is easily extensible, maintainable, and testable.  There is no way around it…  To grow into a mature Agile team, your software must be easily extensible (see Agility with OCP).

Principles Conceived by Techies

When Agile was conceived in February 2001, it was the product of 17 programmers and software engineers, leaders in the software industry, discussing better ways to develop software.  During this two-day meeting-of-the-minds, Kent Beck proposed that the goal for Agile should be to “Heal the divide between business and programming.”  And as Uncle Bob Martin (a co-author of the Agile Manifesto) would agree, this effort has failed.  Some believe, including Uncle Bob, that the divide between business and programming has actually grown.  Somewhere along the line, Agile has become less of a technical movement and more of a project management track.  And while business people and project managers lack technical expertise, Agile has become less about technical excellence, despite the intentions of those 17 authors of the Agile Manifesto.

Ever since started the Scrum Master Certification program, the vast majority of people who have participated in that program have been project managers.  And interestingly enough, Scrum Master Certification classes do not cover technical practices.  While this certification program has helped launch the popularity of Agile, it also helped to further divide the business people and the techies.

So where is the technical discipline?  Where are the programmers?  If you attend any of the major Agile conferences, you will find very few programmers.  And there are very few, if any, technical tracks.  What you will find is a lot of business people and a lot of project managers.  This craftsmanship movement, known as Agile, has dramatically shifted towards project management.  And this shift has spawned the Software Craftsmanship movement in an attempt to foster professional software development practices.

Without technical disciplines, Scrum becomes what Martin Fowler (another co-author of the Agile Manifesto) has coined as Flaccid Scrum.  This occurs when progress is hindered by the lack of technical excellence; when a team struggles to extend software quickly or when technical debt is inhibiting progress.  As Uncle Bob Martin says “Scrum without technical practices becomes an efficient business discipline coupled to an undisciplined engineering team and very rapidly causes a mess to be made.”

Conclusion

My 10+ years as an Agile Coach has shown me that most Scrum Masters have little, if any, experience in software engineering.  Not just in programming or software development, but in software engineering.  And for a Scrum Master to facilitate the adoption of technical practices that are required for a mature Agile team, they must have the knowledge and experience of applying software development techniques and software engineering practices.  Facilitating changes in process is a very important part of being a Scrum Master; but he/she needs to be just as effective in facilitating technical excellence.
Tags:
Agile Ken Schwaber Martin Fowler Scrum Scrum Master software engineering SOLID team Uncle Bob Xtreme Programming (XP)

Doug Klugh

Doug is an experienced software development leader, engineer, and craftsman having delivered consumer and enterprise firmware/software solutions servicing more than one billion users through 20+ years of leadership.

Similar Articles


subject Article

Managing Technical Debt

The manner in which technical debt is managed can give a company a competitive advantage when it’s most needed or destroy a well conceived product.  When incurred properly, technical debt can greatly decrease time to market, providing a short-term advantage over the competition.  But if that debt is not paid off quickly, it will slowly, yet surely, erode the quality and the value of your software.

Read More
subject Article

Planning for Failure

Quality software is built around the expectation of failure.  To deliver reliable software, you must always plan on things breaking.  In designing and building software for critical systems, such as air traffic control or nuclear power plants, runtime reliability is absolutely critical.  And while human life may not hang in the balance of a business application, the life of the business may.

Read More
subject Article

Conducting the Technical Interview

With a shortage of technical talent, many of us are competing to find and hire the few technical rock stars out there.  And among those rock stars is a lot of mediocre talent trying to capitalize in a very good job market.  It’s hard to blame them for wanting a slice of the pie, but as leaders, we need to wade through the mediocrities to find those who can effectively support our development goals.

Read More