Inefficient software development. Is the learning process to blame?

This topic should be of interest not just to managers but also all those working in self-organising and self-managing teams, where each member is personally responsible for overall performance.

What kind of knowledge is needed in projects? Agility, change, learning

Agile teams are no strangers to change; it accompanies them daily and requires them to learn new things all the time. This means that the learning process is continuous. We learn as we deploy new tools or optimise the software development process. 

Knowledge management is often associated with content, taught via workshops or training courses, which we have to invest in to help our developers work better. But of course, each team also has testers, analysts and scrum masters, and we should take care of their growth, too. I hope we all remember that 😉     

Other aspects of knowledge management:

• Domain knowledge – software is developed for clients from a variety of different industries, the team always needs to pick up some knowledge about the field in which it will be used;
• Process knowledge – nobody is born with specialist knowledge in software development process methodologies; no matter if our project is agile or traditional, we still need to get the hang of it;
• Knowledge of the organisational culture and relationships within the company – this learning aspect is often given short shrift and it can cause no end of problems. Ignorance in this area may spark conflict and misunderstandings during the project, which can delay work (and make it a drag!)

How do we learn and why does it matter?

Humans are anything but simple and our are learning processes can be complicated. The most important thing to keep in mind is that we all have different learning styles. There are many theories that explain them, but let’s discuss a theory we actually use in our own projects. Developed by Honey and Mumford, its big advantage is its relative accessibility, which allows managers to easily identify all the different learning styles they encounter in their teams.

4 learning styles, as proposed by Honey and Mumford:

1. Activist – a person who wants to soak up experiences and learns by doing (group discussions, brainstorming, trial and error).
2. Reflector – a person who learns by observing others (individual analysis, smaller groups, practical examples).
3. Theorist – a person who loves statistics, facts and figures, models, stories. They need to take in a lot of theory before they can act.
4. Pragmatist – a person who always looks for the best solution and itches to put knowledge into practice as soon as possible (case study, case analysis).

Let’s take an example: the company buys a new coffee machine. The activist presses all the buttons and tries to make their favourite espresso by trial and error. The reflector lets others go first and looks at what they’re doing. The theorist picks up the user manual, while the pragmatist just wants to get things done as soon as possible – e.g. they might be googling an instruction video and asking around for tips at the same time.

As a manager, you might want to know how your team members learn to help them grow better and boost overall team performance in the software development process. By bringing together employees with different learning styles, you can neutralise negative trends, such as the theorist’s preference for moving slowly from theory to practice or the activist’s tendency to rush headlong into things without thinking.

When does learning happen in the software development process?

We can divide the software development process into three phases and look for the moments that are especially conducive to learning and knowledge transfer. The tips, tools and methods you’ll find below will work not only for agile projects, even though some have to do with, e.g. scrum ceremonies.

Kick-off phase

The start of a project is when everyone is still eager to get down to work and errors are the most likely. The initial phase of software development process requires immense knowledge transfers, especially when it comes to domain knowledge. Depending on the sector, we might need to learn and understand what leasing or crediting involve, for example.

Tools and methods to acquire domain knowledge:

• Documentation provided by the client (theorists);
• Study visit: your software project team visits the client’s office and meets the people who will be using the software. This will let them get a full picture of the solution, open their minds to new ideas, and add elements they might have overlooked at first (reflector, activist);
• Event storming: a brainstorming session where developers, clients and domain experts look at the process that needs to be digitised and discuss it at different levels. Active learning (questions and conversations), often in movement, using visual aids (perfect for all learning styles).

In addition, this phase is a perfect moment to go through the entire software development process. You can devote two days to a Scrum training, because each company has its own habits and preferences that need to be understood by the team.

This is also the time we can learn about the organisational culture: the kick-off meeting is often done by conversation or through a one-pager that summarises the work culture in bullet points. Our recommendation, however, is to use the 5R framework, where the team decides on the following 5 dimensions:

• Results – the team sets goals and makes sure everyone understands them in the same way;
• Rituals – the team decides on how they are going to work (e.g. the daily meeting is always held at 9 am);
• Roles – everyone in the team provides their job title (e.g. I’m a Java Developer), but also an informal description, e.g. someone can say they are a good mediator;
• Rules – the team agrees on specific actions (e.g. working time is reported in Jira);
• Relationships – the team defines all the soft aspects they find important (e.g. no political jokes allowed).

After that, you can move on to the next software development phase.

Software development phase

At the beginning, the knowledge we need to absorb is fairly broad, but then you need to delve into the details and enter an operational mode.

At this stage, we recommend using tools such as (some have proper names that we’ve adopted for our own purposes😉):

