Agile Lawn Mowing Part 1: A Story of Acceptance

I love mowing the lawn. Compared to the day job, yard work shows an instant transformation as a result of your efforts. My dad is now 86 and struggling with his health, so I wanted to help him out. His mower is a big, heavy, petrol-driven beast, so whilst it does a good job, it’s heavy to manoeuvre, and I thought he’d be glad of the offer.

So I mowed the lawn, emptied the grass box, trimmed the edges and felt pleased with my efforts. But dad wasn’t. We hadn’t discussed “acceptance criteria” before I started. I’d assumed my own acceptance criteria:

Lawn must have nice stripes! Grass must be no shorter than 2 centimeters, or else the grass will die in the sunshine.

Dad had an extra criterion–must not drop cuttings!

As I’d let the box get too full, there were places with a fine trail of cuttings which had leaked out! I could rake the whole lawn or just mow it all again. If I raked it, there was no guarantee he’d be happy, and there was a risk that the stripes would lose their edge.

I chose to mow the whole lawn again, effectively doubling the effort and, in agile terms, halving my velocity.

Conscious Acceptance versus Subconscious Acceptance

Maybe you are already shaking your head and saying, “Ah yes, you should have agreed to the acceptance criteria before you started.”

Well, yes, and that works well for criteria which are conscious. However, it can be difficult to articulate exactly what you want or what you consider acceptable until you see what is not acceptable to you. That is when the subconscious criteria emerge.

For example, on a recent project, we were designing and building a mobile phone app with a feature to capture a photo into a scrapbook. Conscious acceptance criteria covered the size of the image, choosing a picture from the library or using the camera to take a new shot. But it was only when a basic implementation was done in an early sprint that subconscious became conscious and the product owner started to talk about cropping and editing the image as well and handling landscape and portrait differently.

This is where, in my experience, an agile approach to software delivery really pays dividends compared to waterfall delivery methods. On a waterfall style project, I would hear conversations like “That wasn’t in the requirements, so that’s a change request,” followed by “it is obvious that it should be included–that is standard processing for photo capture!” 

In an agile project, sharing as soon as it’s reasonable to share means that when gaps arise, they can be discussed as future backlog items and prioritised in the context of the whole project. In our case, the mobile app was for a health data service and the photo capture was a secondary feature compared to many of the other items on the backlog, and so the product owner consciously chose implementing security around handling personal health data over complex photo editing features.

Unlike mowing a lawn or taking a photo with a phone, many software projects are implementing something that has never been made before, something that neither the product owner nor the team can fully imagine as they are discussing acceptance criteria.  Which brings me back to rapport and empathy and a good relationship between the team and the product owner for delivering the common vision.

Emotional Acceptance

In terms of keeping the product owner involved, I’d sent Dad inside to sit down and have a cup of tea. If he’d been watching me, he would most likely have commented after the first time I dropped cuttings on the lawn, making his subconscious conscious. I’d have been able to adapt sooner and reduce the rework.

However, Dad might not let me mow the lawn again. His experience was that we don’t share the same standards and, although the job got done exactly to his satisfaction in the end, how he felt about the job may still influence him in the future.

For me, acceptance criteria are more than a checklist. They reflect what is important to that person in a wider context. A product owner leaves clues about what is acceptable, and it’s our job as analysts and designers to constantly pick up on them if we want to keep a good relationship and deliver a good project.

Ways of Sharing Knowledge On Agile Teams

To be agile and keep being agile there is one important aspect you should be conscious about: sharing knowledge.

One thing is that your team should be cross-functional. This of course does not mean every individual on the team should be able to perform each other’s tasks. Cross-functional teams are composed such that they have all competencies needed to accomplish the work without depending on anyone not part of the team.

However, it does not mean that none of the team members have overlapping skills either. In fact, we often refer to the T-shaped person as the ideal team member–having both a broad and in-depth skillset.

In addition, things other than just technical or tool specific skills are involved. Domain knowledge, knowledge about the architecture, coding standards, testing conventions and anything that touches how the team works every day come into play.

To be as effective as possible, I believe it is important that every team member have a base level of understanding of all these things. With a common architecture and domain understanding, every discussion about how to implement new features or how to makes changes to existing parts of the system will be a lot more effective and the outcome will be of higher quality.

Below I have listed some of my favorite practices, feel free to share yours, too!

Pair Programming

The ultimate way of sharing understanding and knowledge about the thing your team is working on is getting people together to work on it. Pair team members, let them sit together and struggle with the problems together by looking at the same code at the same time. Have your team rotate pairs every so often to widen the impact. You are not only getting instant feedback, but also cooperating on sharing knowledge about the code and the domain and architecture of the code. Pair programming is a great way to share knowledge and get a new team member up to speed as well.

