Forming, Storming, Norming and Performing in a Scrum Team

An essential Scrum Master role is to facilitate the formation of new teams, and this is where Tuckman’s “Stages of Group Development” model can help.

In 1965, Bruce Tuckman published “Development Sequence in Small Groups” which detailed four phases of group development. By understanding the evolution of team behaviour, the Scrum Master can specifically target each phase:

Forming: The assembled team discusses the development vision, roadmap and high-level features. Initially, they work independently on tasks and act as a group of people rather than a team. Lacking clear alignment and trust, the team members avoid conflict and instead focus on collecting information and agile planning.

The Scrum Master works in the forming stage to promote positive initial team behaviours. Leadership style at this stage tends to be directive and teaching. Activities include:

Running a kick-off workshop to orient everyone involved in development Creating the right physical environment to aid collaboration Engaging with businesses, customers and stakeholders Encouraging the team to confront threatening topics

Storming: Team members begin to form opinions of each other and start to challenge situations they feel are unfair or wrong. Personality clashes and arguments highlight tensions in relationships and disagreements over practicalities. Decisions are difficult due to the high level of uncertainty that is present.

Note that approximately half of teams skip this phase; for the rest, the Scrum Master strives to get the team to face its conflicts and find solutions. The leadership style transitions to providing guidance by coaching and mentoring. During the storming stage, the Scrum Master:

Facilitates workshops to understand conflicts and identify solutions Empathises tolerance and demonstrates the value of differences and diversity Promotes agile values and principles

Norming: When agreement and consensus have been reached, the team starts to become cooperative and cohesive. Roles are understood and ground rules are established. The team members take responsibility and work together for mutual success. By becoming accountable, they begin to understand each other’s contributions.

The empowered team assumes authority during the norming phase, which alters the leadership style to emphasize facilitation and support for the team. The Scrum Master’s actions include:

Facilitating customer workshops Organising external activities to increase socialisation Developing communities of practice and mentoring Ensuring the team does not grow complacent and avoiding potential conflicts Focusing on constant innovation and incremental improvement Helping the wider organisation to support the team and transform more widely

Performing: With firmly established roles in place, the team can focus on achieving their common goal, often with a high level of success. A strategically aware, motivated and skilled team working in an autonomous and self-organising way can move dynamically and address issues quickly.

During the performing stage, the leadership style is participative and collaborative, with the fully empowered team providing its own solutions. Scrum Masters:

Encourage a high degree of autonomy Support growth within the team, both personal and aligned with delivery goals Facilitate development review and disengagement activities

In 1977, Bruce Tuckman and Mary Ann Jenson published “Stages of Small-Group Development Revisited" which added a fifth stage, the adjourning stage, which covers the break-up of the team. This phase recognises the sensitivity and insecurity that team members face following successful completion of development. In this stage, the Scrum Master facilitates a review to enable self-reflection and recognition of contributions, followed by the co-creation of a plan for transitioning roles.

It is important to consider that changing circumstances, such as the addition of new team members or unexpected market conditions, can cause teams to revert to earlier stages in the model. Even high-performing and long-standing teams can run through the same cycles, with experience providing the knowledge and tools they need to move through the stages faster.

Tuckman’s model also highlights why a move to long-term teams and product development make sense due to the lengthy period of time required to form high-performing teams.

Mathematician George Box once said, “Essentially, all models are wrong, but some are useful.” The value of a model is in its application, and Tuckman provides us with a simplified view of the development of maturity within a team and its relationships, ability and required leadership style for each phase. By using this model, the Scrum Master can empower the team with the right tools to move forward.

Consider your current team using Tuckman’s model – which phase are you in? Let me know in the comments section below.

Linguistics in Agile: Top 10 Anti-Agile Terms

Agile practices have introduced a new lexicon for people to absorb and understand. Happily, along with the useful terms comes a more entertaining vocabulary.

Here are my top 10 favourite anti-agile terms:

