Great Leaders Create Great Cultures

Great leaders create companies that are fun to work for. Old school thinking is about power and and self-serving behavior. Agile leadership is about an open environment with no offices, flat organizations, continuous learning and improvement, information sharing and aware of your mission for making a difference in the world.

What is culture? A set of shared beliefs, values and practices.  Check out Hubspot's culture at http://slideshare.net/HubSpot/the-hubspot-culture-code-creating-a-company-we-love

Look at a company's culture. It says much about that company's leadership.
 

Five Bad Habits of Leaders in Poorly Performing Organizations

Five Bad Habits of Leaders in Poorly Performing Organizations

There is a cultural war taking placing within the enterprise. It is between the unwashed commoners and the executive ranks. Between those that are adding value vs those focused on advancement. 

In recent years we have seen many bottom up efforts that introduced agile and lean practices into IT and software development organizations. Much has been written of the value realized by such efforts. 

While Agile has focused on effective self-directed teams, it has not addressed a key blocker, dysfunctional leadership. Since Agile values visibility, transparency and courage, it is time to name the blockers manifested by dysfunctional leadership. Once we have named the blockers the next logical step is to remove the blockers.

Remember, a poor performing organization should be laid at the feed of it leaders. The organization performs as it has been led. Lead poorly and the organization is likely to perform poorly.

Below are 5 bad habits of leaders frequently witnessed in poor performing organization. How many have you witnessed?

1. Managing up

Since the first and foremost goal of the eager executive is to get promoted, he or she must focus on those that have the power to promote. Consequently,  a fast riser can little afford to spend time where the work is being done. Instead he or she will focus on being visible to ones superiors. Remember, it is the bosses boss that has the power to promote.

Identifying behavior : ask the staff about their leader. Is she or he available to communicate goals and vision, coach the team and remove blockers or does he or she spent the bulk time in corner offices with other executives.

2. Manage perception

While managing up, the ambitious executive has to influence his or her superior’s perceptions. A favorite matra is "percetpion is reality". It doesn’t matter if you are actually adding value, what matters is that your superiors perceive you as adding value. This will require great presentations and speaking skills. You won’t have time to actually add value as you are consumed with managing the perception of your superiors.

Identifying behavior : ask the staff if they see their bosses boss. Communication is frequently filtered by the boss and never goes directly outside the organization, especially upward.

3. Avoid accountability

By “holding underlings accountable” you can avoid blame. Instead of taking ownership of the system, i.e., they way work is done, and utilizing root cause analysis and the flow of work between departments, the dysfunctional executive finds someone or some group to blame. By doing so he or she is seen as being a strong leader because he or she has identified the guilty and were swift to dole out the consequences.

Identifying behavior : avoids risks and accountability at all cost. Does well at placing others on the hook for any deliverable.

4. Claim credit for other’s successes

This is the sister bad habit to avoiding accountability and blame. Once something has been viewed as successful, a dysfunctional  leaders will attach his or her name to it. It is important that the leaders superiors see him or her as the reason for the success. Should a leader attach his or her name to something that later fails, he or she must declare it a success anyway. Remember, a ambitious leader must avoid fault at all costs. Nothing can bring a fast climb to an end sooner than a highly visible failure.

Identifying behavior : finds out what his or her boss views as valuable and claims credit.

5. Optimize Locally

Since everyone is at risk for being judged by the performance of his or her organization, it is essential that one do all one can to make it appear ones organization is highly functioning. If it means one should sub-optimize the whole i.e., negatively impact a neighboring organization or the company, so be it. What is important is not the end result to the company but how others see a leader’s organization.

Identifying behavior : person has little interest is what is good for the company. He or she is only focused on what is good for his or her organization.

There is one more unspoken dysfunction a leader of a poor performing organization. It is not being caught with any of the 5 dysfunctions identified above. If accused, said leader must deny practicing any of the dysfunctions identified above. A real career killers is to admit to possessing any of the above dysfunctions. Odd thing is, the dysfunctions are very visible to the rank and file but are touted as exective skills by the leadership. The emperor has no clothes.

Our Leadership Pandemic

Corporate America : Our Leadership Pandemic

The disease is rabid self interest. Not the healthy sort of self interest that we all need to employ to provide for our families but the short sighted self centered sort of self interest. 

Look at the symptoms. Almost exclusively you see leadership managing up. There is more interest in managing perception than managing the business. Future leaders are taught that managing perception is a critical skill if one is to advance. This is a key symptom of the leadership pandemic.

Look at a leadership meeting. It is about making oneself look good and avoiding blame. Problems don’t get solved. Instead, everyone is jockeying for position. Net result is the creation of a culture that teaches the underlings to do the same.

In lean and agile, leadership goes to were the work is done (i.e., gemba walk). Managing perception is  not needed when one sees things with ones own eyes. Leadership is on the floor observing the work frequently. Such behavior is the pulse of a healthy organization.

