Three Ways Agility Helps Business Intelligence

The ability to learn and adjust on an ongoing basis, a key benefit of agility, is extremely helpful for business intelligence and data warehouse initiatives.

If you’ve worked in business intelligence for any length of time, then you’ve experienced the ongoing discovery that happens with business intelligence efforts. Once you get a feel for the kind of information that business intelligence can provide, you come up with all kinds of things you can use the data for that you didn’t think of initially.

How can you experience the benefits of agility with business intelligence? In this post, I’d like to take a look at three ways you can use agility to improve the effectiveness of your business intelligence efforts.

Express Your Outcomes as Questions and Decisions

Every initiative is more effective if you can describe success in terms of the outcomes you want to reach instead of the outputs you want to deliver.

With business intelligence initiatives, those outcomes are best described as questions you want to answer or decisions you want to make. When you describe outcomes in that way, you will experience the following benefits:

You can deliver something quickly that provides your customers with value as you build out the rest of your data warehouse. When you go through a full pass of all the steps to deliver a data warehouse on a small subset of the overall data warehouse, you can learn some things that can be applied to the rest of the data warehouse. You can focus on only the data you need and avoid using data that will not be used, saving analysis, development and testing time. By organizing your work around specific outcomes, you can get a more useful indication of progress.

I’ve found that Socratic questioning is an effective way to uncover those questions and decisions. I recently wrote a post on BA Times that describes how you can elicit the questions users want to answer and the decisions they want to make.

You can capture these questions or decisions in the form of a user story (As a <who>, I want <what> so that <why>), job story (When <situation>, I want to <motivation> so that <outcome>) or other template of your choice. The format really doesn’t matter.

What does matter is that you identify distinct questions and decisions (outcomes) that are satisfied by big chunks of functionality you want to deliver (output). You can call the big chunks features, epics or whatever term you prefer--again, it doesn’t matter. I’ll use the term “big chunk” for the rest of this article.

By organizing your work around each big chunk, you can deliver the functionality that delivers the data formatted in a way necessary to answer a question or make a decision. If you focus on one big chunk at a time, deliver it to your customers and then get feedback on that big chunk, you can use that feedback to revise your approach to subsequent big chunks. You may decide to deliver different big chunks, the same big chunks in a different order or in another way altogether.

Whatever changes you make, you’ll find that you more effectively deliver the functionality necessary to answer questions and make decisions, and you can avoid unnecessary work.

Incrementally Deliver Value

A common assumption about business intelligence is that you must get all the data warehouse functionality to its final before it can provide any value. However, you may find that you can provide value in many ways before getting to the final desired form of data access.

Even though your user ultimately wants to get to a daily report with all the data they need, you may find you can manually extract specific data from the source systems and place it in a single table that your users can manually query to get the answers to their question.

Once you verify that you have the correct data, you can automate the process, organize the data in a more user-friendly manner and perform necessary transformations to the data as you extract it from the original source systems and provide it to your users.

In his book “Agile Data Warehousing,” Ralph Hughes provides a way to slice up the big chunks of business intelligence work into smaller improvements to the process as described above. There are a variety of characteristics of both the user-facing data view and the back-end data storage that you can gradually improve to achieve a level of functionality that provides the most value for your users.

Here are a few of Hughes’ suggestions: 

Data View (Front End) Decomposition

Refresh Frequency

How frequently is the user’s data view updated?

●     Daily

●     Weekly

●     Monthly

●     Quarterly

●     Yearly

User Friendliness

How can the user access the data?

●     Single Table Access

●     Mobilized access (linked tables)

●     Defined navigation

●     Picklist supported

●     Dashboards

Automation Level

What triggers a refresh of the data view?

●     On demand at workstation

●     On demand posted to server

●     Scheduled refresh on server

Transformation Type

What transformations (if any) happen between data storage and the data view?

●     Direct data transfers

●     Applied business rules

●     Aggregation


Data Storage (Back End) Decomposition

