CMMI and Agile Blog

January 30, 2017

Avoiding two common software project troubled paths by “being agile” rather than “doing agile”

This week I want to talk to you about two common troubled project paths, and give you some simple tips to avoid both.

The first troubled path is putting too much effort into documentation. When you catch your project heading down this path stop and ask:

What is the driving need behind our documentation requirement?

Often there are two driving needs. First, your customer or senior management may be looking for some kind of assurance that the software team is doing the right things.  The second reason is to help users and maintainers once the software is deployed.

Unfortunately, traditional documentation isn’t very good at meeting either of these needs. It isn’t good at helping users and software maintainers because often it isn’t trusted to be kept up to date after delivery.  And, historically, documentation hasn’t been very useful to software teams at helping them create high quality software.

The second common trouble path is reacting to the first troubled path by declaring “we’re agile!” –and throwing out the essentials for high quality software along with the documentation.

Now, today, it is a fact that we are seeing more and more organizations trying to increase agility, but many of these same organizations are struggling to figure out how to “become agile” without jeopardizing essentials for success.  And in a moment I am going to explain more what I mean by that phrase “become agile” because I may not mean what you think.

But first, a little background. You may know that in previous blogs and publications I have talked about Essence.  Essence is a framework that captures essentials for high quality software in a simple way—and most important to today’s topic—those essentials are independent of the degree of agility you are driving for with your teams. Essence also includes a simple language to express practices on top of the essentials to give guidance to your teams.

Today I want to talk to you about three simple parts of an Essence practice and how these parts can help your teams find their right level of agility while not jeopardizing essentials for success and help you avoid both common troubled paths.

Those three parts are:

  • the purpose–or goal– of the practice;
  • the activities conducted as part of the practice;
  • the work products produced.

Activities in an Essence practice are what people actually do when carrying out a practice.  They can vary greatly in prescriptiveness. In other words, you can provide activities in your practice that just specify “what” people must do or you can be much more prescriptive specifying in detail the “how to” side of your practice activities.  Similarly, the degree of detail specified in a work product can vary greatly.

Now, let’s look at some examples from my “Upside Down” book.

In Story Two in Part I of my book you learn about a team that came up with an innovative approach to achieve the goal of their sprint review practice when they learned a key stakeholder could not attend the meeting. They actual got on an airplane and went to the client’s site to engage that customer and get their feedback.

The point I want to emphasize here is that the real goal of the sprint review practice wasn’t holding a meeting called a sprint review which is what too many teams get overly focused on when they blindly zero-in on following specified “how to” activities in highly prescriptive practices.

Stated differently, what we are seeing too often is teams falling into just “going through the motions” of prescribed activities. Other authors have referred to this as the difference between “being agile” and “doing agile”.   And, to be honest, I really didn’t understand this difference until I observed it in one of my own client organizations.

What you learn from that story I just referred to is how a team stays focused on the real goal and figures out a creative way to achieve that goal which is gaining the buy-in of key stakeholders—not holding a meeting called a sprint review.

In that same story you learn about a challenge the team faces with a tester having difficulty communicating with developers.  In this case, the team came up with an improved testing practice that included the activity of developers placing a note in the ticket to the tester.  The note in a ticket could be viewed as an example of a very lite work product—not a heavy documentthat helped the communication problem.

In this story it is important to understand that the goal of the testing practice wasn’t to create a note in a ticket.   The real goal was improving communication between developers and a tester. Placing a note in a ticket was just one possible activity that could help the team achieve the real goal of the practice.  And in this story you learn how the team understood that in certain situations if it made more sense to just get up from their workstation and go over and talk directly to the tester that was an option they could and should use.  This is a perfect example of “being agile” rather than “doing agile”.

What you learn from these stories is that where teams often get in trouble is when they start confusing the activity they conduct as part of a practice, or the work product they produce with the goal.  One simple way to help yourself is to keep asking yourself are we are getting too much into “doing agile” –  or just going through the motions of our rituals, such as sprint reviews even when the key people can’t attend?

