Search Results

One of my favorite cars that I ever owned was a 1967 Ford Falcon. I bought it for $600 when I was in college. It really wasn't much of a car. It was a 2 door coupe built on the same frame as the classic Mustang, but without any of those muscle car good looks. It was the kind of car intended to be a hot rod for my grandmother. It had a straight six cylinder motor combined with an automatic transmission that was best described as apathetic. It had all the fundamentals you need in a car: an engine, brakes, doors that open and close, and a horn that went "Beep! Beep!" I remember the first time I stepped back and looked at it after I bought it and thinking, "Well, I'm going to have to change this right now." Of course, being a college student I had to do everything on the cheap. So I ran down to the auto parts store and bought a bunch of cans of spray paint. I taped up the windows and the headlights and proceeded to paint the entire car bright canary yellow. Sufferin' succotash! Was that car ever bright! Unfortunately, so was the car parked right next it (Oops). Then I bought a genuine race car hood scoop. You know, the kind like Mad Max had on the front of his car? Well, I grabbed a drill and bolted that baby right onto the hood (no, not the motor, the hood). That hood scoop didn't actually do anything but look cool (and act as storage for my friends used beer cans). Then I put some old fat used tires and some moon rims on the wheels and I had a genuine, bonafide, race machine. Now granted, I really didn't change the motor at all. And those beer cans in the hood scoop rattled a lot whenever I turned sharply. After all, it was still just grandma's skinny little straight six. But you can't argue that I didn't have one of the most distinctive looking cars in SE Portland at the time. There was something empowering about being able to make any old cheap modification, large and small, just for the fun of it. So I just kept at it. Somehow I only managed to get pulled over by the police once - and that was for driving while simultaneously eating a very large bag of M&Ms. Guilty as charged: it was an "M&M DUI" - Driving Under the Influence of M&Ms. Yes indeed, those were wild days. I still like to customize things. Whether it's cars, boats, or my house, I just can't seem to keep things stock. I guess I need to tweak it a bit to make it mine. Perhaps I need to fine tune things until they fit just right? And so it goes with some of the processes that we use. I don't think I've ever done Scrum the same way twice. And you can rest assured that I've never been able to implement a framework without bolting a metaphorical hood scoop on it or otherwise changing it to better fit the needs of the teams. I don't really understand how people can refer to any framework as strictly "cookie cutter" or standardized. That just doesn't really match with my experience. You see, we always have to customize things. No matter how dogmatic we may be, there are difference issues and impediments that beg for us to make small changes. And that's OK, we need to be able to change things a little bit here and there. There are three reasons I believe that the customization of frameworks is important. First, sometimes when you look closely at those frameworks you will find that there are multiple practices that can be used in the same place. I’m thinking of the myriad different ways that we can facilitate planning meetings for example. So you have a choice, you can use the stock practice as proscribed in the framework, or you can use a custom variety of your own. It’s kind of like customizing my old Ford Falcon and turning it into a hot rod. Second, frameworks also have gaps. Again, close inspection of frameworks will reveal gaps in the recommended processes and practices. Not everything is completely spelled out, that’s why they call it a framework to begin with (there are bits that are intentionally left blank). It’s supposed to be skeleton upon which you hang your organizations processes. The processes that are already described are what many might call essential, but they are by no means all of the processes that you can have. You can certainly add more and you can certainly innovate in the way that those additional processes are integrated or combined with the framework. If you want to hang a stained glass window in the rear window of my Falcon, be my guest. Third, frameworks are intended to serve as the foundation or soil within which the seeds of innovation can take root and grow. Most agile frameworks are all based on the underlying assumption that this is the starting point from which you will evolve. Over time you will either hang more processes off that skeleton or you will change the skeleton itself to better suite your business and technology domain. It's only through customizing our frameworks using these tools that we achieve remarkable outcomes. Customization provides alternatives to stock practices that may grow stale over time. Customization can also help us to fill in the gaps in the process that were never anticipated when the framework was created. And finally, customization serves as the seeds of innovation that we plant in our frameworks in the hope of developing exciting new ways of working. We're here to build hot rods, not clunkers, so it's time to customize our frameworks.

