“They were always energized by the mind-boggling challenge of how to make the product better”, says Patrick Steyaert, their coach. This consistent commitment to continuous improvement at all levels is a testament to the character of Nemetschek Scia before a poorly implemented Scrum was introduced. Unfortunately, such poor implementations of Scrum are common. The acts of leadership the engineering team had demonstrated before their Scrum stifled them is sad.
In many of today’s ‘Agile Transformations’, I commonly find poor implementations of Scrum that discourage acts of leadership. In the name of collaboration, empowerment is replaced with suffocating boundaries and ceremony noise that limit healthy problem solving and innovation. Nemetschek Scia’s story underscores for us the importance of leadership and the necessity of respecting both people and the nature of knowledge work.
Nemetschek Scia’s story is a Scrumban story. I’ve documented in Scrumban [R]Evolution, Addison Wesley, that Scrumban has itself evolved to become a family of principles and practices that create complementary capabilities unique from both Scrum and the Kanban Method. These capabilities have led to distinct manifestations. One such distinction is as a framework that helps teams and organizations develop their own set of processes and practices that work best for them — not to accommodate inadequacies and dysfunctions Scrum exposes, but to resolve them in a manner that is most effective for their unique environment.
The intent at Nemetschek to create a cadence of faster delivery cycles with higher quality is a good one and one that Scrum promises and in some cases delivers; however with it often is sacrificed the respect for nature of work (how long something may take to build) in a way that mitigates risk not just from a technical standpoint, but also from a customer and market standpoint. Such risks are often hidden, but known by the people who do the work. Localizing the product owner role has often had disastrous consequences. It’s a high calling. You are called to know the market, forecast relative ‘priority’ often with no respect to the cost of delay, be a servant leader and extract as well as understand intelligence generated from the team and decide on the relative priorities of work, attend ceremonies, review work, answer questions and much more. It calls for competence in understanding the market, leading people, managing work- all in in one person! It’s one that the best of people may fall short on. I think at least a few of the inadequacies of Scrum can be attributed to this call from Scrum to localize such a role.
Often organizations engage in implantation of ‘Agile Transformations’ buying the promise of faster delivery cycles and improved quality without sufficient consideration to what that does to their workforce. The story of Nemetschek Scia’s should serve as an ample warning regarding the risks of the large disruptive changes that do not consider the way people learn. One of the problems created was the destruction of the team’s identity by implementing Scrum in 2005. Their ‘tribe’ was disrupted. Scrum was introduced in a way that causes a schism to develop. There is safe way to introduce Scrum with Scrumban.
Kanban is really simple. Visualization in itself solves many problems even as the team Nemetschek realized. The limiting of work in progress is an important tool that helps balance demand and capacity. As a Scrumban practitioner and advocate, this or any of the other Kanban practices, principles, agendas, and values of the Kanban method are a perfect compliment to Scrum. In fact, they actually help the team amplify Scrum using the Kanban method to maximize the benefits while balancing the serviceability agenda with the survivability and sustainability agendas via the values the Kanban method espouses.
Often complaints are leveled that teams practicing the Kanban method owing to no structured process may have little discipline. Such an accusation comes from an inadequate understanding of what the Kanban method is. In fact, if anything, the accountability of a Kanban team owing to its values, principles and practices, is greater.
The competent team at Nemetschek owning the outcome of the project lead to a better understanding of the risks of their project. The understanding of their risks lead them to act accordingly and drive the right outcomes for their project. It was worthy to note the presence of a dedicated person helping manage the flow.
Lastly, success is really remembered and enjoyed if and when a team’s way of working can produce results consistently. This is what the team at Nemetschek has done with the employment of Scrumban.