Many organizations are well on the way to implementing Agile / Scrum, or have already done so. We did that a few years ago, but we have noticed that strict adoption does not work well. HBR research confirms this; we have since largely stepped away from it.
Agile software development
Frameworks for adaptive software development such as Agile have existed for a long time and have manifested themselves in many forms. But the core of most of these models consists of two things:
- Forming hypotheses (for example what kind of task a job should accomplish).
- Collaboration between different departments and expertise for prototypes.
This is mainly in the context of 'facilitating advancing insight' and not taking a defined path - which often turns out to be incorrect afterwards.
When Agile developed software in 2001, it formulated a set of four critical principles to improve software development and boost the motivation of software developers and product manager:
- Individuals and interactions over processes and tools.
- Working software over extensive documentation.
- Customer cooperation over contract negotiations.
- Responding to change over following a plan.
During the past three years, Harvard has analyzed the practices of software developers in more than 500 different organizations in their research into motivation with the help of research and surveys. They have found that what happens in practice far deviates from these principles.
We have also experienced this at Lucius:
Processes and tools
In practice, processes and tools turn out to be the drivers of work, not 'individuals and interactions'. In a large Fortune 100 company, the head of digital products told Harvard: "We must not question the Agile process". In another Fortune 500 organization, product managers and engineers communicate exclusively through their tools, which are primarily used to distribute and manage tasks.
Documentation is essential
Nowadays, documentation is an essential part of working software, especially when you develop Test Driven' ontwikkelt.
In a researched technology company, the product team focused on pre-writing small requirements (called user stories) before actually producing them. These requirements were placed in a ticket queue as tasks for the next available developer to work on.
The level of documentation was very high to keep the ticket queue moving. Eventually this process became one of the many small 'waterfalls', where work was passed from a product department to designers to development.
This process is exactly what Agile wanted to eliminate. It is no wonder that the CTO of this company said: "my software developers feel that they are cooking a lot of small orders in a restaurant."
You will not get there without an integral plan
When it comes to 'responding to a change before following a plan', it is often misinterpreted as 'not having a plan'.
Without a (global) plan, teams will not know how to prioritize actions and how to invest responsibly in those actions. This principle has gone so far that software developers believe that it is not necessary to have timeboxes or common defined milestones.
It would be fine if these incorrect applications would actually improve motivation and performance, but we found that the opposite happens in practice.
Little feeling, reduced motivation, own hide first
Agile, when executed as described above, reduces the total motivation of software developers. Because they:
- are not allowed to prototype,
- do not manage their own work,
- do not have contact with customers.
Because of this they have little feeling for the project, the possibilities and the goal; instead, they feel emotional and economic pressure to only complete their own tasks. They stop learning and only do their very best to do their own tickets, a bad thing.
The key seems to lie in balancing production activities with advancing insight (adaptive performance). Whether you are a developer or a product manager, below are some suggestions that you can consider to find this balance. In this everyone remains motivated and performance of software development team is improved.
1. Software development must be an integral team effort.
Instead of a process in which one person (product owner) compiles requirements, it is better to have this done by the entire team: product owner, designer, software developers and project managers. In such a process the product owner and the software developers work together from start to finish to design a function.
When there are technical ambiguities, they can be tackled by means of a Proof of Concept.
2. A 'delivery unit' of the team must be at least a viable prototype.
Teams often find that they waste time because they constantly have to adjust. In order to prevent this, not only must ideas be developed as a strategic challenge, but they must also be implemented with rapid prototypes aimed at learning exactly enough to know what works for clients..
In other words, what they have to do is:
maximize the speed to completion
To reduce wasted effort and increase the autonomy of the team, prototypes must be short-lived. A prototype may not last longer than a week.
Sometimes this requires the team to minimize a function to what is absolutely necessary to test the 'weakest assumption'. Sometimes this means that the team does not code, but instead completes an offline prototype through research.
3. The approach must be customer-oriented.
The process of building software (even software for internal use) must always be customer-oriented.
In the simplest case, these principles should apply:
- "Challenges" are always framed around the impact to the customer.
- Problem-solving meetings always start with a customer update, and stakeholders regularly come to these discussions.
- Each prototype is built around a customer-oriented hypothesis. In this way, the team can keep themselves accountable for the outcome of the prototype.
Even more important, however, is that software developers see with their own eyes how customers use their products. This requires the front line and the software developers to work together to see if the product creates the desired impact for the customer.
4. Use timeboxing to focus on prototypes and avoid waste
Interestingly, adaptive / agile software development encourages timeboxes as a way to ensure that a prototype gets the investment that is justified and to indicate the acceptable quality level of a given job.
On the other hand, typical agile practitioners avoid timeboxes or deadlines, fearing that the deadline will be used to create emotional pressure.
One of the worst feelings for a software developer is to spend a few months working on something that is ultimately not useful.
This may cause emotional pressure ("I let everyone down") and a sense of futility ("why am I doing this?").
To prevent this, you want to be clear about how far developers can go before they check whether the direction is still correct. The greater the uncertainty about the prototype of a team, the greater the risk, the shorter that should be. With that in mind, the timebox is not a deadline. It is a limitation that should lead to the level of depth and quality for a prototype before a real test. In this way, time boxing can increase total motivation.
Thai boxing, another kind of Timeboxing
5. The team must constantly question their process.
A famous principle of technical design is known as Conway's law. It states: every organization that designs a system will produce a design whose structure is a copy of the organization's communication (ie process) structure.
In other words, if you are a monolithic organization, you produce monolithic designs. If you are organized into segments, optimize the software architecture for that structure.
If you want to obey Conway's law, it is better to continuously adapt your structure and processes to the problem. This requires teams that have simple, lightweight processes and structures that they constantly question and adjust.
So instead of building "Agile" up as a religion that can not be questioned, development teams should have the habit of constantly analyzing and optimizing the processes of their own team. In the best examples, teams determine their model on a monthly basis and decide whether they should be modified to produce a better product.
The ability to attract, inspire and retain digital talent becomes crucial for organizations. Most organizations have fallen prey to a simple message - implement Agile as a series of ceremonies and everything gets better.
Unfortunately, most of the time it does not improve because the human side is lost. By returning to the basic principles of motivation and adaptive performance, you can build an organization that is truly agile.