How do you facilitate 120 people to rank 40 epics in just 1 day? With a few small modifications Mike Cohn's Theme Screening described in Agile Estimating and Planning (2005) works very well. The basic technique is: Identify the selection criteria that guide your decision making. Examples might include cost savings, customer retention, market differentiating. Choose a baseline epic that is well understood by the audience and is likely not the highest scoring or the lowest scoring for each of the selection criteria. Mark “=“ in each cell under the baseline row Compare each epic with the baseline epic using the selection criteria. If it is better than the baseline, place a “+” in the cell. If it is worse give it a “-” symbol. If it is the same give it a “=“. Repeat for each epic. Scoring 1 for each “+” and -1 for each “-“, add up the scores in each column to get the total score for each epic. The highest ranked epic has the highest score. Variations on a Theme This is how to modify the technique to work at a very large scale: On a large wall, attach butcher paper and layout the ranking table. Attach the epics horizontally left to right as the header row of the ranking table. Use large Post-its so that the Epics can be easily moved if necessary. Identify the baseline epic before the event and propose to the group. It might be sensible to have more than one candidate baselines just in case. Identify the selection criteria at the event. Ask each table (5 -8 people) to brainstorm selection criteria. Affinity group the selection criteria and dot-vote to reduce the list to the top 3-5. Hold a confidence vote before proceeding. Give each presenter 3 mins to describe their epic with 2 mins for questions Modify the scoring technique to get to consensus quickly and avoid ties. Give each table green, red and blue sticky dots. Each table discusses the presented epic briefly (2 mins) and decided whether the epic was better (green dot), worse (red dot) or same (blue dot) than the baseline for each selection criteria. Attach the dot in the appropriate cell on the ranking table. Score +1 for each green dot, -1 for each red dot. Conclusion Did it work? Yes it did. We were able to zero in on the epics to be prioritized and the group was able to draft a lean canvas for each in the afternoon of the 2nd day. Naturally we had some challenges along the way. We were slow to start. Everybody was unfamiliar with the flow but after the first few epics we established a good rhythm. If you are facilitating this exercise watch out for presenters who say "you know me, I'll keep this brief". They never do. Use a time-box and stick to it. The target number of epics for the workshop was 22. By the start of the first morning that list had grown to 40 and grew to over 60 as attendees realized key initiatives were missing. Although we made good progress it was apparent to all in the room that we had too many epics so before the the second day we culled some of the lower value or future epics and refactored others. The great thing with the voting approach is the scores are not impacted by the number of votes cast. If we lose a table or a table abstains we just assume a blue dot. The colored dots made for a very good information radiator; taking a step back it is easy to note from the clustering of red or green where the least important and most important epics were.

