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 a traditional 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 how to manage conflict on 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.

Lessons Learned 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.

Is 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.

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

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?

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?

 

Adaptive Leadership

I’ve been a Project Manager for many years and, over the years, I’ve gone through a lot of job interviews, particularly as a consultant where you might change roles every 3-6 months. One of the questions I’ve been asked in interviews is “What is your leadership style?”. My answer to that is I use an “adaptive leadership” approach; that is, I think that’s there’s not just one leadership style that works all the time and you have to adopt a leadership style that is appropriate for the situation.

How does that apply to Agile Project Management? There is a popular stereotype in the Agile community that all project managers are only capable of operating in a “Command and Control” leadership style. I’m sure that is an exaggeration, but it is true that many project managers have a tendency to assume a somewhat directive leadership style. For years, that has been an essential characteristic of many project managers – you can’t just sit on the sidelines and let a project run its course without some kind of direction and leadership. Agile changes that paradigm dramatically by emphasizing self-organization and empowerment of the team and positions the Scrum Master in the role of a “Servant Leader” to support the team rather than leading and directing the team. So, where does that leave the project manager? What value does he/she provide to an Agile team? I think the appropriate answer to those questions is that “it depends”.

A lot of people will say that a project manager can’t possibly play the role of a Scrum Master because the roles are so different. I don’t necessarily agree with that perspective…that perspective is based largely on the stereotype that all project managers are only capable of operating in “command and control” mode. I believe a good project manager has learned over the years to develop an adaptive leadership approach that’s appropriate for the situation and I think that’s very appropriate in an Agile environment.

There is an idealistic Agile view that all Agile teams are totally self-organizing, completely empowered, and require little or no direction or leadership. The team, as a whole, should function on its own without much direction at all – that’s true to some extent, but a more pragmatic view is that all teams aren’t necessarily at that level of maturity and some leadership is needed to help them get to that point. “Adaptive leadership” is an important skill in this kind of environment…a good Project Manager or Scrum Master should be capable of providing a sufficient level of leadership to get the team to a level of self-sufficiency and progressively back out as the team reaches that level.

“Adaptive Leadership” or learning to adapt your leadership style to the situation is a very important characteristic for project managers to be successful in an Agile environment.