In the previous post I tried to describe the why, in this second part I try to describe the context and some particulars.
The vision/direction
The vision of this project was borned because of a pain. Pain experienced by a lot of people trying to make the software work for a new certain type of client. People from all levels of the company were involved. The existing product we speak was formed by 3 big sub-products. This meant that integration between the 3 sub-products had to work. We knew about this problem for some time, but usually people react when there is a great need or a pain. So I waited for this occasion, all the other efforts being useless, to rise the idea that it can be solved and all this integration setup to take ~20 minutes.
The team formation
In those difficult moments, from the start, the right technical persons were being chosen to make the integration work for that new client. After a month of big presure the problem was solved and it was decided that we should make the project. I asked for those initial persons. I did not said: “Please give me one person from project A, another one from project B, and one from Project C”. When I spoke with the responsible for each of the sub-project, I asked them for the specific person. I emphasized the fact that I need those persons, by saying their full name, and that is not a coincidence that is about them. I wanted to show the importance of each of the person needed.
A team is not formed by choosing randomly/available/free people, not at all … is much more difficult.
Before going to speak regarding the possibility to have a new project I spoke which each of the persons which I wanted in the new team. For me it was clear that no other person would qualify, so the project would have been with them or not at all. I wanted to have their approval and permission. I have said to them no platitudes or pseudo-motivation stuff. I say this because otherwise I would have consider that I would tell bullshit and offend them and that is not an option for me. They agreed and so the work to form the team started.
It was not easy, but in the end, the desired team was formed: 5 persons. The respect between us, at least what I felt, was enormous. I realized again that once the right people are in place then we can concentrate on the nasty things from the outside. At least we knew that no problems would occur from inside and I was right. I am amazed of how much energy is lost on trying to solve internal problems just because the team is formed in a careless way, a lot of energy is lost and not on solving the real problem(s).
In all this a wonderful person from the client helped us a lot.
Strategy
We knew what we wanted to do grosso modo. We begun the discussions between us, in Crystal parlance I would say it was the “Reflective Improvement”. There are many details which can be said regarding how we defined the strategy and documented it to offer vizibility, but one thing I remembered vividly is the technique named “Advocatus Diaboli”(1) which helped us a lot. We knew from the start that the colleague, playing the devil advocate, intention was not to hurt us, not at all. Actually he was more like the guardian angel and this from the moment when that pain begun.
Although we had the strategy, we knew surprises will occur, we realized from the beginning that we will meet those unknown unknowns(2).
Also we decided to use a different style of reporting to show our progress and we used the Parking Lots diagrams from FDD(Feature Driven Development) – we wanted to see better the forest from the trees and also to avoid possible anomalies with the current techniques involved with story points – a future blog post will be done regarding this.
Robustness vs Resilience(3)
We knew we couldn’t tackle an important subject and repair code without causing problems/bugs in production. There were too many instabilities we had to deal with. Even if a problem would have occured in production, we knew we would have to solve it as soon as possible, to recover fast. This way of thinking helped us not being paralyzed/rigid in our approach. What I can say is that is strange when one team focus on resilience and all the others on robustness(actually was rigidity), still we did not gave up. On each occasion I had, I tried to emphasize the need to concentrate on resilience not on robustness.
The Seven Properties of Crystal(4)(5)
For me these properties were like constraints in the complex adaptive systems. But I let one of the team members to describe these properties in connection with the project, in the next post.
(1) “Devil’s advocate”, https://en.wikipedia.org/wiki/Devil%27s_advocate
(2) Dave Snowden, “The Origins of Cynefin”, http://old.cognitive-edge.com/wp-content/uploads/2010/08/The-Origins-of-Cynefin-Cognitive-Edge.pdf
(3) Dave Snowden, “Risk and Resilience”, https://www.youtube.com/watch?v=2Hhu0ihG3kY
(4) Alistair Cockburn, “Crystal Clear Applied: The Seven Properties of Running an Agile Project”, http://www.informit.com/articles/article.aspx?p=345009
(6) Alistair Cockburn, “Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams”, https://www.amazon.com/gp/aw/d/0201699478