Agile in Name Only, or AINO: Companies that have adopted agile frameworks and practices without embracing the cultural changes required. Dark Scrum: Abusive forms of Scrum, where the framework is misapplied to oppress and exert power over developers. Ron Jeffries introduced this term in September 2016. FrAgile: Agile practices that are performed without rigour or discipline. FrAgile provides an excuse for poor quality development that avoids accountability. Lipstick Agile: Agile practices cosmetically applied without any understanding or noticeable difference to the true nature of development. In other words, you can put lipstick on a pig, but it will still be a pig. ScrumBut: Scrum is "adopted," but dysfunctions are accepted by the team as the standard way of working. The syntax for this is (ScrumBut)(Reason)(Workaround). For example, "We use Scrum, but we have thirty-four people in our development team because we are working on a complex project.” Scrumdamentalist: An evangelically pure follower of Scrum practices who operates from an ivory tower, typically with a two-day CSM "qualification" and no experience. Essentially, scrumdamentalists have no sense of reality. TrAgile: Tragically implemented agile frameworks or projects that end in tragedy. In these situations, agile practices are nominally in place but without true understanding or tangible improvement. For example, daily Scrums which contain 32 people, last an hour and consist of everyone giving a status report according to a Microsoft Project plan. Wagile: A hybrid of waterfall and agile development practices resulting either from desperately trying to save failing projects, or from slipping back to waterfall from agile. By completing several short waterfalls, teams delude themselves into thinking that they are agile. At best, this adds shorter iterations, agile walls and daily meetings to failed waterfall projects in an attempt to reduce overall risk and appease management. Water-Scrum-Fall: A failed implementation of agile where requirements gathering is completed first, and teams then perform the implementation before the results are passed to the deployment team for eventual release. Zombie Agile: A blind adherence to agile practices without adopting the mindset required to make them work.

Please tell me about your favourite agile (or anti-agile) term in the comments section below.

The Role of a Product Owner (Part 4): Pragmatic Considerations

In this series of posts, I have covered responsibilities, characteristics, daily activities and anti-patterns of product owners. In this final post, I wish to summarise a few pragmatic considerations of the role.

The product owner is the single neck on the block, and is responsible for setting the direction for development as well as making hard decisions in the interest of driving value creation. They work in close collaboration with stakeholders, customers, the Scrum Master and the development team daily.

Filling the Product Owner Role

Unfortunately, experienced product owners are hard to come by in many organizations. For this reason, existing employees will typically be expected to fill the role. The two employees who are most likely to make that transition are:

Project managers: PMs can serve as effective product owners by using their financial, people, planning and organisational skills to oversee domain knowledge and product backlog management. The ability to shed any command and control tendencies in exchange for a “one-team, one-dream” mentality will also help to smooth the transition. They will usually require assistance from a business analyst to manage the product backlog.

Business analysts: With their strong product knowledge and solid customer relationship skills, BAs also tend to transition well into a product owner role. They will often require a project manager’s support, particularly when it comes to stakeholder management and financial modelling.

Developing as a product owner takes time, so a “product owner team” comprised of both a project manager and a business analyst is often employed to provide the project with a secure foundation. This allows both the PM and BA to learn from each other for the duration of a project (or product development life cycle), and thus develop more rounded skills than they would have otherwise.

A Careful Balance

A product owner must carefully balance customer outcomes against business value while simultaneously considering both technical debt and team morale. This requires deliberate coordination between many elements within the project, including other teams, suppliers, business departments, customers and users.

Another necessary consideration is the widespread organisational change required to support agile development. Although this change begins with small Scrum teams, it quickly expands to encompass the entire concept-to-cash life cycle of a product. Of course, changing the finance, legal, HR and PMO departments of an organization can be a lengthy process, but agile requires--or perhaps causes--rapid cultural transformation.


Thank you for reading this series of posts. It has been an interesting exercise to open my thoughts on Scrum roles to challenge and discussion, and I hope they have proven useful to you in some small way. If you have any opinions or observations on this series, please feel free to share them in the comments section below.

If you’re interested in learning more about product ownership, I recommend the following five books:

“Succeeding with Agile” by Mike Cohn  “Strategize” by Roman Pichler  “Agile Product Management with Scrum” by Roman Pichler  “Essential Scrum” by Ken Rubin  “Product Mastery" by Geoff Watts 

The Role of a Product Owner (Part 3): Anti-Patterns

Part one of this series examined the responsibilities and characteristics of a product owner; part two looked at their daily activities during a sprint. This third post focuses upon common anti-patterns seen with the product owner role.

Here are my “dirty-dozen” product owner anti-patterns:

1. No Single Product Owner