Refresh Frequency

How frequently is data from the original sources updated?

●     Daily

●     Weekly

●     Monthly

●     Quarterly

●     Yearly

Refresh Type

When a refresh from the original sources occurs, how is the data updated?

●     Direct Link

●     Snapshots

●     Error recycling

●     Schedule driven

●     Manually invoked

●     Incremental loads

Transformation Type

What transformations (if any) happen between the original sources and the data storage?

●     Direct data transfers

●     Applied business rules

●     Aggregation

Target Layer

What layers in the architecture are updated when a data refresh occurs?

●     Staging

●     Integration

●     Linking history tables

●     Linking tables

●     Fundamental tables

●     Reference tables

●     Presentation

●     Fact tables

●     Historical dimension tables

●     Non-historical dimension tables

●     End user access views

The idea is to gradually improve on a specific characteristic one small chunk at a time. For example, you may start off with users, manually querying directly against the data storage using SQL. You can then improve this experience with small chunks that introduce each of the following changes:

Offer access through a controlled querying environment where links between tables are pre-built Provide data in a report that the user can refresh manually Automatically deliver the report to the user on a regular schedule

After each step, get feedback from the users to determine if you have met their needs or if additional improvements are necessary.

Adopt Different Technical Practices

To effectively deliver data warehouse functionality in an incremental fashion, you’re going to need to adopt some different technical practices than what you may be accustomed to from your past experience working on business intelligence initiatives.

First, it’s important to remember that you will change your database structures throughout the process of building the data warehouse, and that’s okay. To make that process as smooth as possible, it’s best to create Data Definition Language (DDL) scripts to make changes to the data structures as well as Data Manipulation Language (DML) scripts to update the data in those structures. Then, include those scripts in the version control along with the processes you use to run your ETL processes.

In this way, you have clear means of moving from one version of your data warehouse to another and you have a straightforward way to automate that process.

Another helpful practice is to create tests to include with the DDL and DML scripts to confirm that the changes to the database structures and the initial loads of data are performed properly.

You may also find it helpful to extend a test-driven approach to all the code you write for the data warehouse, including not only the scripts to make changes to the database structures, but also the processes you use to update the data warehouse on an ongoing basis.

Ken W. Collier’s book “Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing” contains a great deal of information on how to apply techniques such as Test-Driven Development to a data warehousing environment.

Agile Business Intelligence Helps You Learn

The main advantage of using an agile approach with your data warehouse is the ability to constantly refine your understanding of what your customers need and to make sure you spend your time on valuable work, delivering only the data that your customers need at the frequency they need it, organized in a way that is most useful for them.

Do you have experience approaching business intelligence in an agile fashion? Leave your experiences or questions in the comments section below.

Sprint Zero for Product Owners

This is the second in a three-part series of blog posts addressing the biggest challenges faced by business analysts (and product owners) on agile teams.

The concept of “Sprint Zero” or “Iteration Zero” has been around for decades. It serves as a container for all those activities that need to be done before the first sprint or iteration is begun. Typically, these activities will include team on-boarding, infrastructure setup, location logistics and the like. Rarely does this “sprint” actually deliver a releasable product.

It’s a very contentious subject. Many authors have argued that Sprint Zero is detrimental to the agile process. In some cases, it may lead to the watering down of team commitment to each sprint’s releasability (see Bowes, Cohn and Leong). In other cases, it might lend itself to the development of a team hierarchy that is inconsistent with agile’s traditionally flat organization structure (Prakash). It is often inconsistent with Lean JIT principles (Leong again). The arguments go on, and I won’t rehash them here.

Whether or not we like the concept of Sprint Zero, however, we can all agree that there is usually work that must be done to prepare for the first iteration that doesn’t quite belong in that first iteration. Whether we call it “Sprint Zero” or the “Project before the Project” or even just “pre-work,” it’s important to get it done.

Unfortunately, almost all of the writing on this pre-work phase is oriented towards development team members. “What about me, the product owner,” you may ask? Don’t worry; this blog post is for you.

