What Does Technical Agility Actually Mean?
Technical agility, synonymous with lightweight system development or product development, revolves around the ability to easily and risk-freely adapt and change course when obstacles arise or when new information necessitates a change. Agility fundamentally addresses the fact that we will make mistakes, we will be wrong, and uncertainty is inherent in the industry we operate in. Even tech giants like Google, Microsoft, and even the iconic Steve Jobs have occasionally been wrong in their predictions – we will be too. Technical agility provides us with the means to handle errors and swiftly change direction based on experience and feedback. Learning from our mistakes is fundamental in system development – what we do is, by definition, innovation; we cannot develop the next product in the exact same way as the previous one.
Advantages of Technical Agility
A technical Agile approach streamlines development cycles and enables faster user feedback. By following short development cycles, often referred to as sprints, the opportunity to adapt and improve the product quickly is created. Compare this to the traditional waterfall process where work is carried out sequentially, potentially prolonging the time to product launch. Feedback – genuine feedback from actual users – arrives at the end, when it is most challenging and costly to act upon.
From Waterfall to Agile – No Hybrids
In the traditional waterfall approach, requirements specification, development, and testing occur sequentially. In contrast, the Agile approach emphasizes collaboration and iteration. Short development cycles allow for continual adjustment of requirements and direction, with a focus on creating value at each step. Collaboration among different team competencies avoids bottlenecks and enhances communication between stakeholders, developers, and quality assurance.
The most common misconception is that a hybrid approach works. My favorite response to this notion is: “You cannot drive a little on the right and a little on the left and hope to reap the benefits of both.” It always costs more than it’s worth to work that way. It’s better to decide on a way of working and then accept the consequences: if you feel the need to use “big design up front” and release the product in large chunks, you can at least optimize for that, rather than pretending to be somewhat Agile on the side. Running two methods in parallel doubles the administration and essentially eliminates all advantages.
Tips for a Smooth Agile Start
- Begin with Technical Agility: Before pursuing a comprehensive Agile transformation, it’s crucial to ensure that your technical development competence is in place. Quality and speed are foundational.
- Start Small: Introduce changes gradually and begin by applying agility to small projects or parts of your work. This allows for learning and adjustments along the way.
- Focus on Value: Identifying the highest priority and most value-generating work is critical. The Rule of One – one week, one task, one team – can help maintain focus. It’s challenging – very challenging – but that’s precisely why it can give you an advantage over competitors.
- Challenge Dependencies: Build organizations around value streams rather than technology or functions. Minimize dependencies between teams and facilitate rapid feedback.
- Test: When you start testing, you discover where it hurts. The reason Agile transformations fail is often due to trying to figure things out and roll them out instead of testing. Test the product with actual users, test the approach with actual employees, and LISTEN TO THEIR FEEDBACK. If users dislike your idea, it’s a bad idea.
- Learn from Mistakes: Agility embraces uncertainty and errors. The lessons learned from failures are a valuable resource to guide you in the future.
Standards and Frameworks for Technical Agility
Within technical agility, there are relatively few widely adopted standards and frameworks. However, here are some examples:
- Extreme Programming (XP): A collection of technical practices that promote quality and flexibility in technical development. XP includes methods like pair programming and test-driven development to ensure quality and flexibility.
- Kanban: A visual tool that helps visualize workflow and manage tasks. It facilitates prioritization and identifies bottlenecks in the development process.
- DevOps: A methodology that combines development and operations to create a seamless process from coding to deployment. The sooner you can get your code into a production-like environment, the sooner you can get feedback.
- Scrum: The most widely adopted framework in Agile project development, focusing on short development cycles and collaboration within the team.
A Practical Analogy: Creating Value in the Development Process
Let’s illustrate the importance of creating value by looking at an everyday analogy. Imagine a group of people collaborating to cook dinner together. One person is a master at making sauces, but in the middle of the process, they notice that the meat is burning in the pan. If one gets stuck focusing solely on their task, they might reason, “I’m not good at frying meat; someone else must be better at it, and this is their problem.” But what kind of dinner does that lead to? Regardless of how great the sauce is, it won’t compensate for the fact that the meat is burnt.
This analogy mirrors the core of agility. In the development process, it’s not just about being a specialist in a particular task; it’s about being aware of the entire process and taking action when necessary. Creating value is key. If we already have enough sauce for dinner, there’s no point in making more. Instead, we consider what we can do to contribute to the final outcome: in this case, what’s needed to make the dinner as delicious as possible.
The challenge lies in both the organization and the users being willing to embrace this way of working. Many organizations have an inherent tendency to try to control everything in advance, and it’s seen as better to do nothing at all (but have very good time reporting on what hasn’t been done) than to do something that might go wrong but generates insights into what might be right in the future.
This is where the earlier cooking analogy becomes so apt. Just like in cooking, it’s not just the quantity that matters; it’s the quality of each component and how they interact that creates the perfect result. By following a good recipe, tasting, and receiving feedback, we can continue to improve and adapt our products to best meet our users’ needs.
Would you like to learn more about technical agility?
We offer several courses on various Agile ways of working. Check out Consid’s courses.