Each Scrum team must have a single product owner. Multiple stakeholders are acceptable and usual, but one person must be identified and empowered in the role of product owner for the team.

Solution: Identify a single product owner for each team.

2. Inaccessible Product Owner

The product owner must be available to the team to answer questions whenever required so as not to reduce capability and lower morale.

Solution: The product owner must be present to support the team during development - aim for at least 50 percent availability.

3. Proxy Product Owner

When the real product owner is unavailable, and a proxy is appointed, then it is critical that they are fully empowered within the role. Proxy product ownership often leads to delayed decision making, conflicts in direction and an overall lack of trust within the team.

Solution: Engage the real product owner or fully empower a proxy. Additionally consider employing specialists to provide extra support.

4. Role Confusion

There are only three roles within a Scrum team - product owner, Scrum Master and developer. The Scrum Guide specifies each team role, following this guidance helps to avoid confusion and potential corruption of the framework. Additionally, the product owner should never be double-hatted as the Scrum Master.

Solution: The product owner should perform that and only that role. Also, note that the product owner is part of the Scrum Team and not separate to it.

5. Lack of Product Focus

The product owner’s focus must be on developing a successful product. When the role is confused as a managerial role it can attract political appointments and results in sub-optimal performance.

Solution: “The product owner is responsible for maximising the value of the product and the work of the development team” - The Scrum Guide 2016.

6. Inadequate Product Backlog Management

The product owner is responsible for creating and managing the product backlog. By evolving the product backlog during development, the product owner maximises return on investment and improves customer outcomes.

Solution: The product owner must maintain the product backlog so that the work is visible, transparent and ordered.

7. Poor Feature Slicing

Product Backlog Items should consist of vertical slices of end-to-end functionality. Solutions are developed and delivered incrementally from skeletons, prototypes, minimum viable products and minimum marketable products to fully featured products.

Solution: Create work based on the end-to-end value to maximise feedback and reduce risk.

8. Lack of Vision

The product owner creates and communicates the vision for the product based upon customer domain knowledge and an understanding of the development life-cycle.

Solution: Create a clear vision and communicate it to everyone.

9. Faster, Faster

Pursuing the speed of delivery over customer outcomes does not lead to long-term product success. Although shorter lead times (concept-to-cash) is great for feedback cycles, sometimes faster is just faster.

Solution: Focus on addressing customer’s needs with high-quality solutions, iteratively and incrementally.

10. Failure to Trust

Product owners must demonstrate trust in the development team in their words and interactions. Trust prevents poor practice such as:

Stretch Goals- Product owners identify extra work “in case the team finish early.” If the development team completes the planned sprint work early, they will ask the product owner what they would them to work upon next. Development Interference- Micro-managing teams plus tracking and chasing each task performed. Self-organising teams require leadership and not management. Estimates as Deadlines – The development team forecast the work to be completed within a sprint. This estimate can change and the product owner must take this into account.

Solution: Trust and support the development team to deliver.

11. Absent Governance

Scrum is not the absence of discipline; governance is still essential to maximise value and minimise risk. The correct outcome-based metrics are required in addition to stakeholder and risk management. Applied correctly, agile projects are lower-risk and more transparent to everyone involved.

Solution: Provide appropriate light-touch governance throughout development.

And we are done. “That was only eleven anti-patterns and not a dozen as you claimed” I hear you cry, well that is because we are agile and always finish early (wink, wink).

Hopefully you recognise some of these patterns and can avoid some of the others.

You have to learn from the mistakes of others; you won't live long enough to make them all yourself.”

- Eleanor Roosevelt (quote attribution is actually unclear, though Mrs. Roosevelt is the best match)

In the final post of this product owner series, I will focus upon the pragmatic considerations of the role.

What do you think? Please let me know in the comments below.

The Role of a Product Owner (Part 2): Life in the Fast Lane

In part one of this series of posts on the role of a product owner, we explored the responsibilities and characteristics of the product owner. In this second post, we will explore the day-to-day activities of a product owner within the context of a sprint to further investigate the role.

For the sake of brevity, I have chosen to focus on a single Scrum team performing two-week sprints as the basis for this post. This is just an example, and every team is different. I’ll cover standard Scrum events (shown in italics) plus additional common activities.

Day 1: Sprint Planning

The Scrum team attends the sprint planning collaborate and agree on a plan of what will be performed during the new sprint. In part one of this event, the product owner discusses the goal for the sprint and the product backlog items that are required to achieve it.