While the team is conducting all its pre-project tasks, the product owner needs to focus on doing five key things. Here they are:

#1: Develop the Product Vision

If you don’t have a solid vision of the product, how it will improve the firm’s standing and what value it will provide to the marketplace, then it’s not a good idea to start the first sprint. Whether it is done intentionally or not, your first sprint will indeed have some implicit vision, and it’s best for it to be one that is purposely developed.

Just remember not to invest too much in this initial vision, either with time or emotional commitment. Early visions are almost always wrong to some extent, and it will be your job as the product owner to ensure that the team is building the right product for the market. This will often demand that you set aside your initial assumptions.

#2: Socialize the Product Vision

Once you have the initial vision in place, it is critical that you socialize it among your key stakeholders. In a simple environment, this might only include various customer representatives and technology implementation stakeholders. If you are in a scaled environment, you will also have a product management team and many other functional teams that you’ll need to work with in lockstep.

Why is this work so critical? Because soon the project itself will begin, and by then you won’t have time to defend the product’s vision to cantankerous stakeholders with their own opinions. If you end up in this predicament, it will become supremely obvious to other stakeholders, your management and, most importantly, the team. You must maintain their respect for your product ownership, and socializing the vision will be one of the easiest ways to accomplish this.

#3: Truly Understand Your Stakeholders’ Problems

At face value, this task sounds enormous. Can we ever truly understand their problems to the extent that we’d like? No, of course not. But, it’s still imperative that we understand them well enough at the beginning to start delivering a product that will meet their needs. After all, you’ll soon be making decisions on their behalf.

What does this bare minimum of understanding consist of? I’d suggest the following:

An understanding of who your customers (or end users) are, the various categories they fall under and how you expect them to interact with your product An understanding of their motivations for buying (or adopting) your product, how and why their needs have been unfulfilled so far and how similar products fall short A good idea of what they value and how they see themselves

If you can have an intelligent conversation about the above, you’re in good enough shape to start your first sprint. Remember to continue to learn about your stakeholders as time goes on.

#4: Generate Some Ideas for the Sprint One Product

Determining the scope of any sprint is the job of the team (at least in Scrum), and there is good reason for this: If we product owners determined what was in scope, every sprint would be a year-long project. Instead, we let the team do this, and that’s good because they’re the ones who know what they’re doing. But every team must start somewhere, typically with the product backlog, and you need to have some list of items on the backlog so the team can figure out what can be delivered.

What you need prior to your first planning meeting is a collection of small ideas (please) that will provide some minimum level of value to the business on their own…

#5: Write Just Enough User Stories to Support a Probable First Release

… And, once you have that list of small ideas, pick a few and turn them into user stories. You’ll have plenty of time to elaborate on these stories later, but if you have a few picked out and written up, you’ll be in a great position to have a solid planning meeting when the sprint begins.

A few tips here:

Don’t go crazy with stories. It’s a good idea to meet with the team before you spend any significant amount of time on them. Keep them short, sweet and not overly detailed. You’ll flesh everything out with the team later. Don’t worry about bigger topics (such as story maps or road maps) at this stage. You won’t have enough content to fill them, and that lack of content will induce you to make more content, which at this point would be a bad thing. Wrap-Up

Performing the above activities will help you to have a solid first iteration of your new agile project. As always, maintain an agile mindset as you do them.

What about you? How have you been preparing for new agile projects? Let us know in the comments below.

The Beekeeper’s Guide to Agility

You know what is amazing about bees? They form an amazing, efficient system, with tight communication, working towards a common goal. Sound familiar?

Now, a bee’s team is roughly 50,000 members strong – each having a specific role that is shared by the super-system. They are truly T-shaped workers, able to do whatever is needed for the survival of the hive.

But bees have a bad rap.

What does this have to do with agility? I’m asking you to challenge your perceptions and seek out a different point of view, both about bees and about problem solving. We cannot blindly follow a process or dogma and expect it to work in any situation.

