Tuesday, December 18, 2012

Where to Start ...

Need to Be Somewhere Different

So we have talked about the six principles, when executed well, that will lead to success. So you are in the middle of your organization and you want to be somewhere different.

Maybe the market has changed, maybe your leadership has changed, maybe you want to enter a new market or maybe your company has been acquired. Any of these situations will create space for change. In order to get through it well you need to know two things.
  1. Where are you today?
  2. Where do you want to go?

Types of Organizations

To help with this, I will describe some different types of organizations. Each of these organization types will require different types of org structures, talents and leadership. The principles discussed will still hold. The style will be different. You can use the following organization types to determine where you are today and also where you want to go.

Harvest (Maintenance)

The harvest organization is all about keeping the existing customers happy (to a degree). The product is proven and its value proposition is well established. Customers know what they have and like it. Organizations in this mode will provide support and fixes for customers to maintain the current value.

There is no plan to modernize or attack new markets. Cost and metrics drive most decisions and are balanced with customer satisfaction. These organizations manage to the margin. Organizations here risk  slipping into technical and third party debt that could force unnatural acts for the organization. Examples include loss of support for third party component, obsolete OS, loss of knowledge on key parts of the system and single points of knowledge failure in the organization to name a few.



Ride it Out (Maintenance with some features)

Ride it out is a lot like the harvest org with a little bit of spice. This organization will push features out on top of its maintenance product. It will do so in the name of customer satisfaction and also for sales. The sales part could be legitimate or it could be a carry over momentum in the organization from that is just what we do.

This organizations is also at risk of neglecting its technical debt in favor of pushing features. Organizations in this mode will usually shift into Harvest mode.


Saturated (Adding Features to Established Product)

The saturated organization, in most cases, has ridden the growth wave. That momentum and the need to squeeze out the remaining sells will lead this organization to create features to close deals. Not all of these features make sense and may cause the organization pain. This organization may have accumulated some organizational and technical debt along the way. Making money covers up a lot of issues. When the money and growth starts to slow, these organizational and technical debt items may become amplified.

Staffing may exceed expense ratios for R&D investment percentages. Reductions may occur and leadership turnover is likely.

Extend (Innovate on top of existing product)

The extend organization will look to create new revenue by integrating new value into their product or solution. This could come from partnering with other vendors, it could come from acquisition, and it could come from create new value on top of the existing product.

This organization could spring up to extend the growth curve of a product or business or it may spring up after the saturation adjustments play out.


Game Changer (Enter a new market)

Entering a new market creates the opportunity to extend financial and business growth  It requires research, investment and expertise. These skills are different than the skills needed in any of the previous described organizations. The game changer is best introduced as the current product is reaching maturity.


Chaos vs. Predictable

No matter what type of organization you have, it will fall on the continuum of chaotic to predictable. Healthy organizations need to strike a good balance between structure and flexibility. 

Healthy organizations will have the following

  • Planned and well executed work
  • Strong practice of continuous improvement
  • Well structured and supportable code
  • Knowledge base for training and support
  • Unit tests and other technical support that will help others maintain the code
  • Automated builds and deployments
  • Servant leaders
  • Strong regression support with automation
  • Metrics at development, qc, services, and support that impact org behavior
Organizations that struggle will have the following
  • Manage by fire drill. React
  • Growing technical debt
  • Tribal knowledge that is decaying
  • Blame game. Selfish leaders
  • Either little process or over process that is used to cya
  • Need for heroes
  • Lack of meaningful business metrics

Healthy organizations will have a better shot at maintaining what they have as well as being able to move and adapt with change.

Wednesday, November 21, 2012

Provide Accountability (Principle 6)

You may want to read my initial post for perspective
Everything I Needed to Know

Accountability (The Multiplier)

Providing accountability shows that your care enough about your mission and your people to get involved and make things happen. Accountability provides the backbone to the other five principles. Practicing accountability multiplies the effects of the other principles.