The last few years, mob programming has come up as a popular alternative to pair programming. This involves getting the entire team together looking at the same code and solving the same problem at the same time. Looking at the effectiveness/efficiency diagram from “Agile Software Development” by Alistair Cockburn, the more closely people work the more effective the communication.

With respect to this, mob programming ideally should work even better than pair programming. How pair programming and mob programming match up regarding cost-effectiveness is, however, uncertain. Nevertheless, working closely enhances knowledge sharing. You should at least be doing pair programming, but make it possible to experiment with something like mob programming as well.

Code Reviews

Another great way to share understanding about what is being implemented is getting changesets reviewed by your peers. Discussing changesets through pull requests is a great opportunity to see which new features are being added to the system. It’s also perfect for looking at coding standards or whether or not the changes adhere to your architecture principles.

If you do pair programming you should let another pair review your changes so that you get a fresh pair of eyes on the code. Doing both pair and mob programming one could argue that code reviews are done continuously, but having a separate discussion when merging changes fosters a slightly different focus. Code reviews could of course be done on other blocks of code or parts of the system, but I find it easier to utilize something like pull requests to trigger code reviews on a continual basis.

Again, this follows the diagram given by Cockburn above. The closer you work, the richer and more effective the communication will get.

Lunch and Learns

As part of your normal pulse you should have regular demos and reviews of the things your team is implementing. While these demos and reviews are a great arena for sharing knowledge they should be part of your normal practice already. Lunch and learns, however, are a great arena for informal knowledge sharing. They are perfect for your team members to share new ideas, something specific about a recent implementation or going through concerns team members have about some areas of the system your team is implementing.

How Are You Sharing Knowledge On Your Team?

The practices mentioned above are far from an exhaustive list of things you can do to enable knowledge sharing on your team. They are, however, my favorite ones–and practices that I have seen work first-hand. By spreading knowledge in your teams, you will enable a base level of understanding of the code, domain, architecture, etc. Without this common understanding, it will be a lot more difficult to get the team to move in the same direction once the direction needs to be changed.

Do you have other good ways of sharing knowledge? Please let us know by using the comments below.

How to Build and Motivate Your Scrum Team: Part 2

In part one of this article, we took into consideration the group’s past project experience and focused on laying a foundation for shaping this group into a Scrum team. We addressed how we made the initial logical and emotional connection with the group and took the first steps in empowering them. 

We now continue the journey and discuss how to build on this foundation as we guide a team through the adoption of the Scrum practices.

My Sprint Cycle

I always use the two-week sprint cycle for my teams unless circumstances dictate otherwise. However, I structure the sprint cycle with one preparation day (also known as a lag day) and nine working days. The preparation day is the first day of sprint, where I schedule the sprint review, followed by the retrospective in the morning and sprint planning in the afternoon. 

The reason for this is that it better ensures the retrospective is done regularly. The retrospective is your primary tool for building this group into a team and helping the team to continuously improve. 

But, I have often seen situations where the retrospective fell into disuse because the team felt they were behind in their work and didn’t have time to spare. I’ve also discovered that since the team is doing something entirely different for the day, it provides them a mental break from the rigors of the nine working days.

The Journey Line

Since the first sprint does not require conducting the sprint review or retrospective, I generally utilize this time to conduct a journey line exercise as described in Lyssa Adkins' book: “Coaching Agile Teams.”   

I have each person draw a journey line of their career on a large sticky pad sheet. I ask them to start at whatever point they want to and take it to the present day. If they ask for suggestions, I generally tell them to start with high school, college or a point in their life when first they developed an interest in IT. However, before I ask them to do their own journey line, I first share my own journey.

The intention of this exercise is to learn about the skills, experience and knowledge they garnered along the way and share what they bring to the team. They are given about 20 minutes to complete their journey lines and then place it up on the wall. Then each person will talk about their journey with the group.

While each person is presenting, I have the rest of the team take notes on the skills, experience or knowledge most relevant to the current team's work. At end of each presentation, each person in the audience will then read aloud their notes and stick them up on the presenter’s journey line.

At the end of this session, I ask them to come up with a team name and avatar that the whole team can agree upon, and we finalize their decision during our first retrospective. I feel that a team identity is critical to the team-building process. Once a name is chosen, from then on, I always address them by their team name.

The purpose of this exercise is the next step in their transition from a group of people who merely work together to a real team that knows the value each team member brings. It also gives them an opportunity to think outside their technical box and talk about why they like what they do, how they got there and perhaps where they see themselves going. Essentially, it’s to further build the emotional connections within the team and with their coach or Scrum Master.

The exercise also provides some insights as to what motivates each team member and what may motivate the team. It is important to remember that motivation is done on a team level and on an individual level. I use the journey line information for each member as a guide for motivation and to aid them in the adoption of agile practices on an individual basis.