That dreaded bee swarm that lands in your backyard and terrorizes your family isn’t just a nuisance, it’s a sign that the hive is doing fantastically! That super-organism is doing so well, in fact, that they have a need to reproduce and form a couple of colonies apart from the original one. This means more pollination of your food, and more honey.

The bees have nothing to protect (no home, nursery or honey stores), so they are fairly docile. They’ve gorged themselves on honey in preparation for their search for a new home to such an extent that they physically can’t bend their butts over to sting you. Ironically, this is one of the safest times to be around thousands of stinging insects.

Human brains are flawed, and constantly give us false information. This causes us to live in an echo chamber, delight in our confirmation bias and blissfully ignore alternate points of view.

I can guarantee that if you identify a problem in your team, business unit or organization, it is likely that viable solutions are not where you immediately expect them to be. If you take the time to uncover your blind spots, you will strengthen your problem-solving skills and challenge others to do the same.

Check out the principles of Integral Agile Theory below for more information. You’ll uncover your comfort zone (how you tend to approach problem-solving) as well as your blind spot (what you are ignoring in that problem-solving).

“We Should Do What They Do!”

One of the most common failures in agile transformations is that they ignore internal culture and how it will change the solution. You cannot do what Spotify or Salesforce* does and expect it to work for you, your team or your company. Process dogma does not transfer verbatim to other instances.

*Insert the cool transformation story du jour.

Why is this challenging at work?

“Touchy-feely” (or “woo-woo”) discussions are uncomfortable in a business setting. This is the blind spot in most transformation efforts. Process changes and improvements (or “do-do”) is the echo chamber of a lot of misinformed solutions, such as requesting more training or implementing another organization’s process framework.

Simply put, if you ignore the human system’s agility (culture) and focus solely on the business agility (hierarchy and processes), you risk dooming your long-term system journey.

Impediments Are Not Generic

If we jump to a conclusion when we are told of an impediment because “the process” tells us to do so, we risk ignoring the uniqueness of our own environment.

I worked in one organization where managers were routinely given the Scrum Master role. This horrified new employees who were familiar with the “standard” role definitions of Scrum.

On deeper reflection, the culture of that company had defined the role of engineering manager as being a true servant leader, with advanced empathy and a goal to coach their teams toward self-management and continuous improvement. These are obviously some of the key responsibilities of a Scrum Master. 

Thus, what initially appears as an impediment is then clearly reframed.  When managers don’t hold these expected cultural traits, that is the true impediment, not the blanket belief that managers should never be Scrum Masters. Such a belief ignores company culture and shared values.

Why Do I Care About This So Much?

I care about this so much because it’s giving agile a bad name. Lazy implementations of the wrong process tarnishes the entire craft with an ugly hue.

I challenge you to embrace your blind spots and look at things differently.

Come say hi at Agile2017 where I’ll be talking about this in more detail. Until then, feel free to share your thoughts about Integral Agile Theory in the comments section below.


Introducing Changes to Your Team

Joining a new team always brings new challenges to both the team and the Scrum Master. The Scrum Master will be always seeking to introduce new ideas and improve the performance and collaboration within the team. Often, he or she will experience some resistance from the team, which is completely normal given that the team is used to working in a set way.

The first thing the Scrum Master needs to keep in mind is that any change, regardless of how small it is, might take the team back to the forming phase if not handled carefully. 

Beyond the apparent behavior of team members, there is an emotional turmoil as well which was described by Elisabeth Kübler-Ross in her work for helping terminally ill patients. She called this turmoil the Five Stages of Grief: Denial, anger, bargaining, depression and acceptance. This model could be also be used to help you, as a change agent, to understand where your team members stand and how to react at each stage.

Jason Little used this model in his book “Lean Change Management,” and I will present it on a smaller team scale rather than an organizational scale.

For each of these emotional stages, you’ll need to behave differently to help the team accept and adopt the new approach you introduced.

