Over the years Voltage Control has hosted various Liberating Structures immersion workshops. We hold these workshops as part of a series of Liberating Structures immersion workshops with a focus on scrum masters, agile coaches, and technology leaders. In this post, we’ll take you through what liberating structures are and how we ran a liberating structures immersion workshop in the past. Through our workshops, you will learn the principles behind why Liberating Structures work and experience specific structures that will allow you to tap into the room intelligence no matter how large the team. 

Our next Liberating Structures immersion workshop is scheduled for December 2021 – learn more and sign up here. We are also holding a mini-workshop on Liberating Structures foundations in November.

“It’s so fun to see people from a super wide range of domains connecting to one another and beginning to realize what’s possible if they begin to use Liberating Structures in their work all the time. New ways of working together really begin to open up and you can see how enlivened our everyday work can be.” — Anna Jackson, Liberating Structures Workshop Leader

What are Liberating Structures?

Let’s review Liberating Structures first. Liberating Structures is a framework created by Henri Lipmanowicz and Keith McCandless, intended to promote powerful ways to collaborate and engage everyone within a team and boost collaborative team interactions. Liberating Structures consists of 33 microstructures, which are a collection of exercises that allow you to unleash and involve everyone in a group. They provide simple rules that make participatory decision-making easier and are a solution to the dysfunctional format of most meetings, or what Lipmanowicz and McCandless refer to as “conventional microstructures.”

Conventional meeting microstructures are either too inhibiting (i.e. status reports/updates, managed discussions, presentations), or too loose and disorganized (i.e. open discussion and brainstorming). They often limit participation and the control is isolated to one individual or a select few–often the extroverted participants in the group. As a result, these conventional microstructures can routinely stifle inclusion and/or engagement. The Liberating Structures framework is built to encourage participation by including all team members–whether teams are in person, work in a virtual environment, or a hybrid one. 

Liberating Structures Immersion Workshop

A couple of years ago Voltage Control co-hosted a 2-day Liberating Structures immersion workshop with Anna at Native, an Austin modern hostel, kitchen, and bar. Liberating Structures had been quickly gaining popularity among the agile coach and scrum masters communities. In addition to Anna’s typical audience of health care, nonprofits, and government we thought it would be great to include these people from the technology world. While not exclusive to them, we designed with them in mind to ensure they would find exceptional value in the workshop.

We also brought in Amanda Bowman, a Liberating Structures practitioner that has extensive experience leading workshops with Anna, to assist in leading the workshop. Like Anna, Amanda is a skilled graphic recorder. They took turns illustrating as we all facilitated individual methods. Adding the visualization always makes an event more engaging and memorable.

The design team used Purpose to Practice, Liberating Structures Principles, and Design Storyboarding to guide our workshop structure. We met four times before the workshop to plan and prepare for the day.

Amanda kicked off day 1 with an Impromptu Networking followed by Douglas facilitating Appreciative Interviews and we wrapped the day with a tour of the Liberating Structures Principles. Day 2 started with Anna facilitating spiral journal and finished the day with everyone’s favorite, 25–10 Crowdsourcing. We also covered TRIZ, Discovery and Action Dialog, Conversation Cafe/What, So What, Now What, Troika, and Open Space led by Anna; 9 Whys, Design 101, What I Need From You led by Amanda; Ecocycle Planning and Critical Uncertainties led by Douglas.

Voltage Control feels strongly that Liberating Structures has an approach to address almost any challenge you may have to overcome. Therefore, we created a suite of free and interactive Liberating Structures templates for MURAL and Miro for the activities we use most often and hope you enjoy using them as much as we do.

During the workshop, Douglas facilitated the strategic methods. Strategic methods are exceptionally well-suited for technology companies or anyone that may face potential disruption. 

Critical Uncertainties and Ecocycle Planning are two of the more robust strategic planning tools in the Liberating Structures repertoire.

Critical Uncertainties

Critical Uncertainties is a tool that helps you to assess the ability of current strategies and build an ability to respond to changes in the future. First, you consider all of the critical and uncertain factors that you are currently facing or may face in the future. From this list, you’ll select the two most important and place them each on an x- & y-axis.

Once you have drawn your matrix, it is helpful to name and describe each quadrant. Once you’ve considered each quadrant, you can then begin to explore each quadrant to determine strategies that may work in those scenarios.

After working on each quadrant, go back and review all your strategies. Consider which strategies are hedging strategies and only work in a specific scenario or prepare you for those conditions and which strategies are robust strategies and will work in all or most situations?

This structure does not help you generate a plan. It is a tool for developing your strategic thinking and building the capacity to respond to and anticipate changes in your environment proactively.

Critical Uncertainties is a great fit for exploring what features to include in your product, planning and preparing for multi-country IT implementations, and executives creating or refining a 10-year strategic vision.

“The workshop helped me learn and practice some of the LS tools. I now understand enough to read about the other tools and apply them as well” — Michael Smith, Director of Orquestando

Ecocycle Planning

Ecocycle Planning helps you to contextualize aspects of the system that you are operating and allows you to scan for bottlenecks objectively. An Ecocycle is drawn as an infinity symbol with four phases and two traps identified. These phases help you to determine where various components of your systems or products in your portfolio exist within the ecosystem lifecycle. The four phases are birth, maturity, creative destruction, and renewal. The two traps are the rigidity trap and the poverty trap. The Ecocycle is a continuous loop and activities and projects can exist in one place on the map and quickly shift to another.

The front half of the loop, birth & maturity is how we typically think of projects. The back of the loop, creative destruction, and renewal, is often new to people. This is an important opportunity for teams to expand how they think of their portfolio or system. Activities can also exit the loop if you decide to end them. The two traps are also an opportunity for series exploration. We find ourselves in the rigidity trap when activity in maturity has become ineffective and we haven’t made requisite changes. Projects live in the poverty trap when we discover opportunities for re-birth and are not investing in the change.

Ecocycle is effective at prioritizing a backlog, balancing a product portfolio, discovering resources that can be repurposed, stepping back, and shedding light on situations where killing one project allows you to proceed on another.

