“The Most Dangerous Game” Film, 1932

During the presentation, we were discussing assumptions and tests. At this point someone asked what types of assumptions I thought are the most dangerous. Were they ones that we didn’t realize we were making, the ones we were sure were correct, or what? After a little thought, I came to realize that there is a particularly dangerous assumption many of us don’t think about: that one which was once true, but has since been invalidated.

I particularly love the power of metaphor and have found myself encouraging people to think about project management, software development, and product management to be more like a series of experiments than like building a house, which continues to be the “go to” metaphor within project management, much to my chagrin. However, if we think about it, the comparison to the scientific method also has a fatal limitation.

Within most fields of science, we are experimenting and exploring a domain that has a set of constant rules. As far as we know, the laws of thermodynamics and relativity remain the same today as they were when discovered, and we can safely assume that they will remain constant in the future. Of course, there are points when theories evolve as they are found to be incomplete, relativity overtaking Newtonian Physics for example. This is based on a model where we are seeking to understand an unknown but have a constant, albeit complicated, set of rules.

When an experimental model is applied to a complex adaptive domain that is ever changing, such as just about any market or business, we have a second challenge. Not only is the nature of our market not entirely known, but the rules themselves are evolving over time. That which was once correct may not hold in the future. It’s really quite difficult to overturn a truth that we learned with hard won experience. Max Planck summed it up well when he famously lamented that scientists are so loath to give up their own theories, even in the face of new contradictory evidence, that “Sciences advances one funeral at a time.”

A Real Example

In 2013, after nearly 130 years in business, the Eastman Kodak company filed for bankruptcy. The tale of the company is a long one with numerous twists, turns and reinventions. A pioneer of what would become celluloid film, Kodak revolutionized the photography market twice. First by replacing the glass plates of earlier cameras, and a second time with massive investments in color film. Kodak was a true innovator, indeed it created the first charged-couple device sensor—a foundational part of digital photography, the first camera-sized megapixel camera, and the first digital SLR Camera.

Yet, leadership at the company was unsure of the promise of digital photography. While they were breaking ground in this territory, it was clearly a potentially disruptive innovation. They wanted to know what it would do to the conventional film market. In their book, “Decisive” the Heath Brothers capture the tale well…

In 1981, a team inside Kodak assessed the threat that would be posed by digital technology during the decade to follow. The report concluded that during the 1980s:

• The quality of prints from electronic images will not be generally acceptable to consumers as replacement for prints based on the science of photography
• The consumer’s desire to handle, display, and distribute prints cannot be replaced by electronic display devices.
• Electronic systems (camera and viewing input device for TV) will not be low enough in price to have widespread appeal.

Now, we know how things turned out; Kodak was never able to rise to the challenge posed by Japanese electronics companies that dominated the market with high-quality digital cameras. The point isn’t to look at how Kodak was wrong, but rather how they were right for quite some time. The market for digital cameras was non-existent in the 1980s, as Kodak predicted. Indeed, the above chart shows there really were not appreciable sales until 1996, with digital cameras only overtaking analog ones in 2003. So their analysis was correct, for about 15 years, which is pretty good when you think about it. The problem was really that they were never able to adequately reconsider that question.

Photo Marketing Association Camera Sales

Agile, Lean Startup, & Tested Hypothesis Life Expectancy

Bringing this back to the world of agile and Lean Startup, we are faced with an added complexity. Not only are we producing products and solutions in a market we most likely don’t fully understand, but chances are, even if we gain insights into the nature of it, they will decay at a rapid rate. Indeed, I would suspect that few companies today would be able to make predictions that last half as long as Kodak’s 15-year projection did regarding digital film. The number of people discussing the accelerating rate of change and adoption are innumerable, but I think G. Kofi Anan’s chart nicely visualises the trend.

Isn’t This All Common Sense?

