The work on new features and maintenance on the Onebip platform stopped for two days as developers were all invited to the periodical review of the business unit. Here's a recount of the experience from the eyes of a developer inside the business world.
Day 1: coaching
The review was a great occasion for putting together in one room all the colleagues working on the same product, Onebip. This means the people in that room will show a very different set of skills and cognitive styles:
- developers have usually a scientific and mathematical mindset, together with the love for technology.
- Reporting specialists have too a mathematical, applied mindset, but they see the platform as users.
- Salesmen are very people-oriented, strong on negotiation and envisioning an outcome; not so on technical execution.
The technical team of Onebip, in which I work, is as much as possible cross-functional on technicians: development, operation and support colleagues work in the same room; some of their internal clients work in the same office. However, a large part of their business-side colleagues is not colocated but living in another city.
So the first day was dedicated to coaching, of a whole team of 26 people. This headcount is an unusual number for , if you think Scrum works in teams of 7 plus/minus 2 people. Some of the activities divided in fact the team into two subgroups.
Some of these coaching activities were a bit Taylorist, in the sense that you would normally attempt them inside a factory than in knowledge working. For example, an exercise consisted in building a wood structure as quickly as possible.
Of course, it's not the activity that counts but making people work seriously on it together; this stimulates developers to see their internal customers not as adversaries that require impossible features for yesterday, but as colleagues working for the success of the same product.
One main take-away for the developers wanna-be coaches is the style of coach Dan, which is aligned with most Agile coaches I saw. He opened the day saying "I believe adults learn alone" and made sure not to tell hints or solutions for the problem we were facing. This is risky as the situation may explode due to people venting their frustration: but it's necessary to let leadership and self-organization emerge.
I must say the last phrase is a bit vague, in the "let's hug trees" style. However, when I read about Deming calling for "instituting leadership" I could think the same. I changed my mind after seeing a team of 15 people facing a problem organize themselves naturally to solve it in a short timespan such as an hour; with leaders chosen by authoritativeness, not authority; and on a problem having nothing to do with their daily work such as wooden constructions.
Day 2: results
The day 2 was dedicated to sharing the results of Onebip as seen by each function, and to communicate new goals for the business. Some of these results were technical, such as the Amazon Web Services migration; other financial such as revenue and margin; other ones marketing-oriented like sales closed and brand recognition.
I have a feeling this involvement is unusual, and that in many other companies developer don't got or are not invited to these internal events, and this is a pity. Also, we were unsure whether it was mandatory to participate or whether we should stop development for a couple of days. But I think most of my technical colleagues have enjoyed the day dedicated to teamworking and also the clear gols resulted from day 2.
Would it be nice if your business colleagues knew more about the technologies used in your project, the design choices you have taken and the capabilities of the product you work on every day? It goes also the other way around: developers can benefit from domain knowledge that they slowly pick up while working in the company. The business events where financial and sales results are shared are ideal for stimulating the informal conversations that enable developers to take decisions not only based on technical but also business reasons.
Customer collaboration is one of the principles of the Agile Manifesto, and it goes into two directions: customers learning what's feasible and its cost from us, and developers learning the value of features and options as they are provided in the outside world.
Gone are the days in which a business meeting is the prerogative of suits and just a buzzword for developers. When you have internal customers to steer a product together with developers, you have the option to put them all together in the same room much often than if you were divided into two different companies. Like Kent Beck writes in Extreme Programming Explained, when you have a problem consider if it is affected by lack of communication and if acting on this value may influence the result.