Create Alignment: You owe the team an explanation. Why are we introducing this change? What are the benefits? How will this change help the team perform better? These are the questions you’ll need to answer to get the team’s buy-in and motivation for the change. Maximize Communication: Try to eliminate doubts and be proactive. Ask the team members over a coffee or lunch about their thoughts on the new change. Try to talk to them as much as possible to clarify what might be puzzling them about the change. Spark Motivation: People are different: what motivates one person might be a demotivator for another. Try to understand each person in the team and strive to find the proper motivation each person needs in order to adopt the change. Maybe you can ask one of them to join an agile meetup or a talk addressing the topic to see the impact and benefit from peers in the industry. Develop Capability: Give the team time to experiment with the new approach. You should pick only a few stories for two sprints to give them space for experimentation, allow them to acquire the needed skills or simply practice the new approach. Share Knowledge: Encourage the team to share their story with other teams in the organization and at events they attend. This can give them a sense of accomplishment as well as satisfaction.

Introducing change is not an easy journey, but the reward is worth the trouble. Don’t be afraid to introduce new ideas and adopt new practices. Your major goal as a Scrum Master is to keep the team continually improving, and this won’t happen by always doing the same things in the same way.

What is the latest change you introduced to your team? How successful was it? I would like to hear about your experience in the comments section below.

4 Ways Attention to Detail Might Be Hurting Your Team

Attention to detail is a pattern of behavior that many teams hold in high esteem. Job descriptions, résumés and LinkedIn endorsements often emphasize attention to detail as a foundational component for any capable team member.

It’s easy to understand why teams value attention to detail ‒ almost everyone experiences the consequences of missed details at some point, and attention to detail can prevent these damaging experiences from happening.

Missed details can lead to inaccurate cost forecasting, underestimating work, a dysfunctional product and a seemingly endless list of other problems.

However, attention to detail can sometimes have a negative effect on your team if performed without proper guidance, and yet I’ve never heard anyone list “inattention to detail” on their résumés or as a skill on a job website.

I would posit that the world needs a few less people striving to be difference makers, and a few more up-and-coming indifference makers.

So, when is it better to be inattentive to detail? As the proverb goes, the devil is in the details. Here are five common examples of when attention to detail can have a negative effect on your team.

When It Adds Work That Isn’t Needed

Attention to detail is only as important as the details themselves. If you’re focusing your efforts on inconsequential details, you may be adding work to your team that isn’t needed.

If your team is a finite resource, this can be an unwelcome burden to contend with.

For example, if you’re in charge of a marketing team, you may be tempted to spend a lot of time carefully tailoring every mass email, Facebook post and tweet. However, if you don’t have any users following you on Twitter and it’s going to be an uphill battle to acquire additional followers, sacrificing some quality on Twitter by not proofreading every tweet might help reduce a lot of work for your team without resulting in much negative impact at all.

Take a look at your team and consider if there is any work being regularly performed with too much attention to detail, where less effort can save a lot of time without losing a lot of value.

When It Distracts From More Important Work

While paying attention to some details is completely unnecessary, other details may be valuable, albeit less valuable than others.

For example, it’s tempting to want to fix all existing bugs in a piece of software. After all, chances are someone is being affected or could be affected by bugs in your software and have a negative experience as a result.

However, not all bugs are created equal -- some bugs may be affecting a large section of customers while others may affect only small segments. For example, your software may have bugs that appear only in IE7, but if only 0.5 percent of your users use this browser, spending time fixing these bugs is time you could have spent fixing higher priority bugs, adding features to deliver more value to larger sets of customers or adding optimizations that reduce costs and deliver a better user experience for all customers.

When It Delays the Frequency of Shipping Increments

Sometimes, paying too much attention to detail tempts people to delay the shipping of increments, which is contrary to the goals of agile.

While it’s true that some details like feature requirements should hold up shipping an increment, scope creep that involves unnecessary details should not prevent your team from delivering. Many times, these minor details can be bumped to the next iteration, especially if the choice to not work on them doesn’t have a significant effect on your users.

