Do teams truly grasp the power of applying Scrum professionally? This is a challenging and somewhat contentious question. In my experience, many teams I’ve encountered operate more like amateurs than professionals. This isn’t necessarily their fault; it’s often a reflection of the expectations set by their organisations. Too frequently, companies don’t demand professionalism; instead, they push for speed and output, which leads us, as software engineers, to adopt shortcuts that prioritise the easy, fast, and cheap over the right way of doing things. This environment fosters unprofessional behaviour and ultimately undermines the potential of Scrum.
Understanding Professional Behaviour
Most teams lack a clear understanding of what professional behaviour looks like. I recall an enlightening experience with an organisation a few years back. We conducted an exercise aimed at defining what requirements should look like for the engineering team. This wasn’t about the engineers themselves; it involved the product management group.
We gathered everyone in a room, broke them into cross-functional groups, and tasked them with dissecting a user interface from their product. They were to outline the requirements they would have liked to have had, with the benefit of hindsight. The results were eye-opening. They crafted detailed requirements, highlighting the myriad questions they had and the information they lacked. The realisation hit them: “Holy moly, that’s a lot of stuff.”
Then came the second part of the exercise. We asked them to take something from their backlog that hadn’t been built yet and apply the same level of detail. Just as they were getting into it, the head of product management halted the workshop. He candidly admitted that his team wasn’t equipped to create or work with such detailed requirements. This moment of realisation was profound; it illustrated the gap between the professionalism we aspired to and the current capabilities of the product management team.
The Role of Scrum in Professionalism
This scenario is not unique; it reflects a broader issue within many organisations. One of Scrum’s core purposes is to foster transparency. A fundamental expectation for any software team is to deliver a usable, working product at the end of each iteration, including the very first one. This product should be production-ready—this is the minimum standard for Scrum. If your team isn’t achieving this, then you’re not truly practising Scrum; you’re missing the level of transparency required for a professional Scrum team.
Many teams come to a stark realisation: “We’re so far away from that.” This can be a tough pill to swallow. As teams strive to meet this standard, they often uncover gaps in their processes. For instance, they might find themselves reliant on a third-party testing team, which complicates their ability to ensure production readiness. I remember a time at Merrill Lynch when we submitted our websites for third-party penetration testing. We had no insight into the tools they used, and the process cost us a hefty sum. The result? Our product was not ready for deployment because we lacked understanding of the testing tools and processes involved.
Embracing a Professional Work Ethic
The true power of applying Scrum professionally lies in cultivating a professional work ethic. This means creating products that deliver real value to our customers—products they can use and appreciate. Many teams only begin to understand this concept as they embark on their Scrum journey. They start to recognise their knowledge gaps and gradually build the capabilities necessary to evolve into professional teams.
In conclusion, the journey to professionalism in Scrum is not an easy one, but it is essential. It requires a commitment to transparency, collaboration, and a willingness to confront the uncomfortable truths about our current practices. If you’re interested in discussing this further or exploring other topics related to Agile, Scrum, or DevOps, I invite you to book a coffee chat with me through Naked Agility. Let’s work together to elevate our understanding and application of Scrum to truly professional levels.
So the question is, do teams really understand the power of applying scrum professionally? This is a really hard one because I, or contentious one, because I don’t think that most teams I’ve ever worked with, like professionals, they act like amateurs. And that’s not necessarily their fault; there’s not a blame there. It’s just how companies expect. They don’t seem to expect us to be professionals and do the right thing. They want us to do their thing at whatever speed they want us to do it at, which means that we are, as engineers, as a software engineer for many years, we’re encouraged to do things the easy, fast, cheap way, not the right way. And that encourages unprofessional behaviour; it supports unprofessional behaviour.
So most teams don’t necessarily understand what professional behaviour looks like, even to the level of… I worked with an organisation a few years ago, and we did an exercise on what requirements should look like for the engineering team to take them on. So this was not the engineering teams themselves; this was the product management group. And we did this exercise where I love it, get everybody in a room, break them into groups, cross-functional groups, and then they have to take some user interface from their product and break down what the requirements they would have liked to have with hindsight, right? So they build these lovely detailed requirements and how much detail and all the questions they had to go ask and the stuff they didn’t know, and they built all this. They’re like, “Holy moly, that’s a lot of stuff.”
And then we started the second part of the exercise, which was take something off their backlog that they don’t have right now, that they haven’t built yet, and do the same thing for it, right? So they’re trying to build out these requirements, and the head of product management stopped us, stopped the whole workshop, and basically said that him and his team were not set up to be able to do this. Just, “We’re not fundamentally capable of creating and working with you to build requirements of this level of detail that we obviously now see this is what you needed in the first place, right, that we’ve never given you before. But we’re not set up to do it.” That’s like a moment of realisation that professionalism is up here and your capacity to deliver is down here, right? This is where we need to be. This is where a professional product management group is interacting collaboratively with the team, figuring out what it is they need, working up front, getting ahead of the curve of the things that the teams need so that everything’s ready at the right time, and they just weren’t ready for that.
And I think that’s true in lots of parts of organisations, not just on teams and scrum teams. And one of the purposes of scrum is to make those things transparent, right? You’ve got to try and do these things that you’re working. One of the minimum professional things that a team, any team, if you have a software team, they absolutely should be able to create usable working product every iteration, including the first, that is production ready. Right? That’s like minimum bar for scrum. If you’re not doing that, if you don’t have that at the end of the Sprint, potentially shippable, not ship, potentially shippable, right? You’re not doing scrum yet; you’re just fundamentally not at the level of transparency that you need for a professional scrum team. And so many teams look at that and go, “Holy crap, we’re so far away from that.” It’s insane.
Right? That is a hard place to be, and it’s a hard realisation, not just for the team, because as the team tries to get there, they’re going to realise all the things they don’t have, right? “Oh, but we can’t create production ready because we’ve got a third-party testing team that comes in and does testing, so how do we know that stuff? How do we know what they’re going to come up with?” Or we submit it to… “Oh, what did we used to do at Merrill Lynch, PWC? It’s also some company we used to submit all of our websites to that would then do a third-party penetration test, and we had no idea what tools they used to do those. They call it just the pen testing cost 15 grand to do a pen test, and you would get an output of stuff you need to go fix.” Well, it wasn’t done right; the product that you created wasn’t done, wasn’t ready, wasn’t shippable quality because you don’t understand those tools that they’re using. You don’t understand those additional checks, and you need to.
So I think the power of applying scrum professionally is understanding what it takes to be professionals and create, have a professional work ethic where we’re creating something that our customers can use, that they can get value from, that they value, right? And most teams don’t really understand that until they start, and then they start to understand what they don’t know, start to add more capabilities in there, and they eventually get to being professional teams.
Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else, agile, scrum, or devops, then please book a coffee with me through Naked Agility.
