Blog


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.

Retrospective

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.

Conclusion

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 Lego4Scrum.com  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.

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.

Chaos

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.

Complex

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 Agile42.com.

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.

Conclusion

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.

How to Build and Motivate Your Scrum Team: Part 1

“Understand their past so that you can better guide them toward their future.”

As an agile coach or Scrum Master, at one time or another, we have all faced the situation of introducing Scrum to a new team or turning around a Scrum team that has lost its way. I feel that the old saying about Scrum that “the concept is simple, it’s the execution that is hard” is referring to those two situations.

In either situation, the first thing you need to do is start from or go back to the beginning and treat these teams as if they were a new group of people.

You need to keep in mind that most core team members either come from:

A Waterfall environment where they were subjected to unrealistic deadlines, long work hours and their expert opinion ignored or never fully leveraged An agile environment that was agile in name only where the product owner and Scrum Master operated with Waterfall’s mentality, and the benefits that come from working on real a Scrum team were never realized.

Thus, calling a group of people a team, even if they have worked together before, does not necessarily make them a team. A team is composed of members that know through experience the value and the level of commitment that each team member brings to the team. This is something that does not happen overnight. It’s a journey that you and the team take together.

As an agile coach or Scrum Master, you need to connect with your team on a logical and emotional level. The logical level stems from your knowledge of Scrum and how well you transfer that knowledge to your team. The emotional level stems from the trust you build with the team and within the team as you guide them through the adoption of the Scrum framework and they come realize its benefits.

The First Step

The first step in the journey is level-setting the team through training. To make the logical connection, I want them to know what I know.

As part of my own continuing improvement, I’ve put together training slide decks for the Scrum Master, the product owner and the core team roles, which I use to ensure that they gain that all-important shared understanding of the Scrum roles and associated responsibilities.

I also find these training decks to be useful for bringing new members up to speed when changes occur within the team, and I continue to update them as I encounter new and better ways to express ideas.

The Second Step

The second step is to help them to decide what kind of team they really want to become and is where I lay the groundwork for building a team and starting to make the emotional connection. So, it is here that I ask them to tell me their thoughts on what makes a great team.

For this exercise, I have them write one thought per Post-It note and when finished, put them on the board. I often use Post-It notes to ensure full participation, especially from the less-vocal members in the group.

Once complete, we rack and stack the notes into three to five categories. Based on the number of categories, each member receives the same number of votes and is asked to go up to the board and select those thoughts on the board they feel are the most important characteristics of great team.

After the votes are tallied, we take the winning thoughts and turn them into value statements that are positive and mean same thing to everyone in the group.

The following is a sample of some actual team value statements:

Sharing knowledge and information freely and openly among team members. Putting the team first and the willingness to do any task necessary to reach each sprint goal. Asking for help when you need it and without delay, and helping others when they need help or when you find yourself with spare time. Taking the time to listen, understand and respect your teammates’ opinions and views.

I have been in many team spaces over the years where I’ve seen team values expressed using single words such as “responsibility,” “commitment,” “trust,” “respect,” etc. and find it sadly lacking because if I don’t know what the word “respect” means to the team, how can one expect those team members to know?

And if that is indeed the case, does this team really know what kind of team they really want to become?

However, when you look at the team value statements mentioned above, there is no question about what that team thinks it takes to be a great team. I would also like point out that value team statements are not a one-time exercise where you are done after you print it out and post it in the team’s space.

This is a tool you will use from time to time in your retrospectives where you might ask the team, “Did we as team live up to a specific team value during this sprint?” … or to remind them what kind of team they want to become. You might also add or adjust a team value statement as the result of what the team learned during a sprint.

The Third Step

The third step is to have this group of people come together to decide how they want to organize their workday. This is what I call a “team agreement,” an example of which is shown below.

Business Hours: 9:30 a.m. – 3:30 p.m. Daily Standup: 9:40 a.m. – 9:55 a.m. Coding Hours: 1 p.m. – 5 p.m. Mid-Sprint Check: Sprint Day 5

Business hours is the timeframe that the team agrees everyone should be on the premises. The daily standup time is when the team agrees to meet and plan their work for the day. Core hours are generally used for the team to engage with others. Coding hours is a period where the team is not to be disturbed so they can focus on work.

And, the mid-sprint check is the point in the sprint cycle where the team reviews the task board to determine if they are still on track to complete all the stories, and if not, how to adjust their work strategy to get back on track.

Conclusion

