Beyond Scaling Agile - Going Back to the Basics
|Francois Desrosiers in Agile Tuesday, August 16, 2016|
It has now been 15 years since the Agile manifesto has come to life. The first decade of Agile showed a strong adoption of engineering practices and Scrum, demonstrating Agile was a viable approach at the team level to deliver business value.
The last 5 years have seen a shift, focusing on scaling Agile at the IT department or even the whole organization. Solutions like SAFe, LeSS, DAD and Nexus are proposing their own ways of scaling Agile beyond the development team. And just Last May, the “Embracing Agile” article published in the Harvard Business Review revealed how Agile values and principles are spreading across a broad range of industries.
It has been great to see Agile go from a grassroots movement to a strategic objective so companies can stay competitive in their industry. While the conversation about Agile moved from the team to management, are we forgetting the core values at the heart of software development? Do we still have in mind how the development team stays at the center of Agile?
We strongly believe first and foremost that the development team is the engine in your car, the core of your organization/department which produces value. Having been developers early in our careers, we had the opportunity to be part of great teams. To fuel such an engine of growth, cultivating a passion to write beautiful code is essential.
We believe team members should have fun writing code together, sharing ideas and challenging each other in front of a whiteboard. Developers are problem solvers. Give them challenges to solve and they’ll do their best. That’s what we did best when we were in front of our screen and we still believe in this.
Another key factor at the core of our engine is technical excellence. Developers like to learn and we should offer them opportunities to become better at their profession. We should challenge them to take them out of their comfort zone. We would be surprised by the innovations they can bring.
While frameworks, libraries and tooling can add additional horsepower to your engine, we believe technology will not solve your team performance. Believe in them to get better, to master their craft. Cultivating a culture of excellence is not magically fixed when we choose a scaled Agile framework. It’s something you do day after day after day.
Just like the check engine light in your car’s dashboard, development teams should have access to such a dashboard to check the quality of their own work. Are the code metrics all green? What is the state of their build server? How many tests have failed in the latest build? These indicators build confidence within the team. They have built quality into the product.
There should also be lights about customer satisfaction. Are the latest features in production being used? What are the tools in place to measure which parts of the application are the most (and least) used? We believe that a developer is motivated when he knows his software is used and wanted. It gives him a purpose, a motivation to make it better. We think we should provide this feedback to the team so they can feel energized and motivated around making users happy.
Software initiatives nowadays are global where the focus on a well-oiled-up delivery train is essential. To stay competitive, organization will leverage enterprise Agility across their business units to stay competitive on the market. We only hope those scaling programs will not kill the core essence of software development where collaboration, team work, purpose, technical excellence, autonomy and built-in quality minimize friction in your supercharged engine of growth.
If you would like to learn more about Scrum, find Scrum training or take a Professional Scrum certification assessment you can visit Scrum.org.
If you have questions on the topic or want to contact either of us, you can email Francois or Louis-Philippe.
Read more: https://www.scrum.org/
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.