The product owner clarifies product backlog items and answers questions from the development team who make the final decision on what is included within the sprint. Working with the development team, the product owner helps to craft a sprint goal to provide a cohesive objective to be met by the sprint.

The development team continues in the second part of this event to determine how the selected work is to be completed according to the definition of done. The product owner does not need to attend part two of sprint planning, but should be available to answer questions when required.

Day 2: Stakeholder Discussion

The product owner meets with high-level stakeholders within the organisation to update them on progress and to ensure that the development roadmap remains aligned with the business strategy. The stakeholders within this organisation are unable to attend sprint reviews so receive their information directly from the product owner.

In the afternoon, the product owner reviews any completed product backlog items against the definition of done and accepts them as completed, or rejects them back to the development team. The product owner collaborates daily with the development team to progress work and answer questions.

Day 3: Product Backlog Refinement

The Scrum team attends the product backlog refinement to review, estimate and split items within the product backlog. The product owner presents product backlog items and answers questions from the development team to ensure that there is an accurate forecast and a common understanding. The aim of these weekly meetings is to ensure there are three sprints worth of product backlog items that meet the definition of ready.

Day 4: Daily Scrum

The daily scrum is a development team event to aid coordination and collaboration. Although the product owner does not need to attend this synchronisation activity, it is worthwhile if they can attend whenever possible. Generally, the product owner is there as an observer but should be allowed by the Scrum Master to answer questions if required.

Day 5: Mid-Sprint Review

For some new Scrum teams, a mid-sprint review (or sanity check) can be useful to gauge progress and discuss any remedial activities that may be required. This meeting should not be required as the product owner works daily with the development team answering questions and resolving problems. In this example, the Scrum team has decided this meeting is useful for their current stage of development.

The product owner and development team discuss progress, review the sprint burndown chart and decide if they are on track to complete the forecasted work. They also identify impediments and agree on actions to ensure work is finished for review at the end of the sprint.

Day 6: Customer Feedback Sessions

Regular feedback sessions are organised to gain valuable customer feedback on the product being developed. These range from facilitated supplier workshops, exploratory customer interviews, usability test sessions and analytics reviews. The aim of these sessions is to guide the development of the product to maximise business and customer value.

The product owner’s role is to fully understand the target market and create strong customer relationships so the best possible outcome can be achieved.

Day 7: External Reviews

When working as a single Scrum team in a traditional organisation with external suppliers and internal departments, the product owner must ensure alignment is maintained. In this case, the product owner has arranged a rolling series of meetings with third-party suppliers, security, quality assurance and operations.

The long-term goal is to pull these capabilities within the Scrum team to provide an end-to-end service, but this will be an incremental improvement.

Day 8: Product Backlog Refinement

The product owner attends the weekly refinement session to work with the development team on preparing product backlog items for the upcoming sprints. This includes adding required detail, ensuring dependencies are addressed and preparing acceptance criteria. Items are prepared according to the definition of ready to ensure that they can be accepted by the development team into a future sprint.

Day 9: Daily Scrum

The product owner attends the last daily Scrum of the sprint to ensure that they understand how the development team is progressing and can support them with any last-minute issues. Additionally, the product owner volunteers to help address any actions and prepare for the sprint review. 

Again, the product owner is not required at this development team alignment event but it is a positive team-building behaviour and should be encouraged as long as the product owner is only present to watch.

Day 10: Sprint Review and Sprint Retrospective

On the last day of the sprint, the Scrum team meets for the sprint review with interested stakeholders and customers. This is an informal review where participants inspect what was completed during the sprint and agree on what to do next.

The product owner identifies the work that has been completed within the sprint and any items that were forecast but not done. The development team then discusses progress, demonstrates work completed and answers questions from attendees. The product owner clarifies and records any feedback to maximise the value of this event.

The product owner ends the sprint review by discussing the current product backlog, updating the release burndown chart and presenting forecast completion dates based upon the progress made.

Following a break, the Scrum team attends the sprint retrospective to reflect upon the previous sprint and identifies potential improvements. This is the key event within the “inspect and adapt” sprint cycle enabling collaboration to identify and prioritise improvements. It is for the product owner to agree on which potential improvements will be included into the next sprint.