When running an Ecocycle internally, you’ll invite your team to begin by listing out projects and initiatives that occupy their time. Then you’ll organize into groups of four and explore the placement of these activities onto the Ecocycle. After everyone has finished plotting on the Ecocycle, everyone shares and explores areas where there is a lack of consensus. Finally, the group discusses the next steps how they might respond to insights from the Ecocycle.

During the workshop, Douglas asked participants to consider various Facebook products and services and where they fall on the Ecocycle. He encouraged them to think of themselves as part of a focus group, and Facebook is asking them: “As a Facebook user, where do these features and capabilities live on the Ecocycle?” The following Facebook services were explored: Groups, Events, Messenger, Dating, Newsfeed, Security + Privacy, and Facebook Live.

“I found the strategies and techniques provided by the LS methods to be ideal for the groups where there are frequently power differences amongst participants. The LS methods substantially reduce that differential “— Andres Guariguata, LCSW

The Value of Liberating Structures

Liberating Structures have many useful applications in the innovation world, such as for Scrum or a Retrospective. Liberating Structures don’t need to be practiced in person – in fact, Liberating Structures are more important now than ever in today’s virtual environment and are great for optimal remote team communication. For more information on when to use Liberating Structures and solutions on using the best Liberating Structure for the job, download our guide here. 

For additional information and ways to use Liberating Structures, check out our Liberating Structures course where you will learn key Liberating Structures principles, practice 5 key design methods, chart a plan for further application of Liberating Structures and connect with a Liberating Structures community. You can also learn hands-on in real-time at one of our Liberating Structures workshops as discussed in this article: a deep-dive of Liberating Structures, when, and how to use them to unleash creativity in your meetings through maximum participation. And, as an extra bonus, you’ll also learn how to do this virtually!

The post Liberating Structures Immersion Workshop appeared first on Voltage Control.

When Sonja Kresojevic was hired at Pearson, she led digital transformation for the international part of their business. After a year, she was promoted and joined the Global Product Office to focus on driving change globally across the whole business. In this role, Sonja was a key part of the design and implementation of the award-winning Global Product Lifecycle program, which focused on transforming product development and delivering a faster and more entrepreneurial-focused organization.

During her years managing products, Sonja noticed that, just as companies deploy agile or lean startup practices to build products, the same principles can be applied in a broader organizational context. “I always see myself more as a practitioner than as a consultant, so my work is inspired by what I learned building products,” she says. Armed with this strategy, she sought to figure out how to apply such principles to transform an entire organization.

At first, Sonja encountered some resistance while trying to implement broad system changes at Pearson. “People’s reaction was often ‘This won’t work here’” she says. “However, this led to us focusing on bringing people on the journey and working to co-design solutions. We enabled them to deliver things that were important to their success and built strong communities of practice to enable learning at scale.”

Empathy and listening was key to the process. Her team invested time bringing stakeholders into the process, through town halls and workshops. She also found that words like “agile” and “lean” were scaring them off, so she listened to their struggles empathically and changed her messaging to help them solve the problem. Gradually internal and external stakeholders became involved and got on board.

Embrace flexibility

One of her main takeaways from this experience was that a process shouldn’t be followed just for the process’s sake. She didn’t approach restructuring Pearson from a perspective of merely implementing lean startup. Instead, she noted the significant issues that needed to be addressed and set out to work to solve them with the organization. Sonja shunned dogma for flexibility, pivoting when encountering obstacles rather than throwing her hands up and deciding things were not working.

The life cycle process was one part of the plan. Still, the company quickly realized that it was just one of the components of a much bigger program that involved how they behaved, how they acted as leaders, how they managed the organization, and how they made decisions regarding systems, tools, culture, and incentives. Sonja believes that even inside large organizations, it is possible to get teams to work and behave differently, applying agile principles and convincing people that value creation should be what drives the organization forward.

“I was very much of the mindset that we don’t have all the answers,” says Sonja, “and that it’s more fun to collaborate with people and to build that momentum through the internal and external community, and expose people to some interesting stuff that was happening elsewhere.”

After 20 years in the corporate world, Sonja passionately believed in her ability to instill change in large organizations but also learned that she was somewhat lonely doing it. She says that, if you talk to other people trying to change large organizations, they’re often going to tell you it’s the loneliest job in the world. You go against a brick wall every single day.

“What I had to do was work hard on myself. To figure out what is it that I want to do next, where do I see myself, how do I contribute to the world differently? I realized that the key is in me, and changing myself, and showing up differently for other people, and not separating my personal from my professional life, because I am one person, and I need to share who I am with the world. I cannot be one person at home and another in the workplace.”

For Sonja, it is of utmost importance to empower the whole organization to enable significant and successful change.

Upon leaving Pearson, Sonja became a strategist and created her consulting firm, Spinnaker Co. She regularly speaks on topics of transformation, business agility, leadership, innovation strategy, and culture. In this role, she sees that innovation efforts die over time because they are not connected to strategy. CEOs usually don’t realize that if they invest more in innovation and connect that to strategy, it can save the company or transform how it works. For Sonja, it is of utmost importance to empower the whole organization to enable significant and successful change, and for innovation at scale to work.

Empower the whole organization

According to Sonja, we need to start empowering people and making some significant changes when it comes to culture, and in how we incentivize people to bring them on the transformation journey. When companies have groups that are solely targeted at innovation, but the initiative is disconnected from the strategy, it is difficult for the groups to succeed. Direction must come from an executive team making deliberate strategic decisions.

“Innovation doesn’t work in isolation,” states Sonja. “You need to know why you are trying to innovate what the strategy is. You need to start to put measures in place. You need to change the way you find not just those projects, or products, or initiatives, but beyond that, you need to start looking at the balance of your portfolio. You need to start strategically investing in core versus adjacent versus transformative. It’s not something you can just stumble upon.”

“Innovation doesn’t work in isolation. You need to know why you are trying to innovate…”

If leaders don’t show their human side to others, they’re going to struggle to get anyone to follow them, she says. The more we show the human side and reconnect with ourselves, the more we are going to be able to influence people around us and start to move the boulder in the right direction, whether it’s in societies or large companies.

