Real Agility managers help their delivery teams to progress through the stages of team development to reach a sustainable high-performance state. Real Agility is the merging of Agile, Lean, and Community Development. Find out how managers’ roles change in this short video by Mishkin Berteig.
At the end of the day your goal should not be to become Agile or Scrum savvy. Instead your real goals and outcomes should align with achieving the key benefits of Agility, and with what Scrum offers. These should include (but are not limited to) increased customer satisfaction, faster delivery of value, improved feedback loops, adopting a continuous improvement mindset, improved employee morale and increased employee retention. Scrum is just one of the many tools or approaches you may choose to get there, but it is certainly an important one to consider if these outcomes align with your goals.
For Scrum to be truly successful at your organization, you must dramatically transform your very culture and business approach. To be clear, this is not easy to do but the rewards are well worth the effort. By embracing such a transformation, the adopted change in behaviour, beliefs and practices should result in a more successful Scrum experience and a higher degree of satisfaction for both your customers and employees.
Jerry Doucett is now offering consulting in implementing SAFe 4.0, as well as teaching the following courses and workshops:
1) “Leading SAFe 4.0” course for the SAFe Agilist (SA certification)
2) “SAFe Product Manager – Product Owner” workshop (SPMPO certification)
3) “SAFe 4.0 for Teams” course for the SAFe Practitioner (SP certification).
Please reach out to Jerry by email or on LinkedIn if you have any questions about SAFe or about scaling Agility.
The next SAFe class is “Leading SAFe 4.0” on September 08 and 09. Please see WorldMindware.com for more information including registration.
This is a great introduction to Cloud Concepts!
Last week 23 new course offerings were posted at BERTEIG’s Training website.
These classes are offered by Senior Agile Coach Jerry Doucett who has worked in Agile transformation since 2008.
More information on SAFe can be found here and you can register for any upcoming class here.
Have you ever wanted to run an agile project?
Or maybe you are a leader in an organization who has had an agile coach approach you requesting to run an agile project?
This light & comical sketch depicts the often humorous interactions between agile coaches and corporate leaders in various departments.
At the end of this clip, the agile coach has spoken with a CEO, Human Resources, Financial Department, etc and when he goes back to the first CEO he’s had a lot of conversations about his project, but it has not yet started.
The concept of two operating models existing within the same space is so clearly illustrated here. The one framework is about upfront-planning, documentation, assessment and projection of a plan. The other framework (Agile) is about very little upfront planning with a “jump-in-and-get-started” attitude. Adjustments are made along the way with continuous reflection and learning. The product continues to improve and is ready to deliver sooner.
The most successful businesses in the world are the ones where Agile methods have been adopted in every level of an organization.
It is just changing everything.
Several months ago I enrolled myself in a project management class. I wanted to learn about the “old way” of doing things–that is, more simply what we would refer to as the “Waterfall” methodology.
However after taking this course, i’m now apprehensive to call it “Waterfall” as there are so many other outlying elements apart from what defines it as “Waterfall” (Gantt Charts). Instead i’d refer to this practice of project management as being “traditional” and respectful towards a more old-style way of conducting business; or, operating business within a reactive environment.
Reactivity – a measure of the deviation from the condition at which a nuclear reactor is critical.
You see, i’m more of an Agile/Scrum guy (in case you were unaware). I attended this class with an open-mind, glass-empty, eyes-open and ears-listening perspective. However, every class I attended, I compared the methods to Agile/Scrum and thus i’d like to share my learnings from the class.
Before I continue, I would just like to mention that I loved taking this class, I learned new skills, I met talented people, and I would happily take this class under any other conditions.
I learned, there’s no reports in Agile. You reading this would disagree, but compare this to Waterfall–nope. The traditional project management system is designed with reporting in mind; in fact I would say that reporting is the first item on the “to do” list.
Before building anything! We need to make a report for it. (Let’s call it RDD – Report Driven Development)
One could argue that this is incredibly important when there are millions of dollars at stake, shareholders that need to know where their money is going, and of course good record keeping in the unlikely event of lawsuits. However, in all this documentation, when does the project actually yield some development? This is why I call it reactive–because to use this methodology is to focus on avoiding pitfalls, and attempt to foresee explosions.
Personally, I think reports are silly. I once saw a young mother have to stay two hours late for work on a beautiful spring Friday because she had to finish a report. She was the only one left in the office, and I asked her “Why do you have to send the client the report? Why not just schedule a meeting during office hours, and give them a presentation or conduct discussions containing the data within the report?”
“That’s a good idea, I never thought of that” she replied.
Possibly another case where a “nice to have” feature is causing stress to a worker just because a project manager is following an outdated methodology.
One thing I love about the traditional project management suite, is its dictionary of terms and definitions. A lot of really smart people developed and documented the standards that are used within PMP/PMI, such as academics, engineers and scientists. There’s now mountains of documentation supporting all of the concepts within the waterfall world, and rigorous thought-out processes for (almost) every instance that may occur in a project. Also, sidenote: I’m not saying that all of these career paths tend to rely exclusively on documentation, but there’s certainly a lot of documentation involved.
When I was a chef, if you were to cook on the east coast, you’d refer to the small crustacean “shrimp” as “shrimp”, if you were to travel to the west coast, all of a sudden the same crustacean would be referred to as a “prawn”. I’m sure you’ve been in a project where the east coast team used a term that was different from the west coast team, and if you consider communication to be the backbone of Scrum–this could lead to a failure.
Because of that, there’s not a word i’ve encountered within Waterfall that doesn’t have a standard definition. The word “baseline” is used to define the starting position, and that’s why I refer to this education as a “history” class. It’s the sort of stuff you learn before you get into large projects.
There’s a proper place and time for documentation, and in Agile it’s a discouraged practice. Because why have documentation when you should be acquiring the information from talking to human beings. Verbal conversation and timed-planned meetings can introduce subjects with greater accuracy and less time than a well-documented word file.
In dealing with million-dollar projects, and teams of hundreds of people there’s no room for ambiguity within language. And please keep in mind, documentation creates standardization, and it’s the processes required to generate the ubiquitous language that i’ve noticed is a shortcoming within Agile in comparison to Waterfall.
I’d say that the majority of the process we use in Agile project management exist foundationally within Waterfall–but we don’t even realize we use them. A tad bit of studying, and learning the baselines will enable individuals to fortify the foundation in their next project.
Yes, I learned about historical concepts within the project management world. Such as process theories and their corresponding theorists. It’s truly fascinating to learn about how we got to where we are today in terms of project management.
In 1962 Everett Rogers was considered an early adopter and supporter of modern change controls and change requests.
Ultimately, the sad truth is that the majority of processes we follow today in project management are just to cover ones ass. As, historically, the project manager tended to be the focus of “blame” when failures occur within a project.. and the first person to be fired.
Keep in mind that this project management approach is over a century old, and the Agile manifesto was formulated in 2001. So I like to believe Agility is devised for a new world of empowering teams and building stuff, however it’s very important to know where you came from.
The biggest takeaway from my history class, was learning about all the tools that currently exist within the antiquated project management methodology and their gorgeous tools for creating estimates.
Creating estimates is tricky in Agile; mostly because to adhere to the iterative development that the Agile framework represents, you don’t ever look too far into the future. The reality is though is that most businesses need a longterm plan and a lot of us in the Agile world use duct tape and a series of levers and pulleys to make Agile work with estimates. If you’re struggling with estimates, I recommend reading the Project Management Body of Knowledge Version 5 (PMBOK).
These guys have literally been doing estimates for an obscene length of time. I believe if we can hybridize their approach while adhering to the Agile workflow, we’ll have something that can truly change the world.
Having said that, as an entrepreneur I create a budget for all my projects. I accomplish all the business goals early-on in a project so that I can work to pivot them later. Pivoting is what it is to be an entrepreneur, and something that doesn’t work well with Waterfall–which is very un-business-like.
This is the most ridiculous thing i’ve ever seen. I’m familiar with the RFP process as i’ve worked for corporations that thrived from the activity, and during my history class we studied more about what makes the RFP “tick”. Every time I think of RFP’s, I think of how Walmart operates, have you heard this story before?
Walmart tells it’s toothbrush suppliers how much it’s willing to buy the product for, and if the toothbrush manufacturer is unable to accommodate that price, Walmart will choose to get toothbrushes elsewhere. Problem is, there’s always that factory in China who will do it for a third of the price of North America, and create miserable working conditions for the workers. Yes, that’s the world that the RFP creates.
I love the aerospace industry. And what’s the difference between NASA and SpaceX? Well that’s easily the argument of Waterfall vs Agile–as NASA is still using the RFP when they should be considering iterative in-house development. The James Webb Telescope announced in 2002, to cost $842 million and to launch in 2010 was awarded to (what is now) Northrop Grumman Space Technologies. Northrop Grumman then released separate RFP’s to build components of the spacecraft. It then became a global initiative as subcontractors from all over the world were bidding on the components. You can probably bet that those subcontractors put-out RFPs as well.. But that’s my assumption.
TLDR: As of 2013 it’s estimated to cost a total of $8.8 Billion, and launch in 2018. Oops.
If I could summarize Waterfall in one sentence, it would probably be something like: “Waterfall is an excellent tool to make stakeholders happy, and get money from venture capital”. Where Agile is like “Agile is an excellent tool to get shit done, and keep everybody involved in the project at a consistent level of satisfaction.”
Every time I hear about a project going over budget, extending deadlines, and ultimately creating failures within business–really breaks my heart. You know that all the troubles from such a project creates unnecessary headaches, and potentially unemployment. Be a responsible project manager and don’t focus on the happiness of stakeholders.
Learning more about Waterfall was great, and I learned a lot more about Kaizen (iterative development, or, Agile within the Waterfall world). It has also taught me more about what truly makes Agile unique, and not just a buzzword used within industry.
**subtext: if anybody wants to challenge me to building a spacecraft using Agile/Scrum — bring it on.
In the past, in our North American culture, power and authority in an organization was held by those who earned the most money, had the titles to go along with their authority, and they had the right to make decisions about where they went, when they went places and who they associated with. They also had the power and authority to decide what others did and didn’t do in their work environment. That was in the past.Where we are headed in a more unified and equal culture, based on principles of collaboration and understanding is that power is now more equally distributed. Those who didn’t have access to education now do. Those who were previously barred from environments of wealth and prosperity are now welcomed in. Corporate cultures, and organizational models across the board are changing and it’s good for everyone.The biggest challenge in any change arises when someone’s fear of being excluded is realized. The issue is no longer about money or time or integrity. The issue is that as work environments change, old (mostly unconscious) patterns of exclusion are changing too. It means janitors associating with doctors and delivery teams eating lunch with those in leadership (imagine that!). When an organization is going through a transformation, when they notice behaviours which were limiting and exclusive and change them, they are actively contributing to an ever-advancing civilization. They are creating a new and inclusive culture.At times, mistakes will be made. Old ways will sneak their way back in and one or more team member may get snubbed or excluded for one reason or another. This happens. It’s normal and is part of the learning process.But in time, the aim for any agile team is to continually make these old exclusive unconscious habits conscious so that work environments can continue to embrace a greater diversity of people, not just of cultural backgrounds but from different social and economic backgrounds, too.The difference in life experience from someone who has lived in poverty to someone who has lived in wealth is as if they grew up in different worlds, even though we inhabit the same earth. Everything is different. Language. Behaviours. Hopes and Dreams. Everything is different on any level.However, just as different races are now joining together in work and in marriage more often, so are people from different socio-economic backgrounds coming together too, in work, in community building, in families.The pain of the growth is a worthwhile investment into a brighter and more unified future not just for us but for the generation to follow us.
BERTEIG’s David Sabine presented “Rethinking Education” at the first ever TedX talk in Fort McMurray, Alberta in 2012!
“Rethinking Education” has received nearly 3000 views and offers an insightful perspective into the way youth are streamlined into either vocational or educational career paths, and the funding which supports curriculum development. He even addresses important issues such as gender bias. I like how David sees Agile Transformation as having a positive influence on change in our current educational model and how he invites a radical approach to a new way to think about education.
I absolutely love how he combines his background in music composition with his professional training as an Agile Coach at a time when his personal life was changing with the upcoming birth of his daughter. He says “What we need is a common understanding, for a collective effort, for a collective benefit. That is how collaboration will manifest in our social system.”
What an encouraging and inspiring presentation! Please watch the video and share your thoughts on how you would like to see our social education model change now for the future.
From the Scrum Alliance Orlando Conference ”Open Space” Discussion, April 2016, facilitated by Valerie Senyk
Transformation is a big word that Scrum/ Agilists use. It is what we promise our customers through training and coaching.
On the last day of the Scrum Alliance Conference during the Open Space forum, I posed the question: “What is transformation? What do we mean by it?” We had forty-five minutes to try and understand this issue.
Initially, discussion centered around the idea of change and some of the manifestations of change. However, it was pointed out that transformation requires more than a methodology we follow. In fact, it’s more of a way of thinking.
It is easy to say what transformation is NOT: it is not rigid, not prescriptive, not directive. It is about different ways of behaving, it is supportive, and requires a new mindset from being prescriptive to adaptive.
I asked if the participants saw themselves as agents of transformation. Almost everyone did. So, what do they do? And how do they do it?
Participants spoke of the need for greater knowledge and education around Agile, as well as the need to understand stakeholders. To be an agent of transformation is about enabling people, and to enable them we need to understand them.
One commented that when an organization experiences pain, that is an opportunity to go in as an agent of transformation and use that pain as a motivation and means to change.
Transformation is not a one-time event; it requires continuous learning. In order to have continuous learning, agents must create a safety net for innovation to occur. The mindset must be that failure is okay. Trust in the process and in the agent (agilist) is necessary for discovery.
It was understood we can achieve transformation at a surface level to begin with, but true transformation occurs at a personal level. How is it possible to achieve this deeper level?
One participant spoke about the need for love, for truthfulness and for transparency to be part of a personal-level transformation. As a member of the BERTEIG team, I know that love, truthfulness and transparency are integral to how we work, and how we deliver services.
Ultimately, there is a difference between change and transformation. Change means one can go forward but then step backward. Change is not necessarily permanent. But transformation is really about irreversible change! And small transformations are steps to larger ones.
Discussion then centered on what motivates transformation. Behavioural change needs to be felt/ desired at a visceral level. Organic analogies were suggested to help educate and motivate – that in the natural world we see constant development and change. Why would we be any different?
The question was posed: What do we transform to? People need to be shown the beauty of the next step…beauty in itself becomes a motivation.
Is it enough to help change an organization or corporation to run beautifully and smoothly within itself? Or is there a higher purpose to transformation?
One attendee spoke about how all the cells in the body work autonomously for a higher purpose, which is the functioning of a human being.
In business also, transformation can also be pursued for a higher purpose. Imagine a corporation transitioning from pursuing purely monetary rewards to its pursuit being about making a positive contribution to society. It was pointed out that studies show that companies with a higher purpose actually have higher revenue.
However, it was also expressed that everything that matters in life cannot be measured.
We concluded the session with the idea that transformation requires looking outward as well as inward. It’s not just about us and our customers – it’s ultimately about creating social good.
I have been grappling with the idea of transformation for many years, from the viewpoint of the spiritual as well as that of an artist. Hearing the ideas and understanding of the twenty-plus people who attended this session helped me see that transformation on a larger-scale requires patient but strongly-motivated steps toward an ideal that may seem intangible to some, but is worth every moment in pursuing. For it is in the pursuit of the best ways over the better that transformation is wrought.
Hundreds of Canadian employees from corporations, businesses and organizations are attending training to become Certified ScrumMasters and Certified Product Owners under the aegis of the Agile umbrella. From testimonials received from almost all attendees, they are enthusiastic about this training. As many have written, the training is helping them think beyond the status quo, and they are excited!
They return to their workplaces, report to their managers, talk amongst themselves – and then what happens? Nothing. Nothing changes. Their learning, their positive motives to enact change, their hopes slowly dissipate in the face of ignorance and apathy.
Where’s the disconnect?
It seems the disconnect belongs to the executives. CEO’s, VP’s, upper management have been avoiding a work revolution happening right under their noses. The revolution began in 1998 with the creation of the Agile framework, resulting in the Agile Manifesto, http://agilemanifesto.org, written in February of 2001 by seventeen independent software practitioners.
Not only has Agile transformed software creation, but it has been proven to be of value for all areas of business enterprises and organizations beyond software and IT departments.
Are executives remaining willfully ignorant of a twenty-first century framework for creating more fulfilling workplaces and delivering greater value to their customers? Or will Executives learn what is happening at the grassroots and make changes to fulfill the hopes of employees?
This is a call to action. It is time for executives to step up to the plate.
Real testimonials about training can be found at http://www.worldmindware.com/CertifiedScrumMaster
Very nice article called Why I Always Start a Meeting with a Check-In. From the article by Ted Lord, senior partner, The Giving Practice:
The greatest benefit of working in a group is our diversity of viewpoints and approaches; groups hobble themselves when they don’t continually give attention to creating a container of trust and shared identity that invites truth-telling, hard questions, and the outlier ideas that can lead to innovation
One antidote to over-designed collaboration is the check-in.
Great metaphor! Scaling Agile – a perfect method.
I have heard many reasons why a new team should wait to start “doing” Agile. Recently, I was asked to help a group who was struggling to get a Scrum team started. They had real obstacles to overcome, but waiting wasn’t helping them.
This group was part of an IT initiative to develop a business intelligence program for a large energy company. The existing processes were highly inefficient and wasteful. The losses were in the ballpark of $1M/day. There was a long history of failed solutions. Needless to say, this was a critical project.
Those of us who understand Scrum well know that the more critical a project is, the more urgent it is to get a team up and running as early as possible. Unfortunately for this group, there was a great deal of cultural inertia from the IT management holding them back, including chronic distrust between IT & business leadership. IT management perceived Agile to be a risk and a threat. They were tolerating it as a “pilot project”. They wanted to be sure that when Agile failed, they would not be left holding the bag. Their solution for self-preservation was to insist on getting the architecture of the system in place before the team started to work on features.
The only developer that management trusted with the initial architecture work was also extremely busy working on other projects. This individual and several other people slated to be on the new Scrum team were tied up working on change requests for a Waterfall project with no clear end in sight. It seemed impossible to predict when the system architecture work might begin, let alone end.
Meanwhile, the Product Owner was waiting for some new functionality that he could use and show to his superiors—the stakeholders that he reported to in the business. The program manager, who was the champion of the Scrum implementation, understood Scrum to be the way to succeed. The first Scrum team was wrapping up on the first project in the new program and the business was happy with the process and the results. This confirmed his understanding and gave him some traction to move forward. But he didn’t have authority over all of the slated team members (specifically the sole developer trusted by IT management) to start.
I tried to explore possibilities of moving forward with the program manager. The conversation went something like this:
TB: Are there some people who are available to start as the team for the new project?
PM: Yes.
TB: Great! Do you need the star developer on this project or are there other people who have the skills to do the work who could be on the team?
PM: There are other people with skills who are available and who could be on the team.
TB: Great! Do you have the authority to make that happen?
PM: Yes.
TB: Great! Can we have the first Planning Meeting tomorrow?
PM: Yes.
TB: Great! What time do we start?…
One might get the impression from reading that conversation that we were on our way to Sprint 1. However, as we know, things are usually not that simple. There were several more obstacles to work through.
(As an aside, I know that some people reading this might be thinking “what about Sprint Zero”. These guys were talking about Sprint Zero, -1, -2…basically all the way back to Waterfall. I needed to help them overcome that tendency.)
Below are a few of the other obstacles they were struggling with:
—
1. The program manager had assigned a project manager, one of his direct reports, as the ScrumMaster to the new Scrum team. This person was already responsible for (and overwhelmed by) the Waterfall death march project now in perpetual change request mode.
Advice for anyone in this situation:
Find someone else to be the ScrumMaster. It would be a better use of the external consultant (myself in this case) to serve as an interim ScrumMaster (coach) so that the team could just start, rather than trying to use a traditional project manager who was already overwhelmed by other responsibilities. In other words, don’t wait for your ideal ScrumMaster candidate to be ready. In most cases, management’s first choice for ScrumMaster is often not the best one. If you do not have an experienced coach to serve as interim ScrumMaster, then the best thing to do is hire someone specifically for this role. Again, it is better to just start than to wait for this new hire. If you have to wait for the new hire, someone from the team should just volunteer and learn on the job until help arrives. Even that will give you far better results than waiting. Just start!
—
2. The project manager who was assigned as the ScrumMaster was assigning Product Owner responsibilities to a business analyst that reported to him. The “BA” was worried that the Product Backlog was not ready for the team. The real Product Owner had created a high-level Backlog with items that were most likely too large for the team to complete within the two-week Sprint duration that they had decided on. The BA was trying to work with the PO, but there wasn’t much reciprocity there, mainly because of lack of knowledge of the business on the part of the BA and the PO’s lack of trust in the BA’s ability to serve as his proxy on the team. During one of my previous visits over a month before, the PO, BA and a few of the other team members had workshopped the Product Backlog, refining the top “epic” and creating a User Story small enough for the team to start working on and complete in the first Sprint. Now, that story was lost and forgotten.
Advice for anyone in this situation:
Don’t wait for the Product Backlog to be perfect. If the Backlog is not ready, use the first part of the planning meeting to identify what the team and the Product Owner can agree on as the deliverable for the first Sprint. In fact, that is all you should be discussing in this meeting in any case. With the right people in the room (the whole team) this can be done well enough. If the team is not able to agree within the time box of this meeting, it most likely means that you don’t have the right people in the room. For example, there may be a project manager and a BA who want to delay the start of the project because they feel uncomfortable with the perceived ambiguity of the process. It would be better if these people were not on the team and not in the room. If the team says something like “we can give you ‘X’ in two weeks” and the Product Owner says something like “good with me”, then make that your Goal for the Sprint and get on with the second part of planning—creating a set of tasks to execute the deliverable.
During the first Sprint, the Product Owner can be working with the team to refine the next items in the Backlog based on what has been learned from the Planning Meeting, which is probably a great deal. The purpose of the Product Backlog is to realize a great Product. Don’t wait for a perfect Backlog—just start!
—
3. The culture of fear and distrust perpetuated by IT management was pervasive and the team was afraid to make a commitment to a deliverable.
Advice for anyone in this situation
Help people understand commitment as a team capability that develops over time. Teams are able to make and keep commitments based on historical velocity. For at least the first Sprint and perhaps for a while after that, new teams will not be able to make firm commitments. Most teams fail to deliver after their first Sprint. There is a learning curve to Scrum. There is a lot of change and a lot of new things going on. The environment of a new Scrum team is drastically more dynamic and complex than what most people have previously experienced. It takes getting used to. People need space to learn. Help them overcome their fear of failure. Agile is about failing fast. Get it wrong early, learn, adapt and change course. What a young team needs to be committed to is learning what it needs to do in order to deliver potentially shippable product every Sprint. In order to do that, you need to be doing Scrum.
—
I started this post by identifying that there are many reasons to delay “doing” Agile. I believe this stems from a cultural dichotomy in our society between “being” and “doing”. We don’t start doing something until we believe that we are prepared to succeed at it. We have to “be” ready before we can “do”. This is a false dichotomy that Agile is designed to help us overcome. Another dichotomy is success vs. failure. The only real failure in Agile is the failure to learn and improve. Even the notion of “failure to deliver” is misguided. The real failure is not learning to deliver. In order to “be” Agile, you need to be able to fail. In order to “fail” at Agile, you need to do it. By doing Agile and failing, we learn to be Agile. There is no other way.
So, please… just start!
This is my first crack at a series of posts intended to document reflections, insights and experiences that have been generated over the past several years at Berteig Consulting in our work helping organizations to transform with Agile methods and approaches.
The most recent iteration of our collective practice is the Real Agility Program. The Program was created as a flexible yet systematic process for developing high-performance teams. The Program involves assessments, training, leadership and delivery teams coaching and internal coach development for teams and organizations that want to transform in order to become hyper-productive, lean and robust.
A central tenet of the Program is that teams are organic in nature. They are living systems that grow and develop in the right conditions. They also develop in stages. The Real Agility Program addresses the natural stages of team development with a sequence of steps or “sections”.
Much like a seed, a new team has the latent potential for developing into a complex organic system of high-performance capabilities. Capabilities of high-performance start out as a simple set of attributes and grow in complexity and strength over time. Capabilities to carry out more complex activities are built onto capabilities for more simple activities. Little by little, high-performance can be realized in this way.
Something that most teams need help with early on, particularly if they do not already possess a growth mindset, is overcoming the false dichotomy between theory and practice. An indication of this is when we hear people say things like “well, that makes perfect sense in theory, but it’s just not practical for us.” Or “we need help to put that theoretical idea into practice in our own reality”. This reveals a mindset that conversations around concepts and ideas are only valuable if they can be implemented immediately in a measurably beneficial way. The desire for technical recipes is understandable. They can help with immediate pain relief. They are not the most effective way to build capabilities.
The Tree of Organic Growth is an exercise that we often share early in the Program and is designed to help teams develop a more integrated mindset and approach to capacity building (very similar to The Tree of High-Performance in Lyssa Adkin’s wonderful book Coaching Agile Teams). The facilitator usually starts by drawing a simple diagram of a whole tree, including the roots. Sometimes, simply exploring the concept in a conversation serves the purpose just as well. The team is asked to identify values, concepts, principles, qualities, skills, attitudes, habits and knowledge that are already present on the team that will serve as roots for building capabilities of high performance. The conversation is not merely a nice, (“fluffy”) theoretical stroll in the proverbial park, but a critical aspect of the hard work of re-shaping thought, which in turn re-shapes reality.
Let’s look at an example of the aspects of building a specific capability. A well-known Agile capability of high-performance is the self-organization of the team. On one level, it starts to happen as soon as a group of people come together to accomplish something and no one person is identified as the “boss”. Without certain capabilities in the members, however, this can get very Animal Farm in almost no time. High-performance requires the development of qualities, attitudes, conceptual knowledge & understanding, habits and skills in all members of the team. For example, team members need to develop the qualities of openness, integrity and helpfulness. Attitudes such as a humble posture of learning and serving the team need to be developed. Knowledge of concepts such as consultative decision-making and Wideband Delphi and how self-organization differs from traditional command and control project management needs to be developed. Good habits and practices such as regularly coming together as a team to reflect and plan are essential for the team to become able to deliver complete increments of high value often. And, of course, team members will need to learn skills in terms of communication and collaboration, as well as other technical skills that may have previously been outside of their formal roles.
Furthermore, everyone can develop in any of these areas of any capability at any given time. Just like in any organic system, capabilities of high-performance benefit from constant nourishment, feedback and reinforcement.
Growing a high-performance team is a complex process that requires a great deal of effort, patience, time and a supportive organizational environment that will allow for all of these aspects to develop on a team. It is an investment in people as much as it is a business decision. There are no shortcuts or formulas, but with the right conditions, every team has the potential to develop capabilities of high-performance.