Before publishing this blog, I was sharing this idea with someone who responded, “Well, isn’t this all common sense? Of course we need to recheck things like that from time to time.” This gave me pause, and almost caused me to change the post to try and respond. I would really like to think that logically, we should know this, and yet we don’t. Kodak didn’t. I can’t count the number of other companies that identified solid markets, but struggled to respond to changes within an established space. Going beyond business, within military circles, there is the old saying that “We always fight the last war.” Clearly there is something bigger playing out here.

I suspect there are a number of reasons why we fail to reevaluate assumptions in response to change. The availability heuristic would predispose us to favor that which we are most familiar with. Loss aversion may make people more likely to stick with the models they know, rather than risk losing them in pursuit of new business opportunities. Even innovative companies like Kodak could fall victim to the “innovator’s dilemma“, where a focus on the immediate market, chemical film, prevented them from really understanding and seriously investing in future markets, like digital photography, until it was too late. Even putting aside some of the cognitive and business research, let’s just imagine what it would feel like to be in a company like Kodak. You are part of a firm where the past successes have been built into your company. The people who figured out a prior market challenge have been promoted, their successes are part of the corporate lore, depending on how long ago key insights were achieved, they may also be built into corporate procedures and other processes within the company. Indeed, the entire organization is tuned to repeat whatever it did in the past. From this vantage point, I can certainly have quite a bit of empathy for a company that is unable to overturn established insights and beliefs.

The post Agile & Lean Startup: What’s the Most Dangerous Assumption? appeared first on BigVisible Solutions.

These are the words that every agile coach yearns to hear from the people they work with. While it’s always a goal of mine to change the mindsets of clients, I have had mixed results over my five years as an agile coach. On one six-month engagement with a client I’ll call Prosperity, though, something transformative took place. I’ve spent some time since then thinking about what made those six months so successful and why Prosperity continues to push the envelope of what it is capable of doing as an organization.

At first, I thought it was all around the process. Prosperity, like many other clients, started out wanting to “learn agile.” Teach us Scrum, help us start out right, and let’s roll out agile across all teams, were there primary requests. So I started with what I considered at the time to be a “perfect” way to rollout Scrum to teams—a two-week “Sprint 0″ approach of training, workshops and preparation for sprints that is consistent with every team. I have used this approach with many clients, with varying results. At Prosperity, though, the teams really took to it; they loved it and felt it was going to transform the way they worked. While I can say that all the teams at past clients benefited to a certain degree and were ready to work in sprints at the end of the rollout, I definitely didn’t get the feedback that this was somehow life changing. In fact, from some clients, I got the exact opposite feedback— that this was too process heavy. While all clients saw the results of going through this “kick off process,” none of them had embraced the change to the degree that Prosperity had. So that wasn’t it.

My next thought was that it must be the all around coaching style I had used with Prosperity. I had tried a more directive approach at the start with Prosperity then switched to a more supportive, kind of “back of the room” approach once they started to “get it”—maybe that was the reason why they had responded so well. While I’m not one to usually want to be more directive and in control, I hypothesized that perhaps the key to success at a client is to start out more directive and then back off when the teams are ready. To test my theory, at another client, I tried to be much more directive from the beginning. Bad idea! I almost got fired from the client with that approach.

So if it was not the process, or a specific coaching style, what was it that made my six months with Prosperity so special? Would I ever be able to see the same success elsewhere? The prospect of never having that level of success with a client again made me question whether I should continue being an agile coach. Maybe it was nothing I had done, but just working with the right people with the right attitude. Perhaps it’s not at all about coaching, but about people being willing and able to change given their sheer desire to do something different.

Because that was such a depressing thought, I delved a bit deeper into everything that had happened during my time with Prosperity, both on their end and on mine. In the end, I did find some great lessons on coaching that I believe will help anyone who wants to bring out the best in people.

Agile Coaching Lessons Learned