The product owner role is varied and demanding with focus required upon stakeholders and customers plus strong and continual support needed for the development team.

Although not noted above, the Scrum master is also an integral part of the Scrum team and supports the product owner with managing the product backlog and facilitating events.

While the product owner role is generally considered a half-time role, it is often a full-time activity when all of its many aspects are covered.

What do you think? Let me know in the comments below.


The Role of a Product Owner: Responsibilities & Characteristics

In the Scrum framework, the product owner is the voice of the customer, represents the internal stakeholders, and is responsible for delivering the highest possible value to the business.

In this series on the role of the product owner, I’ll help clarify product owner responsibilities and characteristics, the day-to-day work of the PO, anti-patterns that emerge in this role, and additional considerations not to be missed.

The Product Owner Overview

As the empowered lead role within the Scrum team, product owners are responsible for the product’s success. By creating, ordering and validating the list of work to be performed, the product owner has authority to decide what will be developed and when.

The ideal product owner is the person paying for the product, more generally a business-facing person is empowered to fill the role. It is important that they understand the market, product, business and any constraints involved.

By creating and communicating a clear vision, the product owner focuses the efforts of the team upon delivering the best possible customer value. Working closely with the customer and internal stakeholder, they work to bridge the gap between the business and customer needs, and the development team.

To achieve this, they must have deep customer knowledge, provide proactive stakeholder management and understand how the product is developed and delivered.

The product owner role is very demanding with significant responsibilities and as such, is generally considered full time. If you cannot devote at least half of your time to the role, then it is better to recruit someone who can.

Product Owner Responsibilities

Product owner responsibilities vary widely dependent upon the product and development environment, but include many common factors. The product owner owns all these responsibilities, but they should collaborate on them and may decide to delegate certain aspects.

Four common product owner responsibilities are:

1. Alignment on Vision

Product goal setting and the creation of a vision are the responsibility of the product owner. The vision needs to be clearly communicated with all those involved in the product including stakeholders and the development team. This enables the vision to be used when making decisions on prioritisation and direction.

2. Managing the Product Backlog

The product owner is responsible for the generation and management of the list of work to be completed by the development team. This involves writing product backlog items along with acceptance criteria, and ordering them to achieve the product vision. By making the product backlog visible to all those involved with the development, the product owner optimises work performed and ensures stakeholders understand the overall strategy and developmental roadmap.

The product backlog is the live source of all remaining work to be completed during development. It is continually updated to ensure that the team is able to deliver the most important tasks iteratively and incrementally.

3. Owning the Finances

The product owner is accountable for good economic decision-making during development at the sprint, release and product level. The iron triangle of scope, budget, time (and quality) can be traded in order to provide the best return on investment. The cost/benefit of each product backlog item can also be used to determine the ordering of work.

4. Participation in Development Events

The product owner is a key part of development events including planning, refinement, review, retrospective, the sprint and daily scrum.

During planning activities, they work with stakeholders to determine the content and steps required to deliver the next iteration at a sprint, release or product level.

Within weekly refinement sessions, they work with the development team to define, elaborate, estimate, order or delete product backlog items.

They lead reviews to ensure the product increment is examined in the optimum way to elicit feedback and determine the route forward for development.

During retrospectives, they collaborate as part of the team in determining and selecting improvement actions.

During the sprint, they work in the Scrum team, including answering questions and accepting product backlog items as they are completed. Only the product owner has authority to add or remove work from the sprint, cancel the sprint or stop overall development of the product.

They can also attend daily scrums to coordinate and collaborate with the development team on development work being performed within the sprint.

Product Owner Characteristics

There are five common characteristics for product owners:

1. Available and Engaged

A key aspect of the role is being available to answer questions from the development team. Questions can arise at any time and any delay will impact the capability of the team. The most successful projects have fully engaged product owners working daily as an integral part of the team.

2. Empowered

The organisation must empower the product owner to make decisions with the knowledge that they will be held accountable. In order to maintain the required speed of development, decision-making must be made locally at the product level. If the product owner is frequently overruled by the organisation hierarchy, then their team will start to bypass them when asking questions.

3. Decisive

The development team's questions must be answered promptly and with authority. Delaying decisions will prevent the work planned from being completed, and frequently reversing previous decisions will lead to a lack of trust. There is a balance to be made, but with the knowledge of the customer and support of internal stakeholders the product owner is in the best position to make these decisions.

