Review: Do Disrupt: Change the status quo. Or become it.

Do Disrupt: Change the status quo. Or become it. by Mark Shayler
My rating: 5 of 5 stars

On the surface this Is a book about business, but its message is relevant to other changes as well. It opens by explaining why “Disruptive” is over used, and what it really means and continues with motivating ideas, prompts and exercises.

This short book -- which the author encourages you to write in to complete the exercises-- would be useful for someone thing of doing something entrepreneurial ,either on their own or in the context of an organization they are a part of. Change agents of all sorts (consultants, as well as internal ones) might also find some of the exercises Inspiring.

I plan to revisit this book later for inspiration should I decide to become an independent consultant. I also find my self inspired to apply some of the thinking to make some aspects of my current job even better.

Also consider

• Fearless Change
• More Fearless Change
• 7 Rules for Positive, Productive Change: Micro Shifts, Macro Results

View all my reviews

Designing your life: Design and Agile Tools Applied to Life.

Designing your Life: How to Build a Well-Lived, Joyful Life by Bill Burnett and Dave Evans explains how you can apply design thinking to life choices. While the true test of the information in the book is to do the exercises and embrace the process, and look at the results (which I have not yet done) I finished the book with an excellent understanding of the possibilities and the feeling that I could use the tools to better understand my goals. Participating in a mini-workshop that Bill Burnett helped to validate that the process can be very powerful. A lot of work, but powerful.

As I mentioned in an earlier Techwell article (which was based on an interview) many of the concepts here may be familiar If you are a student of agile principles. Some of the exercises are reminiscent of those in Innovation Games. There is an exercise that is reminiscent of a career timeline exercise that Johanna Rothman has proposed, and the discussion of job searches and job descriptions is very consistent with some of what Johanna has written about the subject.

There are other elements that sounded familiar as well. The discussion of problem reframing will be familiar to those who work with software requirements, and the discussion of the qualities of a good “design team” will be familiar to anyone who has studied teams and read books such as Extraordinary Groups. Even if the concepts are familiar, there is value in seeing them applied to life design.

That the tools are familiar should not lead you you dismiss the value of the book. (After all, one could argue that much of the “agile toolbox” derives from other disciplines.) Like any tool box, tools can have many applications and it's useful to have a guide to how to use a tool to solve your problem with the right techniques, and to understand that there are versions of the tool that are more finely tuned to your purpose. I hesitate to say "solve your problem efficiently" because life design is neither a problem with a single solution end point (it's a process) nor is it simple. By applying the collection of straightforward steps in this book you can start on the path to understanding how to design a like that is congruent in all dimensions that matter.

Regarding solving as compared to exploring, the authors emphasize that there is difference between engineering problems and design problems is that design problems in that engineering problems are more about solving, and design ones about building forward. While I believe that to be a good engineer you need to understand design, I agree that there are different perspectives, and engineers don’t often switch between “explore options” and “solve a defined problem” appropriately.

This is an easy to read book that can be useful in helping with evaluating both the big picture and specific aspects of your life. You may even gain some insight into problems related projects, since the tools are similar. Reading the book is valuable. Working through the exercises with a team can be more so. The book is full of are exercises and is supplemented by a web site with worksheets and other resources to use. This is an easy to read book that can be as useful as you want it to be.

Patterns and The Storytelling Animal

I had the good fortune to be involved in the early days of the Software Patterns.  In brief, patterns are about capturing solutions that people have developed organically over time, which have proven to be the best ones for the context at hand. What's interesting about patterns to those who are used to more academic approaches to learning about software,  is that a good pattern isn't novel. If you've been working in a domain for a time you are likely  to recognize solutions you have used before. If you've struggled with the problem in the past, you are likely to appreciate that the "common solution" is now documented.

By writing patterns, and hanging around people who studied and and worked with patterns, I learned to appreciate that the value of context: it's not enough to have a toolbox of solutions; you need to understand which solution makes sense given the specifics of your problem. In that way, Patterns fit into a set that includes agile engineering practices and software configuration management: Things that help you to focus your energy on the solving the hard problems that apply to your specific situation.

A good pattern is something that other's have used successfully. When trying to understand whether something is a pattern or just a "cool idea" you often find your self trading stories with others who have worked in a similar domain. My work with "Patterns People" also helped me appreciate the value of story in sharing knowledge. The books that inspired the first writers of software patterns, The The Timeless Way of Building , and A Pattern Language: Towns, Buildings, Construction (Cess Center for Environmental), are about building and architecture, fields in which there is a long history and much tradition. Traditional approaches to building evolved organically over time, and the ones that worked were shared and persisted. To understand the difference between a solution that works and one that is adequate you need to know more that just what to do. You need to understand the story behind the solution, and the story behind your current situation.

The value of story in learning and transferring knowledge seem to make sense on the surface. But it also seems to contrast with the way that we sometimes apply business and engineering processes. We want highlights, key points, and simple rules. But we often don't have the patience for the story that describes why (and when) these rules apply. And applying rules without context can sometimes be uncomfortable.  I recently read a review copy of The Storytelling Animal: How Stories Make Us Human, and this book shed some light on why stories work well for learning, and why avoiding story can make us uncomfortable.

