A fool with a tool is still a fool.
People and Interactions always beat Processes and Tools
Marty de Jonge
Last Thursday: Just in time! John, the Product Owner Telcom, enters the room for his bi-weekly meeting with William, and Jenna, the marketing managers of his division. The purpose of these meetings for John is to get a good picture of the expectations and (mid-) long-term plans of the management to be able to set clear priorities. He also wants to use this hour to regularly work on the relationship with these two stakeholders.
The moment they sit, John starts to explain the agenda and goals. of this meeting. Jenna interrupts “John, I would like to come back to what I said last week, all those sheets and stickies that are hanging in the building nowadays. Personally, I think it is a lot of rubbish, but if it helps you, fine by me…. What I’m really not happy about though is that I’m expected to go there if I want to know the progress of the production.”
John is silent for a moment and replies: “Ehm, yes, right. You know, you are correct, that is expected. As a team, we value that we are open and transparent about what we are doing so you, as a stakeholder, can see at any time in a glance what is being worked on and how far we already are with the work that we will deliver in this sprint. Isn’t that something you want too?
“Jenna frowns and answers: “Yes, of course, I want to know what’s the progress, but I don’t have time to go to all of the teams every time and look at their walls. Besides, don’t you also put everything in JIRA? Why can’t you just run a report every week and mail it to William and me? That reduces a lot of redundancy. For us not to have to come to the teams every time we want to know something and for the teams themselves too. Because the time they loose now on writing all those stickies and sheets can be better spent on doing some actual programming! “
Unfortunately, a scene that is still very common. Stakeholders who think they understand the progress of product development because they can look in an online tool and feel all those stickies and posters are absurd.
Somewhere in the process, in my opinion, something went wrong because of the underlying value that visualization intends, is not secured in the organization. Either, the information visually displayed by the Scrum teams does not answer the needs of the stakeholders, or the basic Scrum principles are not known or supported by the management.
“The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.” — Monitoring Progress Toward Goals — The Scrum Guide -
“ Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.” -The Scrum Guide -
In both quotes (and in much more other parts of the Scrum Guide) there is one word that stands out: transparency. And that is exactly what it’s about when speaking of visualization.
In Scrum, the pillar ‘transparency’ is all about being open and honest to all stakeholders. (And the other way around, the stakeholders being transparent towards the ‘bigger’ picture and end goal) For example, presenting the mistakes you made (and what you learned from them) or showing everyone the deviation between ‘expectations’ and ‘results’. An important means to do so is showing this by visualising. Visualising your mistakes can be done by a “F*ck up sheet” hanging in the team room ( or even organising a special party for it), showing deviation can be done by adjusting the burn-up or burn-down sheet every day after the daily Scrum. From stakeholder side, include developers for a “mood board session” at the early stage of a new campaign. You might be surprised what valuable input those guys and gals come up with!
Physical visualization literally increases the way things become visible and it contributes to a collaborative environment. Once things become visible, personal communication based on those insight contributes to making it easier to work together on any subject. Things that people don’t see or might have different views on, can be put on the table by just showing it. Once things are visual it becomes possible for people to discuss it, share their views, and align their thinking. Besides the fact this contributes to the Scrum pillar of transparency, it also contributes to the Agile value “ Individuals and interactions over processes and tools”
Before you can dance, you must first learn the steps
Looking both at the stakeholders as the teams it takes time to learn working together in another way than before.
Just imagine working in a company for years where everything was “logical” structured. Expertises and working field were organized vertically in silos. In those silos, all people who did the same(ish) job worked together and had their own language. Also, there was a reassuring hierarchical structure that made it perfectly clear who tells people what to do and who is creating the output that is required.
Imagine this company decided to implement the Scrum framework to improve cooperation between these silos. They even start to promote autonomy to multidisciplinary teams and create new roles.
- Marketing managers were used to hiring external ‘digital advisors’ that wrote thick documents and they pushed that to the IT-silo to build the stuff that was listed in those documents. Every two weeks they got a PowerPoint presentation in the steering committee to see where the deviation to the plan was and “steered” it by distributing the meeting minutes with decisions.
Getting them used to get out of their rooms, see the progress with their own eyes and actually talk to developers, takes time and effort.
- Development teams were used to be told what to build, and to complain about the stupidity of those marketing people for asking stuff that did not fit the legacy systems. Besides that, they only did hear something from the people in the marketing-tower when things were not delivered as expected. So, better not show them stuff they do not understand anyway to avoid a shitstorm of criticism.
Getting them used to show openness and transparency where they made a screw-up, what was learned from it and how that impacted the progress, takes time and effort.
In my opinion, the biggest mistake an organisation can make when it has not yet seriously adopted the Scrum values of courage, respect, openness, focus and commitment, is to hide all transparency in a tool.
Transforming a company and using Scrum as a guide on that journey is a true discovery for all people involved. To explain this in a metaphor; On every journey you take, the better you know and understand your fellow travellers, the more fun you have along the way. Instead of both losing yourself in your phone or tablet the moment the bus takes of, imagine what would happen if you first talked to each other about your expectations and fears of this discovering journey and work from thereon.
You will probably have different views on some topics. discussing them though will surely help you both to come to a better mutual understanding and together come up with a better plan for this trip to arrive at the designated destination. Sure you can use your phone or tablet, later on, to look for details and capture what you saw, but do not start with it.
Scrum favours face-to-face communication on this journey. This helps you answer questions and discuss implications in real-time rather than through things like email or reports.
Ask yourself, what would make a bigger impact? Information that was pushed to you whenever you walk by it in the hallway or information you had to pull yourself out of an online database you will have to find your way in?
Right,…So first learn to work on transparency in real life before you jump to digitalise everything.
Marty de Jonge
As an agnostic change agent, I am constantly amazed at what happens in organizations and learn every day. Enthusiastic writer and always open for discussion.