Define and Own the Problem (Principle 1)

Preface - you may want to read the introductory post.

Let me start with the simple and move out from there.

What are we trying to do?  And

Who owns making sure it gets done?

No matter at what level a problem or opportunity exists, it must be defined to be owned and it must be owned to be delivered. Just having an organization or team that does this regularly (and mind you they do not have to be great) will make good strides in providing value.

Seems simple and in well running organizations or teams it is handled without much fan fare. For weaker organizations or teams, problems can be 

• poorly defined or not defined at all
• the wrong problems can be defined
• they are not owned
• they have the illusion of being owned

Once you have definition and ownership, you can improve your outcomes and accountability by asking two questions.

1. Did we define the right problem?
2. Do we have the right owner(s)?

To help illustrate, 

Project status meeting

Project Leader: It looks like we will not make our delivery date due to delayed development and QC.
Development Leader: Yes, we will be late. Requirements were delayed so we had to push out some work.
QC Leader: And of course, that will impact QC.
Project Leader: The date has financial implications. We need to make some corrections. What can we do?
Development Leader: Hard to make up time when requirements are late.
Requirements Leader: Some of the requirements were late. Most were on time or early. It is not a requirements problem.
Project Leader: So what are we going to do?

... Long silence...

Project Leader: I will schedule a followup meeting after I look for ways to crash the schedule.

Meeting adjourns

You have probably been in a meeting like this. And even worse, you have probably had the same meeting multiple times to dance around the problem. This can occur in any type of SDLC. The problem is rooted in the organizational or team culture. So for the example above:

What is the problem? Who owns it?

There are many problems in this. First, the leaders do not behave as a team (Five Dysfunctions of a Team). Second, the project is late and there are financial impacts. Third, it is not clear exactly why the project is delayed. Fourth, it is not clear if or how the date can be met.

When it comes to ownership, all in the meeting have some awareness that the project is late and there will be financial impacts. Having been in a few of these types of meetings, the thought bubbles for the different leaders may go like this.

Requirements Leader: Development always blames us. This is their problem it is not mine.
Development Leader: We have to pick up the slack again because the requirements team goofed around early on in the project. I knew this would happen. This is their fault.
QC Leader: Always the last in the train of misses. They always expect us to pick up the slack. This time I am holding the line.
Project Leader: Someone has to fix this and I know these people never will.

So the project leader walked away owning the problem. All the other leaders left the meeting feeling justified and the primary problem of making the date still exists with no clear plan for resolution.  It is likely this meeting will happen again and with likely the same results.A lot of emotional energy can be spent on these types of issues and meetings and without a direction to move forward, it will rob creative energy from your organization or team.

Break Down

As a leader, you can walk away from the meeting and look at the problems from the meeting and better define the problem and then begin to create ownership.

1. The leaders do not behave as a team (Five Dysfunctions of a Team). 
2. The project is late and there are financial impacts.
3. It is not clear exactly why the project is delayed.
4. It is not clear if or how the date can be met.

You have a team problem of trust and accountability. The team knew well in advance of this meeting about the issues. What are the barriers that keep them from getting through this? The team and not the project leaders alone owns the problem. Following the value to the customers is an organization problem. There are no points for being able to explain why we did not make it. There is only reward for delivery. 

Defining and assigning ownership

We need to make the date for our financial commitment. What can we do to make this happen? If we cannot make it, what can we make and what are the financial, customer and organizational impacts. Finally, this level of execution as an organization is not acceptable. We need to be better going forward. As a team, I want both of these areas solved. I will give you until the end of day tomorrow to provide the time line for addressing these matters.

I would love to hear your stories and comments.

A good book with stories about defining and getting others to own and lead change can be found in the book Switch.

The Principles

1. Define and own the problem 
2. Follow your work to your customer(s)
3. Practice continuous improvement
4. Provide professional growth
5. Build and practice teamwork
6. Provide accountability

Development Principles (a working description)

The following is a working description of the six development principles.

1)      Define and own the problem – All projects contain problems and issues. In fact, the very nature of development is to solve a problem, create a new solution, and make customers happy. Each of has a role in this. Time will be wasted when a problem is poorly defined and/or not owned.

2)      Follow your work to your customer(s) – We get paid to deliver quality software to customers. That is the end goal. The journey to complete that includes many internal customers. Work with your customers to complete clean quality handoffs. In the event of problems, see  principle one and three and make sure you, your team and your partners are working as a team to solve these issues. Acting on principle two will be hard when people, process and planning are weakly defined.

3)      Practice continuous improvement – Without this principle, we will never be better than today and we will likely get worse. As a leader or team contributor, you need to build in time for this improvement. In many cases the cost of doing things at their current state will afford enough time in waste to pay for the improvement. Work with your teams to generate ideas, catalog them, prioritize them, estimate the cost, estimate the gain and then begin doing. Start small and just get in the practice of allowing yourself and your team to improve the game.

4)      Provide professional growth – We depend on good people to make things work. Good people want to be valued and grow. We are not a factory that produces the same thing every day. We need people that are creative problem solvers that work well in teams and follow the general course of process. Practicing the other five principles will generally support this. For managers and leads, Items like strong performance reviews, walk arounds, and one on one time will help. Leaders also need to find out where people want to go and help them in their career. For individuals, be great at what you have been given and strive for more. Look at upcoming releases and planning to find items to own that will advance your learning and growth. Also look at teamwork to accomplish items bigger than can be done alone.