Sprint Planning

Sprint planning is where you show the team you’re serious about breaking away from the detrimental waterfall work patterns and empowering them to take ownership of the work. Using my sprint cycle as a reference, I limit team member capacity to 54 hours for project work per sprint. The limit is based on the concept of the ideal day being six hours.

The remaining time is used for backlog grooming sessions and a buffer to account for the fact that an estimate is not a certainty. I also allot four hours for sprint planning to allow them sufficient time to carefully plan. I want them to understand that sprint planning is all about planning for a sustainable pace and that the team as a whole is responsible for the success of the sprint. 

There is nothing more motivating for a team than completing all their stories in the sprint as a team and being able to do it consistently. The fact that they plan their work and then succeed reinforces not only teamwork, but also a sense of pride that can only be found in having ownership of the work.


The retrospective is not only about continuing improvement, it is also an opportunity to start empowering the team. In the confines of the safe and blame–free environment of the retrospective, I use the first two sprint retrospectives to give them the opportunity to tell me what went well and what didn’t go well.

I create three columns on the wall titled “Stop,” “Start” and “Keep.” Using sticky notes, I have everybody write one thought per sticky note and have them place each one in the appropriate column. Upon completion, the team then eliminates any duplicate notes. 

Moving forward I then open the discussion with the “Keep” list items to confirm with the team that these are practices we should keep doing. Next, we review the “Start” list and the “Stop” list items together to see if there is any correlation between the items in both lists. In other words, there may be a practice in the “Start” list that automatically eliminates a corresponding practice in the “Stop” list if we choose to implement that practice.

The important items will generally show up in both columns, confirming that they represent priority issues for the team. I then ask the team to select two items for action and come up with a quick plan to resolve them during the next sprint and report on progress in the next retrospective.

The purpose of this exercise is to show the team that when they have an issue, it is not only heard, but they can also take part in how it’s resolved. They are empowered to make their work environment better. The information gathered from these two retrospectives provides the basis for many improvements that can be taken on during future sprints, and frees up time in future retrospectives for exploration into other areas.

Another exercise, which I do during every retrospective, is the “note of appreciation.” I ask each team member to take one or two sticky notes and write down how another team member helped them out during the sprint. After everybody is finished, we go around the table and each team member reads their note aloud and hands it to that team member.

The purpose of the note of appreciation exercise is to show that while outside of the team, they will always be recognized by their team name for their successes, inside the team, we will always take time to recognize our teammates.


We continued our team building with a journey line exercise, using it to introduce the team members to each other. They learned about each other’s history and then acknowledged each person’s skills and the value that each brings to the team.

In doing so, we increased the individual comfort level that comes from being part of a team. We also talked about the importance of having a team identity to foster a sense of belonging.

We then moved to sprint planning where they were told the “what” and “why” that was needed and gave them the opportunity to determine “how” it was to be accomplished. We set reasonable boundaries by determining the team’s real capacity, thereby setting the stage for them to plan for success rather than putting them in a situation that was doomed to failure.

In doing so, we not only empowered them, but also gave an opportunity to take ownership of the work and an opportunity take pride in their success.

In the retrospective, we showed that it’s OK to fail (what didn’t go well) because we learn more from failures than we do from our successes, and when we resolve a failure, that success is all the sweeter.

They also learned that recognition comes in two forms:

Recognition for being part of a successful team Recognition for your work by people who really know your value

In the end, team building and motivation are all about people and how we regard one another. 

I Played LEGO with My Team!


As 2016 came to its end, I wanted to do something different with my teams. I decided to try LEGO® Scrum which was proposed on  and highly rated by many practitioners.

I won’t explain how this game is played since there is a very good guide on the website, but I will try to share my experience and the lessons the team learnt.

My main goal was to coach the teams on how different teams can work on the same product, share the same backlog and plan sprints together. I divided my two teams into three smaller ones, four members each. I acted as the PO and tried to simulate several real life scenarios, like changing priorities and team members getting sick during the sprint.

Reasons I Chose to Build LEGO City

We chose to build a LEGO® city. The reasons?

We are building a product that is very similar to building software. You can decide on several buildings aka user stories which can have different levels of complexity and require different amount of time. It is something tangible the team can feel and they can see the direct effect of their decisions right away. It can be fun. Playing the Game

First I presented the training’s agenda and how we will organize the sprints and so on. Afterward, I presented the requirements of the city and we wrote the user stories together.

We did the estimation using a fast estimation technique, “swimlane sizing.” We created several groups with different story points, then each team nominated one member to place different user stories in the group where it would fit more. Then a sanity check was done where all the teams reviewed the estimates to make sure everyone had the same understanding.

