August 6, 2020


News for Agilists

Enter Sandman. Bureaucracy — the stuff of Nightmares | by Harry S Long | Serious Scrum | Jul, 2020

Bureaucracy — the Stuff of Nightmares

If you’ve been a Scrum Master longer than 9 months, you know that a lot of the job is handling the “admin work” for the team. Especially if you are in a fully collocated situation! Many in the US have to deal with a LOT of paperwork. Status reports, organizational meetings, metrics and charting, an endless stream of leadership questions and re-directs have to be addressed.

Of course, there are the ever-present Scrum Master team sessions! There are budget, resourcing, schedule, coordination, training, coaching and all other things that have to be picked up by SOMEONE on the team. If you designed your team correctly, they mostly have day jobs. Jobs like coding and designing and testing…

Image by Stefan Keller from Pixabay

A Scrum Master can go a little nuts trying to help with the admin load. And hope to help the team and the organization to make good Scrum-based decisions. If there was only someone else, who if you could work with them that might be able to make some of this disappear. We don’t need a “Super Man” type to take on all of it, some of the metrics can help the team. Some information is critical for the organization to realize the ROI — and help us code another day. Who would possibly be able to take on this paperwork beast and help the poor Scrum Master out?

Luckily for us, if we slow down and listen, we can find just such a hero. Usually, if you are working on a mid-size organization, they are right there in front of you. Most of the time, us Agile Types are too quick to write them off. But if we are smart, and get to include them, they can lighten that load significantly. They are hiding in plain sight, so much so, that many in the organization could confuse the two of us! I’m talking about the Project Manager.

Dancing with the Devil

I know, I know — PM’s do waterfall, they can be included in SAFe blabbity blabbity blah. And the PM has a reputation — he’s the guy that “bugs the team” with endless requests for status. He’s the guy that more than anyone represents the Waterfall model we are fighting against. He’s the one that badgers the team to go faster, and in a worst-case scenario will direct the work just so things “stay in budget” or “stay in phase”. He’s the BAD GUY HARRY — HE’S THE SANDMAN!!!

Unless — you see what he does, and work with him to figure out how to help one another. Some of my best mentors were Project Managers. They taught me how to help a team, how to NOT get in their way. It was these guys that taught me to slow down, to listen more closely and to help remove blocks from the team. This may mean little to you, all SM’s “remove blocks”. But I am ruthless in identification and demolition of blocks, because “a bad system will beat a good person every time” and the PM’s taught me to see the system. To flow in it, to understand the WHY of how things worked — including funding.

The Headless Horseman

On my last couple of engagements, I worked with organizations that were trying their first agile transitions. Both of these companies had a full PM community, one out of need and the other out of history. In both cases, the PM was “added” to the team without information or consultation — they just started to show up. I remember not being 100% comfortable with this move. It was unannounced and a bit of an imposition by leadership that was not fully engaged in the product development cycle. In both cases, the PM was voluntold to show up to account for the budget.

I remember the stand-up with the new team assigned to me. I was the new Scrum Master, there to help the team achieve some sense of stability and delivery. The team had tried to work without a SM for a while and had come off a bitter disappointment. As I introduced myself and reviewed some expectations, I noticed many stakeholders were present at this meeting. I had assumed this was a large team, but the twenty plus people in the 16 person room had me taken aback.

Nonetheless, we covered who we were, what we did and “walked the Jira board” as the team had done for a while. I noticed that many of the attendees asked questions ad hoc, but did not participate in development. I would later discover that these were representatives from Marketing and other areas. One person, in particular, was a little disruptive, and he drew my eye.

The next day, I re-acquainted the whole room with the Stand-up guidelines. The members of the team had a right to speak about their work, and if you had no work, you would hold your input until the end. If you had bigger questions, you would speak to the Product Owner or the Scrum Master after the meeting and we would work to help you out. In summary, the team was to be allowed to coordinate and collaborate to be able to meet the Sprint Goal.

The disruptive gentleman gave me a glare! He was not having any of this. But, he politely put up with that session, and at the end made sure to tell me that he would not leave the session without budget answers. I was equally upset with this person, and let my leadership know about it!

As the sprint progressed, the time we spent in stand-up was reduced. And stories started to finish. The team was able to address some of the planned bugs, and even took on and completed a couple of unplanned items. Given the improvement, fewer stakeholders showed up. But my friend was still there, in some cases wanting to ask developers questions in the middle of the sprint. We had to have a talk.

Interestingly enough, my friend would not speak to me! I stopped him at the start of the next sprint, with the Product Owner, and asked him what we could do to address his visible concerns. He shrugged us off but started to come only every other day. This slowed the second week of the sprint, he was only there once. And after that, maybe once a sprint. I was a bit confused!

But the team had improved in the working of the stand-up and in their delivery. The noise reduction resulted in productive demos, and in forwarding progress. Things were now going significantly better. The feedback had changed from punitive to curious and slightly optimistic.

Three sprints into this new team I was nominated for an award. I was stunned to receive such recognition. This was a small award for the work I was doing in this team. I was shocked to find that I was nominated by the Project Manager. He wrote that I had done such a good job with the stand-up, he was getting all the information he needed by simply attending. He could now rely on the information from the team, and if he had any questions he knew who to ask.

The budget and reporting clouds had cleared. We had fewer issues (and less noise) from the stakeholders. Removing the noise from the meeting allowed the PM to clear the path for us to receive more funding. It empowered the team to do the best work they could and also helped to elevate the mood of the whole project.

Similarly, while helping a non-software Network team, we had a small but critical project. The PM was the link between funding, a coordinator with the third party supplier and the clients who were requesting the work. In this instance, we met upfront; and kicked off the sprint work with full connection and transparency.

In this case, communication with the stakeholders allowed us to handle one large issue that arose due to an engineering error. The potential to have this blow up into escalations and contingencies was palpable. But the team working together handled this big issue. Within the first report of an issue to the stakeholders, the item had been corrected and overcome.

Again, high-level information and timely collaboration left the PM holding a bag of praise for the team and for himself. Without me having to do any additional reporting! And again, the exposure (and respect) for the team handling their work during stand up was the main reason the PM was able to handle the flow of information.

The project went off seamlessly, and to the surprise of the PM, ended ahead of schedule. The stand-up was the primary tool for information gathering and sharing. Once the project ended for the team, the main concern was unusual. Without the stand-up, how would the stakeholders receive such high quality and timely information?

I had to explain that the stand-up was a working session for the team while we had work. With full delivery, and no work remaining, it would become a waste of time for the engineers to still meet. Not to mention we would not have anything to speak about! Grudgingly, they agreed to end the stand-ups. But not without making me promise to be 100% available to any questions!

To sleep, perchance to Dream

In both cases, I could have requested the interruptions to be removed from the team. The Product Owner and I would have had to handle the stakeholders. We would have had to send a formal status every time someone in leadership felt slightly uncomfortable. I would have 7 reports to file, instead of 3. We would be the “single wringable neck” of old-time Scrum. We would have no help to handle all the admin issues associated with a load of showing progress to the finance and accounting departments.

But I chose to embrace the Sandman — and my nightmares simply disappeared. I still had a big enough challenge in BOTH of these organizations, as is evident from the writing. But paperwork and admin issues outside of the team were gone. This allowed me to focus on my passion, helping the team (and leadership) understand and embrace Scrum and agility a little bit more. That made some of my dreams come true!

Do you want to write for Serious Scrum or seriously discuss Scrum?

Source link