“I don’t think I can influence leaders in large organizations unless I show them by example how I’m leading myself, or how I’m behaving with my friends,” she says. “I think we need to start to model those right behaviors for other people. We need to be brave enough, and we need to start to speak up and have the real conversation, instead of just the polished version of it. I think some of those softer skills, if you want, is what’s missing when you look at executive teams nowadays.”

The more we show the human side and reconnect with ourselves, the more we are going to be able to influence people around us and start to move the boulder in the right direction.

Global transformation one individual at a time

These days, Sonja talks to her clients about her evolution and transformation, humanity, and vulnerability as much as innovation or business transformation.

“Humanity needs a substantial upgrade,” she states. “I am finding myself more and more focused on the human side: whether it’s to do with all the personal changes we are all undergoing, or with how to bring communities together to facilitate change at scale. I am looking for new, innovative ways to get us working together and learning from each other.”

This belief has led Sonja to recently launch a community called the Seedtime Collective, along with co-founders Héloïse Ardley and Philip Horvath. As they describe in their site, Seedtime was “born out of our personal transformative experiences and a realization that global transformation can only happen one healed individual at the time. We believe that exposing people to transformative experiences that nurture body, mind, and soul, in a supportive and authentic community will create an environment where people can learn to trust their inner-guidance, unlock unique learnings and work together to bring a much-needed change in their communities, organizations, and society at large.”

I love the boldness of Seedtime’s vision and am looking forward to seeing the work that Sonja does there. Sonja has proven that a flexible, human-centered approach that is inclusive and honest will yield better results in bringing innovation and change, even at a large scale.

If you want to read my other articles about innovation experts and practitioners, please check them all out here.

The post Applying Agile Principles to Corporate Transformation appeared first on Voltage Control.

Heidi will be speaking at our upcoming event—Control the Room: The 1st Annual Austin Facilitator Summit! Taking place at Austin’s Capital Factory on May 23, 2019, learn more and get your tickets here.

Heidi Helfand believes that coaching is a core aspect of effective organizations where people are excited to come to work every day and create innovative solutions. After working as a writer, interaction designer, and project manager, she came to coaching when she was hired as AppFolio’s first Scrum Master. Now as the Director of Engineering Excellence at Procore, she works as an embedded coach to help staff realize the Procore promises: the pursuit of autonomy, mastery, and purpose.

As someone who was regularly involved in team-based work, Heidi wanted to understand how to improve her teamwork skills. “I’d read different books within and outside of software and one of the constant things I would always hear was the dogma that, if you want high performing, highly productive, successful teams, they have to maintain the same composition. They have to be stable.”

These team recommendations were often based on research like Bruce Tuckman’s stages of group development: forming, storming, norming, and performing. “He forgot a phase that I call stagnating, when you keep teams together for too long, the energy is low, and the people feel like they’re trapped. They need a change. Things aren’t moving.”

Reteaming

While these models are often referenced in the software world, Heidi learned that they are largely based on research done on therapy and training groups outside of technology. Heidi’s experience with product development teams didn’t match up with the accepted wisdom that successful, productive teams were ones that didn’t change. Realizing and embracing that changing teams were inevitable, Heidi was driven to uncover why her teams were able to achieve success despite the constant change.

“I conducted over 30 hours of interviews with colleagues at software companies all over the world. I coded the stories for themes, and then I wrote the book Dynamic Reteaming, which talks about five team change patterns for successful reteaming. It’s almost a study of proving the point that these teams change and there are patterns to how it happens in the wild. You can do various things to coach teams when they change and that’s my specialty.”

For years, the effectiveness of software development has been focused on the work and workflow. Everything from counting lines of code written to the number of hours remaining on a task was seen as indicators of success or productivity. Based on her research, Heidi has put the “accounting of the work” aside and chosen to focus more on helping individuals and teams pull themselves out of stagnation and get excited to come to work every day.

“When we give people the ability to choose how often they change and the topics that they work on, it can help them find that spot that is renewable.”

While the appetite for change varies from person to person, Heidi has observed that change can often serve to refresh an organization and inject a renewed sense of motivation or creativity. “Some people want more change than others. Some people prefer more of a stable situation. We have these different preferences. When we give people the ability to choose how often they change and the topics that they work on, it can help them find that spot that is renewable.”

For organizations seeking to ignite a drive toward innovation, reteaming is an approach that can foster greater creativity. But reteaming is not the solution for every situation. “I’m not saying bust your teams up and start your reorg now. I get misinterpreted for that. If you have a team and the chemistry is awesome, they’re delivering value continuously to the customers, it’s an enjoyable experience, and they feel like they’re continuously improving and motivated toward excellence, keep them together. Anytime that you embark on a deliberate reteaming, especially a large scale one, even if it’s through self-selection, it can cause a lot of fear and discomfort, so this is not to be taken lightly.”

Human-centered metrics

Heidi views coaching as one of the key components for determining opportunities for change with metrics that are geared toward the whole human rather than productivity-based data.

“I’m a big believer in engagement surveys on the individual level as well as a team level. Since the context is always changing, you can have benchmarks and check-ins with people to see how they’re doing. It’s focused on the learning and desire to be in that place that brings out the best in you.”

One tool that Heidi uses to ascertain the level of fulfillment for individuals and teams is the Employee Net Promoter Score (ENPS). She recommends asking questions like “How likely are you to recommend working at this company?” with an accompanying field to explain why the rating was chosen.

Culture Amp is a product that Heidi uses to get feedback from a large number of people, but free products like Google Survey for groups of 250 people or less are available for those willing to spend time manually processing the responses.

In the process of writing her book, Heidi interviewed Kristian Lindwall who works at Spotify. He and a colleague shared their internal process for visualizing areas of improvement through their Spotify Squad Health Check (SHC).

In an SHC, “good” and “bad” are contextualized with an “Example of Awesome” and “Example of Crappy”, and team members use a scale of red, yellow, and green to indicate where practices in each area fall in the spectrum of awesome to crappy.

Heidi has adopted the SHC approach with the addition of movement to engage different areas of the brain. “I get a group in the room. We’d have red, yellow, and green objects on the floor. People would walk to the different red, yellow, and green, and then you debrief. You foster a dialog and take notes so you can use it as a team improvement activity.”