As soon as we started with the first sprint, many issues facing newly formed teams were obvious: there were alpha males, shy persons, people who didn’t want to make decisions, etc.

As a result, two teams failed to deliver their committed scope. One team decided to work on the design of the city and drew it on paper for others to place the finished buildings, i.e., the integration environment was missing. The other team spent too much time building a “perfect” building and didn’t manage to deliver the second one.

On the second sprint, a team member of the “successful team” got sick and they didn’t manage to deliver, while the other two teams delivered all they’d committed to.

Just before the third sprint, there was a change of requirements and new features were requested. The teams estimated them and each team worked on one of the new features while some of the previous user stories in the backlog were left behind.

One of the teams working on one of the new user stories finished a little bit earlier and tried to “add” more features which were not required. This led to making the finished building fall apart. They managed to fix it by the end of the sprint, but it was a good lesson.

My Remarks

At the end we had a debriefing or a retrospective to get feedback. Here is my overall feedback on the game:

The game is fun, of course, but also simulates what happens in real life. The game is also stressful, we had very short sprints (seven minutes) as well as the meetings. Not everyone loves games in the office. If teams plan together, they can work on the same product, but if the teams are not co-located, it will be more challenging. What the Teams Learnt

Since it was similar to real life, there were many lessons the team learnt during this practice. Also, the teams appreciated trying something new and fun. Here is a highlight of some of their comments:

Scrum coaching is not always boring and we can have fun at work. Several teams can work on the same product and share the same backlog. While designing the city, the team was trying to reach the perfect design which cost them a lot of time. Gold plating is harmful. Don’t get tempted to add features that were not initially required unless they are needed. While committing to delivery, leave some room for emergencies, which means taking risks into consideration.

In general, I liked the session and I would like to do it with more teams involved in the future.

Have thoughts about this exercise? I would like to read your thoughts on the idea and practice itself in the comments below.

10 Common Reasons to De-Prioritize Requests & How to Explain Them


Every agile team is faced with decisions about which requests or user stories to prioritize, and the choice can often be difficult‒especially when we’re expected to adapt to rapidly changing requirements.

When working with stakeholders or external team members, the process can be even more stressful as requests build up; stakeholders with competing interests may express disapproval if their requests are not prioritized over others or not completed in the timeframe they desire.

In these situations, it’s essential for an agile team to be able to de-prioritize or defer work to a later date, because time and resources are finite while requests can be infinite.

Many stakeholders will regularly check in on the progress of their requests and become frustrated if progress is not made as quickly as they prefer, however, in many cases, there are rational reasons for allowing new requests and work to supersede existing requests.

At some point‒or perhaps even frequently‒your team will need to explain why a request was deferred or de-prioritized, which can become an uncomfortable situation. To help you best prepare for this discussion and explain your decision, here are 10 common reasons why your team may need to de-prioritize a request and some examples of how you can explain your decision.

1. Newer, More Valuable Requests Have Been Introduced to the Team

Possibly the most frequent reason a task has been deferred is that more valuable requests have come up, which represent more value than older requests. Because agile teams are expected to adapt to changing priorities, and we can’t complete an infinite amount of work in a finite amount of time, something needs to be pushed a little further down the priority list or roadmap.

To help explain this, start with why the new request is very valuable and important to your users and organization. While it’s also important to explain why the older request is not comparatively as valuable, you may want to avoid beginning the conversation with reasons the request was devalued relative to new requests, and focus on the new opportunity being presented.

If the stakeholders care about the users and what’s best for your organization, they should understand why it’s important to complete newer requests that provide more value to the users you’re ultimately building the product for.

2. The Request Is No Longer as Valuable to the User

Sometimes the requested work will no longer deliver as much value because conditions change. For example, if a stakeholder requested your team build features that help users sort their recyclables into aluminum, plastic and paper, but the government no longer requires sorting of recyclables into categories, the request becomes far less valuable and possibly not valuable at all.

When explaining this scenario to your team, start with explaining the original value proposition (i.e., sorting recyclables), explain what condition changed (i.e., government regulation changed), and then explain how that change reduces the original value proposition (i.e., the change in government regulation reduced the need to sort recyclables).

3. The Request Is No Longer as Valuable to as Much of Your User Base

Let’s say you’re working on a product focused on college students at a select set of universities, much like Facebook did when it started. You may get requests specific to college students, such as advanced features for managing tuition, securing financial assistance for college and educational curriculum management.

However, your product may evolve the way Facebook did, to serve the entire world’s population above a minimum age such as 13 years old. Suddenly, requested features like securing financial assistance for college are only delivering value to a smaller percentage of your users, whereas previously, they benefitted all of your users.