I am sure we have all had the opportunity to see a child in full tantrum mode and a parent or adult all to willing to give in to make the pain go away. Though the pain may go away temporarily, the child has been rewarded and now knows that a nuclear tantrum will get him/her what they want. And I am sure we have all stood in judgement of the situation knowing that we would and could do better. Without accountability, our people, our teams and our organizations will have its own form of tantrums.

Create the Right Environment

Effective accountability requires creating the right environment. Accountability works best when expectations are set and understood. Without the right expectations, applied accountability can demoralize a person, team or organization. For example, a fixed scope delivery date mandated by leadership without evaluation of team based estimate and planning creates the wrong type of expectations. Regardless of how the project turns out, the people basically did as they were told. Their accountability was to do as they were told.

In order to create the right type of expectations for accountability, following the first three principles is a great start. Defining a problem clearly gives people the clarity they need to execute which leads to clarity of ownership. Definition of the problem will always require an understanding of the customers and what their success will look like. And finally, practicing continuous improvement means that the bumps on the way must be examined and acted upon. Maintaining is not good enough.

Accountability Moves People and Teams from Apathy to Engagement

Lack of accountability parallels apathy and apathy is the beginning of the end for your team or organization.

Many people do not like applying accountability because it involves conflict and can be uncomfortable. Leadership requires one to lead through this. Though accountability can be hard, as leaders we must move from apathy to engagement. Applying accountability provides a strong upside. Most people will not like the initial parts of accountability but at the core, people need this honest feedback to grow and thrive. When done with respect and good will for the person, it will, in most cases, be received well and end positive. Either way, the person or team needs to respond to the feedback and chose to be in or out. You will avoid apathy.

A Story

I once had a senior architect on one of my teams. A talented and capable person. This person out executed just about everyone in the organization at the individual level. This person was frustrated with the results from other team members and wanted "justice". I explained, that as a senior level architect, you need to be a multiplier. Your job is to make those around you successful. This can be done through training, setting technical patterns/standards, design reviews, code reviews and process changes. I am more concerned about the overall team delivery results than the results of one (we must follow our delivery to our customers).

We went through the job description for a senior architect and used it to set expectations for the role. We agreed on some next areas of improvement and we agreed on how I and other leaders need to make changes to support this person in the senior architect role.

The road was difficult. This person exceeded at individual level execution, but had a hard time being the multiplier for the team (and as a side note, the team was technically capable and reasonable). We had many conflicts, discussions and coaching sessions.

The senior architect ends up leaving and that was tough. Myself and other leaders experienced some first hand on the job training for what we need for our organization in the way of a senior architect. I heard later that the senior architect that left appreciated the honesty and feedback and that was helpful in his new role (this person was not appreciative during the engagement). The leadership team did go on to hire several other architects and this experience gave each of these leaders a clearer vision on what the organization needs out of this role.

In the middle of this, I would be lying if I said I knew it would work out. All I knew is that not providing the accountability and direction would be harmful to the team and organization. We would be endorsing apathy. You have to thoughtfully lead to make positive changes. This requires action.

Some Things to Try

  • Introduce agile to one or more of your projects. Self managed teams.
  • Tighten up your execution and support of agile
    • Attend iteration reviews
    • Attend standups
    • Verify that retrospectives are taking place and that actions items are being completed
  • Examine your existing job description for your people
  • Create job descriptions if you do not have them
  • Use the job description to help set correct expectations with team members
  • Help them succeed in their role
  • Provide frequent feedback (focus on finding the positives and coach through the negatives)
  • Year end reviews should not be surprise
  • Look to create team based ownership. Allow for controlled opportunities so they can learn.

  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

Wednesday, November 14, 2012

Practice Teamwork (Principle 5)

You may want to read my initial post for perspective
Everything I Needed to Know

An Example from Baseball

 Below are the World Series participants from 2007 to 2012 along with their team salaries and the max team salary in MLB. Here are some stats:

Year
Winner
Team Salary Rank
Runner Up
Team Salary Rank
Highest Team Salary
2012
SF Giants
8th ($117M)
Detroit Tigers
5th ($132M)
$197M
2011
St Louis Cardinals
11th ($105M)
Texas Rangers
13th ($92M)
$201M
2010
SF Giants
10th ($97M)
Texas Rangers
27th ($55M)
$206M
2009
NY Yankees
1st ($201M)
Philadelphia Phillies
7th ($113M)
$201M
2008
Philadelphia Phillies
12th ($98M)
Tampa Bay Rays
21st ($43M)
$209M
2007
Boston Red Sox
2nd ($143M)
Colorado Rockies
25th ($54M)
$189M

  • The winner on average paid $74M less in payroll than the highest paid team
  • The runner up on average paid $119M less in payroll than the highest paid team
  • How the above 12 teams salaries compare to the rest of MLB
    • 50% pay in the top third of the league
    • 25% pay in the middle third of the league
    • 25% pay in the bottom third of the league
So what can one conclude or infer from this data. Money alone will not win a title. Money will buy top talent and top talent alone will not guarantee a title. There is more and it is magical. We have all seen it, we all want it and at times we are afraid of it. The it is TEAMWORK. We want it because we want to win and we are afraid of it because we must surrender part of ourselves to the larger goal. This requires trust and vulnerability.

The teams above won because they combined together to be better than the sum of the individuals. They captured the magic in the form of a team using teamwork. Many love the idea of teamwork, but fall short of getting there. Why?

Build Team By Removing Anti Team Thinking

In short, I believe selfishness, leadership style, and a focus on the short term limit many organizations from becoming team oriented. Lets start with selfishness.

Selfishness

Leaders need to place the value of teamwork above themselves and the individuals on the team. This means creating space, rules, principles and rewards that support teamwork. Saying it, holding an offsite, sharing your feelings will not magically make it happen. The book Five Dysfunctions of a Team does a good job of pointing out the ingredients needed for a strong team and some steps to get there. It must be built into the culture and the leadership

Selfishness - The Hero

The hero is the enemy of being team. These are people that derive great value from being the savior. They hold key knowledge and are reluctant to share. They manipulate circumstances to highlight their heroism. They like hearing how much they are needed. The hero is truly selfish and subscribes to the scarcity mentality. There is not enough greatness for all, I must protect it for myself. People around this person will struggle to grow and though they may be labeled a team, they will not win like a team.

Selfishness is even worse when you take it to the role or departmental level. When blame or discussions revolve around statements like its developments fault, or product managements fault, the organization looses sight of the customer and delivering value. They are not operating as a team and like the baseball teams, they may spend a lot of money, but will not make it to the big game.

From a development process point of view, agile succeeds on self managed teams. Agile promotes teamwork in backlog grooming, sprint planning, daily stand-ups, reviews and retrospectives. Agile, in its true form, will not reward the hero. When one company went to agile, one of the key people (the hero) went to HR and complained that he/she did all the work and did not wanted their review to be tied to the team. In this case, the person has challenged the mission of the organization. Will the org bow down to the hero or will it risk moving forward for the multiplier principle of teamwork.

Leadership Style

As stated above, teams succeed when individuals willingly give their creativity and passions to a mission larger than themselves. They are committed to serve the team and work to win at all cost. For the individual, this requires a level of vulnerability and trust. Leaders needs to protect this. You cannot scream team and then turn around and undercut it. Leaders need to create space and rewards that recognize the team more than individual accomplishments. I have heard from people at review time or in a 1 on 1 discussions how great they did and how valuable they are. I ask them, are we making our goal and show me how you are making people around you better. This throws many people off and the reality is many cases they are great (just individually great). Leaders need to promote that greatness along with the willingness to serve and help those around them be great as well. We succeed or lose as a team.


Focus on the Long Term

When focusing on the short term, we will tend to do what it takes to maximize the outcome. Beg borrow and steal for today and worry about tomorrow later. Team thinking can be deconstructed quickly in this kind of environment. It matters not what the team said they could do, they are mandated to make a date, do it a certain way all in the name of results for today. It is much harder to better define the problem and give the team space for controlled opportunities. In agile, it is common for teams to fail their first 3 or 4 sprints. You will need to look beyond the short term to give teams chance to form. For teams, it is more about how you finish than it is how you start.

