This post builds upon the knowledge of Org Topologies™. Last week I was invited to give a lecture at the Free University of Amsterdam at the faculty for Digital Business Innovation. I consider it a real honor to teach the students of a University. The lecture triggered many thoughts about the relevance of teaching Agile/Scrum.
The lag in mainstream education
I received some papers in advance by the professor to get me up to speed on the subjects at hand. The first paper was a 2012 study on the tensions with remote (off-shoring) teams (Ramesh et al Ambidexterity in Agile Development ISR2012). By now we are 10 years on and we know that “buying hands” in a low-wage country doesn’t work that well. The second paper was more recent and interesting. It dealt with the tensions surrounding the issue of dev-ops. Of course, it is only a very small part of the educational program I am experiencing, but still…
The themes covered here on Scrum and Agile are not current in daily practice. It confirmed my preconception that regular education struggles to keep up with developments in our field. This is not surprising, considering that the “time to market” of a university paper is several years.
Studying the software development industry through the lens of scientific papers is a history lesson.
Young people at university have some idea about what “Agile” and “Scrum” is. They know the theory, and they have had a couple of chances to get some hands-on experience while doing an assignment or two during their studies. One might wonder how constructive that has been for learning true Scrum and Agile. What my student children (and some of their fellow students) tell me, is that in general a couple of driven team members get into conflict really fast with the more “lazy” types and then try to finish things with as little irritation as fast as possible. Not exactly the best Agile experience.
It is difficult, if not impossible to teach Scrum to students at a college or a university. Scrum and Agile need to be learned experientially. In general, there is insufficient Agile knowledge among the teachers. Even in institutions where they teach (software) development. I raised this subject at a Business School a few years ago. They acknowledged this and agreed to work with me to learn about Scrum by doing. They invited me to coach the teachers group responsible for developing the new curriculum. It was a tough ride. Teachers and supporting staff are a very deep Y0 environment: Single-skill specialists, who first need to develop a complete plan and a design before going into the phase to deliver the product. Clearly, there will be a few teachers with sufficient hands-on experience with Agile somewhere. But not at this school.
Teachers are expected at many schools to teach Scrum and Agile without having any practical experience, let alone certification. If you don’t know about something you should not teach it. Agile/Scrum is maybe underrated and seems easy enough to throw it in the mix as a teacher. But this is not true. But frankly, graduating young adults who know absolutely nothing about Agile is not an option either.
Teachers
Don’t teach Agile if you don’t have the proper professional certification. Ask a Professional Scrum Trainer to teach the classes in question. There are hundreds of them. You can find them at Scrum.org
Learning by doing
Most people’s first encounter with Agile is at work. They are working in a department where an Agile Transformation is underway, or they have been hired at a company where they are placed on a Scrum Team. Even though we are underway with Agile for about 20 years now, chances are high that these people’s first encounter with Agile is in a dysfunctional environment. In most teams and companies are ecosystems of the lower Archetypes. Hopeful yet entangled teams (A2). The chance that someone who has no Agile experience will learn proper Agile in such an environment is low. The chance that a newcomer will start in a high-performing Agile organization and be able to learn from a good example there is virtually zero. The chances of learning the wrong principles and practices are many, many times greater. This is a huge problem.
Lack of knowledge
The root cause for poor Agile implementations is the lack of Agile knowledge. We do not adapt our old habits, processes, and patterns remain unchanged, the focus is on a new way of working, processes for control and reporting are not adapted, and so on. Take a look at the following model. It is an overview that helps you see the implication areas of change. A product development organization is a complex adaptive system. Change needs to be systemic to be sustainable. Changing only one part of this system will not optimize the whole system. Each of the elements needs to change so that they are all congruent, or in harmony with each other. We use this model as a centerpiece to discuss transformations in our COTP1 training.
Managers
Managers are extremely busy. They spend long days back-to-back in meetings. That is inhumane, isn’t it? A lot of the “work” done is not very meaningful. Mostly, managers optimize for “their” department. This does not necessarily contribute to the purpose of the organization as a whole. In most companies, the manager owns some application, system, or other narrowly defined responsibility. They get KPIs and OKRs and have to make sure “it gets taken care of” (in a cost-efficient way). And managers manage, so they task others to make it so.
Organizations of the higher Archetypes free managers from this kind of work. That is because the people who make the product are able to solve more complex customer problems themselves without the intervention of a manager. Especially in the higher archetypes, there is a need for managers to deal with important matters such as determining what the group should best be working on (set priorities) and creating the right conditions for the people to do the work (education among others). Applying the micro-management required for the Y archetype to function, becomes counter-productive in the A-level and higher archetypes.
Scrum Masters
Scrum Masters were identified as the new leaders at the time when Agile was introduced. The new Servant leaders. Unfortunately, this did not happen according to plan. Scrum Masters usually do not fulfill the role they should. To remove any misunderstandings about this role: There are three main areas of attention clogged together in the role of the Scrum master:
- Establish and sustain a well-functioning team.
- Ensure that value prioritization can be done properly (supporting the PO).
- Take care of systemically changing the whole organization, creating an Agile environment by adjusting (or having adjusted) organizational elements that hinder empirical product development.
In many cases, Scrum Masters lack the right knowledge and experience. Too often Scrum Masters do not have solid training or certification. And there are those who “just don’t have what it takes” to be a Scrum Master. And finally, there are those who “have to do it on the side”. Even though this practice is mentioned in the latest version of the Scrum guide, I say: Don’t do this! Don’t combine the role of Scrum Master with any other role! It is a bad choice that leads to a loss of focus and transparency.
As Scrum asks of us, we must apply the principles of Transparency, Inspection, and Adaptation to ourselves as well. Scrum Masters can make or break a company. By fulfilling the role without proper the required knowledge, you undermine the empirical process of continuous improvement. You should be aware that the role of the Scrum Master is essential to the company’s ability to stay relevant to the customer in the long run.
I propose these suggestions for improvement:
- Training institutes start experiencing Agile by working within their teams.
- Training institutes employ professionals to teach Scrum/Agile.
- Executives join software development teams to participate as team members (aka Gemba Sprints).
- Managers add the tool “continuous organizational design” to their toolbox (i.e.: learn to use Org Topologies™).
- Managers establish the Scrum Master role and make sure people are properly trained to increase their chances of success.
- Managers only deploy Scrum Masters full time and Scrum Masters do not accept multiple roles.
- Scrum Masters inspect themselves and decide if they contribute to systemic improvements with empirical process control. If not, find another role or get educated.
Get introduced to Org Topologies™: Self-paced video training.
Matching song to listen while reading: another brick in the wall – pink floyd
© 2023 Roland Flemm