Again, when explaining your decision to de-prioritize the request, explain the original value proposition and what changed to reduce that value proposition, but this time end by explaining how the change decreased the percentage of users who would receive value from completing the request.

4. The Request Deviates from the Updated Roadmap and Product Goals

Pretty much every roadmap needs to be adapted and modified at some point as product goals shift, and when this happens, there will be requests which are no longer as relevant.

For example, in the social network example above, it’s usually a conscious product strategy to shift from focusing solely on a niche market like college students and target a wider audience like the entire global population. During this transition, your current user base may still be college students, but you’re attempting to capture new markets with new user bases.

In this case, your explanation should start with what the original value proposition was, then explain the shift in your roadmap, then explain how the original value proposition no longer delivers the same value to your target market‒even if they’re not your current users yet.

For example, “The student loan management feature was very valuable when we were focusing on just college students, but our organization has decided to change our target market to include the entire global population; therefore the student loan management feature will only provide value to a small set of our target, expanded user base.”

5. The Request was Satisfied Another Way

It’s not unusual for a request to be satisfied another way, which makes the original request irrelevant or unnecessary. For example, a stakeholder may have asked you to build an electric scooter, but your team first built an electric bicycle that delivered more value to more users.

Once the electric bicycle was released, users who originally asked for the scooter ended up trying it out, and found that it met most of their transportation and enjoyment needs. Since most people were satisfied with the electric bicycle, they no longer saw urgently needed value in having an electric scooter.

In this scenario, explain the value proposition of the incomplete request, explain the value of the request that was completed, and then explain how the completed request provided the same or similar value to the user and how it decreased the user need for the incomplete request.

6. Completing the Request Presents More Risk Than it Previously Did

As your product changes, introducing new features or bug fixes can become more and more risky, as features and code start depending on other areas of the product.

For example, let’s say you’re building a publishing website that starts out with just basic blog posts. As your product matures, you develop more features that rely on blog posts‒feeds, categories, comments, tags, social sharing, canonical URLs, preview snippets, advertising and more.

When you were first building the product, someone requested private members-only restrictions on some content. Back when the only feature on the site was blog posts, this seemed pretty straightforward, but now that you’ve got a bunch of features relying on this core feature, things get a little more risky in terms of what can go wrong.

For example, could secure content introduce problems with SEO meta data, preview snippets, feeds and comments? Could disruptions in feeds be seen as a bug? Could email notifications about comments that are no longer accessible to non-premium members be seen as a bug? What about actual bugs?

For this scenario, the value to the user didn’t change so much as the risk presented by implementation. First explain the relatively lower risk of the request in the past, then explain the conditions that resulted in elevating the risk of implementing the request.

7. The Request Would Now be More Difficult to Support Than Previously

Similar to the above example of elevated risk, sometimes the resources needed to support the implementation of a request become elevated over time. A lot of the time, this is due to scale and complexity of the product, as well as user behavior.

For example, unlimited frequency of Excel exports for huge tables of data would be much easier to support if your user base was small and not expected to grow, but if you added a large number of users over time, you may want to put some restrictions on how frequently users can pull data and how large the sets of data can be to avoid crashes that harm all users.

In this scenario, explain the original resources needed to support the request at the time it was submitted, then explain what changed (i.e., user base size) which escalated the difficulty to support the request in the current state of the product.

8. The Request Could Be Better Handled by Other Resources That Weren’t Available Previously

Sometimes the resources available external to your team change and can better handle requests that were originally submitted to your team.

For example, maybe you were the founding team of developers at your company, which has since expanded to include teams focusing on specific sets of features or markets.

Your team no longer should handle all requests, and it’s very likely another team or resource will be more focused and do a better job on the request. Maybe the team of developers handling ecommerce features would be better suited for building out a new shopping cart feature.

In this scenario, explain the new resources that now exist and why they’re better suited for handling the request. Sometimes it’s developers, but sometimes it could be another resource like more manual workers or skilled workers who can perform data manipulation and custom reports in Excel, for example.

9. It Turns Out the Request Was Far More Difficult Than Originally Estimated

Similar to other examples above, sometimes changes in the product or other external factors make a request more difficult or costly than originally estimated. Going back to the content publishing website example, adding more and more features can make it more difficult to implement additional global features that interact with that newly expanded set of features.

In this case, explain the difficulty of the request when it was originally made, then explain what changed and how that increased the difficulty of implementation.

10. The Request Would Be Less Frequently Used Than in the Past

Whether it’s a change in your user base size or a change in user behavior, sometimes requested features just won’t be as frequently used as originally anticipated. A common scenario that comes up frequently is around bugs and bug fixes.

For example, you may be working with a video player technology that doesn’t support a specific browser as well as another video player, and a stakeholder may request that you change video player technology to better support all browsers because users are seeing too many errors.