And why is over committing a problem? One of the base Agile Principles is that we try to set things up so that Teams operate at a sustainable pace. When Teams hear about this there is general excitement that it might be possible, that they might be able to restore some kind of work / life balance. Then there is the belief that “they won’t let us do that around here.” This is a rational concern in many organizations as Management often believes that being busy is a sign of being productive and useful, and that management tools like “stretch goals” and “mandatory overtime” will result in increased delivery of value. Coaches are aware of this, and so coach management that they need to be very positive about how they want to have a sustainable pace. Management (often though coaching) understand that they have an interest in a plan based on reality to improve the predictability of work delivered. They begin to understand that to improve how much is delivered (throughput) they cannot overload the Team as this increases the amount of work-in-progress. They begin to realize that one reason the organization are annoying their customers is that we say we will do something, and then fail to meet that commitment simply because there is too much work to get done. In other words Management has a reason to be positive about the sustainable pace and can be authentic in their delivery. They are looking forward to the day when the Team makes and meets commitments more often than not. But still it inevitably happens. All the work is now visible so we know Teams are trying to take on more than is realistically possible. We try to help the Team, but they don’t seem to be able to do anything about it. Perhaps we leave it this time. “They’ll learn when they don’t make it.” But the next time it happens, and the next time, and the next time. But now it’s worse. The original excitement that Agile will deliver a work / life balance is gone since the Team has to work hard to meet the commitments they made. I’ve seen this pattern happen over and over again. I once ran a survey of 65 Teams and found that the average overcommit of the Teams was 42% and that about 69% of Teams over-committed on a regular basis. What Factors Contribute to Teams Over Committing? The question we have to ask ourselves is “why?” After all, no one is forcing the Team to do this, right? Management thinking is correct - if we don’t address the problem we will remain unpredictable in our delivery, and have reduced throughput due to high work in progress. Over time, we will further reduce throughput due to a reduction in engagement of the Team. Worse, our customers will see no improvement in our ability to make and meet commitments. My view is that there are a number of factors which contribute at the individual and Team level: Image management: We want to look good, both as an individual and as part of a super Team. We therefore want to be seen to be doing more, to provide more value. Not understanding how to say “not now”: Many organizations (especially IT organizations) have a policy to say “yes” to all work. This history has not taught Teams how to say “not now” to their customers and stakeholders. Even if they know they cannot do the work. Optimism bias: People overestimate the likelihood of positive outcomes when they look into the future. There is benefit in having a positive outlook, but in this case we are letting this attitude adversely affect our ability to make rational decisions. The retrospective bet: The last retrospective was very positive and the Team determined a problem and a solution. The Team bets on this result. This means that we assume we will get better before we actually get better. A genuine want to help: Knowledge workers really want to help and so when someone says “I just need this ...” they will take it on themselves to get it done, especially if they know the person asking. Hero culture: The organization has traditionally rewarded (one could even say developed) the heroes of an organization. This is so ingrained that people are not even aware they are operating this way. Uncontrolled work intake system: Many Teams, especially when starting, do not have control of their work intake system. This means they are unable to plan and predict the work, and are impacted more than expected by “break ins”, for example. Invisible work: The Team thinks it has a view of all the work, but in reality a lot of work is hidden. This hidden work usually impacts the ability of the Team to deliver on their commitments. Poor estimations: Early in a Team’s life the Team will not have a good understanding of what it takes to deliver value which often results in over-committing. Return work: When work is completed, there are often issues associated with the initial delivery, and time must be taken by the Team to address these issues. This is often not factored into the capacity of the Team. And sometimes Management do not help the situation: Management talks, but does not walk, Agile: For example, there is a conversation on over-committing, but no real action. Message to Team “situation normal: just keep saying yes.” Or management says “Thank-you Brent for taking this on.” Message to Team “we will continue to reward heroes.” Management unwillingness to make the hard calls: Sometimes management are presented with a problem and are unable to make a decision. Even though the Team has evaluated various positions management response is “If we just did it like this … we can do both of these …”. Spoken like a person who doesn’t actually have to do the work. Management unwillingness to protect the Team from the consequences of “not now”: While Teams make the call, and Management agree, you will often see Management fold when their customer or stakeholder complains about the decision. Don’t get me wrong, there is often a need to change plans, but if that discussion does not include a discussion about taking work off the Team, all management is really saying is “you have to do it.” In many ways these are all examples of short term thinking that has huge consequences in the long term. What Can We Do To Reduce Need to Overcommit? The question is “what can we do to improve the situation?” There are some obvious things we can do. Firstly, we can help our Teams understand that these drivers exist and create problems for ourselves. Sometimes a simple discussion based on raising awareness will help. This is true of both the above individual as well as management factors which lead to over committing. For example: Many people are unaware of the optimism bias we all have. You can make people aware of this bias by having a discussion around the Prudential Ad About Thinking Positive in the Future You can talk about the Hero culture in the context of books like the “Phoenix Project”. We could talk about using “Yesterday’s Weather” approach to determining how much work to take on instead of assuming we can do more. A capacity buffer could be added or increased to reflect the unknowns in the work intake system. The idea here is to force the Team to commit to less “planned” items until the intake system stabilizes. Retrospectives could be run on the estimates, to improve the Team’s understanding of the work. Team Members could ensure that “everything is on the board” to reduce the impact of hidden work. Teams could do a value stream mapping exercise to understand percentage of work that is accurate and complete, and so work to reduce the amount of work that returns. Management could show awareness of their fallibility by admitting to past errors and discussing how they will address going forward. We also might try a more “culture oriented” approach. For example, we could adopt a mantra like “under-commit and over-deliver”. We would set the cultural expectation that it is OK to under-commit so long as we meet the resultant expectation. Some Management will worry than this will mean that Teams will slack off. The data above shows that we do not have this problem in reality. And wouldn’t you love to be in the room when a Team reports to the customer saying “we were able to complete the committed items and, since we had spare capacity, we also delivered this high priority item you were wanting.” BTW: I have actually seen this happen. Often these approaches have been tried and you still find a pattern of over commitment. In these situations the Team might want to set up a single subject Retrospective to discuss approaches to improve. This might be a place to discuss the issue, raise awareness of factors, and review possible approaches. I suspect that when you ask the Team, there will be other, more specific factors and potential approaches to take. And finally we could also consider other more direct and experimental approaches. For example: 1/2 Velocity experiment: Team sets up an experiment by saying “Why don’t we set up an experiment where we plan to half our normal velocity as an artificial limit just to see if it helps.” The idea here is that by reducing the commitment the Team will actually produce more and feel better about the result. 1/2 Iteration experiment: Team sets up an experiment by saying “Why don’t we set up an experiment where we plan to half an Iteration just to see if it helps.” The idea here is that it easier to plan a short term future than a long term one. Note: These ideas can be applied at all levels of Iteration - a Team 2 week cadence, a Program quarterly cadence. The bottom line is that over commitment is a problem that needs to be addressed if we really want to achieve a sustainable pace for the Teams, manage the expectations of our customers, ensure good work / life balance for our people increasing their engagement, and increase throughput.

