Agile Challenge: Adopting Technical Practices

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