• Domain storytelling. Workshops designed for the project team, assisted by the moderator and domain experts. Domain experts present the business domain and its processes, using their business terminology. The project team can ask questions in everyday language. The moderator then presents stories told by business experts as pictograms, mapping out the entire process so that everyone can leave the workshop with new domain knowledge. This is the first step in creating user stories.
• User-story mapping (after domain storytelling). A method that allows all the requirements, aggregate user stories, to be collected and organise them into a logical whole. This is the basis for creating the project backlog, i.e. the scope of work that you will need to develop the software.
• Pair programming. A method for developing knowledge for the software development team. Two people work on a task at the same time: one does the programming, the other provides support (e.g. suggests how to optimise the code or manages the initial knowledge transfer as a more experienced member of the project).
• Study Time. It is a good idea to set aside a few full days (e.g. 5 per quarter) for the purposes of learning. These days should be used by project team members to study the ins and outs of a project element/problem or complete an external training course.
• System tours. A knowledge management method, used especially in very elaborate software development projects. If a system builds a new solution, people in charge of a given area/functionality can record a video to provide others with a virtual tour of the functionality in question. These videos can then be used every time a person from another area or a new project member wants to learn about a particular aspect of the project. They are a ready-made vehicle for knowledge transfer, faster and more effective than individual onboarding.
• Retrospective. A retrospective can be devoted to education; you can also organise separate meetings (1-2 per week) for the scrum master to meet the project team and discuss a single issue, e.g. how to estimate user-story cost (especially if the team reports doubts/problems).

Lessons learned phase

The lessons-learned session is a moment to take stock of the project and draw conclusions. The learning tools you might find useful in this phase include:

• Start-Stop-Continue: we get the project team together and start by writing down the things we didn’t do but, with the perspective of hindsight, should consider in the future. Stop: we identify things we did but now think we shouldn’t have done. Continue: we identify things we did that worked well.
• Plus Delta: a similar solution, where we make a list of things that did and didn’t work in our software development process.
• Timeline: we build a timeline along which we distribute our project milestones. We discuss each event and draw conclusions (again: what worked well and what limited/hindered our progress).

Of course, different methodologies can be combined. What matters is that the lessons-learned session wraps up with a recap and conclusions you can use in other projects.

Knowledge drain, or changes in the team

Our team will change; this is inevitable, so we need to learn how to impart our knowledge to new employees effectively. Onboarding can be done through documents or videos (theorists and reflectors), but also by pair programming (activists and pragmatists).

In our company, we also created the role of a Buddy; a Buddy is an experienced employee designated to mentor a new project team member. They offer help with practical matters and teach them the ropes.

If you opt for instruction, training or teaching by a single person, keep in mind that Richard Mayer estimated people can sustain a high level of attention for approximately 12 minutes. Knowledge should be imparted in 15-minute time slots, in a condensed and well-considered format.

We can also fall back on the TWI method (Program Training Within Industry), which consists of three stages: we teach what we do, how we do it and why we do it. At the end, the trainee should always report back how they understand the teaching point in their own words.

Knowledge drain – tools:

• Documentation – it can be hard to rein in all the project documents, but we should focus on creating a transparent and frequently updated documentation system (this requirement should be added to the definition of done, so that the documentation is expanded as you go along with each development increment).
• No knowledge silos – the project team should consist of people who are all responsible for a different aspect. However, it is better to avoid teams where only one member has the necessary knowledge. We should always have someone on call to fill in for them, e.g. during the vacation season.
• Related knowledge – it is important to build a culture of knowledge sharing within the team, where everyone can impart and share insights from their field. We should focus not just on core knowledge but also on accessory and related fields. Understanding the different roles and fields of expertise of different team members improves cooperation and communication, which boosts performance and accelerates the software development process.

Scrum ceremonies

• Daily – the goal is to improve public-speaking skills and knowledge (this goes beyond core project knowledge, but comes in handy, e.g. in contact with clients).
• Refinement – to show the perspectives of different team members (programmer, tester, analyst). No role should be ignored; if it is, projects are often not delivered on time (e.g. we might be unable to predict that testing will take much more time than we expected based on our own knowledge alone).
• Review – this is not a demo! This is a session during which we learn about the product and what should happen next. By looking at what has been developed thus far, we can take an informed decision about where to take it from there.
• Retro – we learn to give feedback, or come up with specific action points (something for activists) to focus on in the next sprint. In addition, by analysing root causes, we learn about various creativity support tools (such as Ishikawa Diagram, O’Connor matrix) and there is nothing to stop us from using them in our daily work as well! After all, software development is a creative industry 😊

Not sure you really know how to use these learning tools and practices in your software development process? Contact us!