Transparency Retrospective

I want to devote the next resprospective to the Scrum value transparency. I want the team themselves to develop mechanisms which will increase transparency within the team and to the outside. How can I do that?

Do they understand that the real way to assure transparency is through the continuous integration of work to a standard of release quality?

If that isn't possible for some reason, what transparency do they need to put in place to help close the gap?

@Ian's questions can help you find some direction to go.  If you can answer those questions or even better have the team answer them, it will get you on the right track.

Transparency is not easy.  And it sounds like it at your company it has been used more as a weapon than a tool. However, you have pointed to a few things in your comments that I would focus on. First:  

They are also afraid to use code written by some team members when they go on ´vacation before the release because they expect it to not be sufficiently tested, etc. 

This is actually a pretty typical problem in software development.  Since some developers see their value in what they know that others don't, this comes up in many organizations. (I say that because you say you have no background in software.)   Ok, that one with these:

The team does not see themselves as autonomous and do not strive to

The board shows me that they leave the tasks almost finished but non-tested for a long time, which often keeps them from finishing the sprint.

But many of these agreements are not being applied by all members and then the other members get frustrated.

All of those comments are triggers for me that these individuals aren't working as a team.  If they were working as a team, the transparency issues you discussed would not be so prevalent. Instead of focusing on transparency, I'd start focusing on how to get the operate as a team.  Respect and Commitment would probably the the Scrum values I'd focus on first. They need to learn to respect each other's skills, respect that no one will intentionally do something to cause problems, respect that others will help them when they need it.  They need to commit to each other that they all want to do the best work possible, commit to the idea that the work they do is valuable, commit to producing quality work.  And I'm going to throw in one Bravery item.  They need to be brave enough to push back on their PO/Management to do work that will not compromise the quality of the work that they do. 

You have a lot of work ahead of you.  How do you do the things I listed?  Wish I could tell you.  But as with all things agile, you will have to find what works for the team. I'd start working on a single item at a time.  Get them to agree on something to try, remind them of it daily.  It sounds against the "let the team get better" but sometimes they need pushes and nudges.  As a SM, you can and should do that.  

Also, on your question

Are there any known alternatives to burndown charts I should know about?

Yes, many things.  Remember that Scrum is a framework and does not prescribe process.  The use of burndown charts is not actually mentioned anywhere in the scrum guide.  It is an "industry standard" that has been adopted.  I personally don't like burndown charts for tasks because I have seen to many teams attempt to cheat them.  I prefer to burndown stories.  Stories are the things that provide value.  Tasks are just a means.  If you must use a burndown chart, try burning down the story progression.  Given what you have said, I would be that it will be a straight line across the top until the last day or two of the sprint. That actually shows them more of a problem with delivering value. 