In closing, teamwork, along with professional growth and accountability, are the multiplier principles. These are the principles, when executed well, create high performing organizations. Do not under estimate the power of a talented team, with a big hard problem, and the organizational support to make it happen. Watch the movie Apollo 13 for a great example of teams rallying together for a great cause.

Some thing to try


  • reward teams for team successes. Public recognition, team lunch, a thank you.
  • look to diffuse hero behavior and move to team ownership. This may mean some tough conversations with some of your "best" performers.
  • set goals at the team level based on team delivered results
  • reward team behavior even if the results needed to be better and help give the team what it needs to be better
  • do not be afraid to take some chances
  • work through team training like Five Dysfunctions of a Team
------

“Individual commitment to a group effort - that is what makes a team work, a company work, a society work, a civilization work.” Vincent Lombardi
  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

Monday, November 12, 2012

Provide Professional Growth (Principle 4)

Practitioners and academics have argued that an engaged workforce can create competitive advantage. These authors say that it is imperative for leaders to identify the level of engagement in their organization and implement behavioral strategies that will facilitate full engagement. In clear terms, they describe how leaders can do that.  


To say it on a lighter note, a CEO was asked how many people work in the company. The CEO's response was about half.

A disengaged employee or team member places many stumbling blocks for the team and the organization. First, they harm themselves. They have settled for less than their given talents and potential. They become numb. They lose creativity and trade it in for “I do as I am told” mentality. Second, they can block others and make it harder for others to be engaged. It takes five to ten positive comments to overcome one negative comment. In the same fashion, a disengage employee will require some multiplier of motivated and engaged employees to overcome the one disengaged employee. This pattern is even worse when you consider teams or organizations that become disengaged.

Move From Do As Your Told To Unleashed Creativity

So providing professional growth creates an environment of engagement. People tap into their gifts and talents. They release passion and energies that cannot be forced or managed out. It happens when people care, trust is high and people feel supported.

As a leader, I have heard the question many times: what do you want me to do? I wish it was that easy and I wish I was that informed and that smart. I know that if you do what I want, I will get a dim version of what is in my head. I will lose the creativity of others and the opportunity to learn from them. The better question would be what do you want to do and how can you help with our mission. People need to own their own growth. We as leaders need to create space and support for them to grow.

Creating space for experiments with tough love feedback provide great opportunities for people to grow. In one of my assignments, I had a person that differed on me on how to structure a team and integrate some contractor resources. I felt strongly on my position and knew I was right. I had the choice to force my will or allow the controlled experiment. I worked with the person and we agreed on the needed outcomes for the teams. We also worked through the risks and concerns. With that, this growing leader was on his way. It was so not done the way I would do it and it was very successful. We both win. The business gets strong delivery, the leader has grown in experience and confidence, and I have become more humble. In the case when it does not go as well, the item of controlled experiment comes into play. I never put people in a place that a failure would cause them long term harm. I must be willing to own the risk. The “failures” become teachable moments and can provide equal or greater professional growth than the successes.

In the agile world, the concepts of broadening the T’s, retrospectives and self managed teams all support and encourage professional growth and engagement. As agile leaders, we must build and protect the environment to support the agile principles.

Team Turn Around

I worked with a team demoralized by politics, unrealistic demands, technical debt and general tone of you suck. The team had a deliverable due in a week. The team was behind and the quality was low. I asked the team if we would make it. One person spoke up. This alone was amazing. The team mostly looked at the floor and waited for the “beating” to be over. The person said we will make the date. We have to. I then asked will it work and be good quality. The answer was a definitive no. I then asked when we could have a good release. I will tell the customer we will be late. I just need to tell them when we will deliver. The team did not know how to respond. We have never been asked that. When can you have a plan pulled together? The team thought for a moment and said can we tell you in the morning? I said sure. What if we do not make our final plan, the team asked? How are we doing so far on delivery with quality? Not so good. Then we have room to get better, so make it happen and let me know what you need.