Heidi recommends the SHC be conducted quarterly and emphasizes that the results are not for management to analyze team dynamics. Rather, the activity serves as a tool for team reflection and self-improvement.

In addition to team reflection, Heidi is an advocate for individualized coaching. “I do unscripted coaching on a one-on-one basis with people and help them by listening, asking powerful questions, and forwarding and deepening the conversation. I help people set goals for how they either want to be different in the future or what they want to do differently in the future.”

“Through listening and powerful questions…managers get better at helping the person solve their own problem as opposed to…telling them what to do.”

As a coach, Heidi works with individuals that she doesn’t manage so there can be openness without the complication of her having control over salaries and promotions. While there are advantages to dedicated coaches, coaching can also be another component of a manager’s toolkit. This approach to coaching is one that Heidi teaches in her workshops at technical conferences.

“Through listening, powerful questions, and other things I teach, these managers get better at helping the person solve their own problem as opposed to the manager telling them what to do.”

Autonomy, master, & purpose

Heidi’s definition of innovation was inspired by Daniel Pink’s book, Drive. “I equate the ability to innovate with the ability to be creative — to come up with ideas and to act on them. It’s the pursuit of new ideas through the pursuit of autonomy, mastery, and purpose.”

A key takeaway from Pink’s book was that knowledge and creative workers are not incentivized by money but instead by the pursuit of autonomy, mastery, and purpose. Inspired by Drive and a coach she knew at Atlassian, Heidi started a 24-hour hack day while working at AppFolio to inspire creative solutions for customer and company problems by giving staff “wild autonomy” to work on any project they desired.

“I’ve seen firsthand the shift in energy possible at a company when you give the people more agency.”

The hack days were set up to emulate Pink’s ideals of autonomy, mastery, and purpose. Two weeks before, everyone participates in a facilitated brainstorming session to come up with topics and prioritize them through votes. The week before the event, a marketplace reteaming event is setup during which people autonomously form teams based on what each person wants to help build.

“There was one project that was legendary called 24 fixes in 24 hours, which involved fixing bugs and UI issues that were really nagging but that never really got the time of day because they weren’t the top priority.”

In addition to the satisfaction of fixing a nagging problem, hack day participants found purpose in improving the experience of their coworkers and would sometimes get the added satisfaction of hearing from customers directly about the success of a tool.

“If you go to appfolio.com, they have a marketing website and within there you can see a webpage which is the real-time indicators of whether the system is up or down real-time monitoring. That came out of a hack day. It was an incredible experience.”

At Procore customer conferences, engineering and product teams partner with people from the construction industry through innovation labs to learn about needs and get direct feedback. “Things like this give us a connection to customers, connection with each other, and can shift the energy and motivation.”

Activities like workshops and hack days provide an opportunity for organizations to try out the idea of reteaming and self-selected teams before making a longer-term change. “When you do things where you give people the choice of topic and who they work with, you can see a different kind of energy that you might not see in the day-to-day. It leads one to believe maybe we should do something different in our day-to-day work.”

Heidi embraces the idea that giving people the freedom and choice to do what they want leads to better solutions. The value of events like hack days and innovation labs are often evident in the solutions that are created and the feedback those solutions garner. Even so, summaries are created after each event to capture what was produced and share across the company so that people at all levels of the organization can understand the value of the exercise.

“We’ve got to be responsible business people. We’re funded to do very specific things, so we have an obligation to talk about what happened and to make the time to close the loops. What happened and what did we learn?”

Agency & Open Spaces

Agency is another marker for gauging the success of a given program and is a focus for Heidi when she reflects on her own contributions. She asks herself: “How can I help others have agency? How can I help others feel like they’re pursuing whatever it is that brings out the best them every single day? Those are the people we’re gonna retain. Those are the people that are gonna want to come to work each day to work on our mission. Those are the people that you’re gonna want to work with because you see that spark in them. We’ve got to just try to ignite the spark.”

Heidi is excited by practices like open space events as a means to show individuals their own agency. She writes about an open space event at Procore and how she and her team planned the event.

“Having an event where people come together and find the shared causes that are of interest to them, can be really, really powerful.”

In an open space setting, the people who attend the event are empowered to construct the event schedule based on a common goal like improving collaboration across the organization.

“In organizations that are growing and changing and hiring really fast, you have the problem that sometimes people just don’t know each other. You’re walking around, even if you’re in the same co-located space, you don’t have the history together, you don’t really know each other. Having an event where people come together and find the shared causes that are of interest to them, can be really, really powerful.”

Experiences like open space events can help people embrace the idea that team change is inevitable and provide an opportunity to get good at it. By giving people choice and agency, organizations can provide an environment that fosters the purpose and drive that results in creative solutions for happy customers.

If you want to read my other articles about innovation experts and practitioners, please check them all out here.

The post Reteaming & Creativity in Innovation appeared first on Voltage Control.

This is part of my series on thought leaders in the innovation space. Check out the other articles here.

Murray Cantor is the co-founder and CTO of Aptage, which builds forecasting tools for agile teams. He’s known in the innovation space for his agile management techniques and exploring the economics of investing in and managing innovative endeavors. What many people don’t know is that during his time at UC Berkeley he hosted a weekly music show called The Monday Blues on KALX. The two pursuits may seem at opposite ends of the spectrum, but for Murray’s path, they have an intriguing complement.

Blues is a genre that is difficult to define. The lack of common characteristics among the various types of blues is often attributed to the fact the genre took its shape from the idiosyncrasies of individual performers. That same variability is the reality for many innovation projects as well. Goals and outcomes differ between teams or organizations and projects, and are shaped by the contributions and skillsets of individuals across departments. Murray shared with me how he found a way to measure and manage the variability for these unique projects that all fall under the umbrella of innovation.

The Pitfalls of the ‘Software Factory’

It’s not uncommon to attempt to understand a new paradigm with an existing, familiar metaphor. Many techniques employed to manage software projects to date treat the practice as, what Murray calls, “the software factory.” They assume that what works for manufacturing will translate to software. So why don’t they work?

