Category Archives: Agile Leadership

What Is Servant Leadership and How Does It Relate to Agile?

“Servant Leadership” is a commonly-used term in an Agile environment but if you asked people what it means, I’m sure you would get a number of different responses. For that reason, I think it is worthwhile to discuss “What Is Servant Leadership and How Does It Work in Agile?”

What Is Servant Leadership?

“Servant leadership” sounds like a manager who does nothing but get coffee, donuts, and pizza for the Agile team. Is that what it really is? (I don’t think so)

The phrase “servant leadership” was coined by Robert K. Greenleaf in “The Servant as Leader”, an essay that he first published in 1970 long before Agile came into being.   Here’s a definition of “servant leadership”:

“Servant leadership is characterized by leaders who put the needs of a group over their own. These leaders foster trust among employees by holding themselves accountable, helping others develop, showing appreciation, sharing power and listening without judging. While serving and leading seem like conflicting activities, these leaders are effective initiators of action.”

http://www.ehow.com/list_6753156_servant-leadership-games.html?ref=Track2&utm_source=IACB2B

A “servant leader” doesn’t necessarily completely abdicate the leadership role and do nothing but get coffee, donuts, and pizza for the team.  He/she recognizes the importance of working through others and engaging and empowering others to use as much of their own capabilities as possible.  Here’s an excellent quote on that:

“The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first.

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons?

A servant-leader focuses primarily on the growth and well-being of people and the communities to which they belong”

https://www.greenleaf.org/what-is-servant-leadership/

What is Servant Leadership?

What Does it Really Mean to be a Servant Leader?

A major leadership principle that is applicable to any leadership role is that there is no single leadership style that works in all situations. A good leader should be capable of taking an adaptive and situational leadership approach that is appropriate to the people and the environment he/she is trying to lead.

With regard to servant leadership, the way the servant leader role is implemented will be very dependent on the capabilities of the Agile team you are leading and the environment you are part of. The goal should be to maximize the utilization of the capabilities of the entire team but that doesn’t mean a servant leader completely abdicates a leadership role and turns over all responsibility to the team. Determining the most effective servant leadership role requires some judgement:

  • If the team is very strong and very capable, the role of the servant leader may be limited to a facilitation role
  • If that is not the case, a more active leadership role may be needed by the servant leader

Basically, the servant leader needs to “fill the cracks” as much as possible to help the team become fully effective on their own.

Why Is This Important in Agile?

The idea of “servant leadership” is particularly important in an Agile environment because an Agile approach is best suited for projects with a high level of uncertainty.  In that kind of environment, a lot of individual creativity may be needed to find an optimum solution and maximizing the creativity of the team requires that the team be empowered as much as possible.

It is basically a softer leadership style that puts an emphasis on empowering others over a more controlled approach.  It is ideal for a highly uncertain environment that requires an adaptive Agile approach.  Naturally, it probably would not be so ideal for a more plan-driven environment where conformance to a plan is important.

To learn more about “Servant Leadership” and “Agile Leadership” in general, check out my Advanced Agile Project Management course. I’ve just added twelve new lessons on Agile Leadership to the course.

What is Emotional Intelligence and Why Is It Important?

I just finished creating a significant training module on Agile Leadership and one of the key topics in that module is “Emotional Intelligence”.  I’m sure some people are wondering “What is emotional intelligence and why is it important?”  I’d like to summarize some of that here.

What Is Emotional Intelligence?

First, here’s a definition of “emotional intelligence”:

“Emotional intelligence is the ability to identify and manage your own emotions and the emotions of others. It is generally said to include three skills:

  • Emotional awareness;
  • The ability to harness emotions and apply them to tasks like thinking and problem solving; and
  • The ability to manage emotions, which includes regulating your own emotions and cheering up or calming down other people.”

https://www.psychologytoday.com/basics/emotional-intelligence

What Is Emotional Intelligence and Why Is It Important?

Why Is It Important?

Emotional intelligence is one of the most important skills of an effective leader. The reason that emotional intelligence is so important to leadership is that if you can’t control your own emotions; it will be difficult, if not impossible to be an effective leader.

Here’s a quote that sums up the value of emotional intelligence very well:

“We probably also know people who are masters at managing their emotions. They don’t get angry in stressful situations. Instead, they have the ability to look at a problem and calmly find a solution. They’re excellent decision makers, and they know when to trust their intuition.”

 

“Regardless of their strengths, however, they’re usually willing to look at themselves honestly. They take criticism well, and they know when to use it to improve their performance.”

https://www.mindtools.com/pages/article/newCDV_59.htm

What Are the Benefits of Emotional Intelligence?