Lesson #1: Take time to get to know people. Even before I came onsite with Prosperity, I had numerous conversations with some of the key leaders who were bringing me into their organization. I truly took the time to get to know them, how they work, what they value, and what success would look like. In these conversations, they were also getting comfortable with me and were seeing value through the discussion. These weren’t one-sided interviews where I asked all the questions but dialogues, where we discussed thoughts and ideas. Once I came onsite, I spend about 30-60 minutes with leaders of every key team or department within the organization. While I was exhausted after two weeks of these discussions, I was also energized because I truly felt I had established some real connections. By the time I started to engage teams, I already felt I knew most of the team members and that they were comfortable with how I was going to help their teams get better.

Lesson #2: Appreciate their journey and how they got there. I remember many years ago, I started with a new client. During my first week there I observed a team in their planning session. I sat near the back of the room and wrote down my many observations. I was so proud of all the many things that I was finding to talk with the ScrumMaster about! After the planning meeting, I mentioned to the ScrumMaster that I was going to write up my thoughts and get back to him to have a discussion afterwards. I sent him a very lengthy email with all the things he should consider doing differently with the teams and ways to improve the process. The response was not pretty. His response to me: “We need to talk about this.” Never a good sign! When we got together to talk, he started by saying, “You don’t know a thing about us, why we have tweaked the process, why we are doing the things we are doing. So why do you have the right to say we are doing everything wrong?” Ouch! It took a long time to repair that relationship.

Unfortunately, I haven’t always learned from that lesson and tend to come into teams with all guns blazing only to shoot myself in the foot. At Prosperity, though, I did a much better job. I showed true sympathy and respect for their journey so far. They had tried agile before, but with limited success. I asked questions to learn about what had worked and what hadn’t. I demonstrated that I appreciated what they had tried to do in the past, their wins as well as their challenges. I also had honest conversations around their thoughts on agile—fears, uncertainty, doubts, questions, concerns, etc.—to understand where they were coming from but also to show them that I was not trying to change or fix them but truly cared about where they were in their journey.

Lesson #3: Show them a world of possibilities. I used to get frustrated with coming into organizations as an external coach and having clients think of me as the “Scrum trainer,” with the focus on getting the teams formal training as a measure of success. I realized in my conversations with Prosperity, I had begun to paint a picture about what an agile organization looks like. Not with the adoption and training around practices, but around the results that they could see with such an adoption. By painting a picture of what the organization could become, they started to see the picture for themselves and wanted to be a part of such an organization. Looking back, most of my conversations were around “what could be.” They soon realized that there was much more around changing mindset, behaviors, organizational structure, leadership styles, tools, infrastructure, team dynamics and other areas that also needed to happen. By seeing a possible future and appreciating what it would take to get there, people started to find their own ways of owning the vision and making it happen.

Lesson #4: Create heroes that will change the world (and their organization). A few months after I left Prosperity, the president took the time to write up a very nice recommendation. In the recommendation, he had told me that he and others had nicknamed me “the General.” At first, I was taken aback with association—I thought that I had moved on from a directive role to something else while there. To me, being called a General made me think of some guy that stood on a pedestal barking orders to everyone. I didn’t want to be that guy. So, I asked him about the nickname and my concerns about it. His response surprised me, “No, that’s not how I view a General at all. In fact, it is quite different. To us, we saw you as the guy that could see the overall big picture of the organization, where we were going. You helped us move towards the same goals instead of competing goals within parts of the organization. You helped us gain the capabilities to take on the battle ourselves by creating each of us as an agent of change. You wanted us to be successful and we in turn wanted to show you that we could be. Calling you General is our way of showing the highest level of respect for what you did for us.”

Wow! That’s enough positive feedback to make you want to keep going no matter how tough it gets, right? I then realized that if the focus on agile transformation across the organization is strictly around processes, I would fail as a coach. Instead, agile coaching has to be about transformation of people—helping them gather the courage and ability to be a hero and an agent of change within the organization. Get enough heroes and it becomes a viral effect that others want to be a part. Have enough change agents and not only will the changes stick but people will continue to find ways to keep the organization focused on learning and improving.

