attended September's Scrum User Group meeting where we split into 6 workgroups of about 6 and discussed what issues outside our traditionally immediate sphere of control where causing us problems. Areas that might not get addressed in a normal retrospective as being outside scope. Although I must say that my teams have discussed most of the topics brought up in the Scrum UG in retrospectives at one time or another.The first thing I noticed was how similar the problems brought up by my fellow workgroup members were. The first half of the session was devoted to identifying problems, after which workgroups created cards outlining the problems which were then displayed.
We all examined each other's cards. We were supposed to pick a card, then form another set of workgroups to brainstorm a solutions. All the card listed very similar problems. In fact I couldn't tell which one been written by my original group. I picked one at random and a second workgroup formed to tackle brainstorming solutions.
The number one pain point was
Constantly Changing Requirements
Most people wanted to freeze requirements and / or reduce / funnel / manage communications.
Interestingly the Aconex Project Manager was very much against freezing the backlog during a sprint.
My approach to the problem is the opposite. I will increase communication often with a larger pool of stakeholders. I will make the conversation more concrete with design mockups, paper prototypes, mocked up screens with fake data, and more traditional partially functional prototypes.
Changing Direction and Losing Focus
There is a tension between maintaining a targeted focus and being adaptable enough to respond to an evolving understanding of the requirements. However I would rather lose a little of the sunk costs than end up with something that is not going to be used.If it is clear that the stakeholders are not able to provide a clear consistent vision for the product or service that the team is building I am not afraid of going back to the discovery phase.
The natural tendency is to start coding too soon. At the initial inception and discovery phases I prefer to use whiteboard, flip charts and pen and paper. Even when Teams resist early coding, they often go to Illustrator and Photoshop too soon. It is better to use hand drawn designs to build the initial consensus.
Scrum usually recommends not interfering with the sprint backlog within the sprint, but in practice work items are constantly being re-evaluated and re-interpreted as the sprint progresses. Just because you have the same card on the board as it travels from the waiting end of the board to the done end of the board, doesn't mean that it symbolises exactly the same task at the end of the sprint as it did at the start.
Interruptions
One solution that is often proposed is placing a gatekeeper between the development team and the stakeholders. Statistics and studies are often cited that show the high cost of context switching and the frequency of interruptions in the modern workplace. However the gatekeeper usually becomes a bottleneck. Communication suffers and is distorted as gatekeeper re-interprets and re-phases the information according to her understanding and experience which is often different from both the development team's and the stakeholder's. Most teams suffer problems because of lack of communication and a gatekeeper's job is to reduce communication.
My solution would be to setup cadences of set times to to co-ordinate or ask for assistance and have the team come up with their own protocols on how and when to interrupt. Often it is we, that interrupt ourselves. So turning off toast and only checking email and messages at set intervals can help.
Often the cost of changes and interruptions fall unevenly on the team overloading your knowledge keepers, your specialists. Shifting your highest performers to coaching and training the other members of the team will mean loss of inefficiency, productivity and poorer quality in the short to medium term. Yet failing to do so, can lead to them being overloaded, becoming bottlenecks, and risking knowledge loss when they leave.
Other Issues that were discussed where
Unsurprisingly the Convenor / Moderator / Event Organiser Craig Brown picked up on the similarities in topics workgroups focused on, as well. There was a discussion at the end where the themes of the night were elaborated and possible solutions shared.
No comments:
Post a Comment