According to Murray, software projects lack a key quality required for techniques like Six Sigma to work — consistency of artifacts. “You need to be building the same things over and over again. And then you can decide from that whether you have a controllable process. That means you really understand all the variables involved in delivering what you’re delivering.”

He offers the example of food manufacturing. In order for the manufacturing process to be controlled, manufacturers need to be aware of any variables that could impact food quality. The Six Sigma technique can determine whether there’s an unknown variable affecting a repeated process. “Software is nothing like that. Every work item, every task is something different than the last one.” Murray argues that even when you get to the most granular level of a user story or requirement, for example, each varies so greatly from the next that traditional control mechanisms are ineffective.

In the face of a perceived high rate of failure for software projects, many in the software world have sought to apply standard civil engineering techniques to correct what they believed was a crisis in software management. “The premise was that the other disciplines were better than software. The more mature disciplines had techniques.”

Novel Software Projects

Knowing there were numerous examples of failed construction and civil engineering projects, Murray was unconvinced. He conducted a little study of his own and found some conclusions that were contrary to the failure statistics plaguing software projects.

“The more novel the projects got the more unlikely it was that it was going to complete on time and meet the standard criteria — on time, on budget, original scope. That is almost impossible for a novel project. And even that criteria is probably the wrong criteria anyhow.”

Instead, he found that, if you normalized the data accounting for the amount of uncertainty in software projects, “it turns out the software was just about as good as everybody else. And the reason software seemed to fail more is that we were doing more innovative stuff than other kinds of projects.”

Techniques for Software Project Types

Murray finds that identifying the appropriate technique depends on first acknowledging that software projects come in three types.

1. Change requests or bug fixes
2. Adding new features to an existing platform
3. Building a brand new platform

For change requests and bug fixes, techniques like Lean make sense due to the minimal amount of uncertainty. “When someone hands you a change request, it’s usually pretty detailed. And the code that needs to be changed is pretty well understood.” When adding new features, “spiral development techniques where you continue to interact with the stakeholders to be sure you’re building the right thing” make sense. And when the occasional opportunity to build a brand new platform arises, modeling and prototyping techniques can be helpful. “There are a lot of organizations that don’t know how to do that, so that’s where consultants are really helpful.”

Adding new features to an existing platform is where Murray finds people run into trouble with over-planning.

“If the goal is to plan your work and work your plan, you’re going to fail. One of the insights of agile development is that you’ve got to work out granularity to the level at which you understand things. Your inability to do that is consistent with the amount of uncertainty you have.”

A good agile development practice is to first plan the epic, or high-level user story, for which you have the most knowledge. Design sprints can also be a useful tool at this stage to explore the space or run experiments to reduce uncertainty. With uncertainty reduced, work can be broken down more granularly. But even at this stage, Murray cautions against over-planning: “The idea that a story has to be framed in one sprint is not as important as the understanding that you plan at the level of your knowledge. If you can’t plan at the level you need to, you need to get more knowledge in order to do that planning.”

Thoughts on Earned Value Management

Another stumbling block in software management is the practice of earned value management (EVM) or the concept that value delivered is proportional to effort expended.

“If I have ten people working on requirements analysis, I don’t get ten times the amount of requirements analyzed. You’re actually only measuring whether you spent the money on the thing. You haven’t really measured the value you’ve gotten.”

Instead, Murray recommends an approach where the earned value is assigned to a certain milestone. “So maybe measuring requirements analysis isn’t so much whether their complete, but whether they’re stable.”

The concept of EVM can also incentivize people to complete the simpler tasks first: “We pull the low hanging fruit because, if the goal is to claim earned value rather than to increase the likeliness of project success, you do different things. If you want to increase the likelihood of project success, what you do is work on reducing the uncertainty.”

The EVM approach makes sense for projects like laying concrete or paving a road where “once those things are done, the building you have is that much more valuable because those things have been done.” But it doesn’t work for innovation projects because it pushes the most risk-laden activities to the end of the project where surprises often result in late delivery.

Ongoing Risk Analysis

Murray also sees the standard approach to risk management, rather than ongoing risk analysis, as a source of false security for software projects. “Risk management is when people sit around and imagine all the bad things that might go wrong, what the probability and impact are, and develop a risk mitigation plan. And then they put that on a shelf.” Alternatively, risk analysis is an ongoing process of leveraging new information to reduce the uncertainty of meeting a goal or measurement for a project.

“The idea is working with uncertainty and reducing uncertainty by looking at the information that we have gained is the big picture in all of this.”

Murray looks to a risk analysis perspective for measuring innovation as well. “An innovative effort begins without complete information about the best design, how much effort it will take to deliver, or even what is really required. Since there is missing information, it is impossible to make firm predictions.”

Measuring Uncertainty

For R&D projects Murray recommends measuring the amount of uncertainty in the measures that matter to the project: time, cost to delivery, predicted benefits received after delivery, return on investment, etc. He calls on his mathematics expertise to measure the uncertainty using methods from applied probability.

“The goal of having a customer delighted with what they get is going to be a probability distribution. Neither I, nor the customer, probably knows exactly what they want or could have. We’re going to learn that together.The amount of time it’s going to take to get to the goal of customer satisfaction or time to delivery is a probability distribution.” Rather than a firm prediction at the beginning of a project, Murray approaches innovation measurement as a range that is updated with greater specificity as more information is gained.

This concept also hits on Murray’s definition of innovation as something new — to the organization or the world. If there’s uncertainty about how long an endeavor is going to take and the amount of leverage required to accomplish it, this lack of information is a good indication that something is new and, thus, innovative.

“In construction if you’re building yet another strip [mall], and you’ve built 100 of them before, you can be pretty tight in your probability distribution. If you’re building the Sydney Opera House, no one’s ever built anything like that before. So it’s no surprise the ability to actually estimate how long it will take isn’t very good.”

Planning for Uncertainty

How do you structure programs around such uncertainty? The crucial first step is embracing, rather than avoiding, the uncertainty. “Too often people treat uncertainty as something to be avoided. This leads to either denial, recriminations, or the organization becomes incapable of delivering innovation.”