The team began to turn around. People owned problems, asked for help, took on challenges, and people smiled in meetings. It was still crazy, less political, still had technical debt, but the people were allowed to own and grow. It takes courage to start. It becomes contagious and is fun to be a part of. The irony is that it provided professional growth for me and I too was more engaged.

Here are some ideas that could help with professional growth.
  • Introduce agile and self managed teams. 
  • Allow people to shadow or swap roles with another 
  • When approached with a problem ask for some solution choices and help or let the person run with making it happen. 
  • Create space in your plans for some controlled experiments. Time between releases is a good time for this. 
  • Provide honest feedback to people. Tough love. 
  • Look to remove toxic thinking and if needed the people behind it. 
  • Meet one on one with your team members and find out about their goals and desires. Look for places to get them started. Ask them where they think they could get started. 
  • Be truthful and what you will and will not do. False promises are worse than doing nothing. Apologize when you make mistakes and work to make it right.  
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

Thursday, November 8, 2012

Practice Continuous Improvement (Principle 3)

I had the opportunity to swim at Laguna Beach. As a person that spent most of his beach time on the east coast in Florida, I found that the west coast provide three things that were different. The water is much colder, the currents are much stronger and the shore drops off quicker. The waves were awesome and the body surfing was great. I loved it and I was getting tired. I rode a wave in and was expecting to touch ground. No ground to be found. The current quickly ripped me back out to where I was before. I rode the next wave and tried again and again I found myself pulled back to the same spot. I was getting cold, tired and a little panicked. I took a moment to look around. I found that a group to the right of me seemed to be having less trouble getting in. I began swimming in their direction and sure enough I was able to make my way to shore.

Many organizations are happy to remain stuck in the waves. What has worked before is good enough. This is the way we have always done it. I am just doing what I am told. (Please comment on phrases you have heard that reinforce the status quo). Avoiding moving forward is in effect moving backwards. It took energy to create the product, the organization and the culture. What got you here will not likely keep you moving forward. Competitive environments depend on challenging the current state to reach a better state.
Here are some areas that I have had the opportunity to introduce the principle of continuous improvement in my career. I have done this at all levels of leadership ranging from individual contributor to the head of an organization. By practicing at the level you are today, it will afford you the experience and maturity to be ready to perform at the next level.

You must build it into your culture and make it part of your process. This means creating time, examining, following up and coaching to move things forward. Agile provides great support for this in backlog grooming as well as the iteration retrospective. Backlog grooming needs to address both product needs as well as technical debt. Focus on one at the exclusion of others will grind your productivity to a halt (A book for reference: Managing Software Debt by Chris Sterling). Product management and development must be as one when tying together business strategy and the technology needed to support it.

The use of the iteration retrospective (effectively) by definition guides the team to create improvement items. These retrospectives are powerful since they can address improvement areas in org debt, technical debt, team debt or other areas. As leaders, you need to understand and support their requests. Organizations need to have senior leadership support to remove organizational barriers (Scrum Transition Team). Do not ask for improvement if you are not willing to support it.

For teams that are not full agile, I have used iterative development and the teams complete a technical debt backlog that is estimated and stack ranked. That work is then broken down and completed over in the development iterations. It is important that this work be integrated with the all other work. If it is worth doing, it is worth doing it with core hours.

Some flags that point to continuous improvement items
  • Repeat meetings with same topics and no decisions
  • Manual steps in your process
  • Documentation that is created and not used
  • Lack of stats that measure productivity
  • Defects not being corrected in an iteration
  • People that focus on why not
  • Corrected defects do not stick
  • Endless review meetings
  • Cancel all meetings once a year and see which ones come back
  • Problems solved with long email trails.
  • High defect rates
  • Lack of continuous builds
  • Lack of unit tests
  • Look for high hour/low value activities

