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.”