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.
From Essential Kanban Condensed by David J Anderson & Andy Carmichael
“Kanban is a method for defining, managing, and improving services that deliver knowledge work, such as professional services, creative endeavors, and the design of both physical and software products. It may be characterized as a “start from what you do now” method—a catalyst for rapid and focused change within organizations—that reduces resistance to beneficial change in line with the organization’s goals.
The Kanban Method is based on making visible what is otherwise intangible knowledge work, to ensure that the service works on the right amount of work—work that is requested and needed by the customer and that the service has the capability to deliver. To do this, we use a kanban system—a delivery flow system that limits the amount of work in progress (WiP) by using visual signals.
I’ve been reading the above book on Kanban (the alternative path to agility) to familiarize myself with the method before taking the Kanban course by Accredited Kanban Trainer Travis Birch.
Two points from my learning are the principles of “Change Management” and “Service Delivery.”
Kanban regards “Change Management” as an incremental, evolutionary process as Kanban is utilized. For example, Kanban starts “with what you do now.” A business agrees to pursue improvement through evolutionary change, which happens over a period of time, based on experience and understanding. If one is using Kanban for the first time, there may be some awkwardness at the beginning, with a number of people trying to understand the principles, and how the visual board works. As the work goes on, understanding is increased, and with the new learning, change occurs in a very organic way. Acts of leadership are encouraged at every level. Changes can occur in all sectors: within individuals, within the environment, and in the cumulative outcomes of the work.
“Service Delivery” in Kanban requires that there is an understanding of and focus on the customer’s needs and expectations. The work is managed by people self-organizing around the work, and by the limiting of work-in-progress (WIP). This can help people feel that they have the right amount of work to accomplish with the right amount of time. WIP limits are policies that need to be made explicit in order to establish flow. The work on the board is “pulled” into the in-progress section only as people become available to do the work. An employee can focus on bringing higher quality to the work, and not feel threatened by a backlog that is crushing them. Policies are evolved to improve outcomes for the customers.
Of the nine values outlined in Kanban, three are directly related to change management and service delivery. The first is “respect;” by limiting the work-in-progress, respect is shown for the employee’s time and efforts, along with respect for the customer’s expectations. “Flow” refers to there being an ordered and timely movement to the work being done that is not overwhelming. “Transparency” occurs because everything is visible on the Kanban board and it becomes clear what is being done, when and by whom.
It’s been proposed that Scrum is for teams and Kanban is for services. In that way, they are both essential to the improvement of many organizations, especially those in which pure Scrum is not enough. They are complimentary from the perspective of improving business.
“Kanban has principles and general practices, but these must be applied in context, where different details will emerge as we pursue the common agendas of sustainability, service-orientation, and survivability. As a result, the journey is an adventure into unknown territory rather than a march over familiar ground” (from Essential Kanban Condensed)
In a recent scan of the e-literature on the reciprocal impact of Agile on HR, I connected some very interesting insights which I’d like to share. A set of insights that looks like ripples across the surface of a pond. Ripples that started when the Agile stone was thrown into the pond in 2001. In its simplest form, Agile is about a different way of working with each other in teams. Teams that are cross-functional, collaborative, co-located and customer-driven in their decision making. The insights provide compelling reasons why HR needs to take an active role in Agile implementations.
“In the most successful Agile transformations, HR is a driver of the change and a key hub that steers other departments’ success.”
HR certainly needs to be ‘a’ driver in the change, but not ‘the’ (sole) driver. Rather they need to partner in the change. Successful Agile transformations will benefit from HR’s expertise in
Learning & Development
Workforce Planning & Talent Management
The driver of the change, historically IT, will need HR’s help to manage the impact to people and traditional HR processes/tools. As the change scales and starts to impact other departments in the business, HR can play a large role in ensuring the business overall stays aligned in delivering end-to-end value to customers.
“2016 will be the year of Agile HR… most HR teams have no clue what Agile HR means.”
(HR Trend Institute)
Agile was a hot topic for HR in 2016 as evidenced by the number of times ‘Agile HR’ has made the shortlist of topics being brainstormed for HR conferences and networks. It was the #1 trend on the 2016 HR Trend Institute list. Its popularity is not cooling off in 2017. And yet most HR teams still don’t have a clue what ‘Agile’ means, never mind what ‘Agile HR’ means.
“As the world becomes more volatile, organizations need to find ways to become highly agile. HR will need to support a world where people may no longer have predefined ‘jobs’ that lock them into doing one activity.”
Agile has entered the mainstream. A necessity given the VUCA world we live in. Agile is no longer the sole domain of IT. The common refrain from all C-suite leaders these days is increased agility and nimbleness across the entire business – not just IT. The impact of capital ‘A’ Agile or small ‘a’ agile will affect HR. People will no longer have predefined jobs – People’s career paths will change. In this VUCA world, standardized career paths are no longer effective. Batch-of-one career paths will become the norm.
“HR’s job is not just to implement controls and standards, and drive execution—but rather to facilitate and improve organizational agility.”
The HR profession itself has been going through its own transformation. The HR profession has evolved from an administrative and transactional service to a strategic business stakeholder with a seat at the executive table. The role of HR now includes a focus on organization-wide agility and global optimization of departmental efforts.
“Human capital issues are the #1 challenge for CEOs globally.”
(The Conference Board CEO Challenge 2016)
The Conference Board’s 2016 survey of global CEOs ranked human capital issues as the number one challenge. It has been number one for the last four years in a row. Within that challenge, there are two hot-button issues:
Attracting and retaining top talent
Developing next-generation leaders
The adoption of agile ways of working will change
How we recruit and engage
How we nurture and grow not only our leaders but our talent in general
In the words of Robert Ployhart, “…employees don’t just implement the strategy – they are the strategy”. CEOs around the world would tend to agree.
The net of these insights is the more HR professionals understand Agile and its implications, the more effective Agile or agile initiatives and people/strategy will be.
I’d like to see HR ride the wave.
 VUCA is an acronym introduced by the US military to describe a state of increased Volatility, Uncertainty, Complexity and Ambiguity
 Ulrich, Dave, William A. Schiemann, Libby Sartain, Amy Schabacker Dufain, and Jorge Jauregui Morales. “The Reluctant HR Champion?” The Rise of HR: Wisdom from 73 Thought Leaders. Alexandria, VA: HR Certification Institute, 2015. N. pag. Print.