Lesson #5: Develop a partner relationship. This is not necessarily a separate lesson, but more the ultimate outcome as an agile coach. The agile coaching role is still very new or unknown to many organizations. While I have tried to describe the relationship between a trusted agile coach and an organization, you really have to build the relationship through the other actions mentioned above. If you are truly going to have the relationship necessary to help people transform, you have to gain their trust and respect. They have to see you as not just a trainer but a guide. They have to feel you care about them and want to help them succeed. They need to understand where they can go and feel you can lead them in the right direction in their journey. In many ways, I feel like I have never left this client. I am still cheering from the sidelines, interested in the people and the success that they are having. By becoming a partner in their journey, a part of me will always be involved.

The post Agile Coaching Is (All) About People appeared first on BigVisible Solutions.

Companies need to do more than just apply Lean Startup concepts, they need a holistic focus on three key areas:

1. Lean Startup
2. Business Model Innovation
3. Continuous Delivery

The Dangers of a Myopic Approach

Though leveraging all three at once may seem overwhelming, those who do so can thrive in extreme uncertainty. To see why, let’s start by breaking down the dangers of only focusing on one of these key ingredients.

Lean Startup Alone

Lean Startup has gone viral. I heard Marc Andressen say, “It’s like we discovered the theory of relativity,” while being interviewed by Eric Ries last winter. Unfortunately people are running with Lean Startup in ways that at best are local experiments and at worst destructive to an organization. Lean Startup is powerful stuff, but by itself it does not address how you retain product/market fit or deliver stable, scalable software to the customer.

Business Model Innovation Only

At the same time, the days of a static business model, with an organization structured like a factory to execute on the model, are long gone. Today, Business Model Innovation is crucial for any business to survive. CEO’s need to be constantly creating, testing and modifying business models. Unfortunately much of this work occurs in a vacuum that is completely decoupled from the delivery of the product. Worst yet, without Lean Startup to validate/invalidate the risky assumptions in your business model it becomes nothing but an interesting thought exercise.

Continuous Delivery By Itself

The emergence of Continuous Delivery is a game changer. We are standing on the shoulders of Extreme Programming and Open Source giants as we can now safely increase speed to customer with our software. Unfortunately these efforts often originate in IT Departments and do not address the inputs for creating customer value. By itself, Continuous Delivery has merely given you a way to deliver waste faster.

Lean Startup + Continuous Delivery

Lean Startup + Continuous Delivery is a powerful combination. Not only can you rapidly design tests to learn but you have the software capabilities to do it in a well designed, scalable manner. However with the absence of Business Model Innovation, you have little hope of taking advantage of the revenue generating opportunities. You’ll pivot in and out of product/market fit if you fail to leverage it with an innovative business model.

Lean Startup + Business Model Innovation

Lean Startup + Business Model Innovation is another powerful combination. Not only are you rapidly designing business models but you are systematically validating/invalidating them through Lean Startup experiments. Unfortunately without Continuous Delivery, you’re chances of scaling it and remaining responsive to customer’s changing needs are slim. Organizations that do not address their delivery streams end up experimenting outside of their release cycles. This is manageable for a time, but will not work well after you need to iterate product quickly.

Business Model Innovation + Continuous Delivery

Business Model Innovation + Continuous Delivery is an interesting combination, yet I wonder that it can really exist in practice without some element of Lean Startup. Essentially you’ve coupled your Business Model Innovation efforts directly to your customer without validating/invalidating risky assumptions. While you could rely on the customers to validate those for you at an aggregate level, that’s an amount of risk I doubt you’ll want to incur.

The Power of a Holistic Approach