This is why Murray believes that standard investment models don’t make sense for innovation projects. “There’s what’s called a CAP M model for investing where they do risk adjustment with the rate of return. Those are well suited for financial instruments where the future values [are] what we buy today. And then the risk is how much that money is really worth given inflation.” The problem is the model fails when future values are based on new endeavors that are full of uncertainty.

“There is no innovation without uncertainty. A successful [innovation] program requires that all the experts and subject matter experts understand that, to be innovative, they need to embrace and manage uncertainty.”

Overlapping Uncertainties

Murray works with stakeholders and SMEs to elicit and capture uncertainties and treats future values, again, not as firm predictions but distributions. “I assemble stakeholders that include the development team management leads who know the development effort time and cost. I also include the business analysts or product management who provide the expected benefit stream and the IT and customer service leads who can project the after-delivery costs. In each case, we use their models capturing uncertainties in their parameters. Their separate interests, concerns and, especially, their uncertainties can be integrated into an overall likelihood model of the return on investment.”

As the project continues, stakeholders update their models based on new learnings about completion rates, requirements churn, and any available evidence from pre-sales and reliability testing. “The ongoing frank discussion of the residual risk results in a learning organization that can deliver novel efforts.”

“The ongoing frank discussion of the residual risk results in a learning organization that can deliver novel efforts.”

Murray’s work with a laboratory equipment company puts this approach in action. “They know that, no matter what, they’re not going to lose a certain fraction of their customers. So they know the worst case.” There is some movement in the marketplace and the company can also make estimates on how much of the market they can capture. “So now we have some models of worst case [and] likely case of the future benefits and costs. And the more innovative it is, each of those has wider distributions.” So as innovation increases so does the variability in outcomes within the worst and likely cases of future costs and benefits.

You may have guessed by now that Murray’s innovation silver bullet is reducing or quantifying uncertainty. He ascribes to Lord Kelvin’s maxim that “to measure is to know” encouraging organizations to measure the uncertainty around setting their organizational goals.

Mathematics & Innovation

His passion for applying mathematical theorems to predict innovation outcomes began at UC Berkeley where he realized that, for him, a Ph.D. in Mathematics was not about the academic math he learned but, rather, the empowerment he gained to observe the world and come up with new ways to understand it through mathematics.

Murray credits his adviser at Berkeley, the youngest faculty member to receive tenure in the Math Department at the time, for inspiring his approach to making mathematical discussions accessible to a wider audience. “When I try to explain things to people, I want them to believe that on a clear day they would have thought of it themselves. Not be impressed with me, but just be impressed that the ideas themselves are self-evident if you just step back and think about them.”

Eventually, he moved on to work with IBM on the graphics subsystem of the RISC System 3000. During his time with IBM, he developed many of his techniques of identifying and working off uncertainty, starting with the more difficult tasks first, and determining project risks through prototyping and simulations. And it was at IBM under the Rational brand that he developed his ideas around innovation outcomes as distributions rather than firm predictions.

Of Murray’s many success stories, one that he’s most proud of is his work on a satellite ground station. Mission planning and prioritization for satellite positioning is an involved process that often falls victim to over-planning. “They would plan something five years out, they would have the integration day, and whatever the pieces were that were supposed to come together never did.”

Murray observed that the various primary and subcontractors weren’t working together to identify and resolve the uncertainty of delivery. He met with stakeholders in DC and pitched the idea of incremental integrations as a means of working off uncertainty. “My first integration was just to see if I could do a sort of ‘Hello World’ test with a stubbed out version of the system architecture because then I knew the architecture would fit together in the end.”

For Murray, this project served as a proof of concept for the effectiveness of his techniques for identifying uncertainty and resolving risks early in a project.

If you want to read my other articles about innovation experts and practitioners, please check them all out here.

The post The Certainty of Uncertainty appeared first on Voltage Control.

I was first introduced to Marcus when I read his post on medium titled: “Why Your Programmers Just Want to Code”. The article was quite popular. Like many folks, I was prepared to hate this article and one I started to read it, I realized Marcus had a played a trick on me. He went on to explain that even the most customer-focused engineers can’t do so in an environment that doesn’t reward or encourage the behavior.

I invited Marcus to speak at the first annual Austin CTO Summit. His talk was a simple note card based activity that he facilitated from the stage. The premise was for everyone to write down ideas for how to improve the summit and the suggestions would be judged based on seniority and or criteria specific to each individual. His simulation demonstrated that systems like this discourage many people from sharing thoughts and stifles innovation.

I’m excited to help bring Marcus to Austin on July 16th and 17th at Capital Factory where he and his wife will lead their Technical Leadership Workshop.

Great skills are not enough

You’re part of a solid team where everyone has great skills and are passionate about their craft. You use agile, or scrum, or Kanban. You have modern tools and frameworks. Everyone’s working hard, putting in the long hours.

“My team was good, but something was getting in the way of being it great.” — Workshop Attendee

The industry is filled with success stories about great software teams. Teams that deliver amazing things with very few people, under incredible pressures. Teams that collaborate, cover for each other, and focus on providing innovative products together. What are they doing differently?

Create an environment where everyone is fully engaged

Beyond Agile. Beyond Teams. Beyond Culture. Remember how excited you were when you heard about agile? The manifesto states that “The best architectures, requirements, and designs emerge from self-organizing teams.” The scrum framework adds to that idea by stating, “Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.”

The Workshop

I’m bringing Marcus back to Austin for a 2-Day workshop focused on technical leaders. In the workshop, you will learn out to help your team perform at their best.

This is a hands-on workshop that will leave you with practical methods and solutions for improving how you and your team work together. The workshop is limited to 26 participants to guarantee an intimate and focused environment to maximize learning.

You’ll participate in engineering simulations which will challenge you and create “sticky” lessons that you’ll internalize and take back to your team.

Price: $2,099 per seat

Get Your Tickets Today

Who should attend?

• People who influence, organize, lead or manage smart technical people in order to achieve business goals.
• Tech Leads, Project Managers, CTO’s, QA Managers, Product Owners, Directors, Software Managers, ScrumMasters who want to improve leadership skills.
• Engineers, Programmers, Testers, and Architects who want to help their teams work better from the inside.

Day 1

[AM] Navigating Change and Learning