However, your user base may shift their behavior and start only using the more widely supported browser, making the frequency of the video player error much lower.

In this scenario, you can explain the original frequency of the problem or need, and then explain what factor changed and led to a decline in the frequency of the problem or need for users.

It’s Not Always Fun, but It’s Why We’re Good at What We Do

Telling a stakeholder that their request is no longer as high of a priority as it previously was will rarely make them happy, and they may actually have negative feelings about this news.

However, shifting priorities is a key aspect of every agile team, and ultimately a main driver of what makes us effective and successful.

Hopefully the examples and scenarios in this blog post can help you better prepare for some of those more difficult conversations. Happy de-prioritizing!

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

Navigating Complexity aka Cynefin for Dummies

For some time now, I’ve been working on getting a better grasp of the Cynefin framework and the related topic of Complexity Theory. This is mostly because I kept hearing something to the effect of: “We’re working in a complex adaptive/emergent system …” as well as, “Complexity: it’s the science of the 21st Century!” So I am trying my best to figure out what the heck folks are talking about.

In this post, I share what I’ve discovered so far.

Meaning of “Cynefin” (and How to Pronounce It :P)

The word “Cynefin” is Welsh, it is pronounced kin-ev-in and it has no direct translation into English. Some of the best explanations I’ve found are: “a place to stand,” “usual abode” and “habitat.”

Dave Snowden, a Welshman and scholar, came up with the Cynefin framework circa 1999 as a way of providing a typology for exploration and decision-making. In the simplest sense, the framework is a tool to help you know where you are (the “habitat”), so you know what you might do or how you might behave (no sense trying to swim if you’re on top of a tree …).

Five Places to Stand

Snowden’s Cynefin framework has five habitats or domains:

Obvious Complicated Complex Chaotic Disordered

In common usage, the words “complicated” and “complex” are often used synonymously, and that can create a bit of confusion. Take a trip with me through all of the domains and let’s see if I can tease the differences apart.

1. Obvious = Easily Knowable

In this abode, the relationships between cause and effect are, well, obvious. This domain is sometimes referred to as simple. Think of a table lamp. If you turn the switch and it doesn’t work, I’m pretty sure you know all the things you need to know to troubleshoot. Check if the lamp is plugged in. Check if there’s power at the plug. Change the light bulb, etc.

In Snowden’s framework, the best approach when you know you are in an obvious place is: sense, categorize, respond.

Sense the light doesn’t work Categorize the problem (power supply or bulb?) Respond appropriately (plug lamp in, turn on breaker, change the bulb.)  