The diet industry thrives on those looking for a quick and easy fix. The inconvenient truth being that the only long term solution to better health is to eat better and move more. Patrick Lencioni (The Advantage) lists three biases we hold that affect our ability to change: Sophistication Bias: organizational health is so simple and accessible that many have a hard time seeing it as a real opportunity for meaningful advantage Adrenaline Bias: becoming healthy takes time; unfortunately many suffer from a chronic case of adrenaline addiction, hooked on the daily rush of activity and firefighting within their organization Quantification Bias: the benefits of becoming a healthy organization, as powerful as they are, are difficult to accurately quantify Our sophistication bias leads us to continuously search for the answer. It must be out there somewhere. We’ve hired the best people so why are we not succeeding? Maybe we just need to invest more? Should we go visit other companies and see what they are doing. Consultancy firms are well aware of this bias. Armed with their slick Powerpoint decks, their suit clad armies descend to regale us with their mystical framework that will answer everything. Bill points out that if it’s that obvious, everybody would be doing it. However he is summarily dismissed because after all, he buys his clothes at Target and who invited him anyway. So we enroll in the new diet. The short-term effects are really encouraging. Boy did we show Bill. Six months later the buzz wears off. Not only that we’re in a worse shape than we were before. We hold a post-mortem. Where did we go wrong? Of course, it’s obvious, we chose the wrong vendor. And so it continues. Three failed attempts later someone asks what happened to Bill but of course he is long gone.