This brings us back to Lean Startup + Business Model Innovation + Continuous Delivery. The combination of all three disciplines gives you an API for thriving in extreme uncertainty. You can create new business models, rapidly validate/invalidate the risky assumptions and deliver value to your customers in a quick and scalable manner. I would not go so far as stating you will be invincible with this combination, but you will be extremely hard to beat.

If you focus on all three of these key areas, you soon will discover that instead of being reactive to competitors, your competitors have become reactive to you.

The post 3 Keys for Innovation: Why Lean Startup Isn’t Enough appeared first on BigVisible Solutions.

The reality is that most people and companies do not continuously improve. I certainly don’t! There are many reasons that continuous improvement is so hard. One of them is that change is uncomfortable.

Feel the Change

If we are going to continuously improve, we need to become comfortable with change. Big changes are certainly hard but can we use many small changes to get used to how change feels? Yes, we can. Here is a small experiment to prove it! Most people, without even thinking about it, have patterns and habits that we follow. This is good, because remaking all the same little choices every single day would be untenable to our sanity. We can also use these habits to practice feeling change.

As an example I will tell you about how I put my shoes on in the morning. (Maybe this is starting to sound silly but, stay with me here.)

Tie differently (Image (CC) by Maya83 on Flickr)

If I don’t think about the process, this is what I do every time I put on my shoes:

• Put on my left sock.
• Put on my right sock.
• Put on my left shoe and tie the laces.
• Put on my right shoe and tie the laces.

I no longer recall why, decades ago, I choose to follow this order of steps. Maybe it’s what my mother taught me, who knows? Now, if I want to feel a touch of change and experience what altering my patterns is like, I can change up the way I put on my shoes. And I learn:

• I have to think about what I am doing.
• I find myself dynamically planning what to do next.
• It “feels wrong” to go out of order.
• Even though I did it differently, I still accomplished my goal.

Small Continuous Improvement Steps

Most continuous improvement comes in small steps—little changes found in a retrospective or discovered during the work. Even such small changes can “feel wrong” at first and force us to think in different ways.

Practice “feeling” change by altering your little routines. Maybe drive to work by a different route. Have lunch at a different time or place. Even wear your brown shoes on Wednesday for once. Remember what that small change feels like. If you don’t feel that way often during your work, are you really continuously improving?

I challenge you to change something about what you do at least once a week. Observe what you feel and learn from that change. Find ways to insert more improvements in your work and get closer to the continuous improvement ideal!

The post Continuous Improvement: Feel the Change appeared first on BigVisible Solutions.

So what to do?

I am trying to increase my velocity by applying speed reading techniques. But so far, that is probably only closing a small percentage of the gap.

Iterative Learning

Then, upon a bit of soul searching, I had an epiphany. Why do I feel the need to read and understand every single word on every single page? This runs counter to what we coach our teams to do—eliminate waste, only document what makes sense, just-in-time practices, and applying iterative thinking instead of only incremental. The answer seemed to be that I don’t feel that I have really read the book if I haven’t read every word. So what? Am I trying to conquer the thing? It seems like a very egocentric point of view.

What if I was able to let go of the ego, and try to read a book iteratively instead of incrementally? Is it even possible? Would it be effective? There are all sorts of ways to tell stories or build products—top-down, bottom-up, inside-out—each of which have their strong points. Sometimes it is most effective, for instance, to grab the user’s attention by initially giving them a nugget that might logically be placed in the middle of a narrative, and then providing necessary foundation, or by filling in the gaps as necessary. Could one apply the same process to learning from a book? I could imagine scanning through a book randomly, stopping at points that looked interesting and digesting a bit—much like I used to do with encyclopedias as a kid. Or, maybe, first reviewing the TOC for areas of interest, jumping to those sections, absorbing a bit, and then searching for any context that was missing.  This would be a completely different way to learn from a book. I couldn’t call it reading, and don’t have a good term for it, other than a new kind of learning.