In general, it’s better to get the increment out the door and collect feedback from users to readjust priorities and understand what work should be completed next. You may find that after your release the iteration, the users have more urgent needs that they communicate back to your team and would rather you not spend your time working out those smaller details.

When It Makes It Harder to Identify Problems

Along those lines, when details hold up shipping increments it can make it harder to identify problems.

For example, if the original task requirements were not fully explained or were missing some details during scoping, the sooner you ship the increment and collect feedback, the sooner you’ll uncover the gaps or items that were built based on incorrect input.

Getting bogged down in details that don’t have much of an impact can often obfuscate problems in your work by delaying iterations, so be sure to critically ask yourself if the detail is worth focusing on before you allow your current iteration to drag on down a potentially problematic path.

Putting It All Together

Attention to detail is very important in many cases, but not all cases. Similarly, inattention to detail shouldn’t be applied in a blanket fashion across all cases.

However, as illustrated above, you may want to analyze your current processes and see if there are gains to be had by eliminating attention to detail when it adds work that isn’t needed, distracts from more important work, delays shipping increments unnecessarily or prevents you from catching and addressing problems early on in the product development lifecycle.

Ready to be an indifference maker? Take a look at your current processes and let me know how your team could benefit from being less attentive to details in the comments section below.

Business Model Canvas: Step by Step

The Business Model Canvas (BMC) is a strategic tool for the product owner that helps to build a faster and more visual representation of new products and services. It consists of a panel divided into nine blocks, such as those displayed in the picture below, which represent the basic elements (building blocks) that compound a business model.

The main goal of this panel is to generate value proposition that meets and potentiates the desired objectives before actually implementing the product or service. Below, I depict the dynamics of how to build a BMC, created by Alexander Osterwalder.

Building the Canvas

In order to apply the Canvas as shown in the picture above, you can either use a printed version (using this pdf) in A0 size to facilitate the collaboration, draw on a whiteboard (simple layout to replicate) or create it online (Lucidchart has a helpful template).

Lucidchart is a good option for distributed teams because it can be built online in a collaborative way. There is also a web-app available created by the makers of BMC.

The Canvas already filled in below can be split into two dimensions: the dimension located on the right contains more subjective and “emotional” elements, while the dimension on the left contains structural and logical elements. It is recommended that you fill out the Canvas from right to left. This way, the wishes and aspirations of the stakeholders can be addressed before you start defining in a more factual method.

Dimensions and Basic Elements

The illustration below shows how the nine elements of the Canvas are integrated with each other. As mentioned before, we will begin to explore the right dimension of the Canvas first.

We start by putting the block “Customer Segments” in place, which maps who we are targeting to provide value and who are the potential customers to our desired objectives. For instance: customers over the age of 50, women, customers from California and so on.

In the block “Value Proposition,” ideas are generated to fulfill the needs of the potential customers, while always keeping in mind the business objectives that are driving this product or service. Examples of value propositions include cost reduction, agility, convenience, customization and decision support. The Customer Segments and Value Propositions blocks are the main elements that will lead the remaining components of the Canvas.    

Once we determine the potential customers and value propositions, it’s necessary to think about how we can link these two fundamental components. This is the purpose of the “Channels” or “Distribution Channels” block, which includes items such as the delivery, blog, newsletter, customer service and webinar. These are the channels that distribute and deliver the value propositions to the customers.

Next, we should understand  the “Customer Relationships” block. In other words, we should figure out how to strengthen customer involvement with the business. To give a few examples: business development partnership, customer retention, customer support, online chat and feedback.

The last right block is the “Revenue Stream,” which translates to the path to generate revenue based on the recommended value proposition. Examples include a monthly subscription, direct sale, paid ads and license.

The image below depicts the fundamental elements of the right dimension from the Canvas.

In the left dimension of the Canvas, we can find more direct and objective definitions that sustain the components mapped in the right dimension.