The Storytelling Animal a well written, compelling book that explores the science, history, and future of stories and storytelling. Among other things, the book covers why children and adults create and consume fiction, the science of dreams, the role of stories in influencing (and defining) history, and what technology means for the future of stories. Not just full of interesting facts, many chapters start out in the manner of a compelling story, drawing you into learning about the science and history of story telling, proving the point stories are a great way to learn.

In our quest for answers,  it is important to not ignore that there is a always a context to a problem. What worked in one situation might not be generally applicable, and a framework or tool that solves one (important) problem well, but not your problem is not de-facto a bad tool or a bad solution. Just not the right one for you. While it's good to be skeptical when presented with a solution (especially if someone claims it to be a pattern), it's also good to not be dismissive of attempts to capture solutions in context.  Solving technical problems well isn't just a matter of applying technology. You also need understanding and a knowledge of what others have done in similar situations. Your situation may well be unique. But it is also likely to be similar to ones others have encountered.

Uncertainty and Agile Requirements

The key value of Agile methods is to help you to manage uncertainty. By being incremental and iterative, you manage risks by not investing a lot of effort in specifying things that may "wrong." At the start of each iteration you can look at what you have and decide that it's the right thing, in which case you can build on it, or the wrong thing, in which case you can try something else. Since you've only invested a small amount of effort relative to the specification you do in a waterfall process, you've wasted less effort and, in the end, money if you are wrong.

This approach of small stories with only some details works really well in many cases. An agile team runs into trouble when the project team confuses "uncertainty" with "vagueness." To be successful, an agile team needs to work off of a backlog that has stories that are precise enough that the team can iterate effectively with the stakeholders at the end of each iteration, and can develop with a high velocity. It's important to add precision even if you have uncertainties. While it's important to be as accurate as possible, don't use your lack of certainty about a requirement as an excuse to accept a lack of precision. When you have a good target to aim for (and you hit it) you can iterate quickly and judge if you are hitting the right targets.

How do you tell that you have enough precision?  This varies from team to team. For a team that has been together for a time and has a clear shared vision, a very brief statement of goals might well be enough. For a project where the vision is less clear,  a longer conversation may be necessary. Three concrete tests are:

• Can the team estimate a story? (See Agile Estimating and Planning for more about estimating.) If the answer is "there is not enough information to estimate" then the story is too vague, and the team and the product owner need to meet to make sure that they understand the options. If the team estimates a story that the Product Owner thought was simple at 3 weeks, you have a raised a flag that you need more conversation to understand what the PO really wants.
  
• Can you provide three options for how to implement the the story, or 3 variation of what the user experience will be? If you find yourself developing many more that seem plausable, the story is too vague, and if you can only develop one or two, then the there is not enough information for you to think through the story. 
• Can you test the story? If you can't come up with a a reasonable high-level test plan, then  the story is too vague. (Mike Cohn has written an excellent article about the value of planning with the larger team.)

While being able to do all 3 for a story is nice, being able to feel like you can estimate with confidence is the one thing that you should do to feel confident that the stories are well developed.  If you can't estimate based on what you know about the story, the good news is that  the very act of trying to come up with an estimate, options, or a test plan will help you refine the story.

One might say that this is too much planning for an agile process, and that this level of detail sounds kind of like a "waterfall."  And at a high level it seems related to the Cone Of Uncertainty, which is a model for waterfall development. The difference is that we still don't need or want to have fully defined specifications at the start of the project; as we approach a development iteration, we want enough detail to have a development target that a stakeholder can evaluate.

At the end of an iteration when something isn't quite right, you want your stakeholders to say "that's not what I want" rather than argue over what they meant. The latter will still happen, and it's OK when it does. By being precise about what you think you want to build, you will identify the high risk areas of a project early on, so that you can take full advantage of the risk management benefits of agile.

Accidental Simplicity

Agile software developers favor simple designs that solve immediate problems, over feature rich frameworks that provide functionality that you may not use. The reason we agile people believe this is the right approach is that building extensibility adds costs, and spending resources (time and money) on something that may not be used is wasteful.

The approach of focusing on simplicity and shorter time horizons works well on agile teams because agile engineering practices such as unit testing and refactoring make it easier to evolve code when it needs change. Without this agile infrastructure teams can fall into the trap of code not changing because change is risky, and what was done first needs to be preserved. Working with the values of doing The Simplest Thing that Could Possibly Work, YAGNI (You Aren't Gonna Need It), and avoiding BDUF (Big Design Up Front) can help you build the right thing more quickly. The challenge is how to find a simple solution, as simplicity doesn't always happen by design. And it's important to remember that "simple" does not mean "no design" nor does a "simple solution" necessarily mean that it is a solution that does less.

Here are some things I try to keep in mind when looking for a simple, agile, solution to a problem:

• To discover a simple solution it's worth thinking through at least 3 options. Even if your first one will be the clear winner, taking a small amount of time to consider the problem may lead you to a better more flexible solution
• Clear separation of design concerns leads to more testable, simpler code. If it's difficult to write a unit test for the code that adds some functionality, maybe there is a simpler solution.
  
• Simple design can be flexible design. Often the solution that is simplest to implement and test is the one that lends itself to extension.
  

While simple and flexible are not always correlated, it's important not to toss aside the things you know about good design when you are trying to do the "simplest thing..." Sometimes following good design and testability principles can lead you to a simple design, almost by accident.