Or are we “being agile” by keeping focused on the real goal and coming up with innovative solutions when necessary, such as finding creative ways to engage our stakeholders when they can’t make it to our sprint reviews, and getting up from our workstations and walking over to talk to a tester when their might be some risk of misunderstanding.

One caution here, if you decide to allow more choices in your team’s practice activities by making them less prescriptive– it is also highly encouraged that you provide clear limits to the activities, and coaching in these limits, so the team does not fall into chaos.

Always keep in mind that activities and work products are important parts of a practice, but they should never be confused with the goal of a practice.

When we see this confusion starting to happen it is often a sign that an organization is falling too much into the “doing agile.”

Use these simple practice tips when you are developing your practices and coaching your teams, and you might just find it easier than you think to avoid both common troubled project paths and find your right level of “being agile.”

January 26, 2017

Is Upside Down the key to Moving Forward?

Last week I promised in my next video and blog to explain two specific ways projects often get into trouble and give you some simple tips related to Essence that can help mitigate the risk of both.  I have had a busy week and so I am putting off that video and blog, but it will still be coming soon!

This week I was interviewed by Bill Fox from Container13; Exploring Forward-Thinking Workplaces

https://container13.com/exploring-forward-thinking-workplaces/

Bill asked me some very interesting questions.  One thing I loved about this interview was that I was able to tie in a strategy that may seem “upside down” that is used by the coaches of the 2016 Little League Baseball World Series Champions from Endwell, NY– which is just 6 miles from where I live.

Check out the interview at

https://container13.com/is-upside-down-the-key/

I’ll try to get back on track soon!

January 15, 2017

A Key Value of Essence Related to Troubled Projects

I have been involved in the development of Essence since 2010 along with many other volunteers from around the world representing industry, academia and research.  And I have spoken on the subject of Essence at numerous universities and in many organizations including many of my own client organizations.  And the reaction I often get—to be frank—has been mixed.

Some people immediately see the potential value and react with comments like:

“Wow! I wish I knew about Essence when we were planning our last project.”

While others react with comments like:

“I don’t get it?” or

 “Why do we need it?” or

 “What’s so great about capturing what we’ve known for years?”

 Although it has taken me some time to figure it out, I now understand at least part of the reason why people react differently when first introduced to Essence.  The reason is because each person views Essence through the lens of their own experiences and perspective.  As an example, I can view my own clients as falling into two distinct types each with their own distinct experiences and perspective.

One type includes successful organizations with happy customers. These organizations have great people with proven track records of creating high quality software and meeting their cost, schedule and performance commitments within reasonable tolerances.  They come to me for coaching because they want to keep aware of the latest thinking and innovations in software development.  They do this because they know they have to keep getting better if they are to stay ahead of the competition.

The second type includes those who seek my coaching because their projects are in trouble.  Many in this group aren’t meeting their commitments and their customers aren’t happy and many don’t even know how they got into the mess they’re in.

Interestingly, it’s the first type who often respond when introduced to Essence with questions like,

“Why do we need it?” or

“What’s so great about capturing what we’ve known for years?”

 While the second type often respond with comments like,

 “I wish you were here and had told us about Essence when we were starting this project!”

When I help troubled projects I have found Essence to be an incredibly useful tool to help communicate to key organizational and project team leaders in a simple way where they went off course, and how to get back onto a healthy path.

This is a key value of Essence specifically related to troubled projects— it is a tool that can help you quickly pinpoint a problem area, and then drill down into that problem area, locating precisely what needs to be done, and then communicate the critical information to the people who need to know to get the project back on course.

I like to use a sports analogy to help explain this key value of Essence:

Most of us don’t appreciate a good referee in a well-played sporting event because we are focused on the game and the great performance of the players in the game.  But when the trouble starts, that is when the value of a good referee is recognized and appreciated by most of us.

What is interesting about this—and the parallel back to software– is that people who have only experienced successful software development efforts often don’t appreciate the value Essence can bring to– not only troubled projects– but to all projects, even the successful ones.  To help my successful clients understand this I like to ask them to think about the following:

Even though you are successful today, how confident are you that your next project will be as successful as your last?  And even for your current successful projects, how confident are you that the success you are currently experiencing will continue tomorrow?

 The point is that on all projects— successful or troubled—there is always risk of new circumstances and new challenges that can jeopardize future success.

 So what are you doing to mitigate that risk today?

