I often see comments in social media disparaging working in iterations. I’ve heard such comments in person at client sites in the past. Why do some people dislike iterations so much? Sometimes they talk about the high overhead of repeated planning and tracking. This makes me suspect that their planning and tracking procedures are not […]
I often see comments in social media disparaging working in iterations. I’ve heard such comments in person at client sites in the past. Why do some people dislike iterations so much? Sometimes they talk about the high overhead of repeated planning and tracking. This makes me suspect that their planning and tracking procedures are not aligned with their needs. Estimating stories is a particularly sore point. People often try to estimate with a precision much greater than they need. If you’re working in iterations, there’s really only two needs for story estimation. Have we prepared enough work to keep us going for the duration of the iteration? Are we getting ahead of ourselves and preparing too far into the future? In other words, we want to have enough work prepared that we don’t have to stop working on it to prepare more in mid-iteration, but we don’t want to prepare more than we need right now. This often gets translated to “preparing exactly the amount of work that we’ll accomplish,” which is accompanied by a lot of anxiety that we’ll miss that measure. That’s WAY TOO MUCH precision. Just try to get it “close enough.” What sort of preparation? In my experience, the important part is that we understand what we want each bit of work to accomplish. Some people get that as a by-product of estimation. I prefer to use Matt Wynne’s Example Mapping to achieve that understanding together from all appropriate points of view. I’ve also seen people upset about the other end of the iteration, anxious that they won’t accomplish exactly the amount of work that they prepared. This usually gets warped into preparing a little more than they can accomplish (not a bad thing) and then someone is disappointed they didn’t accomplish it all (which encourages safely aiming low). I’ve seen teams move to (an approximation of) Kanban just so they won’t be judged as not having delivered “enough.” When that happens, progress seems to get slower and slower. If you want to get somewhere, it’s usually worthwhile measuring your progress along the way so that you can adjust if needed. Somewhere someone has a legitimate need, and sometimes that need has a real deadline beyond which the need can no longer be fulfilled. Even if there’s not a hard cutoff, it may be that they’d gladly trade some of what they want for receiving other parts of what they want earlier. Even if you’re not working in iterations, it’s worth setting a cadence for taking stock of your progress, comparing that to current desires and expectations, and considering if you want to adjust. If you limit work-in-progress, then there is a diminishing difference between a cadence and an iteration. I’ve previously noted that there is an inverse relationship between average cycle time and a count of items completed in an iteration. It’s also worth noting that humans have long organized their activities and viewed their progress in terms of fixed time intervals: day, week, fortnight, month…. Even after people have moved their work indoors and individuals have paid less attention to the phases of the moon, they still tend to measure their work according to cycles of the sun and moon. It seems deeply ingrained and the flow of progress can be noted with simple counting rather than calculated with extraneous precision. If this topic resonates with you, you might be interested in my book, Software Estimation Without Guessing — Effective Planning in an Imperfect World on The Pragmatic Bookshelf.
Another Visualization of the Satir Change Model
Some years back I had a conversation with Bas Vodde about the graphical way that the Satir Change Model is usually represented. If you search on the internet, you’ll likely to end up at Steve Smith’s description, which is very good but shows “performance” as if it’s a measurable thing. While at the UNC Satir […]
Some years back I had a conversation with Bas Vodde about the graphical way that the Satir Change Model is usually represented. If you search on the internet, you’ll likely to end up at Steve Smith’s description, which is very good but shows “performance” as if it’s a measurable thing. While at the UNC Satir Summer Intensive workshop in 2018, I thought about a different way to view the process of change. This view is less from an external point of view, and more from the point of view of the person going through the change. Rather than a graph, it’s a map of the journey from the Old Status Quo to the New Status Quo. <img fetchpriority="high" decoding="async" width="1024" height="576" src="https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080-1024x576.png" alt="" class="wp-image-1589" srcset="https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080-1024x576.png 1024w, https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080-300x169.png 300w, https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080-768x432.png 768w, https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080-1536x864.png 1536w, https://blog.gdinwiddie.com/wp-content/uploads/2024/05/SatirChangeMap-1080.png 1920w" sizes="(max-width: 1024px) 100vw, 1024px" /> Late Status Quo Imagine you’re sitting at home, minding your own business. It may not be the life of your dreams; it may not even be without pain and annoyances, but you’re accustomed to the way things have been going. Foreign Element Then something happens that upsets the apple cart and drives you out of your recent status quo. This may be an internal event, such as deciding that your status quo isn’t good enough, but it’s most often externally triggered. Something may have happened that revealed your status quo wasn’t good enough for you any more. Something may have happened that destroyed your status quo–perhaps you were let go from your job, a loved one rejected you, or, as shown here, your house was struck by lightning and burned down with all your possessions. Chaos Whatever the cause, your accustomed routine is disrupted, and you have to do something different. Your available choices may seem unpalatable. Should you head into the deep woods, or wade through the swamps? The desire to turn around and go back to the way things were is very strong, even if impossible. At this point you may be tempted to turn back to the remains of your old status quo, no matter how uncomfortable that might be. Camping next to your charred house? That could seem preferable to pushing ahead into the unknown, even if it’s sure to lead to a depressing future. Transforming Idea If you continue to push forward through the chaos, crossing the river into new territory and climbing up the steep ridge, you’re likely to reach the Transforming Idea and lets you see the situation in a different light. In this map, the Transforming Idea is represented as a ridge line that lets you see further than you have been, and perhaps see new possibilities for the future. With a vision of a New Status Quo, you can focus on moving forward rather than back to your lost past. Practice and Integration You’re not completely out of the woods, yet. There’s still work to do before reaching that vision. You may have to learn new skills and techniques to make it possible. You need to practice those skills and integrate them into your sense of normal life. The Transforming Idea may have shown you that you need to detour to reach the place you desire. New Status Quo Finally you reach a place where your rate of change slows down and you can settle into a New Status Quo. The Practice and Integration has made this a more comfortable place to rest until the next Foreign Element propels you onward. The New Status Quo is not guaranteed to be better than the Late Status Quo, but it is different. Note that smaller changes are generally easier to accommodate. Also, more frequent changes tend to be smaller. And foreign elements that you’ve chosen are more likely to lead to an improved status quo than are externally imposed ones, if only because conscious choice tends to prefer better over worse.
I’ve been promising Mark Levison since forever to describe the highly effective card wall that evolved at one of my past clients. The team started with a simple beginning, and modified it as they saw fit to suit the needs of their situation. This is not a universal model for others to blindly copy, but […]
I’ve been promising Mark Levison since forever to describe the highly effective card wall that evolved at one of my past clients. The team started with a simple beginning, and modified it as they saw fit to suit the needs of their situation. This is not a universal model for others to blindly copy, but there is much to learn from it. No doubt that it continued to evolve beyond my knowledge, as this team spectacularly took control of their own development process. I’ll never forget the Monday morning that I walked into the team room, direct from the airport, and saw them pulling cards and tape off the corkboard wall. “What the heck are they doing?” I thought. I stood and watched from across the room as the scurried around excitedly with much conversation. Tape and cards started to go back on the wall in a different configuration. I knew then that this team was going to excel, as they were paying attention to how things were working for them and adjusting accordingly. Excel they did, and their wall was in frequent flux as long as I knew them. It’s amazing what a team can do when they have the desire and freedom to improve. New ideas on the horizon This was an IT team, and the functionality they were to build was handed down to them from executives of various departments of the business. The team included a sub-team of analysts to receive and make sense of these requests. As they came in, the names of these requests were recorded on index cards, and pinned up in the left-hand side of the wall. This area came to be known as the Nursery. These represented work that was desired by someone, but hadn’t yet been started. Seeing them on the wall kept them visible during conversations, though. Sometimes those conversations resulted in something else happening, and a card being removed. Business Analysis To the right of the Nursery was a section called Pre-School. It was here that the analysts kept track of their work as they interviewed various people in the business to turn vague requests into distinct understanding of specific needs. In a typical organization beyond a certain size, this can be a lot of work that takes considerable time, especially with the usual communication delays. This part of the wall was frequently reorganized according to their current needs and the way they thought about the work. It had started out as a timeline, with items organized by the specific iteration in which it was envisioned to be developed by the programmers. It was this version that I had seen being dismantled. They had found it too difficult to maintain this as new information was discovered, uncertainties were unearthed, and business sponsors juggled priorities. Sometimes there was a sense of progress in the analysis proceeding from left to right. Sometimes there were just groupings, when it was hard to discern how far things had progressed. Often there were swimlanes to separate different features requested by different parts of the business. Sometimes there was a feature for which a clumps of cards had been generated representing the analysis work, but had run into a snag of some sort. Perhaps the business was unable to make a decision on what precisely they wanted. Perhaps priorities had shifted further up the chain from where the request had been generated. Perhaps the business had just changed their mind about the idea. When this happened, the cards might sit there for awhile, but if the space was needed or reviving that idea seemed remote, the analysis cards were often stacked up and binder-clipped behind the title card and pinned up under the Nursery section. This got them out of the way, be easily accessible if the business desire came back. What’s described here is for IT work for in-organization “customers.” I’ve seen similar representations for product focused research on what external customers actually want and what will give the company a competitive advantage. The questions asked and the details of representation are different, of course. The important part is that, whether business analysis or product research, the people doing that work can organize tracking what they learn in the best way they can according to what makes sense to them. Final Prep for Development As high priority user stories were identified and nearly complete with analysis, they were moved to the right into the Elementary School column. This gave everyone a view of what might soon be implemented. And to the right of that were two columns, Junior High, and High School, representing what was expected to be included in the next couple development iterations. In all three of these columns, if there was something blocking progress on a story, then a “Bridge Out” icon was paper-clipped to the story card. This gave a very visible indication that there was something pretty urgent to straighten out. This might be something like a dependency on another project that had signaled their delivery date was likely to slip. As there were many services being developed waterfall fashion within the company, this was not an uncommon occurrence. If the holdup was due to insufficient information from the business, then the story, and other stories associated with it, were at risk of being postponed. Three Amigos For the stories sitting in High School, there was one more step before they were ready for development. That step was a meeting of the Three Amigos—an analyst, a programmer, and a tester—who looked at the story and made sure they had a complete, and consistent understanding of what the story involved. The analyst presented what they had learned from the business. The programmer looked at it with an eye of what was feasible given the state of the system. The tester brought up edge cases and potential errors to make sure they would be handled appropriately. Sometimes there was a fourth Amigo—the UX expert—to make sure that the chosen solution would be clear and easy for users. When they were satisfied that the story was understood and ready for development, they marked the story card with a colored dot. Only stories with that colored dot were eligible to be brought into the next iteration. Current Iteration Kanban Board Finally we reach the kanban board that Scrum teams every know and love—the current iteration. This had perhaps more columns than strictly necessary—ready for development, in development, ready for testing, in testing, ready for approval, approved—but the buffer columns didn’t hurt anything and sometimes made handoffs a little easier. The approval process was a review by the Product Owner, the highest proxy on the team for the Business. This board was called College, because when a story was finished going through College, it was Working. Tell me about your favorite tool to visualize and enable the progress of work.
For years, I’ve seen people argue online about who should and should not be invited to a retrospective. In typical consultant fashion, my answer is “It depends.” Here I want to describe the dependencies so that it’s not such a mystery. First, let’s define the basics so we have a foundation for the conversation. My […]
For years, I’ve seen people argue online about who should and should not be invited to a retrospective. In typical consultant fashion, my answer is “It depends.” Here I want to describe the dependencies so that it’s not such a mystery. First, let’s define the basics so we have a foundation for the conversation. My definition of a retrospective is Looking at the past, together To gain insights And make choices for the future. “Looking at the past, together” is what the word “retrospective” literally means. The word dates to the 17th century, and is formed from the Latin retro meaning “back,” and specere “look at.” Let’s see how this affects the question of who should attend. What are you looking back at? For a retrospective to make sense, the people involved should be looking at some shared experience. They’re unlikely to come up with insights if they’re each looking at something different. I emphasize the “together” part because I see so many teams and organizations assume that everyone saw the same things and interpreted them the same. Even for a small team working together in a common room, this is almost never true. The differences in what different people noticed, or how they interpreted what they noticed, is often the root of the most illuminating insights. The “who should be invited” question is answered by “who shares that experience.” If you invite just the programmers who are working on a project, they’ll address the things that are important to programmers, and therefore noticed by them. There may be times when this is exactly what you want. As you move to “whole team” product development, you’ll naturally want to include other members of that whole team to include other points of view—that of software testers, designers, customer researchers, and whomever else is adding value to the product. These various constituencies may be working somewhat independently, but toward a common result. The more closely these constituencies work in collaboration, the more reason for them to retrospect on the work together. If they work separately with coordination of their efforts, then retrospecting together on their coordination activities makes more sense. Each constituency won’t have much visibility into the workings within the others. Of course, they might gain the insight that their work together might be more effective if they collaborate instead of coordinate, and that would change things. Usually this question come up in terms of whether the manager or the product owner should be invited. There again, it depends on the working relationship. I’ve seen product owners who collaborate very closely with the team building the product, especially if things like customer research and user testing are done within that team. These would naturally be part of the same retrospective. I’ve seen other product owners who “throw requirements over the wall” to the team working on the product, and show up again to receive the finished work. These would likely interfere with the effectiveness of a team retrospective. They won’t share enough commonality with the team, and likely have a difference in power status that would inhibit others from speaking freely at the retrospective. The same it true for managers. The important question is do they collaborate well, or do they use their positional power to get what they want. In cases where it’s not clear, I suggest having retrospectives both with and without the “more powerful” position in question. You may find that they are both valuable, but the insights and decisions made are on very different levels. In the same way, you might find that it’s sometimes worthwhile to have retrospectives of even larger communities within the endeavor—whole departments, divisions, or even the whole organization. They will uncover different things than a team retrospective, but that has value, also. Now, look at your own situation. Are there people being included that inhibit more detailed insights into the work? Perhaps try a retrospective without them. Are there viewpoints missing that would be valuable to address some perceived problems? Try a retrospect including them. This doesn’t mean you have to give up the retrospectives that you’ve been having. That’s a decision for later. For now, try it and see how it works for you.
The other day, GeePaw Hill mentioned on Mastodon “inline-jiggle-extract” is a coding pattern that needs describing.If I were a better person, I would write that up. https://mastodon.social/@GeePawHill/110262262154288983 As it happened, I’d recently talked about that pattern on LinkedIn I found the sequence of inline, re-order statements, extract to be one of my favorite refactoring arpeggios. […]
The other day, GeePaw Hill mentioned on Mastodon “inline-jiggle-extract” is a coding pattern that needs describing. If I were a better person, I would write that up. https://mastodon.social/@GeePawHill/110262262154288983 As it happened, I’d recently talked about that pattern on LinkedIn I found the sequence of inline, re-order statements, extract to be one of my favorite refactoring arpeggios. https://www.linkedin.com/feed/update/urn:li:activity:7055994041762508800?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7055994041762508800%2C7056048897181241345%29 Jeff Grigg chimed in with his concurrence Dittos! I’ve never really thought this needed to be described separately, given that combining Refactoring patterns is common. [Isn’t it?!?] I look at the callers to a method and think, “This isn’t quite right. There’s still duplication among the callers, the parameters aren’t quite right, (etc…). So I – Inline – Adjust a bit – Extract – (And usually adjust a bit to “clean up” after.) https://mastodon.social/@JeffGrigg/110262321232963245 One of the big benefits of this sequence is that it encourages thinking about the concepts instantiated in code, and honing those concepts to be more appropriate to the domain under construction. This addresses the “technical debt” as originally described by Ward Cunningham by making the code more closely follow the concepts needed by the domain. Another benefit is that editing the code becomes less about typing characters or lines of code, but about expressing the concepts important to the task at hand. I’m certain that this practice of editing at a higher level of abstraction is part of the reason that I became more productive when I started practicing Test Driven Development. Certainly it is responsible for TDD making me a better Object-Oriented programmer.
Has it ever seemed to you that you’ve been here before? Have you ever gotten that sense of deja vu that the situation around you is completely familiar, even though some of the details are different? I have a motto: “When some behavior persists, a feedback cycle exists.” What does that mean? When W. Edwards […]
Has it ever seemed to you that you’ve been here before? Have you ever gotten that sense of deja vu that the situation around you is completely familiar, even though some of the details are different? I have a motto: “When some behavior persists, a feedback cycle exists.” What does that mean? When W. Edwards Deming said “A bad system will beat a good person every time” he meant that it doesn’t matter if you’ve got good intentions and work hard if the system is designed to produce bad outcomes. What I mean is that when a system repeatedly produces certain outcomes, it’s a signal that the system is designed to do so. That doesn’t mean that someone intentionally designed the system for bad outcomes. I’m talking about the de facto design—the one we happen to have. In a complex system, there are lots of effects going on that we can’t predict, or even easily observe. And any system made up of people in inherently complex. Perhaps someone did try to design the system to produce desired outcomes. The mere fact that they called it “designing the system” rather than “growing the system” signals that they were assuming the problem was merely complicated rather than complex. Complex systems have all sorts of non-linearities and unintended side-effects. Complex systems also have extraordinary staying power if they’ve survived at all. They have feedback loops where some the increase of some observable behavior either inhibit or promote some other behaviors. Each of those behaviors, in turn, inhibits or promotes others, and so on, until we have a behavior that either inhibits or promotes the one we started with. If the number of inhibiting influences in the circle is an even number, then they “cancel out” and the result is that our starting behavior promotes itself. That’s what makes it impossible to change the behavior by “trying harder.” Instead, we have to change the system. Changing the system is not an easy thing. Again, you can’t go to the drawing board, draw the system you think you’d like to have, and “make it so.” It’s a complex system, not a complicated mechanistic one. Nor is it likely feasible to break an existing influence of one behavior on another. The system is maintaining that status quo by its design. Complex systems adapt themselves to produce the results that they are producing. (There are also many other influences going on than the ones we’ve been able to identify.) The best approach I know is to try to introduce new paths of behavioral influence that counteract some of the existing ones. Looking at the patterns of influence that we can observe and intuit will give us some hints on where we might introduce these. The proof is in the pudding, however. We can’t be sure that we’ll get the outcomes we want. We have to try things and see what results we get. If the results are going in the direction you want, then perhaps doing more of that will move it further in that direction. If not, then perhaps we should try something else. In Cynefin terms, we probe the system by trying something, sense how the system responds to that probe, and respond by amplifying this probe and/or adjusting our next probe. It’s not easy, but anything less can only succeed by chance.
Optimization of Human Systems is a Fool’s Errand
Michael James is on a rant against Agile Coaching as it often appears to be practiced, but what he describes doesn’t sound much better, to me. Michael describes Agile Coaching as “push[ing] processes and ways of working on teams,” and “trying to ‘change management culture.'” He suggests “starting with a clear system optimization goal stated […]
Michael James is on a rant against Agile Coaching as it often appears to be practiced, but what he describes doesn’t sound much better, to me. Michael describes Agile Coaching as “push[ing] processes and ways of working on teams,” and “trying to ‘change management culture.'” He suggests “starting with a clear system optimization goal stated again and again from upper management.” Never mind that this, itself, is an example of trying to change management culture, assuming that’s not what they’re already doing. A Clear System Optimization Goal The part that worries me is that a “clear system optimization goal” implies that “better” can be described as optimizing along one dimension. The very word “optimization” implies that there exists an optimal outcome or organization. Optimal from the point of view of whom? For what purpose? Such a goal sets a target that, as Deming alluded, people would meet at the expense of destroying the enterprise. In truth, there are many aspects that we care about. Some of those aspects may be valued widely through the organization, and other aspects by only a few. While there may be trade-offs between these aspects, it’s unhealthy that any single aspect take precedence over all others. Profitability? Would you give up the lives of the employees for that? Or the survival of the organization? In a related article, Michael suggests the system optimization goal of the “organization’s ability to respond to change.” Maximizing this at the expense of all other measures, however, would result in an under-damped system with little or no stability. I’ve seen organizations chase whatever is the latest request made of them, and the result is disheartening. While being adaptable is a great strategy, it only maintains its value if it’s accompanied by enough stability to preserve what you’ve already achieved for as long as you need it. Whose Point of View? Given that Michael mentions the “system optimization goal stated again and again from upper management,” he clearly has in mind that the choice of goal is solely the prerogative of upper management. Once the “brains” at the top of the hierarchy has made a decision, the “brawn” supporting it has merely to implement that decision. While this point of view makes it easier to sell consulting services to top management, it doesn’t help the organization. Instead, it creates a single point of failure. Each person in the organization has their own set of values and priorities. There is power in all of those sets being coherent to some degree, and pointing mostly in the same general direction. There is danger, though, in trying to make them absolutely aligned in lockstep, or in ignoring those that are not. No one point of view is reliably “right,” even for the person holding that point of view. Every point of view overlooks or dismisses something of value to someone else. If we’re trying to broadly meet the needs of individuals, subsystems within the organization, and the organization itself, there is strength in the diversity of disagreement and the redundancy of agreement. No, this will not provide an optimal solution for any one point of view, but it can provide a reasonably good solution for the bulk of those involved. We can improve on that if we take some care to intentionally look out for those whose needs are being systematically overlooked. All Of This Is Hard Work All of this is hard work. There is no rote process that can ensure success. People have to weigh the intangibles, and they need to revisit the questions they have to course correct both intent and implementation. There are a number of cognitive biases that describe how people get stuck seeing only part of the view, and consistently overlooking other parts. In a large organization, those things “stated again and again from upper management” tend to align the blind spots of people within the organization. One of the big values of external consultants and coaches is that they come in without those particular blind spots, though they certainly have others. Coaching Coaching is not as completely directionless, as the statement, “pure coaching is a legitimate profession with no agenda,” would imply. This is a view that organizations selling coaching certifications seem to be pushing. It’s true that the coach’s agenda should not override the clients, but if no directional nudging were needed, then the ELIZA program from the mid-1960s would suffice. Rogerian counseling, which I studied in the early 1970s, can take a long time, perhaps approaching infinite, to converge on something helpful for the client. Effective coaching needs to be helpful in a shorter time frame than that. Sometimes the client can be helped to reframe their situation so that it looks different to them, and perhaps triggers some different responses. Sometimes the client is missing some information, and providing that information will help them. Sometimes the client benefits from being “pushed” to consider more options than they have so far. Deciding to provide a reframe, some information, or prompt continuing the search for options all betray an agenda of the coach. The underlying agenda is to be helpful to the client rather than neutral or destructive. When you’re coaching a group of people who interact with each other, it gets more interesting still. I say coaching teams and organizations is fundamentally different from coaching individuals. I find much of the difference lies in helping people become more aware of the patterns of their interactions, but there is more than that. I still struggle to articulate team and organizational coaching clearly enough to describe it succinctly to others. I can often sense places where it’s likely to be productive to probe the system and see how it responds. This gives me, and the client organization, more information about the complex pattern of interactions within it. That awareness can help the organization adjust itself and try to move in a beneficial direction, keeping an alert eye for any detrimental side-effects. Iterative Improvement This is an error-prone process, and needs to be done gradually and cautiously to avoid damage. It’s more a matter of iteratively growing into the organization we’d like to see than it is of designing and implementing that organization. Organizations made of people are far too complex to be fully understood, much less designed from scratch. Yes, it’s quite different from what is often termed Agile Coaching or Organizational Design, neither of which is likely to “just make everything better.” Too often both of these take a mechanistic approach, assuming that they can install the right solution. That assumption indicates people are trying to operate in the Cynefin Complicated Domain rather than the Complex Domain. It’s that insufficient respect for the complexity of human systems that makes them fail to provide much help. The best practitioners of both have a sense of the subtleties and are able to help their clients, sometimes in deep fundamental ways. This requires exploring the reinforcing and the balancing feedback loops in the organization, as well as being alert to the unexpected effects of relationships that aren’t visible to you. Conclusion The titles Agile Coach and Organizational Design Consultant are not the problem. Those who are bearing those titles but practicing with insufficient understanding and skill are a problem, but they can also improve iteratively. There is no Optimal Coaching or Consulting. It’s all a process of doing and learning and getting better. There is no finish line.
Imagine you work for a company that produces a videoconferencing system. You’ve done pretty well with it, but you’re middle of the pack of competition. Then there’s a worldwide pandemic, and the market for videoconference software explodes. There’s a silver lining in this terrible event. A rising tide lifts all boats, right? Maybe not, if […]
Imagine you work for a company that produces a videoconferencing system. You’ve done pretty well with it, but you’re middle of the pack of competition. Then there’s a worldwide pandemic, and the market for videoconference software explodes. There’s a silver lining in this terrible event. A rising tide lifts all boats, right? Maybe not, if the competition has more of what the customers want. It’s critical to remain a viable choice in the eyes of customers. The VP of Marketing says, “We can’t compete. We we need a breakout rooms feature.” “Why do we need that?” “Our competitors have it, and we’re losing sales.” “What do people use breakout rooms for?” “I don’t know. Just build it.” So, a new feature, Breakout Rooms, is added to the product backlog. It’s a Feature because it’s a named part of the product rather than a capability the product gives to the customer. It’s a noun, not a verb. If you were selling this product in a box in the grocery store, you might add a banner across the top corner saying “Now with Breakout Rooms!” The VP of Product looks at the updated backlog and asks “What are Breakout Rooms?” “They’re separate workspaces where some of the participants can work separately from the rest.” “How are they used?” “There seem to be a number of different ways. Just among ourselves and our friends, we’ve come up with a short list.” A meeting facilitator may want to break up a meeting into separate subtopics and assign people to each. A meeting facilitator may want to have small-group discussions so that everyone gets a chance to contribute without it taking an undue length of time. A meeting facilitator may want people to work with intermittent ongoing support from a small group within the context of a larger exercise. A meeting may divide into multiple topics, and the facilitator wants to let participants self-select which topic interests them. During meeting breaks, people may want to have “hallway conversations” with others, but without the burden of everybody being in one conversation. “Ok, those are a good start on stories. Let’s put them in the backlog. Also add a ‘Minimum Viable Breakout Rooms,’ which will be the jumping off point for any of these stories. Now, where can we do user research on these different needs?” These are Big Stories. Some people call them Epics, but I think that’s too grand a name. Allen Holub recommended calling them Fuzzy Stories, because they’re not well understood, yet. That’s true, too. Big Fuzzy Stories are good enough for early planning. Notice that these stories defined in terms of functionality—what people want to do. We may give them names to talk more conveniently about them, but they have more in common with verbs than nouns. Since they’re fuzzy, we might name them based on the situations where they seem important. Let’s call them Assigned Subtopics, Small Group Discussions, Persistent Support Groups, Self-Selected Topics, and Hallway Conversations so we remember our intention for them. These names cover a bit more than the functionality, itself. The names also hint at the context in which we’re considering the functionality. These particular stories seem to have a lot in common in terms of functionality, which is what prompted the thought of a “Minimum Viable Breakout Room.” And none of them seem particularly larger or smaller than the others—at least not as far as we currently know. Research with actual and potential customers may tell us differently. For now, though, we can work with our imperfect understanding. Looking at a bigger picture, we might categorize this work within a larger theme. We might call that theme Facilitation Tools since these stories are all variations of things that a meeting facilitator might want in different situations. I can imagine having other themes, such as Participant Experience focused on making it easy for those not facilitating, Historical Record that covers recordings and saving other artifacts to review later, and Scaling to consider the efficiencies needed to host larger meetings. While we gain more knowledge about specific needs in these areas, and perhaps uncover more, we can start working on the Minimum Viable Breakout Rooms. We might use Example Mapping to slice this Big Fuzzy Story into small slices of functionality for implementation, each with identified scenarios that the system can perform when the slice is completed. <img decoding="async" width="1024" height="791" src="http://blog.gdinwiddie.com/wp-content/uploads/2020/05/Breakout-Room-Example-Mapping-1024x791.png" alt="Example Map of the Minimum Viable Breakout Room story." class="wp-image-1364" srcset="https://blog.gdinwiddie.com/wp-content/uploads/2020/05/Breakout-Room-Example-Mapping-1024x791.png 1024w, https://blog.gdinwiddie.com/wp-content/uploads/2020/05/Breakout-Room-Example-Mapping-300x232.png 300w, https://blog.gdinwiddie.com/wp-content/uploads/2020/05/Breakout-Room-Example-Mapping-150x116.png 150w, https://blog.gdinwiddie.com/wp-content/uploads/2020/05/Breakout-Room-Example-Mapping-768x593.png 768w, https://blog.gdinwiddie.com/wp-content/uploads/2020/05/Breakout-Room-Example-Mapping-1536x1187.png 1536w, https://blog.gdinwiddie.com/wp-content/uploads/2020/05/Breakout-Room-Example-Mapping.png 1650w" sizes="(max-width: 1024px) 100vw, 1024px" /> It seems that Minimum Viable Breakout Room is pretty big and fuzzy, also. We have a number of questions, and that clearly indicates fuzziness. The bigness is indicated by the considerable number of rules and examples we’ve identified. In fact, it was hard to stop at this point, and not create more rules and examples for them. We’re excited to build this new feature! But we also want to guide what we build based on a more complete understanding of customer needs. At the moment, we’re just trying to get started building some of the primitives that we “know” this story will need. Let’s split this story up into smaller, more focused development stories. One common method of splitting is by “business rule,” which are the blue cards. We could turn this into 5 development stories without thinking about it. But now that I think about it, I think I’d like to combine the first two rules into one story. Why? Because I think there’s some synergy between them. And I don’t want the isolation between rooms to be dependent on some magic of people being placed in them. That’s just a hunch. And the “Closing and Reopening” rule–it seems like there may be a lot there that we’ll discover in your user research. We were having a hard time cutting off new ideas, and perhaps this one is a “nice to have” that isn’t needed for “minimum viable.” So let’s put that one aside as a possible future story and make three story cards for development: Room Isolation, Room Create/Delete, and Room Name. If you’re doing Scrum, you would use these for your Sprint Backlog Items. Stepping back, we see a hierarchy of Themes Features Big Stories Development Stories Business Rules Examples or Scenarios These aren’t a strict hierarchy. You may find exceptions where some levels don’t seem to apply. That’s OK. The nomenclature is there to help you do the work, not control you and prevent your from doing what seems appropriate.
As I write this, much of the world is in a state of disarray. Many businesses are shut down for fear of spreading the Covid-19 virus, and others have suddenly switched to distributed work over the internet. Most software developers are working in physical isolation. Even those accustomed to working remotely are reporting that the […]
As I write this, much of the world is in a state of disarray. Many businesses are shut down for fear of spreading the Covid-19 virus, and others have suddenly switched to distributed work over the internet. Most software developers are working in physical isolation. Even those accustomed to working remotely are reporting that the current situation is affecting their ability to get things done. I think it is safe to say that no software development organization expected this to happen. No IT department accounted for the disruption in their estimates and plans. While epidemiologists could predict that there would eventually be a worldwide pandemic, even they could not predict the severity or timing of such a disruption. How has this affected your work? Are you still expecting to meet the plans made before this happened? Have you given up planning altogether, just trying to get something, anything, done? Or have you looked at how things have been progressing in the last 2 or 3 months and adjusted your expectations? The unexpected happens in smaller, less noticeable ways, all the time. I’m amazed when I see otherwise Agile development shops estimate all the user stories they think will constitute a software release, plan dates on those estimates, and expect to hold that steady as if they won’t learn anything while implementing those stories. Others have been dismayed by such behavior, and call for bypassing planning and just working on what seems valuable at the moment. I can’t imagine keeping a company successful without reasoning about potential future events. In fact, I think that’s so important that I recommend revisiting this on an ongoing basis. Sure, estimate what’s needed to meet your goals, though I might do it on a higher level than user stories. Make plans based on those estimates, but include contingency buffers in your plans for the unexpected. Measure your progress along the way. When your progress doesn’t meet your expectations, don’t get out the buggy whip to speed things up. Instead, examine what assumptions were in your estimates and plans. Obviously there’s something going on that you didn’t expect. You can learn from that difference, and adjust your plans to accommodate what you’ve just learned. If this is helpful to you, you might find value in my book, Software Estimation Without Guessing: Effective Planning in an Imperfect World. You can find the ebook on the Pragmatic Programmer’s website or the paper book through Amazon or your favorite bookstore.
It’s been awhile since I’ve done much coding. That’s not my day job anymore, and I lose interest working by myself. In the past week, however, I’ve had a couple opportunities to mob program remotely with the Canton Coders. With the COVID-19 restrictions on gathering in person, people are much more likely to work with […]
It’s been awhile since I’ve done much coding. That’s not my day job anymore, and I lose interest working by myself. In the past week, however, I’ve had a couple opportunities to mob program remotely with the Canton Coders. With the COVID-19 restrictions on gathering in person, people are much more likely to work with you virtually. So last week I found myself mobbing on the Roman Numeral kata and today on the Zeckendorf kata, both on cyber-dojo. A lot of fun was had by all, and I rediscovered what I know about Test Driven Development with a bit more clarity. Both of these katas involve converting base-10 numbers to some other representation. It’s a natural assumption to start with 1 and work your way upwards. This can make your work harder than it needs to be. It becomes even harder if you start with an error condition. Looking for the Roman numeral equivalent of a null did not help us move the code in the right direction. Handle the happy path first, to get the code designed for its utility, and then add the error conditions that make sense. We quickly decided it made more sense to use an integer parameter, which couldn’t be null, anyway. Beyond that, ordering the test cases in numerical sequence of the calling parameter will ask you to take some bigger steps than is necessary. Bigger steps provide bigger windows for errors, and reduce your flow. In the Roman Numeral kata, starting with inputs 1, 2, and 3 is OK. For 1, the simplest path to a green bar is to “return 1.” The 2 case begs for an “if” statement. The 3 strongly suggests refactoring to avoid a long list of “if” statements. So far, so good. The 4 case, however, takes a big leap. It introduces a new output symbol, “V,” and a new concept, out-of-order symbols to represent subtraction. That’s a lot to do all at once. We skipped that for a moment, and did 5 and 6, first. The case of 6 develops the need to consume one character and then work on the next. Then we went back to 4. I think that was premature. We hadn’t yet developed looping on any symbol other than “I,” so generalizing that and using a table of symbols didn’t come naturally. In retrospect, I think it would be wiser to do 1, 2, 3, 5, 6, 10, 20 to advance the looping over one symbol to more than the “I” symbol. We might want to check things with something like 28, but that would drive the algorithm further. I’d rather continue with 4, 9, 14 to introduce the subtractive characteristic. The key is to think about the next smallest step in developing the algorithm rather than the next smallest step in the input. Of course, if you get it wrong, things are not lost. It just takes a little longer.