• Learn the difference between leading and managing
• Understand why change is hard, and how to help your team navigate it
• Uncover how to introduce self-forming project teams to your organization
• Use the Piaget learning cycle to build personal and team improvements
• Connect hands-on design exercises to real-world situations

“The debrief following each exercise provided ample opportunity for deep thinking about how we approach team dynamics, leadership, communication, etc. within our organizations.” — Workshop Attendee

[PM] Building A Productive Team Environment

• Learn the MOI(J) model of leadership
• Put your team’s ideas into practice in the real-world
• Hone your observation and feedback skills
• Improve your retrospective and structured debriefing skills

“The program revealed traits I want to avoid as a leader.” — Workshop Attendee

Day 2

[AM] Improve Communication about Requirements and Design

• Observe the impact of time pressure on technical communications
• Improve communication about complex technical tasks
• Understand the cost of assimilating new members into a team
• Identify real-world areas of improvement for your team’s communication practice

“I gained insight into what might demotivate people.” — Workshop Attendee

[PM] Removing Silos and Low-Bandwidth Communication

• Improve communication with remote engineers
• Understand the role of conversation in communication
• Observe the effects of silos on team motivation
• Observe the effects of Management by Walking Around
• Build proficiency in leading through asking, rather than telling

“Seeing the Satir change curve really helped me recognize that the feelings I had against change were something that affected everyone, even if there is a little difference between each of our experiences.” — Workshop Attendee

Space is Precious

This unique, hands-on workshop is held in small venues where the facilitators constantly interact alongside participants during the workshop.

Each workshop is limited to only 26 participants to ensure everyone has the best experience possible. These workshops fill up fast, so register today.

“You Gotta Love It” Guarantee

All of Marcus’ workshops offer a “You Gotta Love It” 100% money back guarantee. If you attend and feel the workshop was a waste of your money and time, they will issue a full refund, no questions asked. If you’re not happy, we don’t get paid. It’s as simple as that.

“I continue to work one-on-one with Marcus to this day, and I hope I will always be able to lean on him and dialog about challenges He is worth way more than you can ever pay him.” — Andrew Coven, Senior Director of Platform Engineering, Box.com

About the Facilitators

Their goal is to revolutionize the world of work for engineers and those who lead them. They believe that every engineer deserves a good boss, and that any engineer can become one. They stand apart from those who preach that “Leaders are born, not made”, proudly helping great coders become great leaders.

When you sign-up you they meet them, Marcus and Amy. They aren’t a large corporate team with an army of drone trainers. They’re a small, Oregon based team who does 100% of the training ourselves. They create and test their own curriculum. They live and breathe this stuff, and it shows.

Marcus Blankenship

Marcus has worked as a Software Engineer, Architect, Team Lead, Software Manager, Consultancy Owner, College Instructor, Leadership Coach and Business Coach. He specializes in helping Technical Managers and Leaders create high-performing organizations.

His book, Habits That Ruin Your Technical Team is now available. He is currently pursuing an I/O Psychology Degree (Leadership Specialization) from Penn State and lives in Eastern Oregon.

Amy Blankenship, RN, BSN, MSN-Ed

Amy has worked as a Nursing Instructor at Oregon Health Sciences University, specializing in clinical simulations and interprofessional instruction. She has also worked as a post-surgical nurse, hospice nurse, and a hospice clinical manager.

She currently serves as an Executive Board Member of Klamath Hospice, on the Oregon State Board of Nursing Curriculum Council, and as a leadership mentor for the Oregon Nurses Association. She will enter a Ph.D. program in 2018 and also lives in Eastern Oregon.

The post Technical Leadership Workshop, July 16/17 appeared first on Voltage Control.

It was about six months ago when I first spoke to members of Apple’s IS&T team about their use of Design Sprints. I remember it sounded quite strange that they were using Design Sprints so frequently. I was intrigued and wanted to learn more. After speaking with them about their process, I started to believe that they were using Design Sprints as a method of requirements gathering. I was wrong.

Requirements Gathering is an activity for identifying and gathering requirements for an information system. While no perfect method suits all projects, a few standard methods are: User Interviews, Storyboarding, Use cases, Questionnaires, Brainstorming, and Prototyping.

Joint Requirements Definition is a method of requirements gathering defined by a group of stakeholders participating in discussions to elicit requirements, analyze their details and uncover cross-functional implications. Similar to Joint Requirements Definition, there is also Joint Application Design and Use Case Workshops. These cross-functional approaches resemble Design Sprints without the streamlined structure or the prototyping and testing.

Since forming my original opinion around Design Sprints for Requirements Gathering, I’ve had the opportunity to work with Fidelity Investments, multiple state agencies, and recently acquired startups that are similarly using Design Sprints. After getting a closer look, it is clear to me that instead of a tool for requirements analysis they are getting to what I am now calling requirements acceptance. The distinction to me was that they were already equipped with requirements. They had done their research and were seeking to validate this research and ensure that the rest of the organization was onboard.

It is not only critical to understand your customer’s needs and how your product aligns with those needs, but you must also understand how these changes or additional impact your organization. For smaller companies, these concerns may be minuscule or nonexistent. Larger companies must address these organization concerns in order to ensure success.

Requirements acceptance, as I’ve come to define it, is a process for socializing your product requirements and where you intend to drive the product. It is often a complicated and involved process to drive to complete alignment across all stakeholders in a larger organization. As I’ve witnessed first hand, Design Sprints offer an alternative path to the months-long typical process most companies engage in.

“Some were frustrated that they weren’t on the same page, but I was excited that we were discovering it now!” — SVP of Fortune 500

I believe there are five big reasons why Design Sprints are so effective at rapid alignment around product requirements and getting organizational requirements acceptance.

Surface Possible Conflict

A Design Sprint prototype provides a concrete view of the proposed solutions. Stakeholders aren’t relying on a memo, it’s real, and they can’t ignore it or convince themselves you mean something entirely different. 
Seeing the solution in real and absolute terms bubbles up questions about the offering. Stakeholders and leaders can get their arms around it and really understand it. They can have a concerted vs conceptual conversation.

Accelerate Conflict Resolution