While Essence clearly has proven itself in helping troubled projects today, its greatest value may actually lie in helping to mitigate the risk all software projects face of loss of essential software engineering activities that we now know exist and have captured in the simple Essence tool.

In my next video and blog I will explain two specific ways projects often get into trouble and a specific feature of Essence that can help mitigate the risk of both.

December 27, 2016

What I’ve learned about software development and why it seems opposite to everything I was taught

In this blog I would like to share with you what motivated me to write my latest book, which is titled: “It’s All Upside Down”.  And I would like to tell you a little bit about what’s in Part I of the book.

So let’s start with the motivation. The title of this blog post is actually the subtitle of the book, which has a lot to do with my motivation for writing it.

In just the past few years I have made such drastic changes in how I help software development teams as a coach that it often appears what I am recommending to my clients is the complete opposite of many well established long held software engineering principles.

Now, in fact, my recommendations are not really in opposition to these principles at all—but they appear to be because what actually works in practice oftentimes isn’t what we think based on what many of us have been taught.

This was my major motivator for writing this book. I wanted to share true stories of what we have recently discovered really works for successful software development teams in practice.  There are eight stories in Part I of the book that all occurred in 2015 and 2016.

As I share the stories I also highlight 26—what I refer to as– “upside down” principles.  Now, the principles themselves are not really upside down.  What is really upside down is what many believe they need to do to effectively apply these principles.

To help communicate this message I focus each story around three key items:

  • First, the activities successful teams conduct in practice
  • Second, how much of these activities they conduct
  • And third, when they conduct each activity

 

I expect many readers will be surprised to learn how little time successful software development teams spend on certain activities that have traditionally received high focus, and–even  more importantly–  how much time is actually spent by successful teams on activities that traditionally have received little attention.

In closing this blog I would like to point out that I am certainly not the first person to have observed that what works best in practice often doesn’t match the theory.

It is also worth pointing out that this observation is not unique to software development. As the immortal New York Yankee baseball legend Yogi Berra once said:

“In theory there is no difference between theory and practice.  In practice there is.”

Now, in this blog I have referred to both principles and best practices.  In my next blog I will share with you why I focus more on principles in the book, and I will explain the power that principles can bring to a software development team’s performance.

Click to purchase the book

September 23, 2015

What’s the Difference Between a Practice and a Pattern and How do they each Improve Performance?

What’s in this Blog

In this blog I answer this question, as well as share status of work I am currently doing using the new Essence framework and patterns with two of my clients.

Blog

I recently started reading a great book titled The Pragmatic Programmer by Dave Thomas and Andrew Hunt and was pleasantly surprised to see a discussion on patterns. At a number of conferences I attended this year the subject of patterns and how they relate to practices was a common discussion topic.

So just what is the difference between a practice and a pattern and how do they each improve performance?

To help you understand let me step back and explain some activities I have been involved in over the past few months and how I am using Essence and patterns to help two of my clients improve their performance.

In June this year I talked at the Agile West Conference on the subject of patterns –http://conferences.techwell.com/archives/bscwest-2015/sme-profiles/paul-e-mcmahon.html, and I gave a workshop at Binghamton University –http://www.binghamton.edu/watson/industry/professional-development/programs/essence.html, on the topic of Essence, the new OMG standard (www.semat.org). I explained in my talk how Essence differs from other popular frameworks and how organizations can use it to help discover their own best patterns.   In August I gave a similar keynote address and workshop at Agile Africa.

As I explained in an interview at Agile Africa in August I have started referring to the patterns I am sharing as “thinking patterns” because they help practitioners make better decisions.

Thinking patterns differ from practices in that they set a specific context related to an organization’s current pain points. This is key to getting a discussion going in the organization related to where performance improvement is needed. Essence checklists can be used to help stimulate the discussion– not to tell the team what to do– but to get the team to decide what they should do to improve their performance given their specific situation.

What is great about Essence is that it is independent of any specific method so any team can use it. It doesn’t matter what practices an organization is currently using. It can help teams discover their own best patterns– and anti-patterns they need to avoid– leading to improved practices and better performance.