Here are some of the key benefits of developing emotional intelligence:

  • Increased leadership ability because your leadership approach will be based on sound, rational principles rather than being dominated by emotional responses
  • Increased team performance because team members will feel much more comfortable and secure in a non-threatening team environment with no hidden agendas
  • Improved decision-making because decisions are made more objectively and rationally
  • Decreased occupational stress because there will be less emotional tension involved in the work environment
  • Reduced staff turnover because there will be fewer emotional flare-ups
  • Increased personal well-being because learning to accept yourself and gain control of your emotions can lead to a much happier life

How Do You Improve Emotional Intelligence?

The following tips have been reproduced from the Mind Tools web site (https://www.mindtools.com/pages/article/newCDV_59.htm):

  • Observe how you react to people – “do you rush to judgement before you know all the facts? Do you stereotype? Look honestly at how you think and interact with other people. Try to put yourself in their place, and be more open and accepting of their perspectives and needs.”
  • Look at your work environment – “Do you seek attention for your accomplishments? Humility can be a wonderful quality, and it doesn’t mean that you’re shy or lack self-confidence. When you practice humility, you say that you know what you did, and you can be quietly confident about it. Give others a chance to shine – put the focus on them, and don’t worry too much about getting praise for yourself.”
  • Do a self-evaluation – “What are your weaknesses? Are you willing to accept that you’re not perfect and that you could work on some areas to make yourself a better person? Have the courage to look at yourself honestly – it can change your life.”
  • Examine how you react to stressful situations – “Do you become upset every time there’s a delay or something doesn’t happen the way you want? Do you blame others or become angry at them, even when it’s not their fault? The ability to stay calm and in control in difficult situations is highly valued – in the business world and outside it. Keep your emotions under control when things go wrong.”
  • Take responsibility for your actions – “If you hurt someone’s feelings, apologize directly – don’t ignore what you did or avoid the person. People are usually more willing to forgive and forget if you make an honest attempt to make things right.”
  • Examine how your actions will affect others – “before you take those actions. If your decision will impact others, put yourself in their place. How will they feel if you do this? Would you want that experience? If you must take the action, how can you help others deal with the effects?”

Why Is This Particularly Important to Agile Project Management?

Check out my previous article on Agile Leadership and I think you will understand why effective leadership is extremely difficult and so important in an Agile environment with high performance teams.  Agile is based heavily on transparency and openness and if you can’t be open and transparent about who you are as a person, you will have a difficult time being effective in an Agile environment.

How Can I Learn More to Improve My Skills?

Self-awareness is one of the biggest components of emotional intelligence.  Many people aren’t even aware of who they are as a person and don’t reveal that to others.  They live their lives behind a facade that is based on projecting an image of who they are to others that may not be very genuine and others can employees can see through that easily.

When I was a young manager many years ago, self-awareness training was a standard part of many company’s management training curriculum.  The idea was that, to be an effective leader, its important to be genuine and open with others and you can’t do that without self-awareness.  Unfortunately, over the years, companies have cut back on that kind of training.  It was seen as frivolous and not essential and as pressure has mounted to reduce cost of operations, a lot of that kind of training has been cut.

I can’t really directly help you develop emotional awareness in my online training; however, I’ve added two new sections and twelve additional lessons on Agile Leadership and Emotional Intelligence in my online training that I think will be helpful to you to better understand how to develop an effective leadership strategy.  Check out the enhancements I’ve just completed in my Advanced Agile Project Management course.

What’s Really Different About Agile Leadership?

I just finished developing some online training on Agile Leadership and What’s Really Different About Agile Leadership? This article is a brief excerpt of that training.

What’s Really Different About Agile Leadership?

They’re are lots of stereotypes and myths in this area – here are a few of them:

  • Project Managers only know how to do a “command-and-control” style of management
  • Agile requires a “servant leadership” approach which means that you completely abdicate the leadership role

Those stereotypes generally follow many of the stereotypes that people have about seeing “Agile” and “Waterfall” as binary and mutually-exclusive choices with nothing in the middle of those extremes.  Instead of force-fitting a project to one of those extremes, the right approach is to go in the other direction and fit the methodology to the nature of the problem and sometimes that requires a blend of the two approaches.

Fitting the Leadership Style to the Nature of the Problem

You can make some similar observations about leadership style:

  • A good leader doesn’t have one well-defined style of leadership that he/she force-fits all situations to.
  • A good leader recognizes that different styles of leadership are needed in different situations – that’s what “situational leadership” is all about

Another important observation is that the leadership style that is most appropriate in a given situation is directly related to the nature of the project and the problem solving approach.  Here’s how I see the relationship:

What's Really Different About Agile Leadership?The nature of the problem shapes the management objective and

  • The management objective shapes the problem solving approach
  • The problem-solving approach  determines the leadership style that may be most appropriate

Real-world Examples

Here’s how that might work out in different environments:

  1. Traditional Plan-driven Project Environment – Projects that have a relatively low level of uncertainty and require some level of predictability might lend themselves to more of a plan-driven approach to project management.  An important characteristic that differentiates this kind of project is that it is assumed to be possible to define the general solution to the problem with some level of certainty prior to the start of the project.
    • Problem-solving Approach – In that approach, a defined problem-solving approach is what is typically used.  The solution to the problem is generally well-defined in advance and the general approach for implementing the solution is also fairly well-defined.
    • Management Objective – If predictability is important, having a well-defined plan and conformance to that plan are also important.  Naturally, that requires some level of emphasis on control.
    • Leadership Approach – That calls for a style of leadership that naturally might be a bit more directive in order to remain on track with the project plan.  You certainly don’t want members of the project team running loose in all different directions without some kind of plan that integrates all of their efforts together that is consistent with the overall plan.
  2. Agile Project Environment – Projects that have a high level of uncertainty generally lend themselves to a more Agile project management approach where the final definition of the solution is expected to evolve as the project is in progress rather than being well-defined upfront prior to the start of the project.
    • Problem-Solving Approach – This type of project uses a empirical process control approach.  The word “empirical” means “based on observation” which means that both the definition of the solution as well as the process to discover the solution will evolve based on observation throughout the project.
    • Management Objective – Arriving at an effective solution is far more important in this kind of project than predictability.  Therefore, innovation and creativity would generally be emphasized more than control.
    • Leadership Style – This type of project obviously calls for a different leadership style.  If you want to encourage creativity and innovation, you don’t want to emphasize control, you want to empower people and give them some flexibility to use their own intelligence and judgement to explore alternatives as necessary to find the best solution.

Overall Summary

There are a lot of very polarized viewpoints in this area that go something like this:

  • Agile is good and
  • Waterfall is bad

Or alternatively:

  • Command-and-control management is bad and
  • Agile Servant Leadership is good

Those polarized points of view tend to over-simplify what is not quite so simple as drawing a black-and-white comparison between two extremes.  There are lots of “shades of gray” in both the problem-solving approach and the leadership style that is most appropriate for a particular situation.  An effective leader should be able to adjust his/her leadership style and problem-solving approach as necessary to fit any given situation.

  • There is not just one leadership style that fits all situations
  • Leadership styles are not necessarily good or bad – saying a particular leadership style is good or bad is like saying “a car is better than a boat”.  Each has advantages and disadvantages depending on the environment you’re in.
  • Agile leadership is not really a radically different style of leadership that is totally separate and mutually-exclusive with other leadership styles; however, it significantly expands our definition of what “leadership” is.

I’ve developed a significant amount of new content for my Advanced Agile Project Management online training course that goes into this in a lot more depth.

Politics and Agile Project Management

Have you ever thought about the relationship of what’s going on in politics and Agile Project Management? I think there’s possibly a significant relationship between the two. Look at what is happening in politics throughout the world:

  • In the UK,  regardless of whether the decision to leave the EU is right or wrong, the “Brexit” vote indicates that many people want to have much more direct control of their own government
  • In the US,  Bernie Sanders and Donald Trump probably couldn’t be further apart in their political orientation but they do have one very significant thing in common – they are both attractive to people who are frustrated with the bureaucratic and cumbersome nature of establishment politics.

What Do People Really Want?

Without taking sides in any of these political contests, the pattern seems to be clear – people are fed up with bureaucracy and traditional, establishment politics and want a radical change.  However, many people are beginning to be concerned about the potential impact of such radical change.  What will be the impact of tossing out all of our experienced political leaders and moving to a much more unpredictable environment?  I don’t think anyone really knows the answer to that question.

Politics and Agile Project Management

Does that sound familiar?  I think it does. 

What’s the Relationship to Agile Project Management?

A lot of organizations and people are fed up with force-fitting a traditional, plan-driven project management approach on their organizations that hasn’t changed significantly since the 1950’s and 1960’s.   They want to get rid of bureaucratic and cumbersome management processes.  Many businesses and people want radical change and they see Agile as a potential solution to that need.  However, tossing out all of the established way of doing things is a concern to many people and organizations.

An Agile Project Management approach can provide a nice compromise.   It provides a way to break away from a traditional, plan-driven project management approach; however, it doesn’t really require completely tossing out all of the established ways of doing things and starting completely over from scratch.  It provides a way to customize a management solution to fit the needs of a given business environment and projects.

If you look at what has happened with Agile, the Agile Manifesto that was developed fifteen years ago in 2001 started a revolution and many people in the Agile community have advocated a fairly radical approach to get rid of traditional, plan-driven project management altogether.   On the other side of that fence, there have been some project managers who are resisting this change and are equally polarized on insisting that a traditional, plan-driven approach is the only way to do project management and are force-fitting that approach on all projects.

What Does the Future Look Like?

I think that the polarization between the project management community and the Agile community is starting to fade away as people start to see that it is possible to blend the two approaches together in the right proportions to fit a given situation.   I hope it doesn’t take a long time for the polarization that exists in the current political environment to fade away.  Countries are like businesses in a sense – they are much stronger if the people in the country and business are unified around a common direction for the country/business and countries/businesses are weakened by excessive polarization and fragmentation.

Achieving that kind of unifying vision isn’t easy either in politics or in a business environment.  In both cases, it takes strong leadership to bring people together.  That’s why I’m so passionate about helping to develop that kind of leader in the Agile Project Management community.

 

Do You Have Excessive Fear of Failure?

Do You Have Excessive Fear of Failure? I participated in a discussion on LinkedIn this morning that stimulated my thinking. The individual who started the discussion asked the question, “If a pilot project is discontinued because it didn’t achieve results it had hoped for, would that be considered project failure?” The answer seemed obvious to me but it really stimulated my thinking – one of the key things that differentiates an Agile approach from atraditional plan-driven approach is the attitude towards failure:

  • In an Agile environment, a “failure” is regarded in a positive sense as an opportunity for learning and there’s a very popular mantra of “fail early, fail often”. In other words, sometimes you just have to try something and see what works and take a risk rather than being totally risk-averse and attempting to analyze and anticipate every possible risk and contingency before you even get started.
  • In a traditional, plan-driven environment, the attitude towards failure is many times very different. Any significant unexpected event might be regarded as a failure and many times is regarded negatively. There is an inference that it’s a failure in planning that you didn’t do enough upfront planning to anticipate the problem and avoid it.

I don’t think either of these two approaches is necessarily right or wrong. Like many things, it depends on the situation. There are some situations that call for a more risk-averse approach and some that don’t:

  • Some businesses have to operate on the “edge of chaos” because of a highly competitive business environment. If they were overly risk-averse and had excessive fear of failure, they would not be successful in their business and that would be a failure in itself to not do anything to “push the envelope”.
    Another saying I like is “If you’ve never failed, you’re not trying hard enough”. Amazon.com is probably a good example of a company that has a lot of failures like their smartphone, yet they continue to push the envelope to explore very risky new technology such as package delivery with drones because I’m sure that they feel that they need to continue to “push the envelope” to maintain their competitive position
  • In other environments, the consequences of problems may be much more significant and need to be more thoroughly anticipated and mitigated. Sending an astronaut to the moon might be an example. Check out the book, “Failure Is Not an Option: Mission Control From Mercury to Apollo 13 and Beyond” for more on that
  • There’s also a lot of gray area between those extremes where it may require considerable judgment to figure out what the right approach should be. Any project that involves a large amount of uncertainty might be an example. You need to figure out how much of that uncertainty you can tolerate and let it be resolved as the project progresses and how much of it you can’t tolerate and need to resolve upfront before the project starts.
    It would probably be very irresponsible to take a cavalier approach and ignore the potential impact of risks; but, on the other hand, it could be equally problematic to get bogged down in “analysis paralysis” and never get started trying to anticipate and mitigate every possible risk that could possibly happen.

The most important thing is to have a clear mutual understanding and a sense of partnership between the project team and the project sponsor about what the goals of the project are, what level of risk is acceptable in the project, and how those risks will be managed.

  • In an Agile project, that’s typically easier to do because the relationship with the business sponsor is based on a spirit of trust and partnership as well as openness and transparency and the Business Sponsor (represented by the Product Owner) is expected to have a sufficient level of judgment and maturity to make good, sound decisions on the project. Because there is an understanding that some of the risks and uncertainties will be resolved while the project progresses, the Business Sponsor (represented by the Product Owner) is also intimately involved as the project progresses to provide ongoing direction
  • In many traditional, plan-driven environments, the business sponsors may not have that level of maturity and there may be less of a spirit of partnership with the project team. The Business Sponsors frequently put that responsibility totally on the project team to “just get it done” and don’t necessarily want to know about any risks at all. That can lead to a fear of failure and a “CYA” approach by the project team to over-analyze the project to avoid any possible problems and it can also lead to less-than-open sharing of project information to avoid airing any “dirty laundry” with the project sponsors.

It seems to me that the partnership approach where the business and the project team mutually agree on the project risks and how they will be managed is a lot more sensible and has numerous advantages.

Managing Conflict in Agile Teams

I recently saw a LinkedIn post from someone who was requesting advice on managing conflict in Agile teams. One response was to remove the people who are causing the conflict from the team. That may not be an appropriate solution – some level of conflict is necessary and healthy in a high performance team. A team where everyone always agrees with everyone else on the team would probably not be a very high performance team. In this particular situation, the conflict was occurring over estimation and that’s an area where you certainly want to bring out opposing views and attempt to resolve them rather than suppress them.

The right way to manage conflict on an Agile team is not to try to stifle conflict but to accept some values among the team to listen to the views of others and treat them with respect and consideration if you disagree with them. Each person on the team also needs to put their own ego and emotions aside and instead of focusing on who’s right and wrong, focus on working collaboratively with others towards what is in the best interest of the team and the business. Some times people become argumentative and pursue an argument just to have the last word or try to prove that they’re right and others are wrong – that behavior can be very counter-productive. Having a clearly-defined set of values that everyone on the team agrees to is a good way to minimize that kind of behavior.

I suggest that anyone who wants to learn more about team dynamics do some reading on “Tuckman’s Stages of Group Development”. It’s an excellent model for understanding the stages teams go through in the journey to becoming a high performance team. Here’s a brief summary – Tuckman’s model consists of four stages:

  1. Forming
    “Individual behavior is driven by a desire to be accepted by the others, and avoid controversy or conflict. Serious issues and feelings are avoided, and people focus on being busy with routines, such as team organization, who does what, when to meet, etc. But individuals are also gathering information and impressions – about each other, and about the scope of the task and how to approach it. This is a comfortable stage to be in, but the avoidance of conflict and threat means that not much actually gets done.”
  2. Storming

    “Individuals in the group can only remain nice to each other for so long, as important issues start to be addressed. Some people’s patience will break early, and minor confrontations will arise that are quickly dealt with or glossed over. These may relate to the work of the group itself, or to roles and responsibilities within the group. Some will observe that it’s good to be getting into the real issues, whilst others will wish to remain in the comfort and security of stage 1. Depending on the culture of the organization and individuals, the conflict will be more or less suppressed, but it’ll be there, under the surface. To deal with the conflict, individuals may feel they are winning or losing battles, and will look for structural clarity and rules to prevent the conflict persisting.”

  3. Norming

    “As Stage 2 evolves, the “rules of engagement” for the group become established, and the scope of the group’s tasks or responsibilities are clear and agreed. Having had their arguments, they now understand each other better, and can appreciate each other’s skills and experience. Individuals listen to each other, appreciate and support each other, and are prepared to change pre-conceived views: they feel they’re part of a cohesive, effective group. However, individuals have had to work hard to attain this stage, and may resist any pressure to change – especially from the outside – for fear that the group will break up, or revert to a storm.”

  4. Performing

    “Not all groups reach this stage, characterized by a state of interdependence and flexibility. Everyone knows each other well enough to be able to work together, and trusts each other enough to allow independent activity. Roles and responsibilities change according to need in an almost seamless way. Group identity, loyalty and morale are all high, and everyone is equally task-orientated and people-orientated. This high degree of comfort means that all the energy of the group can be directed towards the task(s) in hand.”

  5. There are a couple of important things to recognize about this model:

    • You can’t just jump past the “Storming” stage and go right to the “Performing” stage unless the people on the team have a lot of maturity on working in other teams. You have to progress through these stages to some extent to make progress. For that reason, conflict should be viewed as a sign of progress that you’ve moved past the “forming” stage.
    • You don’t necessarily always proceed through these stages in a strict sequential order…sometimes a team will regress and fall back to an earlier stage and start over from that point and you might go back-and-forth like that over a period of time.
    • The natural progression for a team that is in conflict is to move to the “norming” stage and you do that by adopting rules and values of how the team interacts with each other. Those rules and values are like “training wheels on a bike”. After teams have reached a point of maturity, those rules become just a natural part of people’s behavior and the team reaches the “performing” stage which is similar to riding a bike without the “training wheels”.

    Source: “Stages of Group Development”

    One of the key points in this model is the conflict is a normal and necessary stage of progression on the journey to becoming a high-performance team. For that reason, you shouldn’t try to stifle conflict – the best approach is to manage it by setting values so that it doesn’t become destructive.

Agile Lessons We Can Learn From Sports

I think there are a lot of lessons we can learn from sports – particularly about the importance of character, integrity, teamwork, and values.

There’s been a lot in the news lately in the US about the conduct of some sports celebrities (Ray Rice of the Baltimore Ravens and others). Some people have questioned why we should hold sports celebrities to a higher standard than other kinds of employment. For example, a normal company wouldn’t necessarily fire an employee for beating their kids or having a public altercation with their spouse; but that behavior isn’t acceptable in a sports celebrity. I think there’s a couple of good reasons for holding sports celebrities to a higher standard.

  1. The first reason is that they provide an important role model for kids and others to follow. I just saw a short story on TV about Deandre Jordan (the center for the LA Clippers) that is a great example of that – it showed him working with a bunch of 9-10 year old kids on a basketball team to teach them the importance of character, integrity, and teamwork in sports. That’s the kind of positive role models we need in sports – people who go beyond what’s expected to try to have a positive influence on people in the communities that they are part of. Kids and others in the community look up to people like that and we need more role models like that.
  2. The second reason is probably more directly relevant to Agile Project Management. One of the important factors that binds a high performance team is that they share a set of values and a sense of purpose that goes beyond just showing up for work, doing their jobs, and going home at the end of the day. Their jobs are an extension of the way they live their lives and there’s a real sense of purpose and values behind it. They are also really true to those values – it isn’t just something that they practice in public and put aside when it’s not publicly visible.
  3. If we lower our standards to the level that it’s OK for people (particularly prominent sports celebrities) just do their jobs as long as they don ‘t do anything outside of work that might be considered a crime, it seems to me that we’ve let our standards drop too far. I’m proud to be part of the Agile Project Management community and part of some very dedicated and principled people who hold ourselves to a higher standard.

Are Corporate Culture and Values Really Important?

Are corporate culture and values really important? The controversy that is currently brewing in the Boston area over the “Market Basket” grocery supermarket chain is directly related to the conflict between Agile and traditional project management. “Market Basket” is a chain of about 71 grocery supermarkets in New England that generates about $4 billion in annual revenues – it has been a family-run business founded and managed by the DeMoulas’ family for several generations.

(Source: http://en.wikipedia.org/wiki/DeMoulas%27_Market_Basket)

Arthur T. Demoulas is currently the CEO of the company and has been highly regarded by all company employees and customers for building a strong company culture based on the strong leadership and values. However, some other members of the Demoulas’ family who have an ownership interest in the company didn’t see it that way… They felt that Arthur T. wasn’t paying enough attention to the bottom-line and was putting too much emphasis on corporate culture and values including developing a clearly-defined brand image with very strong employee satisfaction and strong customer loyalty. So, they fired him as CEO and hundreds of employees who were intensely loyal to him promptly walked out of the company in protest. Customers have also started boycotting the stores in response to his firing.

The company has been paralyzed for the past few weeks in the midst of this controversy as deliveries by suppliers have almost stopped because there are no employees to accept deliveries and stock the shelves and customers have walked away. It appears now that Arthur T. is going to buy out the other shareholders in his family to gain a majority and controlling interest in the company. The Boston Globe magazine had several excellent articles on this on Sunday 8/24/2014 – here’s an excerpt of one of them:

“Under CEO Arthur T. Demoulas, Market Basket had a winning business model: He treated employees, managers, and customers as members of a common enterprise, from which everyone gained. Arthur T. rolled out a 4 percent discount on nearly all goods at the beginning of 2014, arguing his customers could use the money more than his fellow shareholders. He paid his employees and managers decent wages, and he treated them with respect. He made sure they understood the objectives, and then let them decide how to achieve them. The greed team that ousted Arthur T., by contrast, is running the company as if they’re take-it-or-leave-it martinets and everyone is losing.”

“At least one of the bidders who emerged to buy Market Basket was said to be offering more than Arthur T. was offering. They said they can squeeze more profits out of the company than when Arthur T. was CEO. They’re deluding themselves. Arthur T.’s business model worked precisely because he didn’t follow this route. Trying to squeeze out more profits will drive customers away, destroy employee loyalty, and increase worker turnover.”

“There’s abundant evidence that a company organized as a common enterprise does better over the long term than a company designed to maximize shareholder returns over the short term. Arthur T.’s business model wasn’t based on zero-sum thinking. He understood that giving everyone a stake in the business would generate gains for everyone, including the shareholders.”

“The reactions to Arthur T.’s ouster proves the point. Customers are staying away from Market Basket stores, even though its costing them, forcing them to buy more expensive food elsewhere. Striking employees are sacrificing paychecks and risk losing their jobs, but giving in means getting stuck with new CEO’s and a board that are likely to cut pay and raise prices. Local politicians have weighed in with some statements of support. This isn’t the age-old labor versus management conflict. It’s labor, management, customers, community, and fired CEO versus greedy directors – something rare in the annals of American business.

(Source: Reich, Robert, “Anatomy of a Meltdown”, Boston Globe, Globe Magazine, 8/24/2014, p 20)

What does this have to do with Agile Project Management? I believe that the conflict between a bottom-line, numbers orientation that focuses on results and a more systemic and holistic approach that focuses on people, culture, and values and other factors that drive results is also one of the key issues behind the conflict between traditional plan-driven project management and Agile.

In 2003 I published a book called “From Quality to Business Excellence – A Systems Approach to Management” which is directly related to this problem. The figure below is a diagram from that book:

Business Excellence Model

(Source: Cobb, Charles, “From Quality to Business Excellence, ASQ Quality Press, 2003)

The idea behind this is that many companies are very short-sighted and reactive – they focus primarily on bottom-line results and when the numbers in a given quarter don’t meet expectations, they try to take some kind of corrective action without really understanding the cause-and-effect relationships that drive those numbers. This can lead to erratic and unpredictable performance. Companies who take a more systemic approach and understand these relationships are able to be much more proactive by focusing on at a deeper level on the performance drivers behind the numbers rather than simply reacting to the end-results. That should result in more consistent, sustainable, and predictable performance.

This pendulum has swung back-and-forth – should a company focus only on bottom-line results or focus on the internal factors like customer loyalty and employee satisfaction that drive bottom line results? The Market Basket controversy here in the Boston area is a perfect example of that. In the 1980’s and 1990’s many leading companies and enlightened managers successfully developed this kind of softer leadership approach that Arthur T. Demoulas is noted for; however, over the years since then, increasing pressure to produce fast-paced, short-term results has caused many companies to lose sight of this concept. To some people, the focus on numbers and bottom-line results may seem incompatible with a focus on some of the softer issues like corporate culture and values; however, enlightened companies and managers are able to successfully develop what I call a “systems approach to management” to achieve both.

Traditional plan-driven project management is also very results-oriented and numbers-oriented with a focus on meeting planned costs and schedules and many people see that approach as incompatible with Agile that focuses heavily on a softer leadership approach, an emphasis on culture and values, and empowered, self-organizing teams. I don’t see those approaches as mutually exclusive and focusing on one of those extremes or the other is not likely to produce optimum results. I think it’s naïve to believe that you can focus on company culture and values and empowered employees alone and the bottom-line numbers will somehow come out right as a result; but its equally problematic to focus on bottom-line results only without an appreciation of the factors that drive those results. The right balance of these two approaches will vary from one situation to another but, in general, a focus on both is needed to some extent to achieve optimal results.

The Agile Product Owner Role

The Agile Product Owner role in Agile is not well understood and how it relates to a typical project management role. I’ve written a lot about “project management” and Agile projects – many people mistakenly assume that “project management” is not needed in an Agile project because there is no Project Manager at a team level. However, even though you may not see anyone with the title of “Project Manager”, the project management discipline is still needed. It’s just a different style of project management and the project management functions are distributed among several other roles rather than being performed by a dedicated Project Manager.

Product management” is another discipline that is equally important and is also often neglected. The role of a “Product Manager” is not well-understood – you typically find “product management” only in companies that market products for external sale such as Intuit Quicken or QuickBooks. You don’t typically see someone called a “Product Manager” associated with an internal IT application development project because the output of that kind of project might not be considered a real “product”. However, many of those applications are significant enough to be treated as a real “product”; and, although it may not justify a dedicated person with the title of “Product Manager”, some product management discipline is needed.

  • Sometimes a Business Analyst might take on some of those functions; however, a Business Analyst does not typically have the level of responsibility and decision-making authority of a true Product Manager.
  • A Project Manager might also take on some of those functions but many project managers are not trained to take on that role and many project managers may not have the decision-making authority to make the kind of business decisions that are needed. In a traditional development project, the Product Manager determines “what” will be built and the Project Manager typically determines the “how”.

Scrum has recognized the importance of this business direction and has created the “Product Owner” role to put more emphasis on providing that kind of discipline and business direction. The Product Owner in an Agile project actually takes on a number of functions that would normally be performed by both a “Project Manager” and a “Product Manager” in a traditional development project. That is actually a huge amount of responsibility that is not fully understood in many cases. When I took a Certified Scrum Product Owner (CSPO) course some years ago, it primarily focused on the mechanics of how the Scrum process works and what the Product Owner role is in that process. It was taken for granted that the students knew enough about both project management and product management to perform those functions in the context of an Agile/Scrum project.

In my experience, the Product Owner in an Agile project is a business person who has been thrust into that role and doesn’t necessarily understand all of the requirements and experience required by that role. The Product Management discipline and functions, in particular, typically are not well-understood because it has often been neglected in traditional development projects. Wikipedia.com defines “Product Management” as follows:

“The role may consist of product development and product marketing, which are different (yet complementary) efforts, with the objective of maximizing sales revenues, market share, and profit margins. The product manager is often responsible for analyzing market conditions and defining features or functions of a product. The role of product management spans many activities from strategic to tactical and varies based on the organizational structure of the company. Product management can be a function separate on its own, or a member of marketing or engineering.”

“While involved with the entire product lifecycle, the product management’s main focus is on driving new product development. According to the Product Development and Management Association (PDMA), superior and differentiated new products — ones that deliver unique benefits and superior value to the customer — are the number one driver of success and product profitability.”

In a company that develops IT applications for internal use, this same general discipline is needed but it is focused on maximizing the business value that the application provides for the company rather than maximizing the revenue from external sales of the product.

As I’ve mentioned in some of my other blog posts, Agile is forcing us to redefine what we think of as “project management” and this is another example of that. The “Product Owner” role is actually a combination of some “project management” and “product management” discipline. Many project managers seem to think of becoming a Scrum Master as a way of migrating their skills into an Agile project but that may not be the best use of a project manager’s skills. A project manager who has an Agile mindset and also has some strong business domain knowledge might be a very good candidate to migrate into the Product Owner role and that would probably be a better use of their skills than becoming a Scrum Master.

That may be a significant increase in responsibility for some project managers but it seems to be very consistent with my thinking about “The Next Generation of Project Management” where the project manager takes on a new emphasis of driving business value rather than simply managing the scope, costs, and schedules of a project.

Was Steve Jobs an Effective Agile Leader?

Was Steve Jobs an effective Agile leader? I watched the movie “Jobs” this weekend about the life of Steve Jobs and his career at Apple and it was very thought-provoking.  Steve Jobs was absolutely brilliant, embodied a lot of Agile values, and he was enormously successful in developing some very innovative products in a relatively short amount of time that made Apple very successful;  but he was ruthless, tyrannical, and very insensitive in his relationships with people.  I was thinking – is that style of leadership really consistent with Agile and is it an effective style of leadership for an Agile environment?

  • Much of the thinking behind Agile is based on the idea of empowered and self-organizing teams where the product definition bubbles up rather than being driven down from above,  Steve Jobs’ leadership style doesn’t seem to be very consistent with that model, but he was very successful in getting things done.
  • Another thing that seems to be not entirely consistent with Agile is that Agile is based on the idea of teams working at a “sustainable pace” and it was apparent that many of the teams that worked under Steve’s direction at Apple worked incredible hours to get things done but they were very passionate and dedicated to their work.

Here are some quotes from Steve Jobs that indicate his values that are related to Agile:

  • Focus and Simplicity – “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things…
    “That’s been one of my mantras – focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
  • Planning – “Again, you can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something – your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.”
  • Quality – “Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”
  • Innovation – “Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.”
  • Requirements and Customer Needs – “You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new
  • Seeing the “Big Picture” – “A lot of people in our industry haven’t had very diverse experiences. So they don’t have enough dots to connect, and they end up with very linear solutions without a broad perspective on the problem. The broader one’s understanding of the human experience, the better design we will have…To turn really interesting ideas and fledgling technologies into a company that can continue to innovate for years, it requires a lot of disciplines.”
  • Continuous Improvement – “I have a great respect for incremental improvement, and I’ve done that sort of thing in my life, but I’ve always been attracted to the more revolutionary changes. I don’t know why. Because they’re harder. They’re much more stressful emotionally. And you usually go through a period where everybody tells you that you’ve completely failed.”
  • Tools – “It’s not the tools that you have faith in – tools are just tools. They work, or they don’t work. It’s people you have faith in or not.”
  • Leadership Style – “It’s not about charisma and personality, it’s about results and products and those very bedrock things that are why people at Apple and outside of Apple are getting more excited about the company and what Apple stands for and what its potential is to contribute to the industry…The people who are doing the work are the moving force behind the Macintosh. My job is to create a space for them, to clear out the rest of the organization and keep it at bay.”

And one of his most famous quotes that really sums up his values is “Stay hungry, stay foolish”.  The source of the above quotes is:

http://www.brainyquote.com/quotes/authors/s/steve_jobs.html

My thoughts on this are that:

  • Steve Jobs definitely had some “rough edges” in his relationships with people but he embodies many of the characteristics of an effective Agile leader
  • There probably isn’t one leadership style that is effective in all situations and some “out of the box” thinking is definitely worthwhile rather than implementing some kind of “textbook” Agile approach in all situations

What do others think?