#coaching #transformation #organization When I first did an agile transformation (450 people located in 12 countries) the coach we worked with provided the leadership with a couple of days training, helped us put together a plan to transform, trained a couple of teams, trained the leadership team on how to train teams, and then, with the exception of a couple of check-up visits, left us alone to figure out what to do. At the time I did not question this approach. It was just the way things were done. Roll forward a few years and what I find is that today I am asked to engage as a coach on a full time basis. The thinking seems to be that it is only by being engaged full time that the client organization feels like they can make progress. Again, this just seems to be the way things are done. In some ways this makes sense. When I first did transformation work there was not a deep body of knowledge around transforming large organizations to agile. Today we can leverage a far larger body of knowledge. And, to be honest, the “full time” model suited me. A long term engagement means a regular check coming; a low risk contracting option for me. My thoughts are evolving here though. As a result of a transformation I am working, one of the principles, Elizabeth Flood, said to me: “I have opportunity to learn so much when you are on vacation.” Elizabeth found that when I was away she had to take responsibility for the success or failure of aspects of the transformation. Since I was not available, this meant that she went out, took risks, and learned for herself. Interestingly, and perhaps a ding on my ego, the results were exceptional when I was not involved. This was a bit of a wake-up call for me. If the purpose of the transformation is to have the organization be agile themselves (to put the agile coach out of a job) am I actually an impediment to that happening? I needed to step back and understand what the benefit is of using a full time coach and evaluate the value we offer over a more “as needed” approach to transformation coaching. The conclusion I came to is that the use of full time coach is risk reduction strategy for the client organization. What I am also beginning to understand is that like all risk reduction strategies, it comes with cost. What surprised me was that the cost may not be obvious. What Is The Relative Cost of a “As-needed” vs “Full time” Coach Engagement? Let’s start with the monetary costs. Simply speaking, it costs more to keep a coach around full time. Coaches that are not full time will cost more on a per day basis simply because they are absorbing the risk associated with fact they are not continuously employed and because some of the “preparation time” for various events. To understand why a full time coach costs more, let’s say we are going to transform an organization of say 500 knowledge workers and basically want to kick the process off over a period of a year (note: there is huge variability in the practicality of doing this, but I needed a timeframe to calculate costs). Comparing an “as-needed” coaching model to a “full time” approach gives a base calculation: As-needed: Let’s say good transformation coach at say $2500-$3000 per day plus expenses. Engagement in this case is: 1 week assessment, 1 week leadership review and planning, 2 weeks start-up training for a number of teams,4 x 1 week checkup session(s) each with 1 weeks additional engagement each time to work what has been discovered, An additional 4 x 1 week as-hoc session based on need. Full time: Let’s say you bring that person in full time is about $2000-$2500 per day. Engagement in this case is:4 days a week for 12 months to kick off something significant. Realistically the “12 months” is really about 40 weeks of actual engagement after removing vacations, holidays, and so on.This includes same activities above, but also the coach will attend meetings, work directly with people, etc. Comparing the cost: As-needed model: At high end of $3000 / day, cost is $192,000 for 16 weeks engagement, plus 16 weeks of expenses for the year. Full time model: At low end of $2000 / day, cost is $320,000 for 40 weeks engagement plus 40 weeks of expenses for the year. Internal expense will probably be around the same for the client organization. Most transformation coaches will tell you they are there to work themselves out of a job (and hopefully you’ll see evidence of that as you engage with them through the transformation). This means you will still need to create a team of people responsible for the transformation, with appropriate level of leadership. This is true whether coach is engaged full time or as needed. What is the Benefit of Having a Full-time Coach? What do you get from a coach when they are full time? What would be missing out of if we went for a more ad-hoc approach? Let’s assume the transformation coach is interested in driving transformation forward and, in particular, is not being used for staff augmentation for the client organization. The full time transformation coach will help with: A sense of urgency resulting in continuous, probably gentle, pressure applied to the organization to change. A different point of view when it comes to assessing how things are going and where we should go to next, based on the wider understanding the transformation coach has of base agile, lean etc thinking as well as their experience in working the transformation. A set of individuals in the organization will be developing their skills based mentorship and coaching of the transformation coach. A wider set of ideas on how to work specific situations that arise in your transformation as a result of their wider experience. A cheerleader that can help drive the transformation as a result of their experience at seeing things improve in other organizations (they “know” agile will help) which can help overcome obstacles. A point of stability as, when things do not go as expected (big or small) there is someone in the room that is calm and helping you through the situation. A way of explaining new concepts that may be difficult for the organization to accept. For many, agile and lean concepts applied to knowledge work are counter intuitive or worse, simply unbelievable. But people need to make the change in mindset to really get the business results they need. A good story, a good metaphor developed by working in previous transformations can help the organization get more quickly to understanding and application. Sounds pretty useful, right? And let’s face it a lot of organizations are using this approach for exactly these reasons. What Are the Hidden Benefits of a More Ad-hoc Approach to Coaching? There are however downside to the full-time approach as well. Looked at the other way the downside of a full time approach are the upsides of an ad-hoc approach. In many ways when you have a full time coach you have effectively “outsourced” the “help” aspects discussed above. For example, do you need continuous pressure from an external source, or do you have a sense or urgency already that can provide this pressure? The first time I did a transformation, we didn’t need someone to keep the pressure on. Let’s face it; we were desperate. Our clients were complaining about the quality of our work. Our sales and marketing organization were complaining about missing schedules and inconsistent delivery. Our finance department were worried about the future trends. To put it simply our jobs were on the line. We did not need this pressure to come from an external source. We just had to continuously remind ourselves and the organization about what we were doing and why, and this created the pressure and the sense of urgency. While it is sometime easier to get external help with “pressure” and “urgency” in many cases you know what needs to be done and why and so don’t need an external coach to help with this. This is the base case but it turns out there is a more insidious and long term problem with outsourcing this aspect of the transformation. By outsourcing “urgency” and “pressure” the organization doesn’t really learn how to do establish urgency and pressure for themselves. If this kind of transformation were a one of event, that would be fine. However todays organizations are operating in an increasingly volatile environment, and the one thing we know for sure is that this is not going to be the last transformation. In fact, much of agile assumes that we need to continuously and relentlessly improve in response to our environment. We therefore need to become good at focusing the organization on what is important, and be able to pivot quickly in response to new issues. In other words, we need to develop the organizational muscles to establish urgency and pressure to change as we detect shifts from the business environment. By outsourcing this aspect of the transformation for agile, we don’t really learn how to do it for ourselves and delay this learning. A similar set of thinking can be applied to all the points above. If we rely on a coach to: Help us with an agile viewpoint, then it will take longer for us to develop this insight ourselves. Again, when I first did a transformation I had contacts I could chat with when we had a business problem that needed to be addressed. But in reality, I spent more time researching the issue, discussing with others in the organization, and so on to come up with approaches that we could try. Some worked. A bunch did not. But we got better and better at it, ourselves. We developed this important organizational capability. Mentor leadership to modern approach, then our leadership takes longer to learn how to continuously learn themselves. In the worst case, this could lead to the expectation that learning needs to be spoon fed to leadership, which is not exactly an agile approach. Help as a cheerleader, or as a point of stability, then we won’t develop our organizational ability to motivate and overcome obstacles this way. Does This Mean That We Should Not Use a Full Time Coaching Model? None of this says that a full time coaching model is bad, only that you might take longer to get to certain outcomes. From a time perspective, you will probably get through the kick-off phase faster with a (team of?) full time coaches. The reality is that organizations might need some of this help. People and organizations learn in different ways and sometimes an “outsider” can do things that no one in the organization can do. Also it might be easier to convince others in the organization that you need a full time coach, as the “as needed” model is harder to work. In the end both models have pros and cons depending on your situation. The main discussion here is not so much about what is right, but rather to help you understand that even though the prevailing model recommends a full time coach, it may not be the best solution for your context.