I have been involved in the software development business for forty-two years and I am only now finally discovering that we have spent a great deal of time defining processes (or practices) and the effort we have put into this activity has in too many cases failed to payback in real team performance improvement because they are not giving practitioners the real help they need to solve many of the challenges they face each day.

We still need processes, but processes help primarily when you are a beginner. Once you have moved past the beginner stage, practitioners often need more focused guidance related to the specific challenges they face each day.   This is where Essence and patterns can help.

As an example, I am finding that Essence is a really good framework to help organizations that want to become more agile to improve performance but are fearful that they might lose critical disciplined engineering processes as a result. This is a valid concern because a lot of companies when they jump to agile, miss essential fundamental engineering practices that they still need to conduct.

Essence provides the fundamental common ground that helps teams continually ask the right questions to ensure they are not losing essential engineering practices as they move their organization to a more effective way of working.

You may have heard the phrase; “With Essence your practices come alive,” and, “Essence practices are what practitioners really do, not what someone thinks they should do. “ I have been using Essence with one of my clients for the past few months to help them address specific pain points, and I am just now getting started using Essence with another client to help them rapidly improve their performance.

What I am learning is that patterns are a great vehicle to make your practices come alive in the eyes of practitioners because they provide concrete examples in how to think through real challenges leading to better decisions given your specific situation.

Over the coming months I am planning to share results from my two current projects and hopefully share successful case studies using Essence and thinking patterns together to improve performance.

January 19, 2015

New Video on Practical Ways Teams Can Use Essence and New Published Paper on Essence

A few weeks ago I shared a You Tube video providing highlights of Part I of a talk on Essence (44 minutes) I gave at Binghamton University in November, 2014 to a group of Computer Science students.  Highlights from Part II of that talk are now available where you can learn practical ways software teams can use Essence including games they can play to help assess where they are, how to conduct a root cause analysis to isolate a problem, and how to use patterns to improve their performance.

Highlights of the talk can be found at:

http://youtu.be/eosjm4NmFS8

The Part II highlights are 30 minutes in length and at the front of this video you can find where in the video the following 13 topics can be found:

  1. Assessment Poker
  2. Case Study Results Carnegie Mellon West
  3. Root Cause Analysis Example
  4. How Essence Differs from Lean Six Sigma
  5. Examples Using Activity Spaces
  6. Using Essence Competencies
  7. Another Example Using Activity Spaces
  8. Where Can Essence Help Most?
  9. Practice Slices and Patterns
  10.  Two types of information practitioners need
  11.  Examples of Patterns
  12.  A Closing Thought
  13.  How Students Are Using Essence at Binghamton University

I also have a new published paper on Essence titled,

A “Thinking Framework” to Power Software Development Team Performance, appearing in Crosstalk, The Journal of Defense Software Engineering in the Jan/Feb, 2015 edition.

http://www.crosstalkonline.org/storage/issue-archives/2015/201501/201501-McMahon.pdf

December 27, 2014

Essence: What’s New and Different?

In November of this year, 2014, I gave a talk on Essence at Binghamton University to a group of Computer Science students.  You can catch the highlights of Part I of the talk on YouTube.  This is a great video to watch if you want to learn what is new and different about Essence, the new software engineering Object Management Group (OMG) standard intended specifically for software practitioners.  If you don’t have time to watch the complete Part I– which is about 44 minutes– you can find a cross-reference at the end of the video to where in the video you can find the following 23 key topics:

http://youtu.be/uDELOAAFVlA

  1. What is Essence?
  2. The Difference Between Scrum and Essence.
  3. What Does Essence Contain?
  4. Why Did We Create the Strange Alpha Word?
  5. What is Different About Essence?
  6. The Essence CARD Deck.
  7. An Example Demonstrating How Essence is NOT Waterfall.
  8. A Question About Essence Versus Scrum.
  9. How Essence Can Power Whatever Approach Your Team is Already Using.
  10. About the Problem We Are Trying To Solve With Essence.
  11. How Does a Team Use the Essence Model?
  12. How Essence Checklists Are Different.
  13. How Do Teams Apply the Essence Checklists?
  14. On the Importance of Knowing When You Are Done.
  15. A Question on How a Team Can Fall Back.
  16. On the Order You Address States, and Decisions on Checklists that May Not Apply.
  17. An Example of a Team Deciding if a Checklist is Applicable to them.
  18. On Activity Spaces.
  19. Competencies Within Essence.
  20. How to Figure Out if You Have a Leadership or a Management Competency Issue.
  21. What if a Team Can’t Meet a Checklist Item?
  22. Why Isn’t Risk an Alpha?
  23. Why is Hardware included in the Definition of the Software System Alpha?

As always, your comments and feedback are encouraged.

August 18, 2014

A Slightly Different Way to Think About the SEMAT Vision and the Essence Framework

In last week’s blog I asked readers to consider providing feedback as to whether the software community needs a framework that fits the needs of the framework vision described in my 15 Fundamentals book.   Tom Gilb replied by referring to his comprehensive handbook on “Competitive Engineering” (a book of about 450 pages).  I have read a good deal of Tom’s book and find value in it.

I have also read much of Scott Ambler and Mark Lines’ “Disciplined Agile Delivery” book (about 550 pages), and I have read Barry Boehm, Rich Turner and their co-author’s recent book, “The Incremental Commitment Spiral Model” (about 240 pages), and going back a little further in time, I have read multiple times Watts Humphrey’s “A Discipline for Software Engineering” book (almost 800 pages).   In all of these books I have found useful ideas and great value. 

Right now I have two clients I am helping who have very different situations, but need similar help related to figuring out the right practices for their organization to keep them competitive in today’s rapidly changing and demanding world. 

I, as a consultant, need to find the time to read books, like those mentioned, because I need to keep up with the latest thinking of the best thinkers in the field of software engineering so I can provide the best advice to my clients when asked. 

In reading each of the books mentioned above I observed useful new ideas and/or innovative techniques, but I have also found certain ideas that I interpret as essentially similar to ideas I already know and understand.    So in the interest of time-management– and getting the most value out of my “new book reading time”–I read books with a filter on. 

My filter seeks out the strengths of each book in terms of what I perceive as new and potentially useful that I can add to my current knowledge base.    I then make conscious mental notes allowing me to rapidly recall each new idea or innovative technique when I observe a client situation where the new idea could be of benefit. 

This allows me at the right time as a consultant to stop and say to my client:

“Hey I think you should take a look at … [fill in one of those books, chapters, ideas/ innovate techniques here]… because I think this idea or technique could really benefit you given the problem I see that you are currently facing.” 

Keeping up with the latest thinking of our best software engineering thinkers is something I must do because I am a software process professional and this is what keeps me competitive in my own business.

My clients come to me because they don’t have the time to do this themselves, and they don’t have the funding in today’s competitive world to keep their staff current on all the latest thinking in software engineering.  I thus provide value they need that they don’t have inside their own organization.  This keeps my business viable. 

But what if there was a way for software practitioners— programmers, analysts, testers, managers—who are actually working on real software projects facing real challenges every day to quickly access and use the strengths and new ideas of these great software engineering thinker’s without having to read hundreds and hundreds of pages as I do to keep my business thriving? 

While I personally look forward to reading great new books on new approaches to help with the challenges of software engineering, most real practitioners just don’t have the time to devote to this activity. 

So– as I expressed in my response to Tom Gilb on my blog last week– what if we could find a way to make the strengths of Tom’s “Competitive Engineering” handbook more easily accessible to the practitioners who need help every day?  And taking this idea a bit further, what if we could find a way to do the same for Scott Ambler, Barry  Boehm, Watts Humphrey’s and all the other great software engineering thinkers work so that practitioner’s could quickly see and access the strengths of each,  compare  them, and then make logical decisions without needing to devote hundred’s of hours digesting hundred’s of pages of books?

Obviously, we would need to be careful how such a framework was implemented because any simplification of serious thought-provoking work could always be open for criticism.   But on the other hand, we know as George Box has pointed out, “all models are wrong, some are useful.” 

