Scrum doesn\u2019t mandate technical practices explicitly. Neither does kanban. Agile is a set of principles and practices, and it\u2019s often hard to choose which one are useful.<\/p>\n
There\u2019s 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\u2019s 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.<\/p>\n
The truth is that organizational and technical practices go hand in hand. Here\u2019s why.<\/p>\n
The term\u00a0agile<\/em>\u00a0was created by a group of people who met because they had in common the way they develop software. The processes they used were called \u201clightweight methods\u201d. They met in a mountain resort and ended up with\u00a0The Agile Manifesto<\/em>. The manifesto says nothing explicit about using technical practices. Here\u2019s a probable reason.<\/p>\n We\u2019ve gathered background information about a few of the authors:<\/p>\n 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.<\/p>\n These people found implicit that teams adopt technical practices to help with their agility<\/strong>. This is probably why they are not explicitly mentioned in the manifesto.<\/p>\n 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\u2019s a list of technical practices, most of them coming from\u00a0Extreme Programming<\/em>, and why they are useful:<\/p>\n Pair programming\u00a0<\/strong><\/p>\n Unit testing\u00a0<\/strong><\/p>\n Continuous refactoring\u00a0<\/strong><\/p>\n TDD (Test Driven Development<\/i>) or BDD (Behavior Driven Development<\/i>)\u00a0<\/strong><\/p>\n Design principles and design patterns\u00a0<\/strong><\/p>\n Architectural strategic thinking on the long term\u00a0<\/strong><\/p>\n Code review<\/strong><\/p>\n Static code analysis<\/strong><\/p>\n Let\u2019s 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\u2019s too late to change the software and build on solid ground by having everything tested in a sprint.<\/p>\n Yet something unexpected happens:\u00a0\u00a0your team\u2019s estimates are unreliable<\/strong>.<\/p>\n I will assume you\u2019re 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\u2019t link story points with time but with complexity or workload. Yet, estimates keep being unreliable. How can we estimate better?<\/p>\n 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\u2026 And that\u2019s where unit testing comes into play.<\/p>\n 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.<\/p>\n When you think of an agile transition, it\u2019s 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.<\/p>\n My advice is to ask people who\u2019ve been through agile transitions before making any decision and to choose wisely.<\/p>\n If you want to have clearer view about organizational aspects and technical practices, we can help with:<\/em><\/p>\n\n
Challenge: start an agile adoption without clear technical practices<\/h2>\n
\n
\n
\n
\n
\n
\n
\n
\n
An Example<\/h2>\n
Conclusion<\/h2>\n
\n