I had a very revealing and productive 1:1 meeting with one of my development team this afternoon. I'd set aside an hour at the end of the day instead of the usual half-hour slot for our monthly 1:1 meetings; instead, the meeting lasted two hours.
Ever since I arrived in my current position I told the team, in true Scrum fashion, that they were self-organising, with the mantra "let the team decide".
Unfortunately, the team had not really grasped what the true implications were.
This was a lack of communication on my part, and not devoting sufficient attention to coaching the team in how to think in agile ways and seeing how they interact.
There had been several misunderstandings over the concept of "ownership". Telling the team that they did not "own" the products left them feeling that they had little or no stake in them. In order to clarify things I had to say that the team does not own: the requirement for a feature, the prioritisation of a feature or the business value of a feature. However, the team does own: the responsibility for committing to, and delivering on, the solution to a requirement; the technical architecture of the solution to a requirement; and, the processes for delivering solutions to requirements.
My previous experience had been that the team would spontaneously self-organise in order to drive requirements to completion. In an Asian context, developers are not accustomed to being allowed to think for themselves: designs are handed-out, tasks are assigned, people do what they are told.
The team did not realise, despite them being told that they are self-organising, that they can have individuals in the team who drive forward the delivery of the solutions to requirements. Now I ensure that the "driver" for each requirement is identified at the end of a Sprint Planning Meeting - how a driver is identified is not prescribed: people can volunteer, I can make a suggestion, I can say that someone should be the driver. The difference is that with a named driver the team feels a greater sense of ownership of the delivery of the solution to a requirement. Maybe one day they will be a little more pro-active in terms of the self-organisation...
The principle of whole-team involvement was also taken too literally, and did not respect the capabilities of individuals. Each team member has his own strengths, weaknesses and aspirations. Whilst some are good at one thing, others are not so good at it - the team should be able to recognise that and act accordingly. The response can be to use the strengths of the individuals directly by them doing things themselves, or indirectly by them guiding or assisting someone else who wants to develop their strengths in that area. How the team had reacted was to assume that everybody was equal (which in some cases they are, such as when voting during estimation in Sprint Planning meetings, and being able to contribute to discussions) and that everybody was expected to do equal work. The emphasis on the removal of single-points-of-failure may have contributed to this attitude, though the drive to remove single-points-of-failure is still on-going.
In terms of agile design and delivery, despite repeated instructions to break large requirements down into iterations and to concentrate on designing the minimum amount in the beginning, and only designing in any kind of detail for immediate (highest priority) requirements, we still ended up tending towards a waterfall design approach.
More involvement in the design process to coach the team to think in iterative and agile ways seems to be putting them back on track - though there are still times when the team risks falling into paralysis by analysis rather than seeking clarification from outside the team.
After careful and persistent questioning, I also managed to get my developer to provide some feedback on me in the 1:1 meeting. So far, I've been inviting my team members to tell me their concerns and problems in our 1:1 meetings so that issues can then be resolved. The 1:1 meetings aim to be a two-way conversation where either party is free to say what they want. Instead, everybody has just been saying that everything is fine and that they are happy how things are going.
However, I'd learned that the team had expressed some misgivings about things to higher management.
So, with a little more humility than usual, a lot of in-depth questioning to get him to open-up more to me, and some straightforward asking of what he thought about me I managed to get some much more honest feedback.
To my surprise I learned that my team can consider me to be intimidating.
My sarcasm does not always travel well, and can be misinterpreted. I also do not like arguing for argument's sake, but will play the Devil's Advocate in order to help people probe their own arguments further, or I will argue my point if I hold by own contrary opinion - this can be interpreted as being aggressive. A constant stream of criticism, though well-intended as my continual drive to improve quality, can also be demoralising.
However, I am conscious that I had been praising good work.
My developer has now gone away with the message that honest feedback is welcomed, and that if anything is affecting communication then that is an impediment to the team achieving its goals of delivering well-designed, high-quality software in a timely fashion, and as an impediment it must be resolved.
No comments:
Post a Comment