With this process, we take into consideration the group’s past project experience and focus on laying down a foundation for shaping this group of people into a team.

We start off making a logical connection by explaining the Scrum framework roles and responsibilities for every person in the group so that they now know what the job entails. We then engage them to tell us what they think makes a great team.

We ask them what is most important to each of them, and then assist them in creating their value statements, thereby making that first emotional connection. In the last step, we take our first opportunity to empower them by asking to self-organize their workday.

In Part 2 of this article, we will continue the journey and discuss how we further build on this foundation we laid out in Part 1 as we guide a team through the adoption of the Scrum framework. 

5 Signs Your Team is Lacking the Agile Mindset

When a Scrum Master joins a new team—whether it’s a team new to Scrum or one that has been practicing Scrum for a while—he faces different challenges. Therefore, the duties and focus of the Scrum Master for the first days are different in both cases.

In the first case, where the team is new to Scrum, most of his time and focus is used to teach and coach the team through Scrum. There is often a standard approach to how the team will be introduced to agile then Scrum.

On the other hand, when he joins a team with only some Scrum experience, he needs to act differently. For example, he needs to watch and observe more how the team is acting and how the members are interacting together to see if the agile mindset exists.

Some teams think they are agile by holding the prescribed meetings, but this is not the essence of agile. This type of team needs to be coached to cultivate the agile mindset, regardless of which framework is in practice.

There are many signs that indicate the lack of an agile mindset. Let’s look at some of the common signs that should send a warning signal to the Scrum Master that the team needs to refresh its Scrum and agile knowledge.

1. Knowledge Silos

One of the teams I worked with in the past used to have each developer working on a specific part of the product, and only he knew about it. Whenever a problem happened, they needed to wait for him to fix it.

This can also manifest when certain persons are pre-assigned to specific tasks or user stories during the sprint planning. This behavior prevents the team from working on priorities; rather, each person would work on the part he/she knows without considering the deliverability at the end of the sprint.

Another drawback of such behavior is the lack of team spirit and teamwork, since each one will be working on his/her own island without caring about what happens on the other island.

2. Not Working on Top-Priority User Stories

Teams working on a user story at the bottom or in the middle of the sprint backlog miss the concept of prioritization, and it could also signify a conflict with the product owner or a product owner who is not doing his homework.

Having a prioritized sprint backlog, and of course, a product backlog, is a product owner’s main responsibility to maximize the value delivered each sprint. If a team decides to work on a user story at the bottom, it is either the user stories that are not properly prioritized, or the team needs to understand the importance of picking work based on priority.

3. Separate User Stories for Testing

Having separate user stories only for testing of other user stories, whether these user stories are in the current sprint or a previous one, signifies that the team either doesn’t have a definition of done (DoD) or they don’t understand the meaning of deliverability.

Although it is acceptable to have separate user stories for developing automation tests, it’s a big red flag when you have user stories for “testing” only. In this case, the team needs to be coached to understand what it means to deliver a working product increment at the end of the sprint and to define their Definition of Done.

Without verifying your implementation, you can’t make sure that you are delivering a working software.

4. No Visibility of the Burndown Chart

If the team doesn’t have or doesn’t use the sprint burndown chart, their progress won’t be clear to them. The burndown chart is a tool to show very easily and quickly how focused the team is. The team might feel they are doing a lot of work, but yet they have flat burndown. This means they are not delivering, and they need to regain their focus to deliver more often.

Another misunderstanding that I have experienced with some of the teams is when they ask to have their burndown chart burnt based on tasks finished rather than user stories.

I consider this a bad practice, since it gives them an illusion of achievement, and at the end of the sprint, you might be surprised by having so many tasks finished but not delivered because the whole scope of the user story, including testing it, was not finished.

5. They Estimate Only for the Upcoming Sprint

Although it is one of the basics of agile to a have prioritized, estimated backlog, some teams might estimate only the scope of the upcoming sprint during backlog grooming sessions. Some teams don’t even have these sessions.

Planning only per sprint is dangerous since it doesn’t allow the product owner to anticipate or plan when certain features will be released. In these cases, the Scrum Master will need to teach the team the several levels of agile planning, and the value of having a prioritized estimated backlog for the team and the customer.

These are just some of the signs I have experienced when joining a team that let me know that the team doesn’t yet have an agile mindset, and more education should be the focus. Have you seen signs like this when you’ve joined a team? Do they exist in your current teams?

I would love to get your feedback in the comments below.