I would also suggest that you use a Kanban measure of Work In Progress (WIP) but with slight modifications so you can show them how their tasks are not progressing.  Kanban WIPs value, which would be the stories.  But in your case you could start to track the WIP for tasks to help them see how tasks reach a certain point in the process and then pile up.  Have them identify strategies to prevent that.  If they insist it is because they do not have the necessary skills (I'm betting on them complaining that they have no tester), ask them if there were other ways to address it.  Possibly doing more automated tests, pair programming so that the code is better reviewed which can prevent defects from being introduced.  There are many ways but see what they say.  If they can not come up with options that are within their control, you should direct them back to what they can change based on their current team. 

Almost all of the most common measures used in Scrum and other agile practices will center on the value that the team produces and not on the tasks that they are doing.  Even the burndown is supposed to show how they are progressing on delivering the value that the forecasted to be done in the sprint. If the metrics are used to accuse the developers of not doing enough work, the teams will start pushing back on any metric.

Find something that they will agree to and make sure that they understand it is to measure the value being delivered and not the lines of code that they produce. 

First, thanks for the replies so far! I will try to break them down to actions I can apply/ offer to my work/ team.

@Ian Mitchell I don't think they are. I have a hard time talking about the Scrum Guide because they often block of/ make fun of what I say. Not really in a mean way but like "She doesn't know reality in a software developing company as a recent university graduate". It's hard to say it works when I cannot show them that I have experience with it working. I am also the first full time SM in this company. So far, developers took a Scrum workshop and now they are considered the Scrum Master & a Development Team Member. So most teams follow the meeting structure and they often also release in regular intervals but I am unsure about them bringing in much knowledge about the scrum guide, the scrum values etc. Therefore, I am having a hard time standing my ground in that respect. I did push for a "Scrum presentation + re-evaluation of how we apply scrum" for this sprint. They took it grudgingly. We are having many meetings at the moment even without all the scrum meetings but that's another story.

@Daniel Wilhite thanks for the tips and information. I'll try to test out/ suggest some ideas asking them to trust me for a little while and then see if it's working. As I stated above I have a meeting planned where I want to (re-)introduce the scrum values and their purpose/ goal. However, you might be right that I should start working on commitment and respect before focusing on transparency. I have to re-evaluate what I consider most important/ or rather most problematic to focus on first. Maybe I'll just go into the meeting and state a few things I consider problematic and let the team discuss what they care about most. Nevertheless, I am afraid the "strong" members will do all the talking and the reserved members will not speak up. I want to avoid that actually. 

About Kanban: I guess I really have to read more about it. I heard about it a few times and I read a sort of summary but I wasn't sure how to use it correctly and effectively.

I am open to suggestions as to what I should try/ focus on as a new SM. I know I lack experience and my network consists of only SMs within this company so far. I will attend a SM course next month and I hope to network there but I guess I have to look for more resources in general.

I have a hard time talking about the Scrum Guide because they often block of/ make fun of what I say. Not really in a mean way but like "She doesn't know reality in a software developing company as a recent university graduate".

Don’t expect that to alter any time soon. I graduated 21 years ago and I still experience the same thing. The pressure is always on to change Scrum to fit the current organization, rather than to change the organization to better support agile practice. My advice is to focus on providing transparency over the gaps. A key part of this is being very precise and knowledgeable about what the words in the Scrum Guide mean because they essentially represent change.

Miriam,

I admire your courage and also your efforts to put things into perspective.

As Ian said, as SM (or AC), you will always meet *some* people who'll look down on you beause you don't understand the importance of whatever it is they do for a living and who think what you do is c__p.

Here are some ideas that may help you:

• As a rather inexperienced SM, you need to learn to listen. Listen to what is being said, but, more importantly, "listen" to what isn't. Ask questions.
• I'll say that again. Ask questions. Ask as many questions as you have to. Even if your questions may seem stupid (or could, in fact, be stupid), we all need to learn and discover, then find ways to improve. Phrase it like "I'm sorry if this is a stupid question, but how does ........ work?"; "Please forgive my naivete, but why not do it this way?"
• The more questions you ask, the better you'll become.
• The more questions you ask, the more transparency you'll bring.
• Make sure you share with the team your concerns and the problems you see. Suggest improvements or alternatives, and always discuss it with them. If they won't agree, then at least you tried. Keep track of all your findings, suggestions, meetings and outcomes (I mean, don't think you'll need to be a secretary, but you need to be able to show to anyone in the organization how things are, and provide evidence supporting your findings)
• Be nice to all, even if some are jerks to you. Show them you're actually living & breathing many values, including common sense.
• Don't be afraid to ask for support or guidance from your manager(s). Be honest and strong. Tell them why you consider things to be wrong, show evidence, and suggest other courses of action, and explain why there's a need to change. If they're not obtuse, they'll understand. And even if they (for whatever reason) won't support you, you'll at least be satisfied you had acted.
• Last, but not least, it's a job. But there are other jobs. So, if, after a while, you decide you can no longer continue working with them, find another company. By the time you do that, you'll be far more experienced than you are now, so you won't be in a worse spot.

Can some of these ideas help you draft an action plan to address (some of) the issues you had described? I sure hope so.

Thanks again for the kind replies! It feels like you can emphasize and truly understand my questions/ concerns/ troubles. It's actually really great to get that feedback.

I will try my best at taking your ideas and putting them into action. I am already asking a lot of questions but I think I can top that and ask even more. At least I'll try.



I decided to change the next retrospective a bit and make it more open. I will say that I recognize a vast number of topics as "improvable".

However, I will state them as questions like such:

How can we achieve that everyone knows at which point in our delivery process we are, at any given time?

How can we improve the communication within the team so that we always know what other team members are working on?

How can we make sure that when one member falls ill unexpectantly, we can take on their work or at least judge whether it makes sense to continue their work immediately?

....

I also plan to “re-introduce" Scrum from its core. Describing what the values and principles stand for. I think they see Scrum as a number of actions/ meetings used to structure work but I want to show them that it’s actually so much more and that the actions can be changed but the values should not be compromised :)

Again: I will keep on watching this post and I will gladly read all the replies to come. Maybe someone else has a similar problem in the future and is happy that this post exists.

I echo the statements that you will always run into resistance.  A few tricks I've used.

• Remind everyone that anything they agree to try is an experiment and in 1 sprint you can reassess whether it worked or not.
• Don't be afraid to call out the "silent' members in discussions.  I will frequently cut off the dominate people by saying "I appreciate your input and I think everyone here knows how you feel.  But how do <pick one of the quiet ones> feel about this?"  Often the silent ones will remain silent until given an opportunity to speak.
• As with all things agile and scrum, don't try to do it all at once.  Incremental deliverables (i.e. changes in behavior) is the key.  Inspect and Adapt apply to everything in agile and scrum, even procedural improvements.

Good luck.  It sounds like you are going to become a great Scrum Master.

Miriam,

If I may, I'd like to offer my perspective as someone who has been around the block a few times as a team lead, 3rd line support manager and engineering manager, as well as pitching in as scrum master when the need arises.

You mentioned in your postscript that you

have no background in software development

Are you able to communicate with your team members in their 'language' of software development? If you're up for it, it can be useful for you to go through some tutorials on the dominant tools and programming language used by the team. This is mainly to help with communication and building rapport, and was exactly what I did when I first joined a company to manage a couple of teams that were using a tech stack that I wasn't familiar with. Also, I echo @Eugene M's point on listening and asking questions. (As a manager, I still constantly remind myself to listen!)

With regards to the transparency problem within the team leading to the issue of

afraid to use code written by some team members when they go on vacation before the release

the measure I took to help address this is to include the explicit step (in process a well as on the JIRA board) of a peer performing code review as part of the Definition of Done. (As an aside, does the team have an agreed Definition of Done?) Peer review allows a team member other than the original author to know what was done if the author goes on vacation. Note that peer review is done right after code commit, prior to merging into the main/trunk code branch, not at end of sprint. (With GitHub, this will be at pull request time.)

How can we make sure that when one member falls ill unexpectantly, we can take on their work or at least judge whether it makes sense to continue their work immediately?

That's a great question, and hopefully the team can come up by themselves a way to address that - it's easier for team buy-in if the idea is the team's rather than yours.

As for transparency outside the team, in my opinion it needs to be tailored to the company culture and history. The misuse of burndown chart in the past to pressure the team to 'perform better' is something that has to be taken into account. As an alternative, for one of the teams I managed in the past I made a point to publish a blog entry on Confluence at the end of each sprint outlining what the team has managed to accomplish, and the challenges the team faced, written in a positive tone. I also explicitly mentioned the people whom I'd like to draw attention to (e.g., stakeholders), along with specific members in and outside the team that have done something noteworthy in the sprint. (Confluence sends email notifications to all names mentioned.) This does not mean you should avoid using charts such as burndown. You can still create them for your own or the team's internal use only (i.e., not communicated outside the team), but you'll need to first work on building trust (and again, rapport) with your team members that the charts will not again be 'misused'.

On the team

help out the support with customer tickets

I know from first-hand experience that it can be very disruptive. The volume of such work is by nature rather unpredictable. One way to alleviate this is by setting aside a number of story points per sprint as a 'buffer' to 'absorb' support work. Another way is for a team member to volunteer or be assigned as a free-moving engineer each sprint to take on support work, and if there is none, to work on low-priority stories (which the engineer may not be able to complete due to support workload.)

The other aspect to support work is transparency and communication to stakeholders outside the team. This, again, goes back to company culture. @Daniel Wilhite made a great point about using Kanban's WIP (Work In Progress) measure. There are even diagrams for this - Control Chart and Cumulative Flow Diagram (https://www.atlassian.com/agile/project-management/metrics). They help visualise bottlenecks and shortages so that the data is made available, and action taken to address them. They also work to highlight the issue of almost-finished tasks, and the need for dedicated testers - bottlenecks. However, if there remains a culture of distrust that they will be 'misused', probably best use them only within the team, and summarise the as talking points in your sprint-ly blog.

On the long list of improvements, keep up at introducing them slowly and incrementally (i.e., hare vs tortoise) - 'incremental deliverables', as @Daniel Wilhite put it. Try each for a couple of sprints - 1 to get feedback and make adjustments, and another 1 to truly assess if the improvement does work. Work with the team to prioritise those that are non-controversial and widely agreed to build momentum. Taking a page from change management, it can also be helpful to have a 'champion' from within the team for each improvement to help promote the improvement for it to have a better chance of succeeding, and to continue to be practised. I agree with @Daniel Wilhite to explicitly call out 'silent' members to get their input on this. I have done that before - it works.

Finally, I don't think it is necessary to mention the Scrum Guide or explicitly restate the Agile values and principles. The excellent values @Daniel Wilhite mentioned can be introduced as if they are standalone as part of the improvement practices - something practical rather than abstract and theoretical. I've found it useful to frame them as desirable improvements rather than specific problems that need fixing. The questions you listed are good starting points.

Hope this helps!