Practicing Scrum (subversively): you CAN do it!

You want to be practicing Scrum! You’ve taken Scrum training, received your industry certification, and perhaps even experienced being a Scrum team member. In your heart you believe Scrum is the right tool and approach for you, and you believe your current organization and your customers could really benefit from Scrum practices. 

However, for whatever reason your organization is either hesitant to consider Scrum or believes it’s a bad idea. Perhaps there was an experience with a poorly executed pilot. Perhaps your leadership see it as being too risky.

What do you do?

This article explores how you could subversively practice ScrumMaster-ing in your workplace without getting into trouble or breaking the rules. (Ssh…we won’t tell!)

Before you even begin strategizing, you need to ensure that what you do aligns with the Scrum values, namely:

Doing Scrum subversively will certainly take considerable courage, focus and commitment on your part. Be aware you will be challenged to respect the existing organizational culture and norms, and your organization may push back on your efforts.

You also need to acknowledge that the very act of being subversive means you are not being completely open or transparent that you are trying to practice Scrum.

Or you could tell your workmates, “I’ve had this terrific training in Scrum and could we try a few of the techniques to see how they work?” Then introduce something as simple as time-boxing or holding retrospectives with your colleagues.

You will also want to ensure what you do is harmonious with Scrum Theory and the pillars of empirical process, which are:

1. Transparency 2. Inspection 3. Adaptation

Normally, one could say there’s a direct conflict between being transparent and being subversive. Keeping this in mind, it is imperative you be absolutely transparent on the actions you are taking and what the specific goals, outcomes or learnings are that you hope to achieve.

However, given the circumstances you’ll likely choose to not use Scrum terminology to describe what you are doing. In other words, describe the practices and activities that you are implementing or recommending, express their benefits and what you hope to accomplish, but don’t explicitly call them by their Scrum name.

As for Inspection and Adaptation, those approaches should be perfectly aligned with your intent to try to help your company become a learning organization. That means you will need to park your ego at the door and accept the results. If your learning shows your subversive Scrum activities do not provide the benefit you’re aiming for, you will need to stop them regardless of whether you think they should work.

Let’s explore some activities and practices you may want to tactfully consider to help your organization benefit from Scrum (without actually “doing” Scrum).

1. Lead by Example

As someone that appreciates the values of Scrum, you should aim to educate others and provide them with a similar understanding. That means practicing these values in how you show up and in everything you do, even explicitly calling out certain actions when they are a prime example (whenever it is appropriate).

This does not mean preaching! Instead, it could be sharing your thoughts about something when contributing to a decision, or simply pointing out when and how something that aligns with the values contributes to a better team, a better experience, or a better solution.

Leading by example also means being human and honest when mistakes are made or when failures occur. This can be particularly risky in an organization that has not embraced Agility, or where failure is frowned upon. That is where you need courage, and a commitment on your part to hold improvement of the work above your own individual career needs.

2. Communicate More

Make a concerted, conscious effort to communicate with your team and partners more. For example, get up out of your seat and spend more time in informal face-to-face discussions rather than sending e-mails or chat messages.

Perhaps you can have short, informal meetings with just the team either daily or several times a week to see what’s been done, what needs to be done, and what challenges the team is facing. The key here is to keep it short, focus on what is needed to move work forward, and define actions to address issues. Then always follow up and make sure the actions are being pursued and that progress is shared with the team.

3. Be Open And Transparent

Although you may consciously choose to not use the proper terminology and language of Scrum, the key is to always be honest about what it is you are trying to do, why it’s important, and what the desired outcomes are.

To this end the goal should be to become an organization that “learns about learning”, constantly tries to improve, delivers value faster, and applies new knowledge in the best possible way. Scrum may be a fantastic catalyst for that, but there are many other approaches that will achieve similar results.

4. Use Better Meeting Practices

Another approach to consider is improve meeting experiences by time-boxing and defining a specific scope for each meeting. Setting a time limit and outcomes for a discussion helps create a sense of urgency, manage expectations and focus the conversation on the most important topics. The facilitator will need to enforce these constraints, otherwise you lose the effectiveness of the practice.

5. Have One or More Key Stakeholders Empowered to Make Product Decisions

This may be a considerable challenge in organizations where there is little appetite or understanding about Scrum practices, but do what you can given your authority and influence. If possible, try to have a single voice (key stakeholder) defined as the person with the final authority on the product or service that your team is delivering. Work with that individual to set them up for success by connecting them with the other stakeholders, perhaps facilitating discussions with them, and showing the key person(s) effective techniques for prioritizing the work that is being asked for.

6. Limit Efforts to What Matters Most

One practice that is important to apply, but often difficult to master, is focus. Limit work and discussions to the most important tasks and activities, and request that other discussions on lesser-important work be delayed. Always try to focus the conversation back to what is currently the most important work.

On occasion you may even want to point out times when plans were well-defined in advance but ultimately changed a lot when the actual work was in progress. This indicates the waste in planning too much up front and in constant task-switching. When done in conjunction with time-boxing this practice becomes a little easier.

On a macro scale, try to limit development to smaller chunks of end-to-end deliverables. In other words, deliver small things often all the way to completion as much as possible (e.g. to a staging environment). Then show the outcome and deliverable to stakeholders and customers, explaining that although the final product may not be done, this is to get them something fast and gather feedback.

7. Reflect on Learning

When possible, ensure that reviews of completed work happen frequently. Ensure the outcomes, functionality and value is shown and that learning (for the product as well as the methods) are part of the discussion.

Without becoming intrusive, seek stakeholder feedback frequently and informally. Be willing to demonstrate an ability to pivot plans based on that feedback.

As a team, hold informal retrospectives of how you worked together. If the term “retrospective” is contentious, consider calling them something else, such as a debriefing.

8. Visualize and Display Work

Have your own personal backlog and list of current activities visible at your desk. Use post-its to represent all work that you have on your plate, and ensure it is always up-to-date. Prioritize the work items you have coming up, and visually represent this as a rank-ordered list of things that you have to do.

It won’t take long for people around you to notice what you are doing and ask about it. Use this as a great opportunity to educate others on the values of transparency and focus.

9. Keep Your Team Size Appropriate

If you are on a particularly large team, see if it is possible to split that large team in to smaller groups. The benefit is more face-to-face time and interaction across the new team, an increased sense of belonging and commitment to the new team’s purpose, and it should also be easier (in theory anyway) to get decisions made and increase alignment.

The challenge will be finding a logical way to split the teams to mitigate dependencies of people, skills and products, and ensuring the new teams can still collaborate with one another. Geography might be a good way to split the team if you are distributed, but you would need to ensure all the skills to deliver the solution exist on all new teams.

10. Push for Automation

If you are in a development environment where tools, automation and engineering practices are not currently being used, and they could be of value to your organization, then start investigating whether it is possible. Tools and automation aren’t cheap or easy to implement, but they dramatically encourage you and your teams to collaborate better and they enable the adoption of Scrum practices such as fast delivery of value.

Final Note

Be confident that your own creativity may help you unlock ways of practicing Scrum methodology without disrupting your organization’s practices.

You may or may not be able to implement all of the above actions but, as one Agile coach says, “it’s all about how YOU show up, how YOU are.” In the final analysis, your example, your enthusiasm, your courage will be the best you can offer.

by Jerry Doucett and Valerie Senyk

If you find this useful, please consider contributing with our
“Value for Value” model.