Transparency is key

We all know that rivalry between departments. We all know that culture: “I don’t know what those developers are doing all that times there in that dark corner”. This seems to be a shared way of thinking in a lot of organisations, within a lot of departments. I used the stereotype ‘developers’ because that group is the most common to be targeted with comments and remarks like that, it is however true that stereotyping this way is cross-department.

Scrum, and actually all agile-based workflows, state that transparency is a key element in making your implementation work.

I agree on that. Sharing your end-sprint delivery with all stakeholders – or even better: your whole organisation  – gives your team (and management) valuable feedback. It also ensures that the rest of your organisation knows what you’re actually doing, even if you choose to stay “in that dark corner”. It allows the other departments to understand more of what you’re doing, and with a little bit more effort even makes them a part of it.

Create an open page on your wiki or intranet and share your sprint progress (show them your board and/or your burndown chart). I prefer an even larger transparency approach; open up all your meetings for anyone to sit in and listen! Let others literally sit in on your daily standups or your planning meeting and even your retrospective. Better yet: make a delivery presentation part of your retrospective and invite all stakeholders (or your whole company).

The biggest fear of teams when discussing transparency is that the team is scared to be viewed upon with a microscope or magnifying glass, that every move they make, or every delivery they don’t make, will be critiqued and (openly) joked about. While this fear might seem realistic at first glance. The opposite was true for all transformations to transparent teams and departments that I have witnessed.

Applying transparency applies positive pressure to your team; they will feel a bigger obligation to actually deliver and not look like fools. Your team will either get positive responses for all the work they’ve done or negative responses for the relatively small amount of work they’ve done. It does give them, however, a chance to defend themselves or openly discuss the problems they have encountered during the sprint, which in turn leads to more understanding from your organisation for the daily work the developers do!

The pressure that your team feels might seem harsh, and it might seem to undermine productivity at first glance. That might actually be the case for the first couple of deliveries. It does give you a clear way of gathering feedback, viewing what you’re doing ‘wrong’, either in your communication or your workflow (note: I don’t believe you can do things wrong, I believe you can do things better). This gives you the opportunity to address these issues and become a better team, a more effective and efficient team, a more contributing team (for other departments or your organisation) and it helps you grow – as an individual team member).

As pointed out earlier; I’ve used the development team as a stereotype but the above goes for any kind of department (and not only for scrum teams). A marketing department also continuously delivers, and they are also proud of what they deliver on a weekly (or so) basis!

Transparency creates understanding, creates clarity and gives your team credit for what you’ve actually accomplished. It creates a bond, within your team, within your department and even within your organisation.

The pain of introducing Scrum

The pain of introducing Scrum – or any new workflow for that matter. Obviously we all love the end result: self sustaining teams, better results, faster results and so forth. Introducing (or actually fully adapting and eventually adopting) a new methodology, whether it’s Agile, Lean, Kanban, Scrum or any other, is a painstakingly slow process.

The team that is to adopt a new workflow, but also the whole company, are stuck in their way of handling things as they are. While they might love the promises that adopting a new methodology brings forth, they are not ready for the changes and process that are involved with the change in many of the cases.

Inform your team and your organisation that changing to a new methodology will take a lot of time and a lot of effort. Make them understand that things will not be running smoothly from the get go.

“A team reflects on how to become more effective”

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

Sources: Agile Manifesto & Twelfth Agile Principle

Scrum, and also other agile methodologies, are built on constant feedback loops. That feedback eventually, time after time, leads to (minor) changes in the way the new workflow is adopted and used.

It is the team that makes Scrum work in the end. It is the team that has to identify and eventually tackle problems and bottlenecks in the current setup. Facilitate and guide the team in the identification and solving of those issues, whether you’re a Scrum Master, a stakeholder or a company as a whole.

Make sure that everyone involved knows that only time and transparency make your implementation work. Make sure that everyone involved realizes that a new workflow takes time to settle in, and mostly that it is a progress, not a straight forward implementation. Any good adoption of a new workflow is one where the team, and the workflow itself, have the space and time to evolve.