In this domain, you can observe directly (look at the plug, the circuit breaker, and then apply best practices (plug something else that you know works into the socket, swap bulbs). Your results will be quite predictable.

2. Complicated = Not Simple, But Still Knowable

In the complicated domain, the relationship between cause and effect requires analysis and investigation combined with the application of expert knowledge. And the results, while possibly incomprehensible for the novice, will be predictable for the expert.

For example, take my computer (please do, it’s really old …). There’s quite a bit that I know I don’t know about its inner workings and why it might not perform the way it should. But there are fortunately plenty of experts who do know.

In fact, they could take my aging Mac apart into its many constituent pieces, figure out what’s wrong and put it back together (adding whatever new gizmo it needs) and it will work as it should.

And these experts could do this an endless number of times (provided, of course, I have the budget for their services). Rocket surgery lives in this domain, too. The approach will be: sense, analyze, respond. Good practices (the right people, the right process and sufficient time) will work every time.

3. Complex = Not Fully Knowable, Not Fully Predictable

When the relationship between cause and effect can only be perceived in retrospect, but not in advance, we are in the complex domain. This is the haunt of unknown unknowns--a  phrase that became popular for a few minutes during the George W. presidency.

Expertise in a particular subject matter may be helpful, but unlike in the complicated domain, it is not necessary or sufficient to control the outcomes.

I came across what I think is a great illustration of the complex domain when I watched a 4-minute video describing the reintroduction of wolves into Yellowstone National Park.

The presence of a small number of wolf packs, absent from the park for over 70 years, literally changed the course of rivers in less than a handful of years. Did anyone expect that? Unlikely. Sure, humans influenced it, but we could determine only in hindsight what would happen and why.

When traveling in complexity, the approach is probe, sense, respond.

Using the wolf example, you’d introduce an apex predator and measure things like wolf population, deer/elk/moose population, small rodent population, stream clarity, raptor count, tree density.

And then respond based on the what you’ve learned from the feedback loops. For example, add more wolves or reduce them. It is a safe-to-fail experiment. (Thanks to Ralph van Roosmalen for the metrics ideas!)

4. Chaotic = Neither Knowable Nor Predictable

In the domain of chaos, there is no relationship between cause and effect at a systematic level. Any moment is one that can have both unforeseen as well as incredible consequences. Decisive steps are called for all the time, yet what will happen is unknowable.

The approach in the habitat of unknowable unknowns is: act, sense, respond. Smash the glass, grab the fire extinguisher, aim at the base of the flame and pull the release. And then maybe run …

When in the domain of chaos, our behaviors tend to be reflexive and rightfully so. We don’t have the time to experiment. While we may learn something, it is often through serendipity.

5. Disordered

The fifth domain is disorder, which is the state of not knowing what type of causality exists. I don’t like to travel there. And when I’m there, I try to get the hell out as quickly as possible.

Cynefin and and Software Development

You might be wondering, “So what does this have to do with software development?” Me, too!

Circling back to my introduction: it’s important to know where you are operating, so you know how you should prepare, how you should behave and what approach you should take regarding measurement and feedback loops. Otherwise you may end up making decisions based on biased or simply inaccurate information.

The Ordered Realms

Back to the Cynefin domains themselves and the context of agile development. The obvious and complicated domains both lie within the boundaries of “ordered” systems. With ordered systems, we can relate cause and effect with confidence. If we take a certain action, we know what the effect will be; given an effect, we can determine what caused it.

A linear notion of decision-making works well. Got a display bug in a browser? Fix the underlying CSS. Lots of error messages in your RAID logs? Find the bad drive and swap it out.

In ordered domains, building new software tends to be pretty straightforward. Fixed processes generally work fine: Identify what you believe are the most valuable things. Do them first. Take measurements (which will be pretty straightforward) and then build more valuable things.

If you find yourself in one of the two ordered habitats, obvious or complicated, on a regular basis, you are safe following recipes and protocols. Also, please send me a postcard. Remind me how the weather is there.

The Unordered Realms

On the other hand, if you’re like me, much of your time will be spent in one or two of the three domains that are unordered: complex, chaotic or disorder.


If you don’t know where you are, you’re in “Disorder.” Your first priority will be gather enough information to know what you know or what you don’t know so you can move out. Are you under a DDOS attack or is a router down? Anywhere will be better than disorder.


In chaos, like complex, no amount of analysis will allow us to predict the full behavior of things. We can not determine in advance what will cause a particular outcome. While planning might be useful, the plan itself will not be.

If you find yourself in the realm of chaos, speed of response is vital. Triage. Stanch the bleeding. Stabilize the network. Get the servers back up and running. Figure out the root causes later. The only advance planning that makes sense is to have a known crisis management crew. If stuck on what to do, perhaps explore an oblique strategy to break the creative block. Novel solutions will likely be sufficient to help you stabilitze and move to another domain.


Last, and not least, we come to complexity, which got me started on this adventure. In complex systems, even though the relationship between cause and effect is often fuzzy, things tend toward being somewhat stable. So we can run experiments and see what happens.

In fact, we ought to run a series of experiments or a number in parallel to maximize our potential for learning. More planning won’t help. The best thing to do is just get started, launch many probes, measure many things, and set up lots of feedback loops. Then we can get a holistic perspective of what is happening. We can begin to see patterns and respond with amplification or dampening.

Our solutions and processes will continually adapt. This is the playground of complex emergence.

The Terrain of Complexity

The domain of complexity covers a varied and expansive terrain. The Stacey Matrix has helped me navigate by using the lenses of agreement and certainty. (Shout out to @scrummando for pointing me to Ralph Stacey’s work.)

In its simplest form, we can draw the matrix in two dimensions as below and overlay four of the five Cynefin domains. I acknowledge this is not a perfect representation of the world around us, as the borders and transition from one domain to another are not so neat and tidy, and with any particular situation, there may be islands of one domain floating in another.

(And maybe we could use a third dimension like entropy, or algorithmic information content ...)

Nevertheless, the 2-D view provides a useful perspective, a way towards greater awareness:

As we get further along the x-axis, the linkages between cause and effect become less clear, and we have less certainty. The y-axis indicates the level of disagreement about what we should (or should not) do about an issue or a decision.

If we pause to find out our general X-Y coordinates, we can design experiments to probe, poke and prod appropriately.

For example, would more or less certainty be helpful (maybe a shared mission/vision) or is it perhaps agreement we should be exploring through coalition building, negotiation, or compromise? How close to chaos are we? Is that an area to be avoided, lest like Wile E. Coyote we end up at the bottom of a canyon, or is it a place where some great innovation may be found? How safe would it be to fail?

Wrapping Up

I want to circle back to the complicated and complex domains, which as I mentioned earlier are easily conflated. I found two things that help grok the differences. First a recent article by Will Allen that explored the art of leadership and management within complicated and complex systems. Notice the contrasting brushes, palettes and approaches that Allen highlighted for each domain:

Roles, Tools and Approaches for Complicated Role defining – setting job and task descriptions Decision-making – find the “best” choice Tight structuring – use chain of command and prioritize or limit simple actions Knowing – decide and tell others what to do Staying the course – align and maintain focus Roles, Tools and Approaches for Complex Relationship building – working with patterns of interaction Sense making – collective interpretation Loose coupling – support communities of practice and add more degrees of freedom Learning – act/learn/plan at the same time Notice emergent directions – building on what works Game Play

The second thing I found that helped me tease apart complicated from complex was a LEGO Serious Play exercise posted by Andrea Tomasini. I’m a big fan of play time, so I was very excited when I came across Tomasini’s game.

In under an hour, it provides an introduction to four of the five Cynefin domains and helps participants explore the effectiveness of different communication and leadership styles along with the impact of planning in each domain. Check out the Cynefin Lego Game on

Happy travels!


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.


Deadlines in Agile

Imagine your company taking on a new project. It could be for a client or it could be an internal project – it does not matter. Along with every new project, there should and will be high expectations and lofty goals – and yes, a release date has been set.

"When” it will be done could come from many sources. It could be by some sort of estimation of all the work that needs to be done or it could be a wish or a guess – it could even be external factors deciding this date. Even if it’s internal project, somebody, usually the part of the organization impacted by the project, wants some way of knowing when the project will have this expected impact.

Deadlines are a reality. The question is: how do we deal with deadlines in agile?

Agile Principle: Sustainable Pace

One of the principles from the Agile Manifesto tells us: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Sustainable pace and deadlines? Traditional thinking usually leads to a lot of overtime when the project end is coming. This is when the project realizes that all those features that the project has committed to aren’t going to be finished by the set date.

To meet the deadline, overtime is used and that has all kinds of negative impact in the long run. You might increase productivity in the very short term, but the productivity lost after the deadline has been met is a great cost.

One hundred fifty years of research proves that shorter work hours raise productivity and profits, and overtime destroys them.

Short Iterations and Working Software

So, without overtime, how do we implement all those features that at project start were viewed as essential? The answer is that we in agile view essential features as something that is always changing based on feedback when iterating over that list of features.

There is just no way that anyone can know all the essential features up front. Short iterations and having working software as your primary measure of progress assures that when the deadline arrives, you are guaranteed to deliver a working product that is likely to contain features that are actually wanted by your customers.

A Shift in Mindset: Reduced Risk and Higher Precision

In a traditional approach, you are managing against the full set of requirements set out at the beginning of the project. You measure success against how many of these requirements are implemented.

Also, since testing the implemented features is a separate phase which usually doesn’t get the necessary prioritization, you might end up with a lot of features that actually don’t work properly. Not only might the features not work, but since no end user really has been involved in testing the features, you also might end up with features the users don’t want or need.

Instead of risking software that does not work and functionality not wanted or needed, you should change to an iterative approach, where for each iteration, you try to get as much feedback as possible about the new features and changes in features done since last time you got feedback.

There is just no way you can think up, upfront, exactly what your end users want and need. You can have a basic idea and work from that, but you need to have a short feedback loop to work on feedback from your users.

Based on the feedback you get, you can inspect and adapt. Maybe you need to go in a completely different direction or maybe you are on track and just need some minor adjustments.

Using a traditional approach, you might not know until your project is done; with an agile approach, you should know very early with plenty of time to make changes.

Building a product that customers don’t want probably wasn’t part of that lofty goal set at the start of the project. You are essentially shifting from “building all these features by the deadline” to instead trying to “build the best possible product by the deadline.”

What If All Features Are Needed?

Sometimes, for regulatory requirements as an example, you can’t just say you have finished the most important features and that’s that. Another important advantage by having short iterations is that you will catch early warning signs that development will progress more slowly than needed for the deadline to be met.

By catching this early, there will most likely still be time to do something about it, like putting additional teams on the development. If you catch these early warning signs, the general rule about putting more people on the problem and how it will only slow you down won’t ring true.

Doing something about the problem when there is still time to do so is one of the great strengths of a short iteration-based approach.

Manage Deadlines with Change in Mind

To a large extent, deadlines are inevitable. Even if a hard deadline hasn’t been set, there usually are expectations of a release date – either internally from management or the ones being impacted by the project, or externally from customers or other stakeholders.

Still, agile promotes a sustainable pace. Short iterations, feedback and a product that works at all stages is the answer. To some, it’s very comforting to manage the development work by looking at all the upfront requirements and managing against those.

This is, of course, a false sense of security – requirements will change while doing the work. We are much better of embracing change and managing deadlines with change in mind.

I welcome your thoughts in the comments below.