Over the years we have worked with several software companies that use Scrum alongside Parmatur Pulse. Recently SAFe has also appeared in some discussions with potential customers as an alternative to Parmatur Pulse. I can now see the same problems in all these Scrum-companies. These are problems we have never encountered with Parmatur Pulse. It has made me dig deeper and compile my own conclusions and opinions. What is happening in the companies that use Scrum and why has SAFe appeared on the scene?
“You are not supposed to feel safe in product development. It’s your job as engineers to deal with uncertainty and risks involved.”
In Scrum, various competencies needed to develop functionality are co-located, such as software developers, testers and engineers. Over time, the Scrum teams have become permanent, based on the Scrum recommendation and maybe also convenience. If you put a group of people together it will be difficult to after some time move someone out. And people who work in permanent and self-organizing teams usually enjoy it. But the teams are small and their deliveries thus become vertical slices of functionality, not an integrated product.
Problems with organizing development work in this way will become apparent after a while. With vertical slices of functionality, the team will preferably work with incremental product development. They add functionality to their existing code. Stories can be broken down into tasks by a product owner and be put into a task management system, where team members will pick their next task without having to communicate with each other. Everyone then knows what needs to be done. This may sound great, but it means that the same product will be invented time and time again (incremental improvements and product care). How much new value does this create for the company?
Self-organization has great advantages, it creates the opportunity to focus the efforts in a group. But there is a back side. It is difficult for any outsider to influence what the team focuses on; they easily create their own agenda. There may also be strong peer pressure on people who are deviant. Tight teams also risk stirring conflicts between teams, especially perhaps between hardware and software that may find it hard to understand each other’s conditions. The conformational pressure also causes the group to over time lose their ability to think creatively outside the box. They will then no longer be able to work with anything else than incremental development.
Over time, a rigid organizational structure has been created by introducing Scrum teams, which through their ability to organize themselves have been given a very strong position in the company. At the same time, many businesses have not worked enough on overall strategies and architecture. And in larger organizations, there is a gap between management and developers. This means that the strategies formulated by the managers will not be put into action. We recently encountered a number of companies working with Scrum, which testify to significant problems with their architecture.
In complex products with both software and hardware, integration of the complete product will be a challenge. When working with Scrum, integration and release are lost as each Scrum team delivers a slice of functionality. These are similar problems as when the waterfall models put the work with production ramp-up at the end of the flow. That is, errors and deficiencies are detected when it is too late.
Scrum seems to have caused severe damage to some companies. Perhaps even the understanding of what product development really is has been lost. No one has the experience of making prototypes for completely new products anymore. Product development resources are spent on continuous improvements, not continuous innovations. The profit is on decline.
It is easy to understand that corporate management is now forced to act. Can SAFe be a solution? My answer is – NO! SAFe is not safe. What SAFe does is reinventing the line organization based on the permanent Scrum teams, introducing more middle managers in new roles and on top of that adding on a lot of bureaucracy. Then we are back where we started, with communication problems between the engineers and very slow moving product development.
Who can be satisfied with a SAFe solution? Maybe the Scrum teams who don’t actually need to change their way of working, at least initially before the control mechanisms of a bureaucratic system strikes. However, the root causes of the acute problems in the business have not been solved.
The founders of Scrum were inspired by an article in the Harvard Business Review 1986. Now is the time to go back to the sources and see what the researchers actually recommended based on their research. We have to shape “The NEW New New Product Development Game”, to break down the rigid structures that have set over time with Scrum and that is being carved out still deeper with SAFe.
The researchers pointed to six characteristics of successful product development.
Built-in instability. The management gives the projects a great deal of freedom but they also give them challenging goals. That work is done in projects is taken for granted in this article. People are brought together temporarily to solve a challenging task. Instability doesn’t exist in permanent teams.
Overlapping development phases. The projects deliver complete solutions and take the product all the way to the customer (not a slice of functionality to be fitted in later). The group utilizes the tensions and conflicts that arise between widely differing skills to come up with new solutions.
Self-organizing team interacting closely together. The group is driven to a point where all existing solutions are questioned. The project team is forced to rethink in order to make major breakthroughs.
Multi-learning arises from close collaboration between people who have different skills and who have not previously worked together.
Transfer learning. Here, the authors point to the risk of transferring words of wisdom through standardized processes based on successful historical examples. It only works in a business that has a stable environment and weak competition. Re-learning is often more important for success in product development. Non-experts should be used instead of groups with a high level of specialist expertise.
Non-experts are encouraged to acquire the knowledge and skills they need by working on the tasks. Unlike the experts who hate mistakes, beginners will be willing to take risks and challenge the status quo.
Subtle control. The projects are set up to be semi-autonomous. Management avoids the rigid control that is found in a bureaucratic stage gate model.Communication between projects and managers is handled through frequent meetings.
So why doesn’t Parmatur Pulse get the problems Scrum is facing?
Firstly, Parmatur Pulse projects are staffed by people moving to the task. This creates built-in instability, transfer learning and multi-learning. The projects deliver complete products that are often also industrialized based on a plan with overlapping phases.
Secondly, Parmatur Pulse is based on the fact that the management is constantly working on strategic direction and strategic design, which drives all development work in projects and assignments and provides challenging goals. The goals force the project teams to work closely together and rethink existing solutions.
Thirdly, frequent visualized pulse meetings are held in the pulse room for all strategic and operational work. That will speed up information sharing and decision making so that you immediately can correct the focus of all work. The manager has control, but in a subtle way.
And fourthly, we use mainly non-experts in the projects. Experts are better used as mentors, product managers and to develop the overall architecture of the product.
Conclusions – SAFe is not safe
The main problem with Scrum is the idea of permanent teams responsible for their part of an existing solution. These teams are over time affected by group thinking where new ideas are inhibited. Group thinking also makes it difficult for management to focus the development work on new innovative products.
In order to handle this situation, SAFe has been developed. But SAFe is a solution to a symptom. The problem is found in Scrum. The solution is not to get rid of Scrum, but to change the how it is used. The idea of permanent teams has to go.
The work done on management level on continuously developing and adapting the strategic direction and design is crucial for success. In Parmatur Pulse strategic work is strongly connected to product development and facilitated through pulse meetings and visualization.
You can use a Scrum-like approach at the management level. Toyota and Scania started using it already in the mid-1990s. Toyota called it stand up meetings in an Obeya, Scania called it pulse meetings in a pulse room.
Parmatur Pulse is an agile model for agile governance of strategy and development, with few fixed roles and with a minimum of bureaucracy and structure. Parmatur Pulse has built-in instability and control all in one.
You are not supposed to feel safe. You are engineers doing product development. It’s your job to deal with the uncertainty and risks involved. Only then can you create truly great products that will guarantee the future of your company.
Read more about agile management in the book The Principles of Agile Management.
Parmatur Pulse 
Over the years, more and more case studies of SAFe have been conducted, all of which have come to the same conclusion: SAFe does not make the organization more agile, rather it increases the shortcomings typical of the bureaucratic way of working, making things worse.
LikeLike