Becoming a high performing team is not a straight line, it’s a journey. By being more aware of where the team is along their journey, you’ll be better equipped to help; whether it’s through teaching, facilitation of a startup or reset, coaching in the moment or other approaches.
The Tuckman’s Team Development Model offers a window into the Team journey as a series of stages. These stages include Forming, Storming, Norming, Performing and more recently, Adjourning and Transforming.
If you’ve read or watched the Lord of the Rings Trilogy, it describes the archetypical Hero’s journey. Here’s a recap of the stages as it relates to the story (Please be advised, there are spoiler alerts ahead).
Forming
The Tale begins in a small village full of Hobbit people. The setting is cast in beautiful lush green pasture-land with rolling hills. There’s a sense of curiosity and wonder about the place.
The characters don’t necessarily know each other well, or at all. However, they share a common connection through their friend Gandalf the wizard whom they admire. You can call him the Agile Scrum Master or Coach.
Soon an evil arrives and threatens the land. Gandalf makes it known to the villagers that they must act to stop the forces in order to survive. He assembles a group of volunteers to combat the evil presence, and they embark on their long journey.
Here it can be helpful for teams to get clear on their shared goals, values and agreements. The earlier they can get to know one another and identify their preferred ways of working, the sooner they can move forward in service of becoming a high performing team.
Storming and Norming
Along the way, the protagonists have petty squabbles with one another. They bicker at times and form camps. Trust is low.
While the group is trying to figure out how to work together, Gandalf, one of the strongest protagonists unexpectedly dies while protecting the group from an attack.
The group realizes that if they continue to operate as they have, that they will not be successful and the world will be lost.
If you find that your teams are going through a period of conflict, know that they have actually moved forward. In service of helping the group, this could mean staying neutral and providing room for the group to work through things on their own, sharing that this is a natural part of becoming a team, or by facilitating deeper conflicts where appropriate.
Performing
Here it becomes evident that the company now is truly working as a team. They share a collective goal. Selfless behaviors are emerging. They are operating more synergistically.
At one point, one of the characters is carrying another up the mountain because they are unable to continue themselves.
Together, against many difficult odds and obstacles the team defeats the great evil and returns back to the place where they started.
Adjourning and Transforming
While the characters in the same place they started, they are not the same people they used to be. They have all been transformed internally. There is a collective sense of accomplishment paired with a bittersweet, melancholy. This is goodbye for some, and for all a goodbye to what was.
There is a sense of optimism and excitement for the next adventure or calling ahead combined with a sense of angst and uncertainly of what lies ahead.
Takeaways
A high performance team is magical, when it happens. However, getting there is not. Becoming a high performing team involves a concerted journey that takes awareness and effort. If you can discern where teams are along their path, and better yet, help them to detect their own stages, you’ve already stacked the odds in favor of success.
Think of a time when you’ve been a part of a strong team. Can you recall where there were major challenges and breakthroughs? What happened?
How does this fit in your current context? Can you identify where your team might be today?
How do you write and communicate effective Business requirements from an Agile standpoint?
I recently worked with a client who was interested in leveraging Agile to improve requirements writing and communication in her organization.
In the pre-call meeting for the class, she asked me, “So how do we establish good requirements between Business and IT? And how do we pass them along and not have to hear from the Business again?”
First, the good news is that there are tangible ways to significantly improve requirements writing and communication.
The second part of this question requires a bit of re-framing.
To expect that no communication is required from the business (or vice-versa) is not a realistic outcome. However, with the right structure in place, requirement communication and delivery will become a productive exercise.
So let’s dig in. Here are some ways to significantly improve requirements writing and communication.
1) INVEST in your requirements
Agile requirements use INVEST to improve writing
Requirements should follow the INVEST principle. That is, they should be Independent, negotiable, provide value, be estimatable, are about the right size so that they can be implemented by the team, and are testable.
2) Use a “card, conversation, confirmation” approach to agile requirements writing and communication
The most Agile requirements are written from the customer standpoint. A great way to apply this concept to requirements is to use the “card, conversation, confirmation” format.
Card: As a <customer> I should be able to <action> so that <benefit>
Conversation: Review the card with development team and cover questions. Aim to have conversations to flush out assumptions and mark as ready. Move on when the team unanimously gives a thumbs up confidence vote.
Confirmation: This is the acceptance criteria that must be met in order to sign off on the requirement. A good way to write acceptance criteria is to use a Gherkin format. Use the vantage of a particular customer/user.
Example: Scenario 1 – Given <a precondition>, when <action>, I should expect <result>
3) Choose the right level of granularity
Requirements should zoom into the right level of abstraction for the audience in mind. Make sure to keep the overarching goals in sight. Requirements should be born from a high level purpose. They should be increasingly broken down into more bite-sized areas for execution.
All of these levels are relevant since they connect strategy to execution. The levels should connect the why to the what to the how.
Initiatives – Organizational business goals (KPIs, Business requirements) Ie. Improve speed of content entry by 10% (Executive level)
Features – Highest level of requirements ie. Content Management and Publishing Portal (Executive-Program level)
Epics– functional requirements – ie. Content Entry (Program and Team Level)
Stories – (Team Level) More detailed but (INVEST) small, independent, valuable, estimateable, testable – entail a conversation, have clear acceptance criteria. Ie. Publisher uploads new science publication document.
4) Establish up-front working agreements for better communication
Agile talks about the importance of customer collaboration. There are two types of working agreements that help improve communication between business and engineering. These working sessions happen initially up front and are revisited periodically.
Draft a Definition of Ready
The Definition of Ready (DoR) includes all things that should be included in requirements before they can marked READY to be worked on by the development team. Some examples might include:
1) Clear acceptance criteria are in
place
2) The requirements include major
design assets
3) The requirements reviewed and acknowledged
by the team
Draft a Definition of Done
The Definition of Done (DoD) includes all things that must be completed before declaring the requirement as DONE (or “done done”). Some examples might include:
1) The unit tests have been written
and pass.
2) Test Coverage is 80% or better
3) The acceptance criteria have
been met
4) The requirement has been reviewed
and acceptance tested by the business owner
5) Take smaller bites
Often the pain associated with requirements is related to information overload. This is often where you may find requirements churn.
Break down requirements into smaller chunks that can independently provide business value. Leverage the INVEST criteria. Try to spend no more than a focused 1-2 hours per session to groom the top-most valuable items. Then move down the backlog of requirements and repeat.
6) Have the right people in the room
Have you ever played the telephone game? And how did that turn out?
Ensure that the right people are in the room from the get-go. The right people are those who can uncover assumptions of the requirement, or those who can help make the right decisions. Wasted time and effort will be saved in the long run.
For a product owner on a team, this
meeting might include the engineering team and designers.
Or for Business Owners, this might be representatives of the financial, marketing and operations teams.
Get everyone aligned in the same room from the beginning and you have already stacked the deck in your favor.
You may find that you have trouble identifying the right people. Step through the requirement end-to-end from a customer standpoint. Try to understand the underlying systems that are in place. Some examples of systems include the Marketing system, Fraud system, Customer Records system and Billing system. From there, identify key people who represent those areas and bring them in.
7) Establish a rhythm
Practically speaking, one of the biggest challenges related to requirements and communication is that Business people in particular often have chaotic schedules, and it is all but impossible to get everyone in the same room.
Are you begging, bribing and stealing for peoples’ time? One of the most effective ways to solve for this is to establish a regular product requirement grooming cadence. So if the events are already established, attendance will improve. With a regular schedule, meetings will be shorter. If you’re a facilitator, this reduces the overhead of scheduling multiple ad-hoc meetings.
Depending on the nature of the
project, a focused hour a week can work well for 10-20 person product/engineering
team.
8) Visualize the work
Leverage a visual centerpiece around the work. It could be an ordered backlog, or a roadmap showing the current and upcoming features.
This will be used as a springboard to help drive collective conversations about the product. Use an easily accessible, up-to-date medium (like a shared wiki). This will go a long way to simplifying communication and alignment.
9) Hold regular product demos to capture and communicate requirement feedback
One of the most powerful ways to bridge
communication and foster continuous product improvement to is hold regular product
demos.
In terms of format, these demos are often hosted and led by the engineering delivery teams. The demo is delivered to the business stakeholders.
The intention is to focus on sharing the actual working solution. This activity should be informal and not require much up-front preparation. So leave the slides at home. From this, you can expect a lot of valuable collaboration to spring up. Questions and feedback from the Business can be used to shape the product backlog in the future.
What’s great about this exercise is that it’s unifying, motivating and engaging. The teams walk away with a sense of recognition and appreciation and the business has learned something new.
In Summary: Writing and communicating great Agile requirements
With the right structure in place, your organization will significantly improve on requirement writing and communication.
Incorporate INVEST and ‘Card, conversation, confirmation’. Your Business will be on its way to having clearer requirements.
Break down requirements into smaller more actionable units. Rhythmically include the right people.
Visualize your work. This will lead to a more aligned view. It will permit feedback to refine the product over time.
Finally, foster a common understanding of expectations between Business and Engineering. Establish working DoR and DoD agreements.
Now you have the structure to improve requirements writing and communication. It’s important to take action! Make a conscious effort to apply these techniques daily and you will gain improvements!
Contributions
Thanks to Daniel Bales and Angela Wick for their valuable feedback.
Michael Nassif is a Principle at ZenAgile, a training and consulting firm that specializes in developing high performance, empowered organizations. They take a heart-centered approach by providing hands-on training and workshops in the applications of Lean and Agile.
Implementing an Agile Transformation is No Simple Feat
Creating deep, lasting organizational change is hard.
One of the biggest reasons behind a successful organizational tranformation is the quality of leadership that is behind the implementation. Without strong Leadership in place, a company is unlikely to make cultural change stick.
The Reason Agile Transformations Fail
Most transformation efforts seek to instill a creative culture – the kind that attracts the very best talent, drives innovation and ignites speed to market. Leaders aim to promote and foster this in their organization. Yet often the same leaders have not fully honed their own internal capabilities and those of their people in order to enact and sustain the change. And so you get a lot of activity that fails to result in a deep, lasting change. And leadership does not see itself as the reason it failed.
Have you ever experienced the “flavor of the month”?
In order for cultural change to stick, leaders must be willing to look inward. Management training and on-the-field practice does not equal the real world day-to-day. Like gravity, without the proper internal operating system in place, Leaders will fall back to their modus operandi, or Reactive Level of Leadership.
As a Lean-Agile coach for Fortune 100+ organizations, I recognize that am limited in my ability to effectively help other leaders rise to a higher level of performance than I am currently capable of internally. Correspondingly, it is important that Leaders take the initiative to work on their own development and the development of their people. The Leadership Circle Model defines this process as:
1) Uncovering the creative and reactive leadership areas
2) Developing creative leadership areas
3) Reducing reactive leadership areas
Broadly, there are five stages of leadership that are relevant to the degree that an organization achieves transformational success; The Egocentric, the Reactive, the Creative, the Integral, and the Unitive. Here I will be covering the first three.
The Egocentric Leadership Level
“Do not tolerate brilliant jerks. The cost to teamwork is too high.” – Reed Hastings, CEO Netflix
At this level, it’s all about Numero Uno (me). About 5% of adults operate here. The emphasis is on loyalty to self. This type of leadership is normal in adolescent development. But in adulthood, it’s considered pathological and it’s extremely destructive to an organization’s health. From a Leadership and culture standpoint, this must be addressed.
The Reactive Leadership Level
This is about loyalty to the organization. There is a strong congruence between a Leader’s competency and their sense of identity. For example, if I am good at fixing problems, then a Problem Fixer is who I am as a person. I may be the Intellect, the Architect or the Orchestrator. That’s me. I’ve seen good talent leave the building because the ways of working changed, like the incorporation of a new programming language into the company’s technology stack as a DevOps and Continuous Delivery enabler. Here, the “Java Expert” identity was put squarely at risk, and they felt compelled to act accordingly.
These Leaders typically care deeply about their people and manage like well-intending matriarchs or patriarchs. It’s all about competency. It’s mechanistic. Input is typically taken from below and decision making is made at the top. At this level, there are lots of risks and liabilities as it relates to leading and sustaining a transformational change. The vast majority of leaders in organizations operate here.
The Creative Leadership Level
The Creative level emphasizes development of self and others. The leader is no longer the sole decision maker. They instead act as facilitators and as developers of people. They are responsible for the vision, and in helping others to see how it converts into reality. At this stage, sharing power is not seen as letting go of control, but rather as acquiring power by way of sharing it.
As I transitioned in my career from a Scrum Master supporting a couple of teams to Coaching a program with over a dozen teams, it was important to recognize that in order to scale successfully, shifting my mindset from being a problem solving leader to a developer of others, was integral. I could not be everywhere. The economics simply no longer made sense.
In fact, the degree to which I was able to equip others as Leaders became my own top success criteria. For example, if I found that in a given week I had an increased volume of people swarming my desk, I knew something was up. I would step back and ask myself, is the intent clear enough? Do people have the information readily available to them make high quality decisions and act? What needs happen to enable them to do their job effectively?
This doesn’t just mean supporting formal Leadership roles like management and product but also the “knowledge workers” who are closest to the work itself.
Thought Exercise:
Clock yourself at five minutes to write answers to the following questions:
What is the primary cause of failed transformations?
Which levels of leadership do you see yourself mostly operating in (egocentric, reactive, creative)?
What are your top two strengths? Where do you go when you’re in a crisis?
Executive Scenario: Our customers are a priority. We need to deliver this by quarter, we can fix things that are broken in q1 next year. What type of Leadership level does this suggest?
“We’re agile, we have scrum teams, we do daily stand ups, we have sprint planning.” What could be missing?
“We have scrum teams, we do daily standups, we focus on impediments, we care about our people and our customers, we monitor our quality, we are often willing to take short term business trade-offs to make sure our technical debt is kept down.” Is this an Agile team?
In what ways will transitioning to the next area of Leadership benefit those around you and your business success?