4. Good Domain Knowledge

The product owner must have a good understanding of the target customers needs and appropriate business knowledge to lead development in coordination with all of the stakeholders. This requires strong support networks within the organisation and the creation of good relationships with customers and third-party suppliers.

5. Great Communication

This role requires an excellent communicator, collaborator and “people person” capable of sharing a vision, aligning people, focusing efforts and motivating the team. High emotional intelligence will help to collaborate and steer the product development to a successful conclusion.


In summary, within the Scrum framework the product owner:

Creates and communicates the vision, strategy and roadmap Generates a high-level release plan Forms the product backlog containing all of the work to be performed Collaborates with the team to develop and deliver the work Works with customers to review releases and adjust development accordingly Actively supports the business with progress updates and metrics

In the remainder of this series on the role of the product owner we will examine different aspects of the position:

In Part 2, we will look at the day-to-day work during a development sprint In Part 3, we examine the common anti-patterns seen for this role In Part 4, we consider the pragmatic considerations of the position

I welcome your thoughts in the comments below. 

A View of Brexit Through an Agile Lens

June 23, 2016 was a bad day for me …

Watching the votes being announced for Brexit, my emotions were a rollercoaster.

No! Who is to blame for this? Surely we can have a second vote? This is going to be terrible

After some processing, I came to terms and thought: Fine, how do we make this work in an agile way?

As the majority of voters in the referendum decided to leave the European Union, we need to accept this result in the UK and move on with the implementation. The difficulty, whilst the political parties implode, is to decide where to start.

We can begin with Maslow and consider our nation’s hierarchy of needs, and then we’ll look at how to implement it in an agile way:

Physiological – We must start by ensuring our food, water, energy, housing and basic goods are not adversely affected. This means negotiating a common market in order to ensure goods and services can still be freely exchanged. This is an initial major hurdle due to the ties between this issue and freedom of movement. Safety – Our army and security forces must continue to work closely within Europe to maintain our nation’s security. Financial institutions need to work across borders, as must our courts, in order to maintain financial and personal security. Love/belonging – With the basics covered, we can move on with our need to feel a sense of belonging and acceptance. This is difficult when starting with our rejection of Europe, but we will need to persevere, state our case and back it up by working closely with other countries to build bridges and personal relationships. Incremental change with consistency of purpose can change how we are perceived. Esteem – We have a need to feel respected, valued and accepted by others. We need to continue reaching out to others through charity, sport, science, trade and any other means we can find to make connections. Being out of Europe gives us the opportunity to make the United Kingdom’s distinctive voice heard, but this takes effort, time and money. Self-Actualisation – How do we become the best that we can be as a nation, to attain our full potential? We need to strive to collaborate, select the best paths, communicate well and continually improve.

Sounds great, but in practice, what can be done, and how can agile guidance help us get there?

Step 1 - Create a vision: After our politicians finish navel gazing, they must work together along with experts to create a vision for our future as a successful nation. Step 2 - Draw up a roadmap: After invoking Article 50 of the Treaty of Lisbon, the UK will need to collaborate closely with the European council to create a roadmap for the next two years. This will need to be done in a calm, politically astute way to work with others and smooth over some of the recent destructive rhetoric. Step 3 – Put together a team: A strong, empowered, cross-party and highly skilled team should be formed to steer the UK through the negotiations and guide the huge amounts of work that must be performed. Step 4 – Collaborate and communicate: Work within the UK to build consensus and within Europe to build bridges. Transparency over the process and progress is critical to avoid people feeling excluded and abandoned. We need to engage all UK residents and bring them into the change process whilst they hold the government accountable. Opportunities to create trade agreements outside of Europe will be important, but first we must seek to resolve the problems we have created. Step 5 – Iterate and improve: As we have seen, nothing is forever. Seek to engage, hold regular reflection sessions both within the team and externally. Hold regular town hall meetings, briefings and anything else required to ensure vision alignment, people are listened to and the process is continually improved.

The next two years are going to be painful for the whole of Europe as the UK seeks to form a credible and independent identity whilst remaining close to our former partners.

The Agile Manifesto tells us to value individuals and interactions, sustainable development, collaboration and responding to change. Using these key values, agile provides us with a lens with which we can manage change in a positive and collaborative value-focused way.