It is good to recognize the improvements and celebrate the wins. Get people to talk about the improvements and how they help. Work to make this principle part of your culture. Practicing continuous improvement leads back to define/own, follow to your customer as well as providing support for provide professional growth.

I would love to hear you comments or stories.


  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


Friday, November 2, 2012

Follow to your customers (Principle 2)

Introduction to the principles

In the starting post, I mentioned the following:
  • We get paid when we deliver something that our customers will buy
  • We stay in business when the customers pay more than we spend. 
This may need to be generalized out from the money aspect and focus on the word value. Money in short is a way to measure value. So whether we are a for profit, non profit, or volunteer organization, what matters is that our customers are delighted with what we deliver and that it brings them value. In order to do that, we must know our customers, hear from them and purposefully plan to delight them. At the point our customers become an inconvenience, the organization is on a quick path to losing those customers.

Do you have a customer centered organization?
Who are your customers?
How do you treat your internal customers?

The principle of following to your customers means just that. In some form or fashion, it should be a face to face delivery. It should be personal and the ownership should be there.And for those that have the opinion that I do not know the customer. My job does not put me in front of the customer. That may be true (and you should find a way for them to visit and see how the end customer experiences what you deliver). These same people can quickly work with their internal customers.
  • Dev to QC.
  • Dev and QC to Services
  • Support calls based on current release
  • Spend a day taking support calls
  • Visit a customer. Walk around and see people experience what has been built
  • Did you delight your team members
  • Did you create meaningful unit test
There are many customers to serve on the ultimate journey to delivering value to the end customer. A culture that values both internal customers and the final customer will have a multiplier effect. It will be baked into the organization. Search on Zappos customer service to see what this looks like. (sample article)

Here are some red flag statements that could signal trouble with how the people in the organization view following their work to the customer.
  • Works on my box. My favorite. We will just ship your box to the customer (and you along with it).
  • That is not my problem, that is dept xyz's problem
  • We will fix it later
  • That's not important, that team just uses customer issues to get what they want.
  • That is too hard
  • I am just doing as I am told
  • We did a great job, that other group is just a bunch of complainers
  • Yeah, it could be better, but the rest of the team is not willing to help
As with any of these principles, they can be practiced at the personal level and be effective (for one). As leaders, it is our job to create the space and environment for the principles to thrive.

I have often run into the wall between development and qc. I have seen arrogance on the developers side touting the incompetence of the qc people (by name in some cases). I have seen the iron wall of qc teams rejecting deliveries on the most minor of issues just to "teach" development a lesson. Again, I am huge fan of agile and these issues (when done well) become a team problem and you will be amazed at what a committed team can solve.

As a leader, if you are going to pick a side on any issue, pick the side of the customer. Do not align with your role as dev leader, qc leader, or whatever leader. Align with how to deliver better value to your customers both internally and externally.

So the best place to start is face to face and seek first to understand. As a leader, I often want to use my power to force my way. Maybe I will lobby up to the big boss to get my way. I am right of course (so I think). It has become so clear to me with my children. I hear these great stories of the injustices they inflict on each other. On the surface, the case is compelling. I need to correct this breach of humanity. Being the judge and making the decision will reinforce with them to always petition to me and I will fix it. I feel powerful. I have just become the prisoner. I now send them off to work it out. At times, I will help facilitate. We talk about the needs of each other. We talk about alternatives. We talk about consequences. They get focused on success when they realize they both can loose.

So is the same with our teams, coworkers, parallel departments and all the places our customers live. Start with a face to face conversation. As a leader, coach and teach your team to do the same. Be respectful and polite. Partner on how to deliver better value to the customer. If you run into organizational or people barriers, do the best you can in the short term and look for bigger ways to influence change. Data can be your biggest helper in this areas. If you can tie back to sales, cost of support, cost of development and how to improve, you will get the attention of those that may be ignoring you.

I look forward to your comments, stories and questions. Keep moving forward.

  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

Friday, October 26, 2012

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.


  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



Monday, October 22, 2012

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.