So do you think such a framework might be useful to the software engineering community? 

What I am suggesting here may be a slightly different way to think about the current vision of SEMAT and the Essence framework, but in a sense this isn’t far from what SEMAT is trying to do. 

The SEMAT community envisions an open marketplace of software aids (practices, patterns, methods, hints, and so on…)  where software practitioners can easily see what is new, compare it to what they currently are using, and make effective and timely decisions that can help their software endeavors today based on their own specific circumstances. 

I would love to hear what you think.  Does the software engineering community need a framework that fits this vision?

August 12, 2014

Three Great Book Titles and One That Missed the Mark: Part II

In last week’s blog I explained how I whittled down a long list of possible titles for my latest book to the following top four choices:

  • The Essence of Improvement
  • 15 Fundamentals for Higher Performance in Software Development  
  • Better Decisions Through Better Practice With Patterns
  • A Framework Vision for Higher Performance in Software Development 

Only one of the titles came close to meeting Peter Gordon’s rule of keeping the title to three words or less, and that was “The Essence of Improvement”.  I liked this title for one main reason besides its length.  I worked with Ivar Jacobson and our co-authors on the “The Essence of Software Engineering” book which focuses on the essentials—or common ground—that always exist across all software engineering efforts. 

I was originally thinking when I started to write my latest book that I was going to distill “the essentials that are common across all improvement efforts”, and so the title “The Essence of Improvement” seemed perfect.  But as the book evolved based on reviewer comments, discussions, and my personal analysis of past experiences working with multiple clients, it became clear that what I was talking about in this book was not common at all.  In fact, the 15 fundamentals– while they seem simple on the surface— are rarely achieved or thought about in most organizations today. 

There was also another problem with this title.   While I have found value in these fundamentals in my own personal improvement efforts as discussed in the book (e.g. golf), the vast majority of the examples I provide relate to software development.  So the simple “Essence of Improvement” title was reaching too far without sufficient research and proof into what it takes to improve and sustain improvements in other endeavors. 

If you read my two blogs over the past few weeks about Practice Slices and Patterns you should have a good idea why “Better Decisions Through Better Practice With Patterns” would have been a great title for this book.  The value of patterns is a key point that I highlight in this book, and I provide many pattern examples from my software development experiences both as a practitioner and as a coach. 

As I researched the pattern idea I became increasingly excited when I found numerous examples of similar experiences to my own in areas that had nothing to do with software development.  Examples include the idea of “thin slicing” discussed by Malcolm Gladwell in his book “Blink: The Power of Thinking Without Thinking”.  

A second example was found In Daniel Kahneman’s book, “Thinking Fast and Slow”.  In this book Kahneman explains how we can improve our quick–or intuitive– thinking by learning to recognize common situations rapidly.  This idea fits perfectly with my own experiences in software development, especially when rapid decisions need to be made by software practitioners on a high pressure project when a deadline is approaching. 

My favorite story that I convey in my book to explain the power of pattern recognition among athletes I borrowed from Jonah Lehrer’s book, “How We Decide.”   This is the story about Tom Brady, Quarterback for the New England Patriots football team in the National Football League.  In this story the reader learns how Tom prepares for football games which gives you an idea why he is such a great quarterback when the original scouting reports indicated he would never make it as a professional athlete. 

The analogies between what Tom does, and what I have found software practitioners can do to help prepare for typical situations they face each day– especially on a high pressure software development project—may well be the most compelling part of my book.  This also turned out for me to be the most rewarding part of my research and work in writing this book.  For that reason this title was my own personal favorite.  It was also Bill Fox’s favorite. 

A late entrant into the list of possible titles was “A Framework Vision for Higher Performance in Software Development”.   I liked this title because the framework vision, which I added just in the last few months of writing the book, turned out to be a major strength of the book based on comments from a number of my reviewers. It was exactly what was needed to help people understand why we need a framework like the Essence Framework.  Creating this framework vision also helped me personally– as one of the volunteers who developed the Essence Framework—to step back and see more clearly the bigger picture and the need for a framework such as Essence.    