With the huge growth in popularity of the Scaled Agile Framework (SAFe) we're seeing a lot of people introduced to Program Increment (PI) Planning. We're also seeing bad habits creep in. Habits that don't align with our Agile values. PI Planning is a very visible cost to the organization. Bringing a team of teams and their stakeholders together is not a decision taken lightly. As a consequence we are seeing a lot of pressure on the planning event to be wildly successful. This pressure is felt most by those preparing for the planning. They spend many weeks ensuring the backlog is in great shape. The pull of the past is strong. Difficult conversations and work assignments start to occur outside the event and, in the blink of an eye, PI Planning morphs into a mere blessing of a plan developed by someone else. In 5-10 years time we might look back at PI Planning as we view use-case modeling today. Seemed like a great idea once but we could never quite get it right for mainstream implementation. I hope it's not too late. I used to advocate that planning is more important than the plan. I still think that’s a good mantra but now I’ve come to believe that more important than planning, is the alignment that is achieved from a well facilitated collaboration. I suggest we start replacing the word planning with the word alignment. Using the word alignment takes the emphasis away from the plan and places it on the key deliverable - ensuring everybody has a shared understanding about the way forward. Try it on for size. Sprint planning would become sprint alignment. PI planning becomes PI alignment. But why not take it a step farther, and be more inclusive. Team alignment is much more inclusive than sprint alignment. After all, Kanban teams need alignment too. PI Planning is exclusively a SAFe term. Why not go back to our roots and bring back an old favorite and use the term release alignment to place the focus more squarely on the customer.

