This article was published first in Today Software Magazine, no 16. Below it’s the full version. The authors are Alexandru Bolboaca and Adrian Bolboaca.
In 2001, a group of people unpleased about the state of software development gathered in a mountain ski resort from Utah. One thing leading to another, they started discussing about the industrial methods applied at the time for managing programmers and about the so-called lightweight methods many of them used informally. The result of this meeting, as you probably know, was The Agile Manifesto.
The conversations about The Agile Manifesto focus usually on the content. But, what can we say about the authors?
The Authors of The Agile Manifesto
- Mike Beedle – published articles about Object-Oriented Programming (OOP), patterns, reusing components and frame- works, programming languages, etc.
- Ward Cunningham – was Principal Engineer at Tektronix, the company that created Smalltalk, the first object oriented language used on a large scale. He was part of the creation of Extreme Programming (XP), created the software design method with CRC and actively contributed to the patterns community Patterns Language of Program- ming (PLoP)
- Martin Fowler – well-known author on subjects like software design and refactoring
- Andrew Hunt – partner at the “Pragmatic Programmer” publishing house which gave us a lot of useful books for programmers and co-initiator of the Software Craft movement
- Ron Jeffries – consultant and program- mer with a very rich experience in Extreme Programming
- Jon Kern – evangelist OOP, starting with C++ and continuing with Java focus usually on the content.
- Brian Marick – tester and programmer, specialized in functional languages
- Robert C. Martin–well-known author of books about design and programming, promoted of the Software Craft movement.
These are just a few of the names from the list of the authors. What we can observe is that each one of them had a solid base in programming, as well on very complex projects.
Scrum and Extreme Programming
Today agile is often considered a synonym of Scrum, being the most spread agile method. And this for a good reason: Scrum can improve the productivity of a team in a fundamental way. But if we were to compare Scrum with Extreme Programming, we will see something interesting.
The way to work in Scrum and XP is very similar. The roles and structure of a sprint are better defined in Scrum than XP. But the major difference between them consists of the fact tha XP required a set of technical practices, from collective code ownership, continuous integration, coding standards to pair programming, refactoring, TDD and simple design. The reason is simple and correct: Scrum wanted to combine the set of agile practices that can be applied to any type of knowledge work. This is why Scrum lets for the team to decide the practices they will use in order to deliver quality software during each sprint.
As Ken Schwaber said at the OpenAgile 2009 Bucharest Conference, “Scrum has its bases on craft”, may it be in software, marketing or creating a radio show. The set of technical practices changes depending on the type of work.
Why You Need Technical Practices
The companies that choose to adopt Scrum pass through a couple of stages. First of all the team is created. Then the plan and the current status are made visible. A few of things can happen from now on:
- The team does not know how to work incrementally, as a result stories that cannot be finished during a sprint appear. One needs to improve the way of doing story slicing.
- The development ends during the sprint, but there is not enough time for testing. The testing moves to another sprint (or sprints). One needs to do cross testing, pairing between programmers and testers and automate tests.
- Stories are generally developed and tested during the sprint, but putting them in production lasts a lot and reduces significantly the development speed. One needs to implement continuous integration to incrementally automate the deployment.
- The development speed increases, stabilized, but one story changes fundamentally part of the application design and all lasts more than a sprint. One needs to do refactoring and a better design that follows the SOLID principles.
- If the application is developed for a more complex environment, usually enterprise, some changes are very hard to be split in stories that fit inside a sprint. Sometimes this is a sign of architectural debt, and one needs to think about architecture on medium and long term.
Here is how agility implies applying some practices like:
- Pair programming to prevent mistakes and having a better and more flexible design
- Unit testing to shorten the time needed to validate the product
- Continuous refactoring to keep a flexible design
- TDD (Test Driven Development) or BDD (Behavior Driven Development) for a better definition of the problem and finding simpler solutions
- Following some design principles and using design patterns to keep the application open for changes
- Architectural strategic thinking on the long term to minimize technical and development risks
Even more, agility implies that all the members of a team, may they be testers, programmers, designers, business analysts continuously learn new methods to work better together, with respect to the impediments they meet. This thing implies either planning learning sessions during a spring or learning inside communities of practice.
Agility implies Craft
This is software craft: the combination between the practices that help in a pragmatical way to bring faster and more efficiently business value and continuous personal development inside a community of people having the same values. Agility implies craft, because there is no other way.
Do not understand from here that the Scrum approach is wrong. Quite the opposite, it allows an incremental adoption of technical practices that are helpful in a given context. A situation where you need to release once every 6 months because the customers do not want more releases (typical examples being hospitals or banks) is very different from the situation when you need to 15 releases per day like the web applications for consumers often need.
The selection of technical practices depends fundamentally on wanted level of agility. Those that started on this road can find themselves or they can ask for help from an expert in order to learn faster.
Conclusion
In conclusion, the technical practices have been forever part of agile. Scrum eliminated them from the model, not because they are not useful, but because it wanted to be more generic and because it is based on the team to select the ones that make sense in the given context. But agility is impossible to reach without a set of technical practices on which one can add organization and finally business agility.
