Scrum doesn’t mandate technical practices explicitly. Neither does kanban. Agile is a set of principles and practices, and it’s often hard to choose which one are useful.
There’s a reason to that. Scrum is not a process but a framework that you adapt to your context. Kanban is about introducing change, and it’s up to you to pick the practices that help with change. I often see this message got lost and people try to do Scrum or Kanban without considering the usefulness of technical practices.
The truth is that organizational and technical practices go hand in hand. Here’s why.
A bit of history
The term agile was created by a group of people who met because they had in common the way they develop software. The processes they used were called “lightweight methods”. They met in a mountain resort and ended up with The Agile Manifesto. The manifesto says nothing explicit about using technical practices. Here’s a probable reason.
We’ve gathered background information about a few of the authors:
- Mike Beedle – published articles about Object-Oriented Programming (OOP), patterns, reusing components and frameworks, 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 contributed to the creation of Extreme Programming(XP), created the software design method known as CRC and actively contributed to the patterns community Patterns Language of Programming (PLoP)
- Martin Fowler – well-known author on subjects like software design and refactoring
- Andrew Hunt – partner at the “Pragmatic Programmer” publishing house which produced lots of useful books for programmers and co-initiator of the Software Craft movement
- Ron Jeffries – consultant and programmer with a rich experience in Extreme Programming
- Jon Kern – OOP evangelist, starting from C++ and continuing with Java
- Brian Marick – tester and programmer, specialized in functional languages
- Robert C. Martin – well-known author of books about design and programming, main promoter of theSoftware Craft movement.
These are just a few of the names from the list of the authors. As you can see, each of them had a solid base in programming and practical experience with complex projects.
Challenge: start an agile adoption without clear technical practices
These people found implicit that teams adopt technical practices to help with their agility. This is probably why they are not explicitly mentioned in the manifesto.
Agile adoptions are difficult. You need all the tools you can get to be successful. Technical practices are important tools for minimizing waste and maximizing value, and you can use them to accelerate your transition. Here’s a list of technical practices, most of them coming from Extreme Programming, and why they are useful:
Pair programming
- prevent mistakes
- have a better and more flexible design
Unit testing
- shorten the time needed to validate the product
- significantly increase the safety of changing existing code
Continuous refactoring
- keep a flexible design
- minimize the cost of change
TDD (Test Driven Development) or BDD (Behavior Driven Development)
- better definition of the problem
- finding simpler solutions
Design principles and design patterns
- keep the application open for changes
- have a clear guide of developing new features
Architectural strategic thinking on the long term
- minimize technical and development risks
- have a clear top level vision about the product
Code review
- minimize the number of bugs
- enforce the clean code rules
- make sure the coding guidelines are applied
Static code analysis
- keep code complexity under control
- have a top view of SOLID principles usage
An Example
Let’s say you need to release your software every 3 months. You adopt Scrum hoping that you can focus on smaller features, help the customer change their mind before it’s too late to change the software and build on solid ground by having everything tested in a sprint.
Yet something unexpected happens: your team’s estimates are unreliable.
I will assume you’re doing everything perfectly: the product owner prepares the user stories until they follow the definition of ready, the team is using planning poker with story points and team members don’t link story points with time but with complexity or workload. Yet, estimates keep being unreliable. How can we estimate better?
One very common cause is that your team is afraid to change the code. The software design is either fragile (changing in one place breaks completely unrelated and unexpected other places) or rigid (making a simple change requires changes in hundreds of files). How can they overcome the fear? If only they could know in a matter of minutes if the software is still functioning well… And that’s where unit testing comes into play.
This is just one example of how technical practices help your effort towards agility. From our experience coaching teams on their path to agility, technical practices often make the difference between a successful and so-and-so agile adoption.
Conclusion
When you think of an agile transition, it’s important to consider both organizational and technical practices. They go hand in hand and the ideal way to start is to understand which ones can help you. Overlooking one of them can lead to partial success or failure.
My advice is to ask people who’ve been through agile transitions before making any decision and to choose wisely.
If you want to have clearer view about organizational aspects and technical practices, we can help with:
An Assessment of the team, projects organisation and Technical Aspects.
Learn more about technical practices at the
- Legacy Code Retreat workshop, also available in-company
- Unit Testing Core Practices workshop, also available in-company
- Test Driven Development workshop, also available in-company
Let us know and we will create a customized package for your needs.
Image credit: http://upload.wikimedia.org/wikipedia/commons/b/b7/IBM402plugboard.Shrigley.wireside.jpg