The term is derived from the behavior of insects in nature. The classic example of this behavior is a beehive when it reaches a critical mass. The workers will grow a new queen, and then the hive will split and a swarm will form that will leave the hive and seek out a location for a new hive. Perhaps the most astonishing thing is the fact that there is no one individual controlling the actions of the hive. There is no controller, no authority, no coordinating influence. Sounds kind of Agile. These characteristics of “swarming” in the insect world are very similar to the kind of behavior that we are trying to foster within Agile teams. We want the entire team to focus on one and only one story at a time. We want to use simple rules. We want to allow the team to self organize. However, swarming is a relatively new pattern to emerge in the software world, and there has been a lot of misunderstanding and resistance to the notion of swarming. The idea of having the entire team focused exclusively on the same story is very hard for some people to swallow. The key is to create the right environment to support swarming activity. If you are going to practice the swarming you need to make sure the following conditions hold true for your team: There is a definition of done that enables the involvement of the entire team The scope of the story is non-trivial A set based decision making model is used Often the argument that I hear is that a given story simply doesn’t require the involvement of everyone on the team. However, the more I thought about it, the more I realized that this probably isn’t really true very often. If we look at the definition of done for a team, we fine that there are activities from virtually every team specialization that are required to get a story into “potentially shippable” form. There needs to be a definition of done that enables the involvement of the entire team. Think about it – what activities need to be done for each story? Can we leave out QA? Documentation? Analysis? Design? Someone once argued that it doesn’t make any sense to build a car 1 tire at a time. I have to agree, but I must also maintain that the challenge must be equal to the resources of the team. We should scale the stories to the appropriate size. The scope of the story must be non-trivial. Instead of building one wheel at at time, perhaps we should change the story to implementing the braking system? Perhaps the team should be implementing the suspension? The drive train? The story has to be scoped large enough that it allows the participation of more than one team member. We also have to realize that swarming opens up some opportunities that we might not have using more conventional team organizational patterns. A Set based decision making model can be used. If the entire team is focused on the same problem, then we can also have them explore multiple solutions to the problem. This can lead to enhanced learning by the team, and allows them to explore alternatives more fully before making a commitment to an implementation or technology. So, if you want to explore your busy inner bee, you need to create the right environmental conditions to support the swarming behavior: There is a definition of done that enables the involvement of the entire team The scope of the story is non-trivial A set based decision making model is used Given these conditions, the swarming pattern represents an exciting opportunity for us to explore a new way of understanding how we collaborate within our teams.