The “Key Resources” refer to the resources directly associated with the business model operation, such as teams, machines, investments and technology platforms.

The “Key Activities” are all activities needed to meet the value proposition, build channels and keep relationships. We might consider managing the social networks (a powerful mechanism to strengthen the customer relationship) or building a web store.

“Key Partners” are people who contribute to both key activities and key resources. Some partners (outsourcing companies, for example) can provide machines to drive towards any key resource. Other types of partnerships can supply contractors or execute some of the key activities, such as monitoring the social networks.

Representing the required costs to maintain and build the proposed solution is performed by the  “Costs Structure” block, which indicates, for example, the amount of money necessary to pay the machines’ maintenance, contractors, OPEX, infrastructure and resources.

The picture below illustrates the basic elements of the left dimension from the Canvas.


The Business Model Canvas is useful for driving the conception of new products and services through its nine basic elements from both rational and emotional perspectives. It also allows the teams to brainstorm insights, ideas and opinions around the product, enabling a common understanding among the stakeholders as well as generating strong performance indicators towards a strategic innovation.

It’s another helpful tool for the product owner to conceive a new product, service, website, e-commerce or game.

Have you used the BMC before? Do you plan on using it in the future? Let me know in the comments section below.


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.

What Kids Taught Me About Being Agile

While agile initiatives now spread beyond IT within the corporate world, one may wonder why we tend to brand these changes as “transformations” or “transitions.” After all, we are merely going back to a state of being which we have in fact experienced for years, not as adults but as children. 

For several years, I ran my own small education business. I taught children from the ages of 6 to 10 about science and technology, specifically space and robotics, my favorite topics, with the help of LEGO® bricks, my favorite toy.

As I was busy with this endeavor alongside my daily job as a software development manager, I got plenty of opportunities to compare first-hand the difference between kids being agile and adults doing agile. This was a topic that surfaced in many agile coaches’ narratives, but it was only then that I truly understood it.

Make a Plan, Then Change It

One of the most striking things I noticed during my students’ activities is that when children are taking on a task, whether self-initiated or not, they always seem to have a plan. The plan is clear only to them and continually changes, but it eventually leads somewhere. Even if that means starting again, they reach the finish line quickly and iterate successfully.

It’s no wonder the Marshmallow Challenge, your typical team building exercise in a corporate offsite event, is often said to be better accomplished by children than MBA grads.

Ask Why (And Truly Mean It)

When children ask “why?” they are truly curious and will likely dig further and further until there are no more answers to be had. They have neither a fear of asking nor a sense of shame, a quality which increases their learning and creative capabilities.

By contrast, adults tend to think twice before asking questions, and we feed ourselves on guesses instead.  We tend to be paralyzed by our culture, our pride or fear of judgment from our peers. Either way, we miss opportunities to enrich ourselves, while children have already moved on to their next learning experience.

Flag It as It Is

Learning how to give feedback to each other can be a daunting task for agile team members, and we often associate criticism with its destructive meaning. In contrast, I would safely bet we have all experienced a very direct, sometimes crushing and often tactless (but always honest and “fairly” constructive) feedback from a child. We can all learn something from them.

Collaborate Rather Than Cooperate 

I often tried to divide work and responsibilities among children in my workshops so that they could cooperate in building a larger LEGO® assembly. In most cases, my efforts initially failed, or at least felt like a failure. In fact, these little builders were often inclined to drop their own task to go and help a playmate realize his or hers.

By trying and iterating on the task together while sharing a goal, true collaboration was born and the children’s learning experience was greatly enhanced. The opposite tends to be true in a professional environment, where a culture of individual goals and target-setting has traditionally reigned supreme.

While agile coaches can certainly help guide and scale your organization in the right direction, asking yourself what has happened with your inner child (minus the therapy…), or simply observing your own children, should help you open your mind to the changes to come.

Have you observed any other ways in which children excel at agile principles? Let me know in the comments section below.