Agile Pain Relief—Certified ScrumMaster Training and Consulting.+Add.Feed Info1000FOLLOWERS
Agile Pain Relief provides Certified ScrumMaster training courses and Agile Consulting to help individuals, teams, and organizations learn Agile and Scrum. Follow this blog to get the latest Agile news, tips, resources and much more.
“I’m not here to experiment. I’m here to get production stacks out the door, and Agile helps us get there.” — Tim Burke, VP of Cloud and Operating System Infrastructure Engineering at Red Hat
Yearly since 2013, Scrum’s certifying body, Scrum Alliance®, sponsors the State of Scrum, a survey of more than 2,000 of their member Agile and Scrum practitioners across 91 countries. The survey data is then analyzed prepared into an annual report. The 2017-2018 report just came out last month and we’ve now had a chance to go through it.
While the numbers were encouraging (particularly the ones that show that once a team or organization becomes Agile, they will almost never go back), one of the most stand-out parts of the report is the short case study on Red Hat Inc.’s adoption of Scrum – a timeless example of how to overcome administrative or executive apprehension about bringing Scrum or any other Agile framework into the mainstream of an organization.
Red Hat, in the business of providing IT product solutions, found itself getting slowed up by traditional “waterfall” structures for building and delivering products to their clients as they got larger. When it came to the implementation of Agile as a solution to this problem, their executive management was concerned that Agile would lead to a loss of control over their ability to deliver.
To overcome this doubt, they implemented a simple approach: use Agile to implement Agile. Instead of rolling out the new paradigm, they integrated Agile methods into their existing waterfall model. Over time, Agile has slowly become the mainstream mindset for work at the company. They focus on how diverse, multinational teams engage and share information, both between themselves and their customers. This emphasizes “individuals and interactions” and “customer collaboration elements of Agile, and is a thoughtful, and focused way of making an organization Agile.
For teams and organizations that are considering following in Red Hat’s footsteps, but like them, find that management is hesitant to commit, there are three things that are always helpful in focusing on when presenting Scrum or any Agile framework for doing work:
1) Delivering Value
This is, and always been, at the heart of the Agile mindset. Any change that you make to how work is done and how your product is built and delivered should always be centered around delivering valuable software that delights your customers. Any conversation with executives should be framed in terms of how Agile helps the team(s) achieve that goal. Through Agile, your aim is to build a relationship with your client that communicates what their most valuable wants and needs are and then allowing the team to self-organize the team’s efforts in delivering on those, early and often.
2) Improving Effectiveness
When clients we work with ask what Scrum is about, we always tell them it’s about building high-performance teams. When you give teams the space, tools, support, and freedom to do a job well, not only are they motivated to do the work, it encourages them to be technically excellent doing it. Combined with a focus on producing a working, shippable product, creating the best outcome for the customer, and being able to do this continuously, will almost inevitably lead to teams that get more work done, get it done faster, and to higher levels of quality.
We’ve all experienced the pain of having someone impose a change on us – it doesn’t work.
Forcing change conflicts with the essential human need for autonomy – No one likes being told what to do (if they didn’t ask to be). Whichever model for understanding human behaviour you use, all of them recognize autonomy — to work in the way we see fit — as a central feature of human psychology. So when an organization imposes an approach to work, whether it be Scrum, Kanban, or another Agile framework, it is unsurprising that the result often is team members feel discouraged and resist adopting the change.
As an example, you could start with, “The business needs working, integrated, tested product every two weeks that delights the customer. We don’t need the largest number of features, just ones that solve the customer problems.”
Explain there are two major approaches (and many supporting practices) that you believe would be suitable: Scrum and Kanban.
Scrum is focused on building high-performing teams who build great products.
Kanban improves the flow of work while building great products.
Any other approach that achieved the outcome “The business needs working, integrated, tested product every two weeks that delights the customer. ….”
In many cases, each approach can be used to complement and enhance the other. Help your teams understand that success with Scrum, Kanban, or other Agile comes in large part from their self-discipline, focus, courage, respect, and willingness to experiment continuously.
Choices Are Just Experiments
All choices that teams and organizations make are just a series of experiments. Each choice comes with a set of trade-offs. Instead of just picking one choice or another, explore both/all to gain a deeper understanding. Once you’ve made a choice, run an experiment to validate your learning. Whichever you select, keep on studying other, alternate approaches and borrow ideas from them.
You Can’t Impose Agile
Agile can’t be imposed on people and still be effective. Agile is a journey you invite your team to join you on, which includes being open to possibility that your team may favour a framework that you had not previously considered. At the end of it though, your teams can confidently say that they participated in the decision and joined you on the journey. All our study so far has been in this vein.