This led me to thinking a little more deeply about what I am trying to get out of reading; the learning aspect of it. What if I could scan a book in a tenth of the time that it took to read it, but retain half of the content? Would that be an improvement? There seems to be some sort of formula that I am trying to maximize, like dl/dt=CVR: Rate of learning equals the “learn-worthy” content of the book multiplied by the speed that I scan it multiplied by the percent that I retain. Is the percent retained equal to the percent value obtained? Do I get half the potential value of a book if I retain half as much? I could simply define R to be the percent value and my equation still holds. Something in the back of my mind says this it is really sad to look at learning this way. Something else says I am on to something.

Of course, there are all kinds of nuances.  For example, some books build upon a foundation which must be well understood to get any value at all out of the latter sections of the book.  For others, it may be easier to skip around. Some, you may be able to get value out of scanning the TOC, or the subheadings, digesting the graphics, or just reading the intros and summaries of each chapter; for others, not so much.  Hence, in a sense, different books have different learning profiles.

The Experiment

I was intrigued enough to attempt this on a book near the top of my backlog: Steven Wolfram’s A New Kind of Science, a 1280-page tome that took him ten years to write. So I did it. I didn’t “read” it. I iterated through it and digested some of it. And can honestly say that, for this particular book, I optimized my learning rate equation significantly. I can’t be sure of the total potential value that the book would have to me were I to read it in its entirely, but from what I digested, I feel like I got about 50% in about 5% of the time—a tenfold increase in my learning rate. And Steven got his royalty. Yes, I do appreciate the irony of using a new kind of learning on A New Kind of Science. And letting go of the idea of conquering a book was kind of liberating.

So, what if we look at a particular learning objective in the same way that we manage a large project or program? I am imagining a vision or an objective like “I want to become learned in Digital Philosophy” (one of my particular interests.) That vision results in the creation of a backlog of books, papers, blogs, etc. The larger of these (books) are epics and can be broken down into stories, like “Scan contents to get a sense of the material,” “Determine the core messages of the book by finding and reading the key points,” “Understand this author’s view on this particular topic,” and so on. By thinking about learning material this way, it opens up all kinds of new possibilities. For example, maybe there is another way to slice the backlog, such as by topic. If the most important thing to further my overall objective is to understand everything about cellular automata, I would assign higher priority to the stories related to that topic, even if they come from separate sources. So, my learning process takes a different path; one that slices through different material non-linearly.

Lean Startup Learning & Continuous Improvement

In fact, this all feels a bit to me like a lean startup approach to learning in that you can experiment with different chunks of material that may point you in different directions, depending on the outcome of the reading experiment. Having a finer backlog of reading components and being willing to let go of the need to conquer reading material might make possible a much faster path to an ultimate learning objective.

And so I am passing along this idea as an option for those who have a voracious desire to learn in this after-midnight world, but have a before-midnight backlog of reading material.

The post An Experiment in Learning, Agile & Lean Startup Style appeared first on BigVisible Solutions.

As I thought about it, I realized that the two-day CSM course basically introduces new ScrumMasters, team members, and other interested parties to how Scrum works and how to move teams through the ceremonies and artifacts associated with Scrum. What it doesn’t do—and likely cannot do in just two days—is also focus on all of the things ScrumMasters have to do to foster truly high-performing teams. The ScrumMaster role, done right, is much more than just scheduling meetings and updating a burndown chart. That leads me to conclude that the name ScrumMaster should (or will) die and be replaced with one that reflects the truly comprehensive nature of the role: team coach. Here’s why:

• With team’s exploring/adapting Scrum and looking at delivery mechanisms like Kanban or a hybrid solution, Scrum as a framework isn’t the entire focus for many teams.
• The ScrumMaster role has become misunderstood over time, translating many times into an agile project manager role, a meeting creator/facilitator role that could be done by anybody on the team. This is very different from the servant leadership role that Ken Schwaber intended. This misconception causes ScrumMasters to feel that they role is undervalued and not appreciated.
• Many ScrumMasters are adding or replacing their title with team coach as a way to address these factors.

