Agile as a Fox
Long customer relationships can be described with the word partnership. The customer learns to trust the service provider and the provider learns to know the customers' systems. The affiliated strong personification can be a double edged sword though.
When the expert, let's call him Lenny, works in the same environment for a long time, the problem solving gets fast. In a familiar, even complex, environment Lenny doesn't need much time to look for the information. He can solve problems quickly.
Problem solving is fast in a familiar environment.
John has recently joined the company. He's got a long experience in software business, but he's not yet familiar with the systems of Lenny's customer. In a problematic situation John needs to begin the work by getting familiar with the system. This can take a considerable amount of time. After a long life and development span, systems may consist of several millions of source code lines.
Elisa Appelsiini's new Agile Product Model, KetTu (fox in English), solves this possible partnership problem. John and Lenny now belong to the same team which takes care of both of their customers. Work can be organized in such a way that on one day they both serve customer A and on the next one customer B. Both will eventually become experts in both of their customers' systems.
Code reviews become lighter when two pairs of eyes have already seen the code when it was written. With pair working the number of potential errors becomes less. Focusing on the work is easier, because the bar to interrupt a working pair is higher than with individual developers. Maybe slightly unintuitively the throughput time shortens when people work together. And as an added bonus: human beings are social animals and working together is simply more fun than working alone.
The throughput time shortens when people work together
KetTu model is based on a team of experts. Communication with the customer is handled by the Technical Product Owner (TPO). TPO removes impediments and helps the team to interpret the customer needs. S/he also prioritizes the backlog and simulates the voice of the customer.
KetTu model has continuous improvement built in. The team continuously inspects its way of work and decides what they will do differently in the future. Within the model the team has the authority to choose their own tools and work practices. Also nothing is hidden, but the customer is always kept informed about the results. Typically the customer gets to follow the progress with a project management tool (JIRA).
The co-operation between Lenny, John and the customers has become deeper still after introducing the KetTu model. Customers feel that they get more value for their money and with the full transparency there's no need to fear for surprises. The customer truly gets what s/he's ordered. The development work is more fun and there's more time left to learn new things.
The development work is more fun and there's more time left to learn new things.
The writer is responsible for the KetTu model at Elisa Appelsiini. The model is continuously developed and modified in co-operation between employees and customers.
This post was originally published in Elisa Hub (in Finnish).
CEO / Co-Founder at Integround Oy
8 年Good post. I find this a bit problematic if you think from the customer's point of view: "Within the model the team has the authority to choose their own tools and work practices." As a customer, I would like to be able to use multiple suppliers. Therefore I want to use common tools and practices across different suppliers. I realize that as a supplier you can have your own set of tools and processes independent from the customer's. But if you are building a model to serve multiple customers as a team, you must be pretty flexible. Building heavy processes internally means that you end up running two sets of processes - your's and customer's Not an easy problem to solve, I admit.