Agile or Scrum don´t matter! What matters is software delivery!

Agile or Scrum don´t matter! What matters is software delivery!

My first official Scrum Master gig, about a decade ago, was in a large telecom. The team I was working with was updating the activation software that dealers used for on-boarding new mobile customers, changing price plans and add-ons, and such.

At the time, my mindset was firmly entrenched in Scrum dogma. As a relatively newly minted CSM, all I knew was Scrum.

I valued transparency, and courage so when it came time to start our agile project, I invited all outside stakeholder groups to our bi-weekly demos. That included marketing, various business units, trainers, directors, managers and more.

The reaction to the demo was mixed. Some thought it was a waste of their time and others thought it was ok. We noticed that over time, only the corporate trainers, and a couple of sponsors continued to attend. They were responsible for updating training documentation, and for training the in-store reps on the changes.

 Our team had clear marching orders:

– decrease the total activation time from X to Y (I can’t remember the exact numbers)

– decrease the total number of screens from 18 to 5 or something. (I can’t remember the exact number, but the existing flow was convoluted)

As I write this story, I imagine people who have the mindset I had a decade ago would say: “BUT YOU CAN’T DO THAT!!! TELLING THE TEAM TO REDUCE THE SCREENS FROM X TO Y IS GIVING THEM A SOLUTION!!!!!”

To which I say, relax will ya? It clarified the intent of what the business wanted, which was to make it easier, and faster, for reps to activate devices so they could make more money.

“BUT STILL….THEN SAY THAT INSTEAD OF GIVING THE TEAM THE SOLUTION!!!!” you may say.

Again, relax…which leads me to the point of this post.

 I always believe the role of the scrum master was a servant-leadership role which, to me, means that my opinion of how things should be, is irrelevant. I serve the team, the team serves the organization who serves their customers so we push-and-pull to figure out the best way to deliver solutions.

As I learned more about agile, I was still confused about why business folks would care about scrum or agile at all. Aren’t they interested in getting stuff done more effectively from idea to production versus wanting to know how agile they were?

I verbalized this confusion at an agile coach camp and generally speaking, I was met with a “you just don’t understand agile” attitude. Funny thing is, today business agility is all the rage so I guess I was right and those experienced coaches were wrong.

And yes, I’m poking fun at the community I love, so don’t take that seriously! That said, for a community that values inclusion, I see this at every conference I attend. Project managers come in with legitimate questions about scrum and agile, only to be made fun and chastised from the very people they’re wanting help from. I’ve been guilty of this as well.

Ok, rant over. Back to the story.

Our team had implemented some testing automation at the GUI level in order to capture before-and-after screenshots for the trainers after every sprint. This way, they could see what was different and they could incrementally create their training documentation.

We went live with zero known defects which was a first for this organization. Our product owner, who to this day is the best I’ve ever worked with, sent out an email on launch day to that effect. I wish I still had the email lying around as proof.

To this day, I’ve yet to work with such an amazing team. For some reason, the stars were aligned and things just clicked.

 These were some of our victories:

• We wrestled deployment away from the deployment team and when it was time to release, we’d come in at 4 or 5 am and do the deploy ourselves.
• After the first sprint, as usual, testing was crammed in on the last day so one of the developers, who was also our technical product owner said: “maybe we should help the testers next time?” That sparked a team agreement: testers will create the test cases and distribute them to the developers, the only rule is, you don’t test what you built.
• Before mob-programming was a thing, we spent an afternoon once a month doing it. We were using Find Bugs ( http://findbugs.sourceforge.net/ ) and decided to bring one laptop into a conference room and smash all the red bugs. It just felt like a good way to learn and share technique, we didn’t know it was a thing.
• Because we had a diverse team, in one retrospective we had each person write all the team members names in their native language like Urdu, Sandscript, and Mandarin. We didn’t intentionally do any team-building, we just liked each other and thought it would be fun.
• When we had our first production problem, I was hauled into the Directors office for a beating, to which I told him to have the people who came down on him come and talk to the team because it wasn’t fair to him. By the way, that never happened, but we made the offer.
• We used Rally and not sticky notes, but we all sat in cubes in the same area so daily collaboration was easy.
• We continued to involve downstream groups in our demos, and sometimes our planning if we thought there would be an impact.
• I sent out a half-page report telling all interested parties what our sprint commitment was, what the output of our retrospective was (only the stuff that was relevant to people outside the team), and again at the end of the sprint with a summary of what happened.
• We had a PM who managed all the budget and other stuff. He never poked his way into the team and to this day is one of the best PMs I’ve ever worked with.

Everything our team did felt like the right thing to do. Never did we use scrum, or agile, as a stick. We knew our purpose, we had a clear objective, and we had a great team.

I feel fortunate to have started my scrum master career in a large organization because it helped shape my view that scrum and agile don’t matter, and people outside the team care about software delivery, not dogma.

These people might have the dreaded fixed-mindset, and there’s nothing wrong with that. As a community, we need to stop clunking people over the head with the dogma stick, and instead, empathize with what’s important for them.

Yes, reporting status to the scrum master might sound stupid for some people, but do you know if that scrum master has people who expect some type of report? Do those people have other people higher up that are expecting some type of report?

There are some simple questions you can ask yourself when it comes to interfacing with the rest of the organization:

• What are they wanting to accomplish with Scrum?
• What is the organization’s tolerance for disruption?
• How intentional should you be about disrupting the status quo?
• Who stands to win, and lose, when the organization is disrupted?
• What up and downstream teams, processes, and departments are affected by what your Scrum team is doing?
• When should you swim with the organizational current and power structures, and when should you swim against them?

I find it helpful to map this out to understand the organizational ecosystem so I can figure out which constraints are real, and which ones are artificial:

 As a homework exercise, if you’re working in a multi-team environment, or an organization with more than 100 people, map this out on a wall.

There is no magic to scaling agile, there is only a conversation with those who are impacted by what your team is doing. You don’t need a big framework or method to understand how to deliver solutions, simply visualize your system, involved the people affected, and come to an agreement about what you’ll change, and what you’ll keep the same.

Use a diagram like this to figure out what you might be disrupting so you can make a choice about how disruptive you should be.

Above all else, get curious, not furious.

If you liked this article, feel free to visit my company Products and Services pages.

We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting, Innovation Training and Innovation Consulting.

With my team, I built 5 main products: High Performing Teams, Scrum Team Coach, Scrum Master Mentoring, Organisational Mastery and the External Business Accelerator.