When I started as an agile coach in 2007, there were fewer people who claimed to be agile coaches. In those days, an agile coach (whether external like I was or internal to the organization) was usually focused on helping an organization adopt or scale agile practices across and beyond teams. These agile coaches were to become the initial change agents/champions to bring about organizational change by helping create other change agents. As I grew into the role, I started working with larger organizations, helping them through any dysfunction and creating/modeling an environment where response to change and creating value were easier and faster. I began to focus my agile coaching on the mindset of overall organizational agility rather than any specific agile framework or tool.

As more people started to add the job title of agile coach in their organization, I became worried that it was in name only—that there weren’t additional responsibilities to go along with the role. Is a person who believes his role is to facilitate the team in meetings really coaching the team? Do many who have that title really know how to coach well?

As we came into our bi-annual company event called BVCon, several of the coaches got together and talked about what capabilities/tools a true team coach, or “advanced ScrumMaster” would need to have to help the team become high-performing. We quickly came up with the following list, which only scratches the surface of everything a team coach, or true servant-leader ScrumMaster, would need to foster agile delivery and high-performance teams:

• Facilitation and meeting management
• Decision making
• Team Chartering
• Systems Thinking
• Problem Solving
• Conflict Resolution
• Team Motivation

Back at the client site, my fellow coach and I talked about what we had learned and the challenges we were seeing with the ScrumMasters. Most ScrumMasters we know feel they have very little respect from their teams or from people outside teams. They feel they understand Scrum and are going through the ceremonies but the teams weren’t getting better. These ScrumMasters didn’t feel comfortable or have the authority to address most impediments or challenges outside the team. Together, we talked with these ScrumMasters about their current role and what they wanted it to become. We discussed how the role of ScrumMaster shouldn’t be about walking the team through a series of ceremonies but of helping the team get to a high-performing state, where the team can truly learn how to self-organize and adapt. We explained how an empowered, fully trained ScrumMaster truly can be a model and change agent for transforming the larger organization.

During these conversations, we came to the conclusion that we would stop using the term ScrumMaster. Instead, we will call them team coaches, to reflect the fact that their role is much broader in nature than they and others had previously imagined. We stopped short of calling them agile coaches, because their focus is more on agile delivery than on overall organizational agility.

I believe this goes beyond my current client. The traditional ScrumMaster role will eventually die, replaced with a team coach that will help create environments for teams to be successful no matter what practices they decide to take on.

The post Agile Delivery: From ScrumMaster to Team Coach appeared first on BigVisible Solutions.

Authority Words

In this photo are some other words and thoughts we associated with authority. The middle column are words I asked people to blurt out as what they thought of first when thinking of authority. The left column are verbs associated with authority and the right are things we “do with” authority. As a group, we built these lists as a way to set the stage for a discussion about how authority is part of our lives and our work with clients.

Continuous Improvement & Authority

I recently found it very useful to think about my own mental anchors related to authority. How do I react to it? How do I gain it? Should I have it and when? How do I react when someone is in authority over me? Do they really have authority or am I granting that to them when I shouldn’t?

Would a change to how you, your team or your organization treats authority be something valuable?

The post Continuous Improvement: How Does Authority Affect You? appeared first on BigVisible Solutions.

Agile Transformation, Agile Coaching, and Everything

In an unscripted interview, Daniel hit me with some difficult questions about life as an agile coach. We spent a good bit of time talking about the challenges of an agile transformation.

We discussed some of the reasons agile is not just about teams and delivery. And we spent some time on how transforming a company means transforming everyone, not just the technology people.

Daniel Markham Interview With Alan Dayley from Daniel B Markham on Vimeo.

I thank Daniel for the opportunity and for asking difficult questions. Daniel’s post of the interview video has good summary information as well.

If you heard something that intrigues, inspires or perturbs you, let’s continue the conversation!