Note: This review is based on an incomplete pdf copy of Product Mastery that was shared with the reviewer, which therefore limits discussion of the book.
Geoff Watts, author of Scrum Mastery, has now released Product Mastery: From Good to Great Product Ownership, published by Inspect & Adapt Ltd. The book contains two Forewards by Jeff Sutherland and Roman Pichler, both masters in the field of Scrum management.
The prose Watts uses is straightforward and provides an easy and intelligent read even for the layman, with graphs and illustrations that illuminate his ideas.
The book is built around the idea of DRIVEN, an acronym Watts uses to discuss the traits and characteristics of a great product owner. The book uses each letter as headings, i.e. D = Decisive, R = Ruthless, I = Informed, V = Versatile, E = Empowering, and N = Negotiable. Each heading offers pragmatic advice into the many responsibilities of being a product owner. I will give a few snippets of some insights that Watts shares.
In the first section, entitled “Decisive,” Watts creates stories and discussion that show how product owners need to have courage and trust themselves and others to make decisions, often with incomplete information. He gives strategies to make the decision-making process easier, such as reducing the number of options a product master is considering, and prioritizing. He cites Edison as once famously saying, “I have not failed. I’ve just found 10,000 ways that won’t work.”
Under “Ruthless” Watts shares a mantra used by product owners: “If the product is going to fail, then I would rather it fail in month 2 than month 22.” In other words, it is better to develop the wrong thing quickly and get feedback, than wait too long in an effort to make sure no mistakes are ever made.
The third section is called “Informed.” Watts includes a quote by Roman Pichler, author of Agile Product Management with Scrum, who told him: “Customer feedback is the basis for ideas. Customer data is the basis for decisions.” Watts then cites the experience of a company that creates mobile games. Rather than ask for ratings or feedback, the company monitors actual usage of their games.
In “Versatile” Watts advises product owners to “remain flexibly firm.”
Under the last heading, “Negotiable,” he outlines games to play when negotiating attributes of a product. In this section Watts makes it clear that product owners need to be careful to not fall into the trap of being a perfectionist. He writes: “The temptation to just add a little extra here or there is very strong; but those little bits here or there quickly add up and can easily lead to significant delays, not to mention an unnecessarily cumbersome product to support.”
Product Mastery is a book that is sure to attract a wide readership as it provides a balance
between vision, direction and execution. Wisely, Watts is not dogmatic in his style. He gives numerous approaches to the items under a product owner’s watch. He writes: “Great product owners know how to find the right middle ground, one with an appropriate balance of data and intuition – and a good measure of courage.”
I personally will be adding Product Mastery to BERTEIG’s book offerings for our Certified Scrum Product Owner attendees.
Product Mastery: From Good to Great Product Ownership (282 pp)
“Business engagement alone is a necessary but not sufficient condition for Agile to succeed”
It’s taken a while but now it’s well understood amongst seasoned Agile practitioners that Business engagement is necessary for successful Agile implementations. Just when we thought engaged Business owners were enough, we’re now realizing Business engagement alone is not sufficient. The impact of corporate shared services, especially Human Resources (HR), on Agile adoptions or transformations are often overlooked. In fact, Agile practitioners often bypass HR in their zeal to quickly change the way they work and the related people processes.
“Companies are running 21st century businesses with 20th century workplace practices & programs”
– Willis Towers Watson
It’s not just IT departments practicing Agile but 21st century businesses overall that are characterized by flatter organizations and an insatiable appetite for small ‘a’ agility. Agility that is pushing and breaking the envelope of current HR processes and tools. Agile individuals and teams are very vocal when it comes to calling out technical obstacles in their way. The same could be said when it comes to HR related obstacles that impact Agile individuals and teams. If we listen, here’s what we would hear:
“Can we team interview the candidate for attitude and fit?”
“I was an IT Development Manager. What’s my role now?”
“My manager doesn’t see half of what I do for my team. How can she possibly evaluate me?”
“With no opportunity for promotions in sight, how can I advance my career?”
“Why do we recognize individuals when we’re supposed to be focused on team success?”
“Charlie’s not working out. Can we as the team fire him?”
As the volume increases, how will HR and HR professionals respond?
“2016 will be the year of Agile HR … most HR teams have no clue what Agile HR means”
– HR Trend Institute
The reality is that most HR teams have no clue what Agile is, never mind how it will ultimately rock their world. Most Agile initiatives emerge from the grass-roots or are driven independently by IT functions with little to no involvement from HR. HR sits on the sidelines and watches IT “do their thing”. There is a misconception that Agile exclusively falls under the IT domain; overlooking the fact that the core of Agile is about the people and culture – the sweet spots of the HR profession.
There are three significant change movements gaining momentum:
Reinventing the way we work – whether it’s IT adopting Agile or an organization becoming more nimble.
Reinventing HR – where HR is moving beyond its historical focus on basic people administration, compliance and transactions to a valued place at the executive table; ensuring context and alignment across the business to generate Customer delight.
Reinventing organizations – as the level of human and organizational consciousness evolves from valuing meritocracy, accountability and innovation to valuing self-management, wholeness and evolutionary purpose. (See “Reinventing Organizations” by Frederic Laloux: http://www.reinventingorganizations.com/)
All three have the common denominator of people; an integral part along the entire timeline of each movement. As these three movements overlap – at the intersection – will be HR. So, who better to help navigate the emerging paths of each change than “the People’s people”?… otherwise known as “HR”.
An analysis of the Human Resources Professionals Association’s (HRPA) Competency Framework shown below can help guide which HR competencies will have the greatest impact (on a scale of 1 to 10) on Agile.
“How do we get HR started towards their destiny?”
If you’re an Agile team member, invite HR to start a conversation about what Agile is and how they can help you and the team.
If you’re an HR professional, here are some suggestions:
Learn about Agile
Visit with your Agile teams during sprint reviews or daily scrums
Talk to your friends and colleagues about their Agile experiences and challenges
Review in-progress HR process & tool changes through an Agile lens
Partner with IT and other Agile implementation stakeholders to guide the success of Agile
To help HR take the first step, here are some suggested Agile learning resources:
In a search for new vistas and growth, my husband had been scanning employment ads across the country and applied for a job he was well-suited for with a large corporation. He received two interviews by telephone and SKYPE. The new job would require us to move several provinces, leaving family, friends and a community we were attached to.
He received confirmation by telephone that the corporation wanted to hire him. We spent a few days agonizing over a decision, consulting with family and friends, praying about it, and decided my husband would accept the job. After his verbal acceptance, a contract followed a few days later, which he duly signed and sent back. He was told it had been signed at the other end and he could now announce the new job publicly.
He gave notice to his present employers, as did I mine, and we proceeded to take steps to put our house on the market, search for housing in the new city, and pack. We had begun to say good-bye.
Three days later a phone call came from the HR Department of the corporation saying they had to rescind the contract as someone “higher up” had not given approval for it.
We were stunned. There had been no hint in any part of the process that the job offer was in any way tentative or not thoroughly vetted. We had taken many steps forward, and now had to backtrack several steps.
My husband had to go, hat in hand, to his current employers to see if he could retain his job. After a painful good-bye session with my team I had to inform them that I was not leaving.
This whole experience has brought to mind the importance of what my employer, BERTEIG Inc, is attempting to do through agile training, consulting and coaching.
The “Agile Manifesto” proclaims:
“Individuals and interactions over processes and tools.”
And, further on:“Customer collaboration over contract negotiation.”
These are prime values to be lived by small and large businesses.
Admittedly, Agile was initially created for software developers, but more and more corporations and organizations are seeing the value in being agile, and are responding to this necessary change of culture in what is currently a time of deep disruption.
What if the corporation my husband was contracting with had honored the implications of “individuals and interactions over processes and tools” and “customer collaboration over contract negotiations?”
If some “higher up” had not actually given approval for this hiring, once the contract was signed at both ends (which it was), could this higher-up not have responded with more agility, more compassion, and more ethically?
What if he had acted in such a way that, even if he did not approve the contract, he acknowledged the good intentions of both sides and let it go? After all, his corporation was getting a highly-qualified, experienced employee.
What if he was transparent and acknowledged that the contract was not to his liking, and asked would my husband consider some other version of it? And then consulted directly with my husband and HR over certain changes to the contract? And made sure everyone was agreeable with the changes?
What if the “higher-up” just called my husband directly, apologizing that the contract was made without his say-so, that they were not in a position to hire him, and offered two-months salary for any damages – material and emotional – that had been incurred?
The above scenarios could have changed the situation from one of loss, to one of win-win for both sides. Agile frameworks are clearly proving to be of great benefit to employers and employees alike.
Hundreds of eager attendees take Certified Scrum Master and Certified Product Owner training from us. Many have taken our Certified Agile Leadership offering in cooperation with Agilitrix. Do the corporations they belong to welcome the changes these attendees are prepared to make? Are corporations taking steps to truly alter their culture?
The Losing End
My husband was almost employed in that organization, where hundreds of others are employed. I wonder how often their employees experience this type of trauma, since this neglectful handling of my husband’s contract is a likely sign of ongoing cultural problems within.
This rescinding of a contract was a losing situation on both ends. The corporation in question lost a highly-talented employee who would have been extremely loyal and hard-working (as was determined in the interviews). My husband lost professional credibility having to backtrack with his current employers. We lost the challenge of a new adventure.
We’re recovering, despite this having a huge emotional impact on our lives. We’ve been agile enough to say: we’re still here, we still have jobs, we can make the best of it all.
I just wish that Big Corp would get it. And soon. Before more is lost.
In reality, Kanban isn’t actually saving Agile nor is it intended to, nor is any thoughtful and responsible Kanban practitioner motivated by this agenda. What I’m really trying to convey is how human thinking about the business of professional services (including software development) has evolved since “Agile” as many of us know it was conceived around 20 or so years ago. The manifesto is the collective statement of a group of software development thought leaders that captured some of their ideas at the time about how the software industry needed to improve. Essentially, it was about the iterative and incremental delivery of high-quality software products. For 2001, this was pretty heady stuff. You could even say that it spawned a movement.
Since the publication of the manifesto in 2001, a lot of other people have had a lot of other good ideas about how the business of delivering professional services can improve. This has been well documented in well known sources too numerous to mention for the scope of this article.
Substantial contributions to the discourse have been generated by and through the LeanKanban community. The aim of Kanban is to foster environments in which knowledge workers can thrive and create innovative, valuable and viable solutions for improving the world. Kanban has three agendas: survivability (primarily but not exclusively for the business executives), service-orientation (primarily but not exclusively for managers) and sustainability (primarily but not exclusively for knowledge workers). Kanban provides pragmatic, actionable, evidence-based guidance for improving along these three agendas.
Evolutionary Theory is one of the key conceptual underpinnings of the Kanban Method, most notably the dynamic of punctuated equilibrium. Evolution is natural, perpetual and fundamental to life. Long periods of equilibrium are punctuated by relatively short periods of “transformation”—apparent total and irreversible change. An extinction event is a kind of punctuation, so too is the rapid explosion of new forms. Evolutionary theory is not only a scientifically proven body of knowledge for understanding the nature of life. It can be also applied to the way we think about ideas, methods and movements.
For example, science has more or less established that the extinction of the dinosaurs, triggered by a meteor impact and subsequent dramatic atmospheric and climate change, was in fact a key punctuation point in the evolution of birds. In other words, dinosaurs didn’t become extinct, rather they evolved into birds. That is, something along the lines of the small dinosaurs with large feathers hanging around after Armageddon learned to fly over generations in order to escape predators, find food and raise their young. Dinosaurs evolved into birds. Birds saved the dinosaurs.
There has been a lot of social media chatter and buzz lately about how Agile is dead. It is a movement that has run its course, or so the narrative goes. After all, 20 years is more or less the established pattern for the rise and fall of management fads. But too much emphasis on the rise and fall of fads can blind us to larger, broader (deeper) over-arching trends.
The agile movement historically has been about high-performing teams. More recently, market demand has lead to the profusion of “scaling” approaches and frameworks. Scaling emerged out of the reality of systemic interdependence in which most Agile teams find themselves. Most agile teams are responsible for aspects of workflows—stages of value creation—as contributors to the delivery of a service or multiple services. Agile teams capable of independently taking requests directly from and delivering directly to customers are extremely rare. For the rest, classical Agile or Scrum is not enough. The feathers just aren’t big enough. Agile teams attempting to function independently (pure Scrum) in an interdependent environment are vulnerable to the antibodies of the system, especially when such interdependencies are merely denounced as impediments to agility.
Some organizations find themselves in a state of evolutionary punctuation (the proverbial sky is falling) that can trigger rapid adaptations and the emergence of local conditions in which independent service delivery teams can thrive. Most large, established organizations seem to be more or less in a state of equilibrium. Whether real or imagined, this is what change agents have to work with. However, more often than not, the typical Agile change agent seems adamant that the sky is always falling and that everyone accepting that the sky is falling is the first step to real and meaningful change. This is not an attitude held by Agile change agents alone. This is a standard feature of traditional 20th Century change management methods, the key selling point for change management consulting.
Naturally, most self-identifying “Agilists” see themselves as change agents. Many of them find themselves in the position of change management consultants. But the motivation for change can quickly become misaligned: Change needs to happen in order for Agile to work. If you are passionate about Agile, you will seek to bring about the environmental changes that will allow for Agile to thrive. We don’t need to follow this path too far until Agile becomes an end in itself. It is understandable then that for some, Agile appears to be a dead end, or just dead.
But if there is a larger, over-arching historical process playing out, what might that be? Perhaps it has something to do with the evolution of human organization. Perhaps we are living in a period of punctuation.
Two weeks ago I joined a temporary team of Scrum Alliance Certified Scrum Trainers and Certified Enterprise Coaches. It was a fabulous experience and I hope that I will be able to do it again sometime soon. We worked together to build real valuable results for the rest of the Scrum ecosystem including reference training modules and in-depth website content, feedback for Scrum Alliance programs, and even some fun videos.
Brock Argue was one of the CECs there, and he has written a great summary of how it felt: The Art of Teaming Part 1. One cool point he makes:
Introductions were friendly and helpful and as we started getting into the work things heated up…. I got frustrated with the direction of the conversation and I grew impatient with the lack of progress we were making. I’m sure other team members were experiencing similar feelings, and as coaches we understand how difficult team formation can be. Imagine how unsettling this is for a team who isn’t aware of these group growth stages; that they’re unavoidable and healthy to experience.
The stages Brock is referring to are the stages of team development as described by Tuckman: Forming, Storming, Norming, and Performing (and sometimes Adjourning is added on).
Thanks to Robin Dymond, Mark Levison who organized the event and Shannon Carter from the Scrum Alliance who supported the event with her personal presence.
Recently after attending a Scrum Alliance webinar on “Best Practices in Coaching,” I was reminded of my experiences teaching Acting students at university, and how I used changing status to help them achieve their best.
Status refers to the position or rank of someone within a particular group or community. I believe it was Canadian Keith Johnstone who introduced the idea of “playing status” to theatre improv teams. It is used to create relationships between characters onstage, and to change those relationships to move a story forward.
Status can be indicated through position, posture, facial expression, voice and clothing. It is a fascinating tool for any trainer or coach to use.
At the beginning of a semester with new students, I would invite them to sit on the stage floor in a circle with me. I would welcome them, discuss my expectations of their learning, and tell them what they could expect from me. We’d go over the course syllabus and I’d answer questions. I purposefully put myself in an equal status to them, as a way of earning their trust, because the processes of acting* requires huge amounts of trust. I also wanted to establish a degree of respect in them for the stage by all of us being in a “humble” position on the stage floor.
However, when I would introduce a new exercise to them that required them to go beyond their comfort zones, I would deliver instructions from a standing position while they were seated. By elevating my status, I conveyed the importance of the exercise, and it was a signal that it was not something they could opt out of. In this way, I could help them to exercise their creativity to a greater extent.
Another way I encouraged my students to take risks was to take risks myself. Sometimes I would illustrate an acting exercise by doing it myself first. For those few minutes I became a colleague with my students, one of them, equal in status. If I could “make a fool of myself” (which is how it may look to an outsider), then they could too.
I had one student who had great potential, but who took on the role of class clown and would not give it up. He fought against going deeper and getting real. One day in an exercise where they had to “own” a line of dialogue, I had him in a chair onstage, while I and the rest of the students were seated. He had to repeat the line of text until it resonated with him and became real. After some minutes, nothing was changing in him. In desperation had him turn his chair around so his back was to us. I then indicated to the other students to quietly leave the room. He could hear something happening but was confused about it. He was not able to turn around and look.
When I allowed him to turn around it was only him and me left in the theatre. I had him go through the repetition exercise again. Without an audience, and with me still seated, he finally broke through the wall he had erected and connected with the line of text from his inner self. It was a wonderful moment of truth and vulnerability. I then allowed the other students back in, and had him find that connection again with the students there. He was able to do it.
He is grateful to me to this day for helping him get beyond his comfortable role as clown to become a serious actor.
When training or coaching, it seems to me there can be huge value in playing with status. Sometimes taking a lower status, an equal status, or a higher status, can move a team or upper management into discovering whatever may have been blocking the process. Again, there are many ways to indicate status and even a status change to effect progress.
In his book, “Improv-ing Agile Teams,” Paul Goddard makes some important observations about using status. He writes: “Even though status is far less obvious than what is portrayed on stage, individuals still can take small steps to encourage status changes within their own team. For example, asking a team member who exhibits lower status behaviours to take ownership of a meeting or oversee a process not only boosts that person’s confidence but also increases status among peers…these subtle actions can help make lower-status team members feel more comfortable when expressing new ideas or exposing hidden problems.”
A colleague reminded me of a 1975 publication called “Power: How to Get It, How to Use It,” in which author Michael Korda gives advice about facial expression, stance, clothing and innumerable ways to express “power.” The idea of using status in the context I’m writing about is not about gaining power, but about finding ways through one’s own status changes to help unlock the capacity and potential of others.
How can a coach use status to help someone in management who is blocking change? Is someone on a team not accepting what others have to offer because s/he is keeping his/her status high? Is a Scrum Master necessarily a high-status team member, or rather a servant to the team (low status)?
I am curious if any coaches or trainers out there have used status in a way that created growth and change.
*Good acting is a matter of the actor finding the truth in oneself as it relates to the character he or she is playing. It requires vulnerability and courage to step out of one’s known persona and take on another as truthfully as possible. Inherent truthfulness also applies to work in any other endeavour.
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.
We are looking for a highly-motivated person to help us take our training business to the next level! This position is focused on sales, but includes other business development activities. The successful candidate for our training sales position will help us in several areas of growth including:
direct sales of our existing training offerings
expand our training loyalty program
launch and expand new training offerings
expand the market to new locations outside the GTA: Vancouver, Montreal, Ottawa, etc.