5)      Build and practice teamwork – Strong teams are needed for development along with a good development process. A good idea of one person can become a great idea when combined with the thoughts of others. We need to build teams that promote good communication and healthy conflict. People will always have different views and opinions. Assuming that they are competent in their role, these differing ideas will provide the tension and competition that will produce better results.

6)      Provide accountability – It is rare that I see people purposefully make a mistake or cause the team or business harm. Most people will try to do what is best. In the case they miss the mark, the team and the leaders of the team need to provide that accountability. Left uninformed, they will likely do it again. It is easy to say where we need to be. It is much harder to provide leadership and accountability to get us there. When done well, it will promote teamwork, professional growth and in the end deliver better results to our customers.

All of these principles work best when combined with a focus on people, process and planning. So if you find areas to improve, look at the people, process and planning that is in play. In most cases, you will find a weakness in an area and that will be the continuous improvement item.

Everything I Needed to Know ...

Everything I needed to know about development ...

I believe there are six principles that govern solution delivery and for the sake of this discussion software delivery. Simply stated:

• We get paid when we deliver something that our customers will buy
• We stay in business when the customers pay more than we spend. 

In my life so far, I have experienced both positive and not so positive versions of achieving those two items. I have spent a good part of my career working around organizational debt, tech debt or strategy debt to achieve those two items. I have also had times when a well structured team moved with great ease to solve those two items. I have seen the principles in action as an entry level person all the way to being the head of the organization. The six principles hold true. So here are the principles.

1. Define and Own the Problem
2. Follow the Solution to Your Customer(s)
3. Practice Continuous Improvement
4. Provide Professional Growth
5. Practice Teamwork
6. Provide Accountability

The first three principles will give you a chance to stay in business. The last three are multipliers that will promote bigger and better outcomes. The principles are simple in concept and can be painfully hard to follow in practice. They are impacted by organizational culture, leadership capabilities, understanding of strategy, financial health and many more. No matter what the barriers, choosing not to practice them and make corrections will create an environment that will not go well for the business. On the other hand, practicing them will provide opportunities for success and a much better place to work.

These principles will help anyone at any level of the company determine if we have a chance to succeed or if we are spinning our wheels.

An Example: We Need A Template

I will start off with an example. I was asked or as some would say voluntold to introduce a new tech stack for a project that was in trouble.

• Voluntold - Is the selfless act of volunteering when you have no other choice.

The jest of the problem goes like this. We have a product and it is costly to maintain. We have a product that is hard to install. We have a product with poor quality. We have an organization that in some perverse sort of way seems OK with it. It is not for lack of trying, it just seems that speed of activity is not changing the situation. You may identify with some of this.

So I was asked to make it right. Now this story is much bigger than what I will cover. I just want to use one part of it to illustrate the principles. As with any project, you must have some definition of what you want to build. I am a big agile fan and love self managed teams that get this and move through delivering solutions to their customers. This group was not there. So the conversation goes like this (DL = Development Lead and RL = Requirements Lead)

DL: Where are the requirements?

RL: We have some but they are out of date. They are mostly right.

DL: Great, I have read through some of those and I am not sure I can tell which part is right.

RL: Oh, about 80% is right.

DL: Can we story board out one of the solutions so the team can get started and we can correct the 20% as needed.

RL: We do not have time for that.

DL: So what is the plan?

RL: We will right new requirements.

DL: It seems like that would take more time.

RL: Maybe, but it will be right and we needed a better requirements template and review process.

DL: OK, I have several templates our team has used in the past and I believe story boarding a value delivery for our customers will help determine where to get started.

RL: No, we will build our own template. This is important.

So for the next four weeks, we spent time as an organization creating the requirements template. No requirements, no analysis, no screen mock ups, we just created the template. This little activity pointed out some big red flags and broke several of the six principles.

Define and Own the problem - The governing problem was that we need to deliver a better solution to our customer. The definition of we need accurate requirements was correct but we left off the need to own it together with a line of site to our customers.

Follow to your customer - customers do not use our requirements. They use our solution.We lost site of our customer in this activity. We also lost site of how we must serve our internal customers.

Practice Continuous Improvement - The existing requirements were mostly correct. We failed to ask the question, what is the quickest and best way to close that gap and get moving on delivering better value to our customers.

Provide Professional  Growth - Even if the project moved to a new requirements template, the team missed the opportunity to risk growing by story boarding out part of the solution. Staying with what we know  can be a blocker for growth.

Practice Teamwork - the development leader and requirements leader where definitely not on the same page and the organization allowed this waste of time and money to go on. The organization even honored it with a line on the project plan with a reviewable amount of hours spent on the task.

Provide Accountability - Given that the process took four weeks needed to be a red flag and that some part of the organization (some leader) should have challenged the time and cost of this activity. It was not, so all left the activity justified and positioned to repeat.

At this point, the response could be to leave and give up. If you choose to stay, you must then face the challenge of how to lead through it. You have your own world of opportunities. Which ones could you get started on today?

What Next

I would love to hear some of your stories. Please post them. Also, let me know what makes sense and what areas need help

In the upcoming posts, I will expand on the principles along with some examples of how to move from breaking the principles to living them out.