The post Agile Transformation: Some of What This Agile Coach Has Learned appeared first on BigVisible Solutions.

Tribal Leadership & Enterprise Lean Startup

The basics of tribal leadership are pretty simple. The book describes five stages of tribes:

• Stage 1: Life sucks. People at Stage 1 are characterized by despair and hostility. They often join tribes that are gangs.
• Stage 2: My life sucks. People at Stage 2 are disconnected and avoid accountability. Think of Dilbert cartoons or the movie Office Space.
• Stage 3: I’m great (and your not). Stage 3 people are about winning and it’s personal. They see themselves as heroes and better than others.
• Stage 4: We’re great (and they’re not). Stage 4 people rally around the ‘noble cause’ of their organization. They have an enemy to rally together against which is often their competitors.
• Stage 5: Life is great. People at Stage 5 find value within their work that transcends beating the competition. For them it’s about a great purpose in life that they are privileged to participate in.

During the discussion in this week’s book club we discussed what stage of tribal leadership is required for a success with enterprise lean startup. It was pretty clear to everyone that stage 4 (We’re great) is required. Then Kristen M made this observation:

That’s why it so hard to implement Lean Startup in an enterprise.  Most enterprises are Stage 3 tribes where everyone is trying to prove how smart they are.  But with Lean Startup, if you aren’t embarrassed by your product when you first launch it you’re launching it too late. People in Stage 3 can’t bring themselves to launch something they are embarrassed of.

Lean Startup is based on customer discovery and validating your assumptions. But most people at Stage 3 think they already know their customer and believe their assumptions are right and don’t need to be validated. Or they believe that they have been hired because they know and therefore can’t admit that they don’t.

My colleague David Bland at BigVisible states it another way: “Leaders typically are not promoted if they’ve repeatedly stated that they don’t know the problem or the solution.”

George Box says, “All models are wrong, but some are useful.”  I’ve found the tribal leadership model to be very useful and rich in meaning, especially when thinking about enterprise lean startup.  In the book Logan even gives a strategy of how to create a Stage 4 tribe within a Stage 3 organization. You can pick up a free audio version of Tribal Leadership on the Zappos website. It’s a good listen as it’s read by the author Dave Logan, who is also a very good speaker.

The post Tribal Leadership: Why Enterprise Lean Startup Is So Difficult appeared first on BigVisible Solutions.

Yet, all too often, I hear of teams whose hours-remaining burndown charts seem to lie to them. The team appears to be on target for the sprint, their estimates seem to be spot on, yet they still have stories left dangling at the end of the sprint. Worse, many times these are the most critical stories! Why?

Why are teams that demonstrate such good agile process unable to deliver? The answer is easier and more engrained than you may think. These teams are more focused on showing they can plan well and less focused on completing stories. Sounds to me as though we are still buying into “Plan The Work, Work The Plan” myth, keeping alive the ability to grasp defeat from the jaws of victory.

What signs, or smells, should you be looking for to know if this is happening to your team? Metrics about hours remaining is the most obvious. Root cause analysis that uses the burndown chart to spot inefficiencies is another. Something is wrong, too, if people want to throw out the burndown altogether because it is impossible to be right.

What Can You Do?

Focus on the primary directive: deliver working software that is completed within a sprint. Make completed user stories the primary metric. Add a story points-completed burndown chart. This will keep you and your team(s) on focused on the goal—delivering working software.

Don’t toss out the hours-remaining burndown chart. Knowing the hours remaining remains irreplaceable when it comes to triaging the work remaining against the planned software delivered. But don’t let past hope steer you and your teams onto the rocks by focusing you on the myth that time usage can be planned accurately. We know that is precisely wrong.

Next blog, coming soon: The least important information to come out of a user story session may be the story point.

The post Hours-Remaining Burndown Charts: An Agile Anti-Pattern? appeared first on BigVisible Solutions.