Is there such a thing as a perfect Scrum Master? Likely not, because of course we are all human and not perfect beings. However, we can make a case for skills that contribute to becoming a perfect Scrum Master.
In 2017, Ken Schwaber and Jeff Sutherland updated the Scrum Values document, and in a video that same year discussed the changes they were making. They talked at length about the Scrum Master role. To quote Ken Schwaber, “It’s a very tough job”.
The 2018 new Scrum Guide states:“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide”.
In short, the Scrum Master (SM) serves the Product Owner, the Development Team, and the Organization. This involves facilitating Scrum events, coaching and educating, removing impediments, and much more. It is safe to say that successfully undertaking those relational interactions requires good people-oriented behaviours, or soft skills.
We may not normally think of Scrum Mastering in the same breath as soft skills, but a discussion lead me to consider this. A colleague stated that a good Scrum Master must understand 4 things: the business s/he works in, the technology s/he works with, Agile and Scrum principles, and, most importantly, people! Based on his experience, he was adamant that Scrum Master certification is not enough – that soft skills should be part and parcel of their training.
How can some of these soft skills be taught?
The Certified Scrum Master Training
The first thing a CST can do is model soft skills in his/her training class: treat all the attendees with respect, be clear about the goals of training, listen and be attentive to questions and concerns, create a safe learning environment, demonstrate honesty and trustworthiness. Modelling these behaviours is one way a CST can teach without words.
But in two days, is role-modelling enough? Let’s look at the Scrum Guide for clues. “When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” http://www.scrumguides.org/scrum-guide
How much are these values discussed in training? What does “courage” or “openness” look like? In-depth discussion, with examples/activities of each of those values/ skills, could go a long way in teaching soft skills.
Scrum Masters can be guided through specific exercises that help them understand and practice the Scrum Values of courage, openness, respect, commitment, focus. As well, specialized skills can be taught, including leadership, negotiation, conflict resolution, compassion and more.
It appears to me there are more jobs available for Scrum Masters than ever before! Why is it so hard for some people to find employment with Agile teams?
The problem is entirely predictable. And for those eager to work in Scrum teams, the answer is also predictable. I’ll explain.
Having taught Scrum to more than 2000 people, I have ongoing dialogue with many former students who are struggling to find opportunities to serve Agile teams and gain experience as a Scrum Master. I have struggled to understand this dilemma because my experience was very different – I learned of Scrum in 2007 and simply asked my workmates:
“Would you like to try Scrum…I could be our Scrum Master?”
Unanimous reply: “Yes!”
That is not the common experience. Many organizations are willing to send their staff to Scrum training for the sake of ‘Professional Development’ but only some of those organizations intend to develop Agile teams. That pattern has created the current condition in which many recently-trained Scrum Masters are eager to apply their new knowledge but do not have organizational support to do so.
I opened my inbox today to a question from a former student of my Scrum class. Let’s call her Jane:
“Hi David, I wanted to get your advice on a dilemma I have. I’m back on the job market and several companies are looking for Scrum Masters which is great to see. I was in your CSM course last year and would love to work with a Scrum team…but I didn’t have the opportunity with my former employer. How can I gain experience if all the available jobs require 2+ years experience? What advice do you have for me?”
Jane is not alone. The job market (today at LinkedIn) offers 591 positions in Canada for keyword ‘Scrum Master’ – and all that I’ve scanned require 1 or more years’ experience in the role.
In contrast to the dilemma described above, I have a totally different problem: I am contacted a few times per month by recruiters and hiring managers who ask me if I’m looking for a new contract.
Where’s the welcome mat for newcomers? Do jobs exist for enthusiasts with no prior experience?
I believe so.
The dynamics we’re observing in the job market for Scrum Masters are well described by Everett Rogers in his paper called “Diffusion of Innovations” (1995). You may recognize his theory by the following bell curve:
I assert that Scrum has achieved “Early Majority” market penetration. And you might be asking what evidence I have to support that claim – of course, other than the fact that opportunity knocks frequently at my door but never at Jane’s. I’ll describe the patterns I’ve observed in the market.
The authors of Scrum (Ken & Jeff, and others) were the Innovators. When I first took on the role of Scrum Master (2007), knowledge of Scrum was limited to a few enthusiasts and early adopters. Worldwide, a few thousand had learned of Scrum; in Canada, perhaps a hundred or so. None of my friends or workmates had prior knowledge of Scrum; there were no job advertisements for Scrum Masters; there were no public training classes; many of the well-known books on the subject had not yet been written; and there was exactly one Certified Scrum Trainer in Canada: my colleague, Mishkin Berteig.
By 2012, awareness of Scrum was spreading. It was a buzzword among start-ups and software development firms and a few brave souls were socializing the practice in large enterprises. Despite the increasing awareness, the number of people who had served as Scrum Master in a proper Scrum team was, I’d estimate, less than 100 in Canada. Yet, anyone with “Scrum” on their resume was considered rare and hiring managers among the early minority adopters were eager to snap them up. A swell of “Agile Coach” contractors was starting to emerge and anyone willing to hang that shingle was considered an expert. I’d argue their enthusiasm often out-weighed expertise but it was a new frontier after all and sheer enthusiasm counted for a lot.
By 2014, I noticed 2 patterns emerge. First, young tech companies in Canada (the ‘early early adopters’) were no longer hiring Scrum Masters. They considered Scrum expertise (or willingness) an obvious requirement of all new hires – like table-stakes. Second, large enterprises were starting to post job advertisements for Scrum Masters. These two patterns infer that the ‘late early adopters’ were onboard.
By 2016, evidence of ‘early majority’ adoption was mounting. I received frequent requests to speak at hospitals, marketing agencies, industry events, ‘Leadership’ seminars. Our federal Government departments started recruiting, not only Scrum Masters, but Product Owners too. Small armies of young MBA grads were being sent by their big consulting firms to my Scrum classes to “get certified”.
So, in 2018… Jane is certainly asking “what does it mean for me?” Well, it means there’s more opportunity than ever before. That is certainly true and awareness and demand for Scrum continues to grow. It also means I see a vast landscape of opportunities, but Jane sees closed doors – unfortunately for her.
There’s good news in this story for Jane… I promise!
Let’s think about the mindset common among the ‘early majority’ adopters. They are risk-averse, but not so much that they ignore market opportunities. They live by a simple rule: “the 2nd mouse gets the cheese.” They watch the early adopters carefully hoping to spot advantageous patterns. (Scrum is one of those.) And when they see a trend, they don’t pounce on it immediately – remember, they’re pragmatic. They will want to hire Scrum Masters, but they’ll be careful about it: perhaps they’ll hire contractors rather than commit to full-time/permanent roles; perhaps they’ll require 5+ years’ experience hoping to acquire one of the early adopters who helped prove the efficacy of the new method; perhaps they’ll train internally hoping to gradually adjust and minimize disruption. They’ll be reluctant to “take a chance” on a new hire without proven experience.
Those pragmatic habits of the early majority adopters make it difficult for them to hire Jane.
5 to 10 years from now, Jane’s job search may get a lot easier. Why? Let’s think about the mindset common among the ‘late majority’ adopters. They are risk-averse – to the point they ignore new trends and look instead for so-called “best practices”. These organizations are doubling-down on Waterfall right now and sending their staff to PMP exam-prep courses. They still think Scrum is a buzzword. But they’ve taken note when Brian Porter, the CEO of Scotiabank said publicly, “we’re in the technology business. Our product happens to be banking.” They’ve felt some shock when Alex Benay, CIO of Government of Canada talks about agile procurement and relentless incrementalism. They will start hiring Scrum Masters when they’re shown evidence that Scrum is teachable, repeatable, reliable, and so-called “normal”. They will believe (and trust deeply) that the community has developed well-established and standard methods which can be taught and learned systematically. They’ll find the senior practitioners too expensive; and they’ll look to less experienced practitioners, like Jane, as a bargain. They’ll be less concerned about in-the-trenches experience and more interested in industry norms.
Those risk-averse habits of ‘late majority’ adopters will make it easy for Jane to find employment – unfortunately though, the salary range is likely to be average at best.
(Let’s not discuss the Laggards today – they’re just funny. They’re the reason your office still has a fax machine and your car still has a cigarette lighter.)
Jane! I promised good news. Here it is…
Even at this stage of ‘early majority’ adoption, you’ll find some people who are on the edge of innovation. Look for those enthusiasts and visionaries! You’ll not find them easily in the big employers (banks, telecoms, etc.) You’ll find such people in start-ups, small tech firms, product companies. Those organizations are not looking for the stodgy corporate mindset – they’re eager to find other enthusiasts and they’re willing to take a chance. They’re more interested to forge new paths than to follow others – so they’re excited by Jane’s willingness to forge her own new path and they’ll want to help her!
So, what if Jane herself is not ready for that level of risk? Well, on one hand I feel every Scrum Master must develop high risk-tolerance. But I understand not everyone starts there. Jane might seek the sense of job security and stability common in large enterprises. In that condition, my advice to Jane would be: consider taking a job as not a Scrum Master but as a team member. If you’re a Project Manager or Developer, or Business Analyst in the past, hunt for those opportunities then look for ways to transition into a new role. That is, after all, the type of pragmatism the enterprises (early majority) appreciate.
Happy job hunting!
*** Thanks to Massimo for the conversation we had on the train yesterday.
Thanks to Brian.
Thanks for Valerie who reviewed and helped improve the article.
“Paratroopers are used for tactical advantage as they can be inserted onto the battlefield from … any location[. This] allows paratroopers to evade emplaced fortifications that exist to prevent an attack from a specific direction”
I believethere are certain analogies between being a Paratrooper and being an Agile Coach or Consultant, including having strategic objectives, a purpose of infiltration, a sense of opposition, and a goal or cause that you believe in.However, I am notasserting that, a) implementing Agility at an organization is a declaration of war, b) Agility is a tactical warfare technique, or, c) being an Agile Coach or Consultant is synonymous to or nearly as dangerous a job as a Paratrooper.
Having said that, depending on the environment an Agile Coach or Consultant may sometimes feel like they are actually entering a corporate or political war zone. They are often viewed as outsiders posing a clear threat. They are often in the minority. They are often dropped in to unfamiliar territory. They often have incomplete or incorrect information. They are often surrounded by opposing forces. They are often made a target, either passively or aggressively. They often start with plans, but what makes them successful is their ability to adapt their plans and react to situations. In other words…be agile!
Like a Paratrooper, a Coach or Consultant is often “parachuted” or “inserted” in to an organization or foreign group with a specific mission. It is often to provide a “tactical advantage” and doing so helps a Coach or Consultant “evade emplaced fortifications [well established norms or strong opposition] that exist”, so they can get the job done from the inside and with less opposition.
A Paratrooper should always enter the field with a good understanding of the landscape, environment and situation. Similarly, a Coach or Consultant should also become familiar with the working environment and culture they are about to interface with. Without critical information both would risk the success of their mission and perhaps more. For a Paratrooper a lack of information could be life threatening, but fortunately the threat is not usually life threatening for organizational change agents. It just might be professionally damaging to their career as well as others and their business.
To that effect, I believe if you are a Coach or Consultant then you should still perform advance research for your intended mission in order for you to be successful, provide value and create an opportunity for learning and improvement. This means you will need to have conversations with both the leadership of their target (organization) and also with the people doing the work. Here’s why.
Leadership (usually the “paying customer” is management in the organization) should have specific and measurable outcomes they want achieved, and it is critically important for you to identify what those are up front and how they are expected to address their business problems. Meanwhile, the employees (usually the workers or teams) are often directly associated with and intimately familiar with the true needs and system issues, so you must also become familiar with their understanding for perspective. Unfortunately, the first battle is often that workers and their leadership do not align on their expectations and outcomes, and without their alignment you have little hope of true customer satisfaction and helping them collectively solve their real business problems.
As such, to manage expectations and increase chances for success it is critically important for a Consultant or Coach to investigate and identify both the needs of the leadership AND the needs of the employees, and then work to align them before any substantial work takes place. The best approach is to have face-to-face conversations with all the leadership and employees but that can take considerable time in a larger organization. So how do you get a realistic pulse of the company without talking to absolutely everyone?
Assess the Team
If the team(s) are using Scrum as a framework then one option is to use a Scrum team assessment tool like Scrum Insight. This tool provides objective coaching advice tailored specifically to a Scrum team as it is designed to detect how aligned the team is to Scrum practices and methods. The free version of this tool provides access to the basic report which contains the team’s overall scores, a “quick win” recommendation that identifies and provides suggestions that can be made to provide the biggest improvement on the team, and a list of support resources. The paid service provides everything in the basic report as well as a detailed Scrum Score Card, a Team Environment Score Card, a relative industry ranking, other education and support resources available for consideration, and it is usually followed up with a personal call to provide you with detailed explanation on the results.
Here is a sample Team Environment Score Card from Scrum Insight. Detailed descriptions for each bar/category are provided in the report:
Here is a sample Quick Win Report from Scrum Insight A more detailed description is provided in the report, and it is tailored to the team’s specific challenges and opportunities.
Another option is to conduct a REALagility assessment – either for a team, a group or an entire organization. The assessment is a 10 minute online survey conducted by every individual, and it is designed to uncover the misalignments between what leaders think and what employees think in an organization. The resulting report reveals the soul of the current culture, and it is grounded in real, actionable data to improve on the problem areas unique to the organization. As a Consultant or Coach these insights can be invaluable in helping you prepare for the engagement, identify opportunities, create alignment, and elicit real, meaningful and sustainable change for the organization.
Here is a sample diagram from a REALagility assessment, showing the relative rankings for an organization around five cultural measures. Detailed descriptions and insights for each cultural score are provided in the report.
In summary, I find it immensely helpful to “arm” myself with information prior to a Coaching or Consulting engagement, and these tools have been pivotal in filling that gap. Having early access to information such as this enables insights that might otherwise not be detected until I am on the ground helping the individuals, teams, and leadership tackle their business problems, which saves time, frustration, and money. An additional advantage with leveraging these electronic evaluations is that they provide an opportunity for people to provide ideas, feelings, agreements or disagreements that they may hesitate to share in a face-to-face interview.
There are certainly other tools that are designed to provide insights and information, but I’ve chosen these two because of my familiarity with them, and because of their effectiveness.
Of course, I would never replace good, valuable conversation with tools or data, but I do find these tools provide additional contextual information that further enables me to ask the right questions and have the right conversations early in an engagement. Finally, these tools can also be used as a benchmark for comparison of progress after a period of time has elapsed, which allows you as a Coach or Consultant to measure and be accountable for success.
We may not normally think of a Scrum Master in the same breath as mastering soft skills, but a recent discussion with peers lead me to consider this.
In 2017, Ken Schwaber and Jeff Sutherland sought to update the Scrum Values document, and together in a video they discussed the changes they were making. They talked at some length about the Scrum Master role. To quote Schwaber,“It’s a very tough job.”
The 2018 Scrum Guide states:“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide.” An extensive list of the Scrum Master’s responsibilities follow in the guide.
In short, the Scrum Master (SM) serves the Product Owner, the Development Team, and the Organization. All of this involves facilitating Scrum events, coaching and educating, removing impediments, and much more. It is safe to say that successfully undertaking those relational interactions requires good people-oriented behaviours, or soft skills.
In recent conversation, a colleague categorically stated that a good Scrum Master must understand 4 things: the business s/he works in, the technology s/he works with, Agile and Scrum principles, and, most importantly, people! Based on his experience, he was adamant that when people are trained to become Scrum Masters, certification is not enough – soft skills should be part and parcel of their training!
How can some of these soft skills be taught?
The Role of the Certified Scrum Trainer
Not all Certified Scrum Trainers have soft skills training or behaviours under their belts. However, the first thing a CST can do is modelsoft skills in his/her training. That means s/he will treat the attendees with respect; s/he will be clear about the goals of training; s/he will listen and be attentive to attendees questions and concerns; s/he will create a safe learning environment; s/he will be honest and trustworthy. Modelling these behaviours is one way a CST can teach without words.
But in two days, is role-modelling enough? Let’s look at the Scrum Guide for clues. “When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and buildtrust for everyone.” http://www.scrumguides.org/scrum-guide
To what degree are these values discussed in training? What does “courage” or “openness” look like? It seems to me that in-depth discussion with examples/activitiesof each of those values would go some way in teaching soft skills.
Soft Skills Training for Scrum Masters
Two CST’s I know invited an Agile Team Developer into their CSM classes to give a half-hour workshop on soft skills. This is a very brief time to be effective, but it provided a taste of listening skills, creativity, risk-taking, etc.
The following is from an article I previously published in Agile Advice: “Everyone has the potential to grow their soft skills. However, a company may not have the resources to help unlock this potential in its employees.
If team development is not part of a company’s culture there may be discomfort in dealing with friction arising from a lack of soft skills. In this case, an external facilitator or coach can be a very helpful resource to guide a work team, using thought-provoking activities and role-playing, to find greater connection and trust amongst themselves, and to address issues with a detached point of view.” http://www.agileadvice.com/2017/05/29/scrum-team-improvement/soft-skills-revolution-may-want-team-development/
Scrum Masters can and should be offered at the very least a one-day training by a good coach/ facilitator.
Scrum Masters can be guided through specific exercises that help them understand and practice the skills of openness, courage, respect, commitment, and focus (the Scrum Values), as well as the practice of compassion, communication, creativity, listening, building trust, and so on.
Summer 2014. The IT group of “Big Data Marketing” was in the full throws of an Agile transformation spearheaded by the new CTO. I was brought in as a Scrum Coach. My initial objective was to launch a couple of Scrum teams and serve as their Scrum Master. Around the same time, the firm’s head of PMO had been re-assigned as the Agile Practices Lead (APL) and he and I began working together on supporting the new Scrum Master community of practice, populated by his new reports. Our work gradually evolved into much more than what either of us could have imagined at the time. This 3-part series is my first attempt at putting down the story of that partnership.
In addition to serving as the initial Scrum Master for some of the teams, I was also trying to help existing team members transition into the Scrum Master role. I wanted to develop internal capacity so that I could focus on supporting a growing program of multiple teams. As the number of Scrum Masters and teams I was supporting increased, so too did the need for collaboration with the APL.
At the time, senior IT leadership was focussed on getting those doing the work of creating value (the teams) to fundamentally change the way they were working. That is, into self-organizing teams with Scrum Masters as “servant-leaders”. This included the reassignment of project managers as Scrum Masters and business analysts as Product Owners and staff into cross-siloed teams.
Chaos and confusion ensued. It was a deliberate strategy of senior leadership: Disrupt the culture of complacency. Force people to transform by throwing them into chaos. Throw everyone into the deep end and the right people will learn to swim.
A great deal of pressure was placed on the Scrum Masters to measure and improve team performance (based on pseudo-metrics such as story point velocity). They were essentially told to create a new identity for themselves and this was painful. Similarly, the APL was on the hook to support all these people in their new roles – to be a “servant-leader of the servant-leaders”. This concept of servant-leadership was front and centre in the conversation: “What is it, and how do we make it work here?” My role was to help create a shared understanding of the desired new culture.
I discovered months later that the day after I started the engagement, around 50 people had been fired. This had nothing to do with me, but naturally people thought that it did. Even years later, this day was commonly referred to by the survivors as “Bloody Monday”. Because of the timing of the mass-exit, unprecedented in the company’s 25-year history, staff understandably regarded me as the consultant who advised the cull. It’s not exaggerating to say that it instilled terror, was emotionally coupled with the transformation as a whole and implicated me as an individual. I thought of myself as one contributing help, but I was regarded as one contributing to harm. I saw myself as a Hippocrates but I was known as a Procrustes. I only learned about this months later, after I had finally managed to cultivate a bond of trust with some folks. A consequence of this fear was that I found myself in many one-on-one sessions with new Scrum Masters who were struggling to adapt and afraid of being the next victim to lose their jobs. Rather than providing Scrum Master therapy, I should have been helping the company to improve its delivery capabilities.
The theme of this first stage was the deep, broad and painful disruption of people’s lives caused by this deep Satir J-curve transformation model deployed by senior management. What I didn’t fully appreciate at the time is that emotionally, people experience change the same way they experience pain. The human brain literally responds the same. Not only were these human beings experiencing deep, chaotic change, they were also experiencing deep pain. And I was complicit in this.
The other contract coaches and I attempted to bring the crisis to the attention of senior management. We believed that it was a leadership problem, they believed that it was a staff complacency problem. The standoff lead to the coaches losing access to the leaders we were trying to help. This was a deep crisis for the group of coaches and the staff. The staff were beginning to see us as their advocates and we failed. For many Agile coaches, their part in the story ends here. In fact, some of the coaches on our team soon decided to move on to other opportunities. Others were not asked to extend their services beyond their initial contract term. Fortunately for me, the story didn’t end here. I will share more about this in Parts II & III of this series.
A teaser: These days, I advise and coach senior management to take responsibility to deliver services to customers, to understand what makes their services fit for the purposes of their customers and to design and evolve service delivery systems the fitness criteria of which are transparent to all those involved in the work. Then, allow people to truly self-organize around how the work gets done. In other words, manage the work not the people.
Being Agile seems to be the rage these days and everyone has an opinion on what Agility means and how to do it “right”. This article doesn’t make process recommendations, but it does provide a quick, effective way to help your team and organization get on track with being Agile (primarily a mindset measurement) and not just doing Agile (primarily a practices measurement). Presented below is a simple and lightweight test that can be applied by almost anyone; it provides clear steps for improvement, and it is geared for alignment with the core Agile Principles and Values.
There are lots of Agile practitioners, coaches and trainers out there claiming to be experts. Some are genuinely skilled while others have a few key certification letters beside their name and yet little to no in depth, real-world experience. Although most have a genuine intent to help and they might actually succeed at it, others might inadvertently do more damage and provide harmful guidance. How can you help them help you?
There are also numerous frameworks, methodologies, and practices that claim they are well suited to help an organization become more Agile. Some of them are simplistic, process-based approaches that may not account for your environment, culture, or specific business needs, while others are more complex and pragmatic. Depending on your situation it can be tricky to know what will work best. How can you find a suitable fit?
There are also many tools and approaches to measure a team’s Agility, the leadership’s alignment with Agile, or the organizational maturity. Some of these simply measure the number of practices (i.e. are you doing Agile), others account for an in depth assessment of cultural factors (i.e are you being Agile), and some are based on scenarios that are idealistic given common real world business challenges.
Indeed there are a wide variety of indicators of varying complexity, so you might be challenged to determine if they are simply vanity measures, helpful health indicators, or suitable fitness criteria, and more specifically if they appropriately measure for the outcomes you are looking for. How can you ensure they are providing valuable insights and actionable results so you may make data driven decisions?
Keep it Simple and Focused
Given all these complexities, how do you know what it really means to be Agile, how can you align the effort, and how do you know how successful you are?
The answer is keep it simple and focused, and be outcome driven. Specifically, start with the foundations of Agile and then evaluate Agility from your perspective, your organization’s business needs, your employee’s needs, and most importantly from your customer’s needs. Then, use that information to measure and steer improvement towards your real desired outcomes of Agility.
In the spirit of keeping it simple and focused, I’m sharing a “quick” and lightweight Agility Litmus Test and Procedure below to measure how you are doing and to ensure you, your stakeholders and your approaches are all headed in the right direction.
A Straightforward Procedure
1) Align With The Agile Manifesto
Read the Agile Manifesto. I don’t mean gloss over it on the train on the way to work, or over lunch, or during your kid’s sports game. I mean READ it, focusing on the twelve guiding principles AND the four value statements.
If it helps, boil each of the twelve principles down to two or three key words to provide clarity. Then, when reviewing each principle ask yourself what you think it really means, and why you think it was important enough for the signatories to explicitly call it out in the Manifesto (what the intent was). To ensure everyone has a similar frame of reference you may find it useful to host a time boxed, focused discussion on each principle.
2) Choose Key Agile Measures
Of the twelve principles ask yourself which ones (pick 3 or 4 at most) are core, or most important to you and your stakeholders (your organization, your leadership, your customers and your team). Don’t just speculate or guess what the answers are; you will likely need to facilitate several workshops with the appropriate people to get to the truth to those questions.
This activity in itself is a test. If there is not close alignment on what the most important principles are then stop right here. Do not proceed until you align on what those key principles are. If you proceed without alignment you risk working against one another and not towards a common goal or outcome. Note that getting alignment might prove contentious so you may need a series of facilitated sessions to hash it out.
Once you align on several core principles they become your key indicators for the Litmus Test for Agility. These are also your defined Agile outcomes, because they encapsulate what it specifically means for you to be Agile (where you want to be).
3) Perform a Critical Assessment
Starting with your key indicators, honestly answer the question how close or how far away are we” for each one. Use a scale of 1 to 7, where 1 means “not close at all” and 7 means “we are totally nailing it”. I chose 1-7 because it gives just enough range to differentiate measures. That, and it is exactly 1/2 of the pH range for a proper Litmus test!
Be sure to seek fair and equal participation in this evaluation, as it is important to help reduce bias and ensure perspectives are accounted for. This means you should ensure you have adequate representation from as many groups as is practical.
Honesty and transparency are also extremely critical here so you may require a facilitated session. You may also need to provide a safe environment to encourage honesty in responses, so anonymous scoring and evaluations would be an appropriate technique to use.
4) Determine Actions
Critically review the summary of evaluative responses for your key indicators. If the average is less than 6 out of 7 then hold a strategic planning session to determine actions to get you closer to achieving those outcomes. Note also if there is a wide dispersal of the individual responses for a key indicator that would strongly suggest there is a large misalignment amongst the respondents, and you need to address that gap.
One question to ask would simply be “what would it take…”, or “what would we need to do to get us to a 6 or higher? When following this line of reasoning be sure to account for the coaches, practitioners and experts you are relying on by asking “What can or should they be doing to align with our key indicators and Agile outcomes?”
Also, look at the frameworks and approaches you are using and ask “How can we switch, change or improve our ways to improve Agility?”
Finally, look at the tools and measures you are leveraging and ask “Are these vanity measures or are they really meaningful?” and “How can we improve these measures (not just the values, but the metrics themselves) to provide more meaningful insights and help us better realize our defined Agile outcomes?”
As a group then choose at least one and no more than three specific actions that came out of the discussion above, implement them, hold one another accountable for them, and measure on the next round if your actions had the desired effect of improving the scores for your key indicators.
5) Learn and Refine
Repeat steps 3 and 4 of this procedure at frequent and regular intervals, being sure to not only measure but also define and take new action.
6) Reassess and Pivot as Needed
If time permits or if your key indicators all show consistent strength, consider switching to some of the other Agile Manifesto Guiding Principles. If it seems logical you may even want to go back and repeat the entire process as your needs and outcomes may have changed.
The core value this Litmus Test for Agility provides is a) in its simplicity, b) in it’s inherent alignment with the Agile Values and Principles, and c) in its focus on what matters most for you and your stakeholders. It uses the Manifesto as a foundation, and then allows you to focus on what is most important to you.
Like all tests and models this approach has some inherent strengths and weaknesses. For example, it is lightweight, cheap, easy to implement, and aligned with core Agility, however it is not an extravagant or in depth test so it may not account for complexities. As such it should never replace sound judgement.
Meanwhile, if you sense or feel there is something deeper going on that may be impeding your organization’s ability to become more Agile then be sure to investigate thoroughly, work with others to obtain nonpartisan assessment, and provide clarity along the way on intent, outcome, and learnings.
If you are practicing Scrum, using a more sophisticated tool such as Scrum Insight (a virtual “Coach-in-a-Box”) can provide much richer, deeper feedback and insights, including recommended actions. Even the free version of the tool provides keen insight.
Depending on circumstance you might also find it advantageous to call in expert facilitation, advisors or coaches to either conduct an Agility test such as this or even help your team or organization get to the heart of their issues and challenges. Organizations such as BERTEIG are not only Agile teachers but they are also hands-on practitioners that can coach your team and organization to reaching new levels of Agility, either with a lightweight touch or a fully immersive engagement.
Coincidentally, reflecting, collaborating, providing transparency, and adopting a continuous learning and improvement mindset are in and of themselves indicators of Agility. So identifying core values such as these and then making them part of your Agile Litmus Test (i.e. making them your new Agility outcomes) shows how simple it can be to improve, adapt and grow even this lightweight approach!
Scrum Insight is a tool for Scrum Masters and Scrum Coaches to help them improve their teams. It leverages the accumulated experience of six expert coaches in an automated online tool.
We have just launched version 1.0. This version includes easy access to a free report. It also includes an optional paid Professional report that replaces the equivalent of 83 hours of on-site coaching.
For Scrum Masters this means access to Scrum coaches that may not otherwise be affordable. For Scrum Coaches, this means leveraging your time to make progress on the hardest problems facing your Scrum teams.
Using Scrum Insight
Using Scrum Insight is a simple two-step process:
Get all your team members to fill out the Scrum Insight survey (and remember to save everyone’s “survey codes”!!!).
Taking the survey requires between 8 and 11 minutes. It seems like a long survey, but is actually very quick to go through.
Load your survey codes and generate your team’s report.
The free report includes a single piece of advice optimized to your team, plus a score for how well you are doing Scrum and how well your organization is supporting your use of Scrum.
(Optional) Upgrade your report to the Professional version for just $500.
The Professional report gives you much more in-depth advice, more detailed score breakdowns, a permanent link to your report and much more.
So far, 102 teams have used the Professional Scrum Insight report, and many more the free report – let your team be the next to take advantage of Scrum Insight.
Reminder: when you do the survey, keep your survey code(s) and print the report that is generated. We don’t collect your email address to use the free report so there is no permanent way to access it other than using the survey code(s).
I just commented on a LinkedIn thread about “Sprint Zero”. It occurred to me that Sprint Zero is often used as one of many coping mechanisms for people who are forced to do Scrum. It also occurred to me that in my 9 years or so working with a reliable sample size of Scrum teams, not one of those teams was populated entirely by people who were not coerced into doing Scrum.
Gut check: The percentage of people I know who are currently on Scrum teams and who would be doing Scrum if it wasn’t mandated by management could be lower than 50%. This begs the questions: What if Scrum was offered to teams as an optional way to manage their own work? Would there be less Scrum in the world?
With one exception, all of the Scrum teams I have worked with were mandated (forced) by management to implement Scrum. The exceptional team was exceptional in other ways. They were by far the happiest and most revolutionary (in terms of recognition for business success in their organization). Although one or two hesitant team members were roped in by their peers, the social climate of the team allowed the wary to adapt safely and gradually to their new reality.
For the overwhelming majority (in my experience), there is an irony, even a paradox at play. A lot has been said & written about how command and control management is antithetical to Scrum. Yet, many—if not most—Scrum adoptions are commanded by management with vanity metrics (i.e. velocity) installed to uphold the illusion of control.
What are some of the other coping mechanisms for people who are forced to do Scrum? What is driving this behaviour? How many of these behaviours have been labelled as “anti-patterns” and why?
Safety is an essential success factor for any organization. Is it safe for people to choose to not do Scrum, or express dissent about Scrum adoption in their organization? What does this tell us about Scrum itself? Does Scrum need to be reimagined or reframed in order to make Scrum adoption safer for more people? Is it safe to do so?
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.
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.
It’s my opinion, and I think the opinion of the authors of Scrum, that a Scrum team must be collocated. A collection of geographically distributed staff is NOT a Scrum team.
If you work in a “distributed team”, please consider the following question.
Do the members of this group have authority to decide (if they wanted to) to relocate and work in the same physical space?
If you answer “Yes” with regard to your coworkers: then I’d encourage you to advise your colleagues toward collocating, even if only as an experiment for a few Sprints, so they can decide for themselves whether to remain remote.
If you answer “No”, the members do not have authority to decide to relocate:
then clearly it is not a self-organizing team;
clearly there are others in the organization telling those members how to perform their work;
and clearly they have dependencies upon others who hold authority (probably budgets as well) which have imposed constraints upon communication between team members.
Zuzi gave her book to me in October. She was visiting Toronto at the time and we spent a few days together teaching Scrum – I was honoured that she would share a classroom with me and that I’d get a sneak peak at her new publication. Almost immediately after she gave me the book I found a few minutes to thumb through it and read the foreword and first chapters. I immediately liked what I saw.
The foreword is written by Linda Rising who frames the book nicely by reminding us of these simple principles: “successful change is built around small steps and learning”, and “the book offers a chance for reflection and evaluation”. Zuzi’s preface describes briefly her journey to become a great Scrum Master. Hers is a story about humility and studious peristence; the journey is unique and difficult for us all. I could relate! The best aspect of the early pages in the book are the photographs of Zuzi. The book exudes her character traits: a friendly and insightful expert, a colleague and advisor. Her photos, as well as her illustrations throughout the book, help the reader to understand her colourful character; her stance as a coach and mentor; and her voice as an author.
My time was limited so I didn’t get far in that first sitting though my first impressions of the book are memorable. It’s a big book – not thick, that’s not what I mean. I mean large, wide pages. Approximately 20 centimetres square. It’s the kind of book that lays open on a coffee table. This is important! I understand many people buy digital books but if you can find the book in physical format, buy it! The medium is the message, as Mcluhan said. The medium, in this case, is a lightweight book that rests easy, open-faced, on a desk or coffee table. As you pass by the table or sit for a while to enjoy a conversation, you’ll find the book open and waiting for you. You’re likely to thumb through it lazily, your mind wandering while on the phone or talking with a friend, then something will catch your eye. It’ll be a page you’ve looked at a dozen times but suddenly a sentence or illustration will stand out for you, draw your attention. Like, “…if you join a discussion with the core metaskill of curiosity it will be different than if you choose listening or teaching”. That sentence is on page 88 – that’s the one that jumped off the page for me today. I’ve read that page a few times already but this day, in this moment, that sentence resonates. Such a simple sentence on a page and sparse text and white space…but exactly the solace you will need.
The Second Sitting
I was riding a train with the book open on my lap. Through the window passed the Canadian landscape, and I’d glance at the book between sips of coffee to take in another paragraph, picture, page. (See how cool the format is??) What I’ve learned from the next chapters of the book is that I share Zuzi’s interpretation of Scrum and of the Scrum Master’s role.
Her perspective is a philosophical one, yet she effectively relates the material to practical examples. Zuzi describes a concept she calls the #ScrumMasterWay. This is an innovative model for understanding how a Scrum Master can adapt their mode of service depending on the conditions of the organization they serve. Perhaps at first, the organization they serve is ‘A Scrum Team’ – and in that mode of service a Scrum Master will facilitate Scrum and help the team to self-organize. Next, after all the easy fruit has been picked and the Scrum Team is capable of continuous and deep self-improvement, the Scrum Master’s mode of service is likely to change – the team no longer needs help with the rudiments so the Scrum Master may focus more intently upon relationships to and within the team. And finally, the 3rd level of #ScrumMasterWay is achieved when the Scrum Master is able to focus their effort toward the entire system, “bringing the Agile Mindset and Scrum values to the company level”.
The Last Sitting
Reading about Zuzi’s #ScrumMasterWay concept in the previous sitting led me to think nostalgically about my own journey. I know this book, had she written it a decade ago, may have saved me from some mistakes of my own. I’ve come to more deeply appreciate her telling of the Scrum Master role.
In the 2nd half of the book, she provides a glimpse into numerous related practices and concepts. A collection of references and teaching tools that most Scrum Masters will discover along their journey. For example, all Scrum Masters will find themselves in discussion with stakeholders about the nature of complex problems and, ta da!, like a stone tablet from a high mountain will appear Dave Snowden’s CYNEFIN framework! A simple diagram…it’s so obvious! All Scrum Masters will find themselves in a personal struggle between telling and listening: “should I coach as a teacher?” or “coach as a facilitator?” and, without fail, a fellow Scrum Master will recommend a training course with the Agile Coaching Institute to better understand the coaching stance(s).
Here’s the truth of it: if a young jazz musician wants to become a great jazz musician, there are some iconic recordings to which they must listen: Kind of Blue; anything by Duke Ellington and Louis Armstrong; Blue Train; Saxophone Colossus. No drummer is worth their salt without having spent a zillion hours listening to Max Roach and Jimmy Cobb. Likewise, every great Scrum Master has had to grapple with the iconic challenges of servant leadership – they’ve spent a zillion hours pondering the difference between the words “should” and “could” and they’ve praised the power of the question, “what if?”
So, to help Scrum Masters along their journey, Zuzi has compiled many of the community’s greatest hits in her book. Einstein is often quoted as saying, “If you can’t explain it simply, you don’t understand it well enough.” Perhaps then, one can examine how well a person understands a concept by how simply they can explain it… right? By that measure, it’s evident that Zuzi understands her material as she’s able to distill complex topics to just a colourful drawing and a few bullet points. “Root cause analysis” is described concisely with 3 paragraphs, 4 bullet points, and a beautiful drawing of a tree. Her purpose, keep in mind, isn’t to make the reader an expert in root cause analysis – her point is as if to say, “remember…problems often run deeeeeeep in the system. They’re organic. Find the seed.” I’m hearing in my mind a wise old music teacher, telling the aspring young jazz musician, “remember Herbie Hancock…go listen to Maiden Voyage…behold the deeeeeeep groove and floating melodies. It’s organic”.
The collection of materials which complete her book include highlights of Tuckman’s “Stages of Group Development”; Lencioni’s “Five Dysfunctions of a Team”; the martial artist’s progression through “Shu Ha Ri”; a shortlist of “Powerful Questions”; and a few others. In this last sitting, as I finished reading the book, I was struck by the similarity between Zuzi’s journey and interests and my own. I too have enjoyed Lencioni’s books, Tuckman’s model, the practice of co-active coaching. While I’ve lived and practiced all these years in Canada and Zuzi has lived and practiced in Prague, how is it we have been exposed to a similar body of knowledge and wisdom? I take some comfort in that, actually.
I face a difficult decision now. Zuzi signed this book for me and it’s in pristine condition. However, if I’m not careful, I am certain in the coming years this book will become littered with notes and comments, dog-eared pages and sticky-notes everywhere. Shall I allow myself to ruin this pristine book? Yes. Yes, I shall 🙂
“Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future,” David Sabine
My name is David Sabine. I’m a Real Agility Coach and have been thinking about what Real Agility means to me.
My introduction to Real Agility began in 2007 when the CTO of the college I was working at in Fort McMurray, Alberta brought in Mishkin Berteig as a third party consultant. Back then, I was a software developer and what I experienced then is still true today. The value of bringing in a third party to solve business challenges is immeasurable.
Time and time again, as I have been involved with companies, either in a training or a consulting capacity, I have found that a third party presence provides or creates a break-through. The purpose is not that I go to a company as a consultant and I bring my new ideas, as though I am the only one with new ideas. What happens instead is that I visit a company and my presence, as a coach, opens the door for the internal staff to explore their own new thoughts, or concepts or possible solutions. So the ideas that are already in the company are just allowed to blossom a little bit in the presence of a third party,because this third party allows or creates a sense of permission, a sense of autonomy for those staff. They’ve been invited to explore concepts and they’ve been invited to think through their business problems from a different perspective and I am there just to reflect what they already have or what they already know.
That occurred when Mishkin Berteig visited the college in 2007, and that occurs every time I go and visit a company for training or consulting.
To really understand what Real Agility means to me, I’d like to tell you about how I came to software development in the first place beginning back in 1993 when I was starting university and was a freelance musician.
I had two passions at the time: the pursuit of music and the logic of programming. My computer tended to pay the bills, more so than being a freelance musician, so as a career path I guess I was drawn to software development and started to build my own products early on in 1996-1997. I was writing software for small business clients with the aim to eventually build a product on my own and release it for sale worldwide.
In 2000, I started to develop a product with a friend of mine. In 2001 we released it to other developers in the world. Our first sale of that product was in Belgium and for the next few years it sold worldwide. We had about 2000 websites that were using our product and it was translated into seven different languages by the community of users. It provided my friend and I with a reasonable income and a great opportunity. It was fun!
In 2006, I realized that my own growth as a computer scientist required working with others beyond this friend, to work in a team, in fact. I moved to Northern Alberta and worked in IT department for a college. As I mentioned, in 2007, the CTO, brought in Mishkin Berteig to provide us with a 3-day training course on Scrum. Quite immediately I loved it because I could see how it would provide us with a lot of opportunity to solve problems we were facing in an IT department and, secondly, it just seemed like a more human way to work. I was reflecting on all of these periods I had had as a musician, working with other musicians, and it just seemed like a better way to approach the creative endeavor than other project management methods that were in play at the time.
Since that time, I’ve been practicing them in a variety of settings and I’m more convinced now than ever that the Agile Manifesto provides us with a great solution space as we respond to business challenges. Recently I’ve decided not to be a developer or product owner but have decided to join Berteig full time and train and coach other teams.
So that’s the story of my personal evolution. My personal journey.
Looking back on that training I can see how I felt immediately that Real Agility was an alternative way of doing things.
I studied music since I was a child and music has always been a huge part of my life,and as a musician, one becomes aware of or familiar with continuous improvement. This is the same concept found in Real Agility. But with music it’s incremental, tiny, tiny increments of improvement over time. We respond to an audience. We respond in real time to our fellow musicians. We are always taking in input and that informs our performance of the music. As musicians, we spend a lot of personal time developing our craft. We spend significant time in performance so we can receive the audience feedback.
What I mean to say is that musicians are excellent examples of high performance teams and are excellent examples of creative excellence, who understand tactical excellence and what it means to get there.
When I joined Software development in a large, bureaucratic institution – the college – it was anything but natural for me. At that time, I was more than just a software developer. I was systems analyst, database admin and a variety of positions or roles. It just felt like an industrialized, mechanical environment where people were expected to behave as interchangeable units of skill. Work was expected to get done in the prescribed procedure. And decisions were expected only to be made by the smartest or the highest paid few and if you weren’t of that ilk, you were not expected to behave autonomously. You were expected to be just part of the machine and it felt very inhuman, as most people feel as a part of a large hierarchical bureaucracy.
When Mishkin facilitated the Certified Scrum Master training course in 2007, it just blew all those doors open. It reminded me that we can approach our work the way I had naturally approached it, as a creative individual who is capable of learning and wants to receive immediate feedback from audience or user, and who can make autonomous decisions about how to apply that feedback into the continuous development of software and systems and large infrastructure.
These business challenges are pretty common. They are delayed projects or projects that that blow the budget, or where a group of people are assigned to the project and they can’t possibly complete the scope of work in the time given. Or staff are demoralized, and how that expands through enterprises. There are many examples. The college where I was working suffered all of the most common issues and the one that hurt me the most or I felt the most was attrition. Dis-engaged staff. The reason for it was simple. The college had not presented with them a purpose or opportunity to be masterful. The extrinsic motivators, salaries and such, were just enough to keep people for a little while and then they would leave. And so the college at the time was experiencing attrition of 35-40% per year and that’s what I meant by inhuman.
“These Real Agility methods presented a change. In fact, people become centric to the purpose!”
When I read the Agile Manifesto I think that it provides us with solutions, and so if our current business problem or business circumstance is that we have disengaged staff who aren’t very productive and aren’t getting along well, then the Agile Manifesto reminds us that perhaps business people and developers can work daily throughout the project together. They can have continual interaction, and then individuals and their interactions become more valuable than the process and the organizational tools that have been put in their way. It reminds us that people should be allowed to work at a sustainable pace. We should build projects around motivated individuals. And that poses questions about how to do those things. What does it mean to be motivated, and how do we build projects around motivated people?
So Agile Manifesto presents us with some challenges, as a mental process, and then when we work through that we understand how it can inform good decisions about how to solve business problems.
“Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future.”
In other words, Agility means being nimble, the ability to adapt to current circumstance, but more than that, Real Agility means that we should approach our work with the intention that we stay light-weight so that when our circumstances change we can adapt without a lot of inertial resistance. So there’s two components there. One is being able to adapt quickly, and being aware of present circumstance but the other is that we don’t want to take on weight and institutional mass, because that’s inertia, the status quo.
“Start executing and worry less about planning.” QA Consultant
This statement appeared on a recent feedback form after a BERTEIG learning event. It summarized a Quality Assurance Consultant’s learning from the CSM training they attended.
This statement so accurately summarizes one of the key principles of agile methodology which is to do minimal planning and review often. It doesn’t mean “No Planning” it just means different kinds of planning and the willingness to jump quickly into action.
Mishkin published an article on this topic in 2015 and it is re-posted here now because it is still so relevant today.
Agile Planning in a Nutshell
By Mishkin Berteig
Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans. However, many teams desire a long-term plan. This can be thought of as a roadmap or schedule or a release plan. Agile planning helps us build and maintain long-term plans.
Agile Planning Process
The steps to do this are actually very simple:
Write down all the work to be done. In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
Do some estimation of the work items. Many Agile estimation techniques exist including Planning Poker, The Bucket System, Dot Voting, T-Shirt Sizes. These tools can be applied to many types of estimation. There are three kinds of estimation that are important for Agile Planning:
Estimating relative business value. Usually done with the business people including customers and users.
Estimating relative effort. Usually done by the Agile team that will deliver the work.
Estimating team capacity. Also done by the Agile team (this is sometimes called “velocity”).
Create the long-term plan. Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work. (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.) Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.
Agile planning allows a team to update estimates at any time. Therefore, the techniques used above should not be thought of as a strict sequence. Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated. Scrum refers to this ongoing process at “Product Backlog Refinement”.
Principles of Agile Planning
In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:
Speed over accuracy. We don’t want to waste time on planning! Planning in and of itself does not deliver value. Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
Collaborative techniques. We don’t want to be able to blame individuals if something goes wrong. Instead, we create safe estimation and planning techniques. Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
Relative units. We don’t try to estimate and plan based on “real” units such as dollars or hours. Instead, we use ordering, relative estimation and other relative techniques to compare between options. Humans are bad at estimating in absolute units. We are much better at relative estimation and planning.
Having a good process is only part of the equation. A good Scrum Master will champion and enforce that process, protect the team, encourage collaboration, highlight (escalate when necessary) and encourage the removal of obstacles, facilitate discussions, provide fair and constructive feedback, cultivate a culture of continuous improvement and learning, and work to help the team live the Agile values.
Remember that the Scrum Master has authority over the process but not over the team. As the process champion the Scrum Master may sometimes even find themselves in a conflict between maintaining the Scrum rules and guiding the team as they discover the need to adapt practices to better align with their own needs and ways of working. In that regard a Scrum Master should understand and embrace the servant leader role. In the end, a Scrum Master needs to be the person that helps the team make decisions, but not the person that makes decisions for them. (By Senior Agile Coach Jerry Doucett)