Tom and Mary Poppendieck have authored several books over the years about what needs to change in how we develop software to be able to meet the demands of the market, competition, and the growth in complexity of technology businesses. A recurring pattern they have witnessed is that people keep trying to discover a “silver bullet”. We explore why that is a bad idea and some of the changes in product development that make it an impossible quest.
Read on for the details, and all the links shared during the show.
According to the Scrum.org and Scrum Alliance websites we have now more than 500 000 Certified Scrum Masters or Professional Scrum Masters. With these kinds of numbers, it is clear that there is a demand for our profession. So what does that mean? How is the breakdown between countries and women vs men employed in this profession?
A more equal opportunity profession?
According to the report that Stefan compiled, there’s no significant difference between women and men when it comes to salary level. However, even if the profession has more women than the overall programming/technical professions, it is still a male-dominated profession (30% of people that replied to the survey are women).
When it comes to education, having a bachelor or similar degree plus hands-on experience seems to be the right level of qualification for aspiring Scrum Masters. Having one certification makes sense, but according to the survey there’s no significant effect of having more than one certification.
Finally, the organizations that hire Scrum Masters seem to be firmly rooted in the Product Development industry. Which begs the question: when will Scrum break-out of IT and product development? What is your view?
Agile PMO? Or waterfall with a bit of Scrum splashed on it?
An interesting aspect of the survey is that it reveals that many Scrum Masters are under the PMO (Project Management Office) umbrella in most organizations. We discuss why this is and what this might mean in terms of the Agile adoption process in certain organizations.
There are currently many different options as to how to govern software development in product organizations. We have SAFe, LeSS and other scaled framework and Oikosofy’s own Agile Portfolio Management governance framework. The Project Management paradigm is however, still the dominating paradigm, and we discuss what that might mean.
If you are interested in more details, and all the data from the Salary Report, you can download it in the Age of Product website.
What did you think of the results? Are they coherent with your experience?
About Stefan Wolpers
Stefan has been working as agile coach and product owner for fast growing, mainly Berlin-based startups for about 10 years. He is writing on hiring agile practitioners, Why agile fails?, and curates Age of Product’s “Food for Agile Thought” newsletter.
Steve has been interested in the performance of IT teams and organizations for many years. His work goes back to the 90’s when he experienced, first-hand, what a hyper performing team feels like during his stint at Borland International.
Borland famously fought off Microsoft in one of the most competitive markets in the 90’s: the code editor and compiler market.
During his experience at Borland, Steve got inspired to go beyond the basics of the definiton of performance and started to look for references and inspiration which later led to the definition of his TameFlow system which he describes in this TameFlow introductory book: The Essence of TameFlow.
Why do we talk about Hyperperformance and not Hyperproductivity?
Steve explains why he struggled with the use of the word “productivity” and ultimately decided against it. The use of the productivity word develops a focus on the wrong kind of metrics, as well as the fact that it drives a single-dimension focus. In contrast, with the word performance, Steve tries to elicit the different aspects that we need to take into account if we want to improve our teams and organizations. Among the different focus aspects Steve mentions what he calls the 4 flows in the TameFlow system:
Operational Flow: How well are you delivering? The operational flow is the conventional “work flow” that determines how work moves through an organization.
Financial Flow: How much wealth are you creating? Financial flow is measured in financial throughput. It represents the rate at which an organization turns its products or services into profit or to other units of value.
Informational Flow: How well are you communicating? Informa- tion is the lifeblood of an organization; even more so in modern knowledge-based organizations.
Psychological Flow: How happy are your people? The highest levels of individual or group performance are achieved when people reach mental states of flow, which is generally associated with a state of happiness.
The take-aways for Scrum Masters
Finally, we review the concrete take-aways Scrum Masters can apply based on the work that Steve has published under the TameFlow banner.
If you want to know more about TameFlow you can visit Steve’s site on the topic: https://community.tameflow.com. In this community you will find others that are applying these insights to their work.
Steve Tendon popularised the Theory of constraints in some of the agile community and he is also the Creator of the TameFlow systems thinking approach which nurtures breakthrough performance innovation.
This system is described in the book with the same name: Tame the Flow.
In this Bonus episode we have Diana Larsen, and James Shore, both authors of acclaimed books about Agile. They join us to talk about their model called Agile Fluency Model™. We talk about how the model emerged.
One of the premises of the model is that teams find proficiency in different aspects of their work. Some teams focus on Value delivery, others focus on improving their technical skills, etc. And although all of these approaches are valuable, they are also different. And we need to understand where we are, as well as what phase best corresponds to the needs of the teams and organizations we work with.
The different phases of team fluency are called “zones”, as in a Bus route. This is because all zones are possible destinations, but there is a certain sequence to the progression. Diana and James discovered this after a long process of learning and experimenting with the teams they’ve worked with. The model reflects their experience, and has been validated by many other Agile Coaches that have seen similar patterns of development for their teams. The Agile Fluency Model is a collection of patterns that teams experience over time, and given their specific focus.
The model is also a useful tool for our retrospectives in the form of a “diagnostics” tool that the core team has put together to help us understand where each of our team is according to the model.
Many will no doubt tempted to call the Agile Fluency Model a “maturity model”, but Diana and James point out that each of the phases of the model has its own maturity dimension, and a team can be very mature in any of the phases if that suits their business context. Maturity is a cross-cutting concern for all phases of the model.
There’s also a very cool story of how the model was invented. Interested? Then listen in on our conversation about the Agile Fluency Model.
When you are ready to know more, follow the links below:
Diana Larsen joins us today from Portland, Oregon. Diana leads the practice area for Agile software development, team leadership, and Agile evolutions at FutureWorks Consulting. Diana is co-author of Agile Retrospectives: Making Good Teams Great; Liftoff: Start and Sustain Successful Agile Teams; Five Rules for Accelerated Learning; and co-originator of the Agile Fluency™ model.