The Essence framework is difficult for many people to understand when first exposed to it for a number of reasons.  One reason is because it is not immediately evident to many people why we need this new framework, or what problem it is solving that other software frameworks have not been able to solve.

By presenting the framework vision in the book using very simple non-technical language it helps the reader to first understand what is needed and why we need it, before we talk about a specific solution. 

 If you take the time to read my book– whether you like the Essence framework or not– I would love to hear your feedback on whether you agree or disagree that the software community needs a framework that fits the needs of the framework vision as I describe it in my book. 

But when the voting was done, the majority of my reviewers polled preferred the title that highlighted the 15 Fundamentals.  What is it that resonates with the idea of the 15 fundamentals that I highlight in this book?

First, these fundamentals are not what many might expect to see in a book about fundamentals and software development.  You will not see Requirements, Design, Programming, and Testing mentioned.  This is because this is not a book about the fundamentals of developing software. It is a book about the fundamentals of performing at a high level and sustaining that performance even under difficult and often adverse conditions–which are not at all uncommon in today’s fast paced and competitive world– when developing software.

Second, in this book I am calling for a culture change in how we implement process improvement today in organizations. A key point I raise is the fact that the speed of change we are all witnessing in today’s world requires that we step back and take a serious look at the process we are using to help our people get better at what they do. 

It is my contention that we need a far better way than what most organizations are doing today to empower our teams to take ownership for improving their own practices and their own personal performance. 

The 15 fundamentals I present in this book are my way of helping you think a little outside the box about how you might help your own organization get started down this path.  If you only take one or two ideas from my 15 fundamentals that can help you make even a few small changes in your organization that can start you down this road, then my ultimate goal in writing this book will have been achieved. 

Love it or hate it, I would love to hear what you think. 

August 7, 2014

Three Great Book Titles and One That Missed the Mark—Part I

When I asked Bill Fox, author of “5 Minutes to Process Improvement Success” (http://5minutespisuccess.com/ ) what he thought of my current working title of my latest book he didn’t answer.  He just said, “the title of your book is so important.  I think you should write down 100 possible titles, then pick the top ten, and then poll your reviewers to get their opinion.” 

When he first suggested this I thought there was no way I could actually come up with 100 different possible titles, but within a couple of hours I had actually created a list of 102.  The next part of whittling the list down to a top ten took longer.  In my case the problem was compounded by a number of complicating factors. 

First, Peter Gordon, my publisher from Addison-Wesley for my second and third book told me that a title ideally should be no more than three words.  When I looked at my list of 102, less than 10 were three words or less and none of them were my favorites. 

Second, Rachelle Gardner, a literary agent says, an author needs to do everything possible to come up with the best possible title because your title “sets the tone, … and hints at the style of the book… and draws the reader in….” (http://www.rachellegardner.com/about-rachelle/).

While Rachelle’s advice makes sense to me, what really complicated this issue was the fact that I had multiple goals in writing this book, and there was no way I could capture them all in a single title.  Furthermore some of my reviewers were highlighting strengths of the book that weren’t even part of my original goals in writing it.

One of the lessons I have learned from writing this book is one should never be surprised if you don’t end up exactly where you set out to go when writing a book.  It is as much a learning process as it is a way to  communicate your ideas.  This is especially the case when you have over twenty reviewers many willing to help guide your thinking.  This also means you need to be open to hearing that the most valuable parts of your book may be different from what you had originally planned.    

My original working title for the book when I started it four years ago, “How to Get Better at Anything” never even made the list of 102.  And the working title I had for most of the second and third year of the book’s development as I wrote and rewrote draft after draft listening intently to my reviewer’s feedback, “Performance Improvement Simplified” made the top twenty, but missed the top ten. 

The top three titles eventually were:

  • The Essence of Improvement
  • 15 Fundamentals for Higher Performance in Software Development  
  • Better Decisions Through Better Practice With Patterns

In the last few months of developing the book a fourth candidate title was also added:

  • A Framework Vision for Higher Performance in Software Development 

In next week’s blog I will share which three titles could have been a great choice and why one of them turned out to miss the mark given where the book ended up.  I will also share which title was my favorite, and why the eventual winner was selected. 

Next Page »

Blog at WordPress.com.