Agile Lead and Software Engineer at Zalon, Jan Helwich on how to work well

At the beginning of 2017, we at Zalon decided to enable our teams to work in what we believe is the most effective and efficient way. At the heart of this restructuring process, we assigned cross-functional teams to business goals or user needs only and let them take full responsibility for solving these problems. This transfers ownership and responsibility to the teams, and allows them to focus solely on the topics at hand. We first evaluated the idea by testing it with a very small team and are currently rolling it out to all our teams.

The teams now ideate, define features, build prototypes for user tests if needed, set up A/B tests, implement and bring the features live, and also monitor impact to decide if further work is needed. To be able to do this the teams need to be fully cross-functional, meaning they must consist of UX, UI, Producer (role comparable to Scrum Master), Product and Business personnel, plus all engineers required to bring a feature to life.

This approach is not new. For example, Spotify is working in a similar way. But there is no common Spotify model and no approach is “one size fits all”. Spotify itself is very unique in setup and state, as it evolved quite fast and was an extremely flexible startup from the very beginning.

In this article we’d like to shed some light on the learnings and best practices that we’ve acquired from taking our first steps in this direction.

The reasoning

I would consider our former practices as fairly agile here at Zalon. For any business problem, Business and Product would start discussing potential ideas; at some point UX would be included. Together, they’d ideate and expand upon them by prototyping and user testing. Engineers were included as needed. This resulted in a relatively rough specification that was then planned in the backlog of a team. We completed the final specification during implementation to avoid common Waterfall problems.

This approach worked decently for us but had some major drawbacks:

• Our engineers still often felt like code monkeys as the ideation process happens before (sometimes way before) actual implementation and those engineers included in ideation were not always the ones implementing the feature.
• The risk of producing waste was high, as Product and UX often worked on things that were never implemented or had to change a lot during implementation.

How we want to work

The basic ideas we wanted to hold on to were already present in the Agile Manifesto from roughly 15 years ago; in the Principles to be more specific. Here are the areas that steered our vision:

• Business people and developers must work together daily throughout the project,
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation,
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

In my experience, the last point is often the hardest. Why? Because it requires a vast amount of trust of leadership in teams. We try to work within an organization that trusts teams to do what they have been hired to do. Implementing this philosophy in other workplaces or companies is another thing altogether.

Our experience with this new approach showed that transparency and trust are crucial. One example in how we saw benefits here was when we calculated roughly how much a sprint costs. Using this information the teams could make informed decisions, i.e. “Is it worth spending more time on implementing a certain feature if the estimated outcome is X?”

One other very important part of this approach is team setup. Here is an overview of what we consider important for our teams:

• Cross functional

It is important that a team is able to solve the problem at hand, from ideation to release of the feature. Our typical team consists of Product, UX, UI, Frontend and Backend Engineer(s), plus one or two associated people from business.

• Long living

The team should work for a certain time together to allow them to really grow as a team, in order to get to the performing phase of team building.

• Self-organizing

The teams self organize.

• Size matters

Studies show that teams should not be too big. This is due to the communication overhead becoming a problem.

• Business should be part of the team, not only through product

The gain from useful information transferred from one area to another is not to be underestimated. Until now, we associated colleagues from the business side as included only for the duration of a feature “project”. This might be a disadvantage when it comes to team building.

What we’ve done so far

So which process are we using? As a department we are still learning a lot every day. We are sure that we have yet to cover every possible case. Regardless, we’re still hoping to share what we’ve distilled from our recent experience in order to grow and learn.

As said, for us it is most important that teams can fully focus on the topics at hand. But how do you get all the small stuff done? We alternate between focus phases and so-called miscellaneous phases. In a miscellaneous sprint, the team “focuses” on smaller improvements, bugs, and the monitoring of new features. The latter is important as the team has usually brought about live features beforehand, thus it is crucial to be prepared for upcoming issues or bugs.

Note: It should be obvious that in a focus phase, critical issues should also be addressed by teams. Experience shows that engineers sometimes have slack time where they are also able to get smaller improvements done.

