by Jerry Doucett and Valerie Senyk
So 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 outright 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 they 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 and transparent that you are practicing Scrum to the extent possible.
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 explicitly use Scrum terminology and language 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 are aiming for, you will need to stop them regardless of whether you think they should work or not.
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 them in how you show up and in everything you do, even explicitly calling out certain actions when they are a prime example (and of course, 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 your organization does 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 has been done, what still needs to be done, and what challenges the team is facing. The key here is to keep it mercifully short, focus on what needs to be done to move work forward, and define actions to address issues. Then always follow up and make sure the actions are being pursued and progress 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 is important, and what the desired outcomes are.
To this end the goal should never simply be to have teams adopt Scrum. The goal should be to become a learning 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 specific scope for each meeting. Setting a time limit and specific 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 if you really want to be successful, 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 Agile practices and Scrum, 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. Then, 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 and rank-ordering 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, when possible 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 specifically 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. Then, 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 or a reflection.
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 are not cheap nor are they 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.
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 likes to say, “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.