When misunderstandings around requirements or solutions to address those requirements are surfaced early, companies then have the opportunity to stop or adapt. You might decide to proceed down a different path, cancel the project entirely, or adjust course slightly. Regardless of the decision, you can make it today without waiting six months and realizing that there is violent disagreement amongst stakeholders.

Circumvent the Pocket Veto

The Design Sprint prototype prompts a conversation around a proof of concept prototype and supplies proof of commitment. When commitment is recorded and confirmed you avoid the unexpected torpedos that can often stifle progress.

Fast Forward Customer Learning

Even if your prototype is just a landing page, the level of learning and understanding you garner from your customers is immeasurable. Gauging their reactions to your positioning of benefits and key value propositions provides deep insights into the viability your product. The best part is that you can get these insights before investing in building a product.

Building Strong Advocacy

The cross-functional team that you assemble for your Design Sprint walks away from the 5-day process having had one of their most memorial weeks in a long time. They not only have had a fun and engaging break from the doldrums of their typical week, but they’ve also been invited to co-create and participate in the shaping of the solution. They understand why trade-offs were made and can justify the current solution to their constituents. They become advocates for the solution to their part of the organization.

“This is how government should be working” — Richard Wade, Texas Water Development Board

Design Sprints are a powerful tool help large organizations drive rapid organizational alignment and get out of their own way. I would love talk with you about how to Design Sprints might help your organization.

The post Design Sprints for Rapid Requirements Acceptance appeared first on Voltage Control.

A common source of confusion around Design Sprints relates to the popularity of Agile development practices, specifically Scrum. When most people hear the word “sprint,” they think of the cell phone company, Scrum rituals, or “that stuff our dev team does.” Because of this, there have been several articles discussing the merits of Design Sprints versus Agile Sprints. One even suggested that Design Sprints may be a way to avoid the purgatory of Agile Sprints.

I’m here to argue that they can be harmonious, not antagonistic. Design Sprints and Agile Sprints work well together and even complement each other. Below are my thoughts on how using Design Sprints in front of an Agile development process can actually lead to better results.

Quick Intro to Agile & Scrum

First, I’d like to cover a few basics of Agile software development for those who are new to it. Agile first came onto the scene with the Agile manifesto, written in 2001. The manifesto consists of 4 values and 12 principles. I’ve listed the values here because I believe in them whole-heartedly.

• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer Collaboration over contract negotiation
• Responding to Change over following a plan

“Agile Sprints” are part of a specific Agile development process called Scrum.

Scrum is an agile framework for managing work with an emphasis on software development. It is designed for teams of three to nine developers who break their work into actions that can be completed within time-boxed iterations, called Sprints (30 days or less) and track progress and re-plan in 15-minute stand-up meetings, called Daily Scrums. — Wikipedia

Agile Versus Sprints

Agile and Scrum are ways in which you build software. They define tools, practices, and rituals for conducting daily engineering tasks. A Design Sprint is a tool you use to dive deep into a problem, to understand if you should build something, and determine what exactly you should build. As you can see, Agile Sprints and Design Sprints share a few core principles in common. They both encourage cross-functional teams, seek to move quickly, and continually react to new information.

When Agile first emerged, organizations began to sit cross-functional team members close to each other so that they could become aware of issues more quickly. Unfortunately, designers were not always part of these teams. Often, the UX researchers and visual designers were part of another team or in an outside agency and their working style closely resembled waterfall development.

While Scrum defines a great methodology for how we should build our software, Design Sprints are a perfect method for determining what we should build.

Working in Sync

While Scrum defines a great methodology for how we should build our software, Design Sprints are a perfect method for determining what we should build. In Scrum, there is a Sprint backlog, which is fed by a product backlog. Design Sprints can help teams focus their product backlog and align the entire team on the features and projects with the highest business potential. They are also an effective tool for validating user requirements that are teed up in the Sprint backlog. In Design Sprints, you often iterate and test much like you would in Scrum; however, Sprints do this iteration through quick designs and light-weight prototypes, which are much less expensive and carry lower risk.

You Need Both

I’m sure you are familiar with the expression “garbage in, garbage out.” Scrum is a great process for developing code quickly, keeping projects moving, and adapting to new requirements. However, if you are building the wrong thing, it simply means you’ll have the wrong thing faster than with waterfall.

If you are building the wrong thing, it simply means you’ll have the wrong thing faster than with waterfall.

Some will argue that Scrum’s iterative nature will allow you to discover these issues and adjust course and that Design Sprints aren’t necessary. There are a couple of issues with this line of thinking:

1. If your focus is on pushing code and building features, it will take you a long time to discover the cracks in your foundation.
2. Once you have built the system, the sunk cost fallacy may make you inclined to continue investing in the project long after you realize it’s not a winner.
3. Technical debt is a measure of uncertainty, so the more you build from a point of ignorance, the more technical debt you accumulate.
4. Design Sprints leave you with a prototype that becomes a “visual spec,” which can help to decorate and improve on the Agile acceptance criteria.

Prototypes Set You Up for Success

I think starting your Agile process with a focused Design Sprint sets you up for much greater success down the road. That’s because Sprints are predicated on quick user feedback from rapid prototyping. Prototypes are by nature disposable and can be easily updated without fear of technical debt or other hidden costs down the road. They allow you to test ideas and features quickly and increase your level of confidence prior to sending the project through an Agile Sprint. When you are done with a Design Sprint, you are ready to build.

When you are done with a Design Sprint, you are ready to build.

You’ll leave your Design Sprint with a functioning prototype that has been battle tested with users. This prototype becomes the “visual spec,” which helps improve on the Agile acceptance criteria. There will be less time needed to write the acceptance criteria because your visual prototype is highly specific, leading to much less ambiguity.

I encourage all Scrum teams to think about their Scrum cadence and on what frequency it makes sense for them to conduct a Design Sprint first. In fact, I’m noticing more and more companies using Design Sprints as a way to validate product requirements and align stakeholders prior to sending their project through an Agile development process.

I would love to hear your thoughts on how you use Design Sprints and the Agile process to inform each other. What’s your cadence?

The post Friends, Not Enemies appeared first on Voltage Control.