The Scrum framework
First of all, scrum is just a framework! The tools and artefacts defined by the Scrum framework have to be used as needed in every company.
Finally, nobody implements scrum to do Scrum. Everybody implements scrum to become agile. When any aspect of the scrum process blocks us building an agile company, the process has to be customized.
Like any framework, the tools have to be implemented as needed. Especially when Scrum is scaled to company size some aspects needs to be adjusted.
With the retrospective-tool, we need to improve the process step by step. We define and implement the artefacts and roles in a way our benefit becomes as great as possible.
The product owner is implemented as a pure organizational role in the most companies. This is not enough.
Most companies enrolling a scrum process by today, are not pure software companies. They are companies building or selling something that is not software. And even if the business is selling a virtual product based on IT-systems and services the product is not a software system at all.
But how to adjust the key roles of a scrum process to scale Scrum to the whole company when the product is not a piece of software?
In our company, the scrum process was enrolled to the IT-teams first.
So, every software-system developed by a team got a product owner, a scrum master and finally a scrum process with a backlog.
Every IT-system became a product from the point of view of the scrum process.
But the business product itself is not represented by a unique software-system. Maybe the business product is represented by the availability of a process choreography through the whole stack of the company from business specialists to IT-systems.
That is no problem at first sight. Business requirements are defined by projects and the backlogs are filled up, work gets done.
Problems scaling scrum in every dimension
There are three major issues brought by this implementation.
- How to prioritize pure technical stories?
- How to align the technical development of the systems to the company business strategy?
- How to develop towards a global company-wide IT-architecture and strategy?
Finally, the requirements and priorities from projects are normally well aligned to global company strategy. Strategic business goals can easily be translated to business tasks and projects.
But what about requirements not defined by any business project?
Requirements primarily needed to develop a modern system environment to become able to support future requirements?
Is it enough to implement required business features to build the platform, the company strategy requires us to build?
Or are there further steps to go, like the integration of new technology, to build up a future-proof technical vision?
Modernizing legacy systems.
How to trigger the technical change necessary to change the systems themselves to become systems supporting the agility learned by the business and IT-specialists?
Without an agile system architecture, benefits of agility and cross-functional business teams are just poor.
We trained agility to all the employees, but we never build the systems we need, to be really agile from a business point of view!
The scalability and flexibility of heterogeneous software landscapes often can only be increased by decomposing and decoupling monolithic legacy systems to scale down required knowledge for development and to enable shifting resources efficiently.
An agile system landscape should be defined as a software system enabling domain specialists to change business rules without any IT-effort. Furthermore, an agile system architecture allows us to scale punctually and to technological upgrade the whole system step by step.
The features required by business projects aligned to the company strategy to reduce time to market will never cover the needed technical development to provide better scalability necessary to reduce time to market.
Even if the needed technical features are covered by the same strategic goal as the required business features business requirements will not cover all technical requirements.
The nature of digital transformation with end to end automation and the need for customer journeys enforces a redesign of established systems.
The technical evolution, the accelerated speed of change and the possibility of automating business processes from end to end need a change of established platforms and architectural models.
Especially the architectural change requiring microservices and distributed systems to scale and react in an agile manner cannot be done during minor refactorings while implementing business features.
That’s the point where the product owner comes into play.
The product vision of a product owner responsible for any kind of IT-system should align business requirements with technical and architectural requirements.
The product owner should be able to provide deep technical and deep business knowledge to weave things together to a solid vision of the IT-landscape supporting the strategy of the company.
Enabling a product owner
- The competences of the product owner role directly express the reduction of hierarchical structures.
- Product owners have to be responsible for the development of their product in every aspect, so they have to have sovereignty over the development milestones.
- Supervisors should not be able to overtake product owner decisions, they are not domain specialists after all.
- By communicating with every stakeholder, the product owner is enabled to create a vision satisfying needs of every stakeholder. A high level of trust supports this.
The other side
But for sure, a product owner with a staffed team and a vision and stakeholders with plans should then be able to provide measurable benefit for the company.
Finally, the product owner has to take responsibility and define the business and architectural frame the work has to be done in.
- As the first contact person for every stakeholder, the product owner should be able to provide information about current working state, anytime.
- The product owner has to actively fetch information when needed.
- The product owner has to know the product as good to be able to develop reliable ideas and timetables with project managers.
- The product owner should be able to motivate the team by telling a complete story and creating an idea about technological future and implementation context.
The most important part is the distribution of information. After all, there is a high demand on every side to be well-informed about next steps and decision reasons.
A product owner has to communicate with all stakeholders and has to translate between business and IT.
An intensive and helpful part of this task is the creation of common sense and a language to express decisions and milestones in a formal, understandable way. This can be BPMN, or any other formalism describing the goal of a development branch on a higher level than implementation level.
Changes to the development team
The second most important part is the need to keep track with opportunities and ideas on both sides. Especially on a technological side, a product-owner has to stay well informed with deep knowledge of current innovations.
Normally an implementation team within the scrum process is staffed cross-functional to the technology Stack.
To be able to improve the technology stack towards future developments it is necessary to have or build up specialists responsible for well-defined parts of the stack.
These specialists have to be focused on their part and continuously develop improvements and Implementation concepts to cover the next milestones of technological evolution defined by the company architecture and strategic architectural changes.
The accelerated speed of technical evolution requires us to establish to continuously advance the technological base. Microservices and distributed systems make that possible.
Even if the product-owner was never and is no member of the implementation team, a strong communication channel has to be established to be able to transfer the operational feedback and ideas back to the product-owner.
A big picture finally always consists of many Details to create a development plan
The opportunity is the possibility to create one big picture containing every requirement from business and architectural goals as well as an operational side.
- From a simple practical point of view, the product owner should be located in the rooms of the team.
- Establishing a learning session, product/architecture owner takes part in, is a great way to keep practical knowledge on the product owner side and to transfer ideas to the team and back.
- A pure technical retrospective to expand scrum methodology by adding a technical dimension can be a platform to inform the team about greater company-wide concepts and to formalize operational decision processes.
The idea of using swarm intelligence to evaluate decisions should not be undermined. Because of that, ideas of all ends of the company have to be wrapped up by aligning IT and business requirements. Maybe some timeboxed meetings to formalize the information distribution can be a way to hook this up.
A defined group of product-owners is able to coordinate the continuous feature stream and decide in short ways about operational priorities and issues.
A central unit with operational knowledge about current and upcoming development iterations is able to provide the important knowledge needed during project concept phase.
If the product owner is physically located in the development team, check backs will be accelerated significantly.
During concept phase of strategic digitalization projects, it is totally necessary to know technical implications and operational realizability. A product owner with deep technical knowledge has to be able to provide that Information.
Scaling scrum and design thinking?
Practising design thinking requires any company to establish completely new ways to distribute and prioritize workloads as dynamic as possible.
Even if a company implemented a scaled scrum process in any way, it is nearly impossible to react as dynamic as necessary to changes in the workload.
Take a look at my other story about scaling scrum and enabling design thinking processes.
The concept described above perfectly fits into “the do it principle”.
At LV 1871 we implemented scaled scrum by utilizing a four-month big-room-planning.
The directors’ board prioritizes projects to express company strategy. During big-room-planning project managers and IT-employees build a coordinated four-month plan.
Prior the directors’ board decision product owners give a recommendation about the sequence of features. During the four-month implementation phase, it is necessary to do operational prioritization because of changed conditions and findings.
Especially in a design thinking process, it is important to react fast on an operational level to new findings of customer needs and wishes.