Essence and Problem Solving Blog

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.

January 8, 2017

Helping Coaches Everywhere

In my last blog I highlighted how far a team can go to solve challenges on their own when given just a few simple principles and a clear goal.  But this doesn’t mean that teams don’t need coaching, tips, best practices and a structure that provides clear limits to how the team operates. This leads to the subject of this blog.

Besides the upside down principles, I also highlight in Part I of the book 18 coaching tips.  If you are wondering if a book that highlights coaching tips is for you, it is.  I believe everyone should view themselves as a coach.  But a big challenge most organizations face is how to communicate the right coaching tips to project personnel who need it, right when they need it.

Let me step back here, and tell you a little about my background.

I’ve been involved in the software business for over 40 years—the first 20 years as a software practitioner and the last 20 years as an independent consultant/coach.  And during the second half of my career as a coach I have often been called in to assist troubled projects.  One observation I have made about these troubled projects is that most of them fall into one or more of a surprisingly small set of common patterns.  But more importantly, when that pattern is detected in a timely manner, it’s usually not that difficult to steer the project back onto a healthy course. I’ve discussed this in previous writings and blogs. But this leads to an interesting question:

Wouldn’t it be great if there was an easy way to capture these common patterns and share them with coaches everywhere so more coaches could steer their project teams when needed keeping them on course?

This was my motivator for including a Part II in my book where I have framed the highlighted principles and coaching tips that have emerged from my stories in Part I within a framework called Essence.

If you have not heard of Essence yet, you have probably heard of the foundation from which it evolved, which I also explain in Part II of the book. I also explain with examples in Part II how Essence provides a simple and easy-to-use medium to communicate any organization’s practices, tips, principles, and checklists even among non-technical stakeholders.  This last point about stakeholders is particularly important. 

This is because when you read Part I you will learn how stakeholder issues related to understanding and knowing how to carry out project responsibilities is a repeating theme throughout many of my stories.  But, more importantly, it’s a repeating theme within many of those troubled projects I referred to.   

In my next Youtube and blog I share a personal story specifically related to troubled projects that can help you understand a key value of Essence that took me quite a while to fully comprehend and appreciate.

January 1, 2017

The Power of Principles

In my last blog I shared what motivated me to write my latest book, “It’s All Upside Down,” and I shared a little about what is in Part I of the book including some information about the 26 “upside down principles” (that aren’t really upside down).

In this blog I explain why I have chosen to focus on principles in the book rather than the more traditional approach of focusing on “best practices.”

So let me start this blog with a little background.

In 2015 I was fortunate to be invited to speak at the Agile Africa conference, and while attending the conference I listened to Kent Beck who gave a keynote address.  Kent talked about what he called policies – or what many of us might think of as principles–used at Facebook.

An example Kent referred to in his talk was “personal ownership”.  I found his talk fascinating.  The way Kent presented his material was by showing a single diagram with all of the principles visible.  He highlighted each principle he was about to talk about. Then he explained—using no extra slides, but just informally speaking– how the highlighted principle was implemented by practitioners at Facebook.

Listening to Kent using this presentation style gave me great insight into how work actually gets done at Facebook– and it struck me that he didn’t say anything about specific “best practices” used at Facebook.

This caused me to think about what the difference is between principles and practices.  This led me to the realization that principles are more closely aligned with goals, while practices focus more on approaches–or steps– to achieve a goal.

Now, please don’t jump to the wrong conclusion, or misunderstand what I am saying here.  Practices are certainly needed– especially for less experienced practitioners who need guidance in the steps to achieve a certain goal.  They are also needed for more experienced practitioners who often need reminders. However, there is a power in simply stated principles, along with a clear goal, that practices alone cannot provide.

For those who disagree, or challenge this assertion, I provide many examples in Part I of my book of the innovative activities teams come up with on their own to address their specific challenges.  And they do this with little help beyond having a clear goal and a few simple principles.

As an example, in Story Two of my book I share four specific examples of simple creative activities one of my clients came up with to solve specific challenges faced with regard to a stakeholder issue and a testing weakness the team knew existed.

Now, please understand that this is not to say that industry best practices cannot help teams with specific challenges.  But it is to say that best practices and lessons that were learned outside your organization can never replace listening to your teammates’ current specific challenges, brainstorming possible solutions to solve those challenges, and agreeing on specific courses of action.

Many might think that industry proven “best practices” would always trump whatever an individual team might come up with.  But my true stories demonstrate over and over again where this is often not the case.

Give your team a clear goal, and share some principles along with simple guidance in applying the principles, and you might just be surprised how far they can go to solving their challenges on their own.

I would also like to point out that I am not the first person to have observed the power principles.  Scott Ambler, one of the reviewers of my book, told me that with Disciplined Agile Delivery (DAD) they emphasize principles because people might actually read them and understand them.

In my next blog I will share with you a little bit about why I decided to include a Part II to my book, and what is in Part II.

« Previous Page

Blog at WordPress.com.