In lean and agile, leaders take accountability for problems, they don’t run from them. What is valued is the ability to collaborate with others across the value stream to resolve issues. This is fundamental to continuous improvement. This is a primary responsibility of leadership.

Unfortunately, the culture of “managing up” keeps the leadership from going to where the work is done. There are no gemba walks. Instead, leaders go to rooms with closed doors and manage perception via PowerPoint slides, elegant phrasing and distancing oneself from any blame. Such a culture teaches future executives how to “kiss the ring” of the current power brokers. Instead of managing the business, everyone is managing ones career.

Thus, problems don’t get solved, continuos improvement is but an empty phrase, the organization becomes dysfunctional and ineffective.

Is it any wonder we see so many American companies stagnate or in decline. Is your organization infected with the leadership pandemic?

Executive Guide to Transformation Coaching

Coaching is one of the hardest skills for an executive to learn.

Why?

The answer I believe is revealing. Most executives are convinced they know what they are doing. In his or her mind, it is the rest of organization that needs to change. Given that executives excel at building relationships and managing perceptions perhaps most executives believe their own spin.

This state of denial is a blind spot that blocks many an agile and lean transformation. Isn’t the first step to change, recognition of the problems?

By believing it is someone elses problem, the executive overlooks an important part of the transformation, the transformation of oneself. Subsequently, such an executive also ignores the transformation of one’s peers.

Think of the discontinuity that will arise. You are asking your staff to change their behavior. You invest in their training and teach them key concepts like how to be self-directed .Not only will this impact your organization, it will impact neighboring organizations. What is being done to prepare the leadership of the coming changes?

Remember, the culture that is in place, the one you are trying to transform, was put in place by the leaders (i.e., you or your predecessors).  The current system (i.e., the way work is done) is primarily responsible for the organizations struggles. It is the leaders that are primarily responsible for the state of the current system.

Understanding agile and lean leads one to understand the importance continuous improvement via root cause analysis. Too many organizations are driven by a culture of blame. If something goes wrong, someone is to blame. An executive must recognize it is the current system that is the root cause of most of the current dysfunction. To move from a culture of blame to a culture of continuous improvement requires the elimination of fear. Removing the fear from ones organization does not happen overnight and will not happen at all if the executive does not change. Teaching leaders that fear is not a tool but part of the problem will be a challenge.

OK, so you are an executive and you have come to understand that the current system is the main contributor to poor productivity and or poor quality. What next? You need to coach your peers!

Too many executives attempt transformation and look to their subordinates to drive the change. When their staff hits against the existing corporate system, the executive is nowhere to be found. When an executive from a neighboring organization complains or blames any person attempting to drive transformation the executive’s backing is critical. Backing your people as they execute the transformation shows you have skin in the game. By not to supporting your people you are placing your people in harms way and many will fall victim to the corporate immune system. This will bring the transformation to a halt.

Your role as coach is to first coach your peers. This is essential if the transformation is to succeed. Your peers need to be educated about the transformation. They need to know what to expect, why the change is necessary and the results and benefits the transformation will bring. Collectively, you can determine the impact to the neighboring organizations and what if any coaching is required. When things go wrong, the leadership needs to bring an end to blame. Instead the leadership needs to coach how to drive continuous improvement via root cause analysis.

As you can see the best transformation starts from the head. The executive educates oneself then learns to coach one’s peers. Collectively, the leaders of the organization can then begin to coach their organizations.

It is a rare executive that has the insight and courage to first transform oneself then become an agent of change by coaching one’s peers. Transformation is hard. Transformation without support from the top is impossible. It will have limited success at best and any progress made is likely to be short lived.

Transformation from the top brings about sustainable transformation. What kind of executive are you?

Agile De-transformation

You have a high performing organization. The teams are self-directed. They can take business goals and work with the product owner to build a backlog, plan iterations and using pairing and test driven development deliver working software. They often delight the business.

Once you have transformed an organization into a high performing organization, how do you stop it? How do you de-transform it?

Why would you want too you ask? If we can identify what would bring an end to a high performing organization, we may gain some insight into what not to do. We may learn that the “don’ts” we identify are exactly what many managers do today unaware of the consequences.

So what is the master plan? In priority order, what would you do to bring a high performing organization to a halt? Here is a short list:.

•        Commit the team to deliver software that was estimated and planned by someone other than the team
•        When the team provides estimates that are higher you tell them to waive their practices so they can commit to the budget, schedule and scope as it stands

Is that all you have to do? Is it that simple? Let’s examine the impact of the above two steps.

By committing a team to a schedule, budget and scope you have taken away the team’s ability to be self-organizing and self-directing. The team not only does not have buy-in, they don’t have knowledge of the solution nor any confidence that it can be done.  What knowledge they do have says it can’t be done yet their feedback is ignored.

By the above actions, you have moved the team from emerging design and iterative and incremental delivery to big up front design with big bang development. Planning not only is a one-time event, it was done by someone other than the team. The ability to deliver working software every two weeks, receive and incorporate feedback and update the plan is now lost.