General process is as follows:

1. Business, in cooperation with Product, prepares One Pagers, which are documents that explain the user need or a business goal, and the KPIs that shall be improved. Also, an estimate of impact is given, so that they can be prioritised in an informed way.
2. Kickoff meeting(s), which might take place before the actual start of the focus phase, so that Business and Product can explain the One Pager to the team and answer questions.
3. Ideation phase (if necessary → 0-2 sprints): (i) Brainstorming potential solutions (ii) Testing ideas eg. by prototypes with user tests, A/B tests etc (iii) Tracking: Are all KPIs tracked in a way we can measure success? Implement as necessary.
4. Implementation phase: (i) Implementing the outcomes of the ideation (ii) Setup of reporting (iii) Bringing features live, A/B test etc

Learnings

Process We are not dogmatic in any way about these process steps. In some cases it might make sense to start implementing certain features during the ideation phase. A small ideation about an unforeseen topic might also happen in the implementation step.

For some teams it works better to have the kickoff and even some ideation meetings before the actual focus sprint starts.

Sprints and meetings Our teams work in one or two week sprints. One of the most important meetings related to this setup is the review meeting. Here, the team presents the results of their work to everyone interested. This can be wireframes, prototypes, or diagrams showing how things are planned, and of course working software as well. The reviews are usually fruitful as here the team can celebrate successes and discuss with their stakeholders how to continue or what next to tackle based on the current results.

Ideation In the ideation phases it is crucial to meet often, as there is still a lot of uncertainty and the team needs to communicate and coordinate next steps often. Once every one to two days works for us. One team even extended their stand-up to up to 30 minutes. We are currently considering the option to start with two full workshop days for bigger topics.

Our teams also found it crucial to write down what they had decided upon during these meetings, but also what they decided not to do and why. When they are working for a longer period on a problem, it otherwise happened incredibly often that they re-evaluated these ideas once again.

Leadership When embarking on a new method of working and collaborating, it is important to support the team undertaking the change. For example, a lot of engineers may be very unfamiliar to ideate and not “just” implement defined tickets. It must be made clear that their input is appreciated and needed throughout that time. Also, keep an eye on and support the team when going through team building ( phases).

Decision making Coming to decisions in a timely manner might be challenging for some teams. Supporting the team here might be necessary, e.g. by consent decision making. Sometimes, input from Business and Product can accelerate decision making if the team is indecisive.

KPIs Try to focus on the least number of KPIs as possible, preferably one at a time.

Rules For some teams, defining rules allows for structure and guidance, so everyone is on the same page and Business personnel understand how technical members of the team work.

Capacity and slack time It is important to note that this requires a fair amount of capacity from the associated Business person, as they are usually responsible for providing a lot of background data, preparing reports, etc. Our recommendation currently would be to have one person with a main focus, or nearly all of their capacity, working with the team. We know this is often not possible and are open to alternatives.

Teams and leaders must also be aware that developers have slack time here and there. There are two things I would like to stress here. Firstly, it is important that the developers are aware that the focus topic at hand must always have first priority. That might also mean they have to support other team members, optimize some processes or check if all the required data is available, thus having a hand in completing more “uncommon” development tasks.

Secondly, having some slack time for engineers is part of many agile methods for good reasons. They should use this time for clean-ups, getting rid of technical debt, research, and so on.

Conclusion

Letting teams take over full ownership of goals for us is already proving to be advantageous. Overall, teams are very satisfied when it comes to focus, engagement and collaboration. Most important is that the results of the first focus areas are “good” to “very good”, e.g. an NPS of up to 70 for one new tool for our stylists out of the box.

For leadership, communicating goals and expectations clearly, supporting the teams in working as a team and on difficult decisions without explicitly telling them what to do, is vital in making a success of this method.

I hope the learnings we shared here are helpful for some teams wanting to implement a similar approach. If you have any remarks, questions or additions please contact me on Twitter or via email.

Want to bring your skills to the table? Have a look at our jobs page.