How about the second bullet point, what impact does it have. You have told the team that their practices are the reason the estimate was wrong. That the practices of agile utilized by the team are the reason their estimate is high and the estimate done by someone else is right.

Never mind that the “other” estimate was done by one or two architects and was very high level. You can ignore that the team took the original estimates and decomposed them into story cards. Discussed proposed solutions with the product owner and used planning poker to bring about shared understanding.

You are telling the team that they cannot leverage the skills they have learned and utilized to deliver successfully many time previously. Instead, the lower estimated is picked, not because it is nearer to the truth but because expectations with the business have already been set and no one wants to bring about the bad news.

Management has now set up the team for failure. If the teams resists, they are told they are wrong. You can imagine how demotivating such an experience would be.

As you can see, it does not take much to destroy a high functioning team and organization. A few simple directives and you no longer have a team but a group of hostages being held accountable to deliver something they don’t understand or believe is possible. The final insult is you have taken away the very tools that have brought them success.

How many leaders put their organization or teams in this very position? When given a high level estimate, instead of bringing the truth to the business, they relent and commit the team to failure. Instead of coaching their peers and the business they throw the team under the bus.

Is there a shorter list than the one above that can destroy a high performing team? I say yes. It is, remove the product owner.

Really? Remove the product owner? Is the product owner that important?

Absolutely! How many organizations attempt agile without a product owner? The product owner is the one that provides feedback as working software is delivered incrementally. Without feedback, how is the team to know if they are on the right path. If the business does not have skin in the game (see http://www.agileandleanatscale.com/2012/03/skin-in-game.html) they are not vested. They have no ownership for what is being built. They are dis-engaged by standers. What chance does a team have to build the “right thing”? What chance does the team have to “delight the business”?

As you can see, it does not take much to destroy engaged, self-directed and productive teams. All it takes is a leader that has little to no understanding of how agile works.

Water in the Boat, Leaks in the Boat

How do you get to zero defects?

Divide and conquer.

We took the following approach. We established a run team. The run team handled customer support issues and fixed existing production defects. Members from other teams would rotate through the run team every iteration. Thus, no one was stuck supporting production perpetually and everyone had an opportunity to learn what our production support issues were.

By having a few developers focused on production issues per iteration, the run team’s productivity would increase as they did not have to switch between new feature development and defect fixes. The run team also provided a firewall to the teams focused on new feature development. By protecting the feature teams from interruptions, the feature teams’ productivity also increased thus protecting our product roadmap.

We created the following metaphor.  We would call defects in production “water in the boat”. The run team would fix defects in priority order. By taking this approach the run team was able to empty the “water in the boat” i.e., fix all production defects over a sequence of iterations. We developed a zero tolerance policy regarding defects and we did not cut corners. We would have entry an exist meetings for each defect, just like we did for features and we would test drive our fixes. This helped ensure that we fixed defects right the first time and with test wrapped around the fixes they would squeak should some future change break what had been fixed.

Meanwhile, the feature teams were busy adding new features to our product. Initially, we did not have our regression tests automated. Thus, after an iteration, we would find that we introduced new defects into our product. The introduction of new defects was called “leaks in the boat”. These leaks existed in spite of pairing, TDD and ATDD. All of these practices did contribute significantly to the quality of our product but did not get us to zero defects. Only when we put in place an automated regression suite that ran daily against all customer configurations were we able to plug the “leaks in the boat”.

The metaphor of “water in the boat” and “leaks in the boat” was a powerful one. It helped everyone visualize an important goal for the run team and the feature teams. Developing a zero tolerance policy for defects did much to reduce our cost and increase our velocity. By having practices in place that ensured what was built today would not need to be fixed tomorrow, it enabled the teams to remain focused on new features and not be distracted by fixes.

We still have a run team, and it does handle the occasional production support issues. However, it now spends the majority of its time working on small enhancements that improve our product and customer experience but by themselves would never make it to the product backlog, which highlights another point. We have learned there is a benefit to providing some limited capacity for those small features which by themselves never make it to the backlog but in aggregate improves our product and brings benefit to our customers. It has made the difference between a good product and a great product.

Cucumber

Am reading "The Cucumber Book". I like concise statements like this one:

"Acceptance test ensures you build the right thing while unit test ensure you build the thing right".

While developers write unit test to drive their designs, it is essential that the business (or product owner or business analyst acting as proxies for the business) write feature files to describe the software's behavior. Developers then automate the step definitions. Following the principles of Outside-In, the scenarios tell the developers what unit tests to write. TDD helps the developers "build the thing right".

Given that some business people are unable to write feature files, the business can work in collaboration with cross-functional teams to write the Gherkin. What cannot be delegated to developers by the business is the behavior expressed by the scenarios in the feature files. Before the feature files can be automated by the developers, the business must ensure that the scenarios define the behavior of the software from their perspective. Only then has the business properly defined what it means to "build the right thing".