Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management

Mindset: The New Psychology of Success: Re-Read Week 4, Chapter 5: Business: Mindset and Leadership

Mindset Book Cover

Today we are lead into Chapter 5 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  In Chapter 5,  we explore the impact of mindsets in the business environment.  The impact of mindsets can be seen in positive and negative business outcomes.  Dweck begins this section with a focus on the negative impact of the fixed mindset at the C level in business.

One of the primary examples used in Chapter 5 is Enron. Enron, (watch the movie Enron: The Smartest Guys in the Room for background) represents one of most egregious examples of excess, corruption and the impact of leaders of the modern age.  Some, if not a majority, of the poor behavior described can be ascribed to the fixed mindset,  both individually and collectively.  The fixed mindset culture of an organization creates an environment in which employees are forced to look and act extraordinarily talented rather than focusing on outcomes. In organizations with fixed mindset, people protect their egos and how they perceived rather than learning from any potential bump in the road. A quote that illustrates Jeffrey Skilling’s fixed mindset drives the point home, “my genius not only defines and validates me. It defines and validates the company. It is what creates value. My genius is profit.”  In Skilling’s mind, he was more important than the business. Dweck also uses the example of Lee Iacocca as the big fish that that would only tolerate helper fish around him. For example, Iacocca used saving Chrysler recover his ego but then was not able to stop burnishing his ego, which nearly lead to nearly destroying Chrysler when things got difficult a second time around.  None of those around Iacocca were able to shift his focus back to the organization rather than his reputation, and the board had to finally force him out. Iacocca, like Skilling at Enron, is an example of someone who makes decisions based on their own good rather than the good of the organization

Jim Collins, author of Good to Great found that organizations that were continuously trying to improve performance through learning and were self-effacing about their progress prospered.  These attributes are a reflection of a growth mindset at the organizational level. One of the reasons organizations with a growth mindset prosper is that leaders with a growth mindset usually surround themselves with great teams rather than having to be the big fish with helpers.

Another negative outcome of a fixed mindset is brutal managers. Brutal managers (I chose not to use the word leader) believe that the needs or feelings of others can be ignored. A fixed mindset allows brutal managers to dehumanize those they manage.

Another danger for organizations (or teams) that are affected by a fixed mindset is groupthink.  It is an affliction where no one will criticize or provide outside information to the leader.  This form of fixed-mindset groupthink needs to find some mechanism to bring in other information so that you don’t fall prey to thinking within a bubble.

On the other hand, growth-oriented leaders peruse a journey of learning.  Dweck’s examples of growth mindset oriented leaders include:

  •    Jack Walsh, GE, was devoted to the concepts of team and growth.  Walsh is not my favorite example because of concepts like cutting the bottom 10% yield negative behaviors. However, this does not reflect a mindset issue.
  •    Lou Gerstner, IBM, opened lines of communication, attacked elitism, accepted that everyone has a lot to offer and focused on customers.
  •    Anne Mulcahy, Xerox, reshaped the company to believe in growth even though it required cutting and suffering.  Mulcahy worried about the morale and development of her people. 

In each case, the growth mindset CEO helped to lead their companies from near failures to highly innovative growth phases.

The chapter concludes with a set of questions and activities that help grow your mind.  For instance: Reflect on whether your workplace promotes groupthink while eschewing information that might challenge the status quo.

Organizational Transformation:  The prevailing organizational mindset, generally set by senior leaders will directly affect how and why change is introduced into an organization.  When helping to introduce change into an organization lead by someone with a fixed mindset, the change has to be perceived to burnish the leader’s ego and has to fix the leader’s world view.  This does not sound like a huge amount of fun; however, the knowledge of mindsets is an effective tool to help introduce change or to challenge groupthink.

Team Coaching:  The most valuable takeaway for a team-level coach is the added ability to recognize mindsets based on the impact they have on the team. In addition, helping teams understand the mindsets around them is also useful for helping the team understand the possible considerations and consequences of changes they attempt.

Previous Entries of the re-read of Mindset:

 


Categories: Process Management

The Pros for Big Bang Change Implementation

Vinigear Bottles

Not Sweet But Useful!

A big bang adoption of a process or system is an instant changeover, a “one-and-done” type of approach in which everyone associated with a new system or process switches over in mass at a specific point in time.  There are positives and negatives to big bang approaches.  We begin with the positives.

Patrick Holden, Project Portfolio Director – Software Development at SITA, struck a fairly common theme when asked about his preferences between the big bang and incremental approaches.  

While I favour incremental improvement, sometimes we really want to get on with the new, to change the mail system, phone, house, car or even your job you will need to prepare to different extents but you make the switch for one and all, it’s a Big Bang.  

The choice depends on divisibility, scope, and urgency.

The positives:

Big Bangs fit some types of changes.  Not all changes are easily divisible into increments which lead to an all or nothing implementation. As I have noted before, most of the bank mergers I was involved in were big bangs.  On a specific day, all of the branches of one bank would close and overnight (more typically over a weekend) lots of people would change signs on buildings, customer files, and software systems. Perhaps it was a failure in imagination, but due to regulations and the need for notifications, it was easier for everyone to change at once.  Organizational transformations rarely have the same external drivers, regulations and notification rules; however, because of interactions between teams, it might be easier not to take an incremental approach.  Adoptions of large scale Agile methods and frameworks such as SAFe are often approached in a big bang manner. In SAFe many teams and practitioners are indoctrinated, trained and transformed together which by definition is a big bang approach to implementing scaled Agile.

Big Bangs generate a too big to fail focus.  Large, expensive, and risky changes create their own atmosphere.  These types of implementations garner full management sponsorship and attention because they are too big to fail.  Christine Green, IFPUG Board Member, suggests, “it is harder to lose focus on big bang approaches when organizational leadership changes.” Big bangs can be used to address the risk of a loss of focus in some cases.  An example of an organization manufacturing a too big to fail scenario can be found in the often-told story of the early years of Fedex (Federal Express at the time).  It was said that the founder consciously borrowed money from smaller regional banks around Memphis so that he could use the impact of the risk of default to negotiate better service and rates.  Big bang changes are often too big to fail and therefore people ensure they don’t.

Management Expectations.   In many circumstances, management has little patience for the payback of continuous process improvement. As I was framing this theme, Christopher Hurney stated, “I’ve seen leadership expect Big Bang results in Agile adoptions, which is kind of ironic no? Considering that one of the precepts of Agility is an iterative approach.” The expectation is often generated by a sense of urgency.  In this situation, a specific issue needs to be addressed and even though an incremental (or even iterative) approach would deliver bits and pieces sooner, the organization perceives value only when all of the benefits are delivered.  The Healthcare.gov marketplace was delivered as a big bang.

Even if the big bang approach to process improvement feels wrong, however, there are reasons for leveraging the approach. Chris Hurney stated that decision makers “tend to feel as though they’ve reached a point where a process has become unsustainable” which makes the idea of implementing a change all at once worth the risk even though nearly everyone would prefer an incremental or continuous approach to change.

Previous Entries in the Big Bang, Incrementalism, or Somewhere In Between Theme

1. Big Bang, Incrementalism, or Somewhere In Between

Next:  Big Bang, The Cons!

 


Categories: Process Management

The Pros for Big Bang Change Implementation

Vinigear Bottles

Not Sweet But Useful!

A big bang adoption of a process or system is an instant changeover, a “one-and-done” type of approach in which everyone associated with a new system or process switches over in mass at a specific point in time.  There are positives and negatives to big bang approaches.  We begin with the positives.

Patrick Holden, Project Portfolio Director – Software Development at SITA, struck a fairly common theme when asked about his preferences between the big bang and incremental approaches.  

While I favour incremental improvement, sometimes we really want to get on with the new, to change the mail system, phone, house, car or even your job you will need to prepare to different extents but you make the switch for one and all, it’s a Big Bang.  

The choice depends on divisibility, scope, and urgency.

The positives:

Big Bangs fit some types of changes.  Not all changes are easily divisible into increments which lead to an all or nothing implementation. As I have noted before, most of the bank mergers I was involved in were big bangs.  On a specific day, all of the branches of one bank would close and overnight (more typically over a weekend) lots of people would change signs on buildings, customer files, and software systems. Perhaps it was a failure in imagination, but due to regulations and the need for notifications, it was easier for everyone to change at once.  Organizational transformations rarely have the same external drivers, regulations and notification rules; however, because of interactions between teams, it might be easier not to take an incremental approach.  Adoptions of large scale Agile methods and frameworks such as SAFe are often approached in a big bang manner. In SAFe many teams and practitioners are indoctrinated, trained and transformed together which by definition is a big bang approach to implementing scaled Agile.

Big Bangs generate a too big to fail focus.  Large, expensive, and risky changes create their own atmosphere.  These types of implementations garner full management sponsorship and attention because they are too big to fail.  Christine Green, IFPUG Board Member, suggests, “it is harder to lose focus on big bang approaches when organizational leadership changes.” Big bangs can be used to address the risk of a loss of focus in some cases.  An example of an organization manufacturing a too big to fail scenario can be found in the often-told story of the early years of Fedex (Federal Express at the time).  It was said that the founder consciously borrowed money from smaller regional banks around Memphis so that he could use the impact of the risk of default to negotiate better service and rates.  Big bang changes are often too big to fail and therefore people ensure they don’t.

Management Expectations.   In many circumstances, management has little patience for the payback of continuous process improvement. As I was framing this theme, Christopher Hurney stated, “I’ve seen leadership expect Big Bang results in Agile adoptions, which is kind of ironic no? Considering that one of the precepts of Agility is an iterative approach.” The expectation is often generated by a sense of urgency.  In this situation, a specific issue needs to be addressed and even though an incremental (or even iterative) approach would deliver bits and pieces sooner, the organization perceives value only when all of the benefits are delivered.  The Healthcare.gov marketplace was delivered as a big bang.

Even if the big bang approach to process improvement feels wrong, however, there are reasons for leveraging the approach. Chris Hurney stated that decision makers “tend to feel as though they’ve reached a point where a process has become unsustainable” which makes the idea of implementing a change all at once worth the risk even though nearly everyone would prefer an incremental or continuous approach to change.

Previous Entries in the Big Bang, Incrementalism, or Somewhere In Between Theme

1. Big Bang, Incrementalism, or Somewhere In Between

Next:  Big Bang, The Cons!

 


Categories: Process Management

14 extensions that can enrich your daily VSTS usage

Xebia Blog - Wed, 02/22/2017 - 22:54
Using VSTS on a daily basis I find that I add a regular list of VSTS Marketplace extensions to my VSTS environment. I find them convenient and helping me to get the most out of VSTS. The list below is primarily focussed on the Work and Code area and not so much on the Build

New features in Xcode 8.2 Simulator

Xebia Blog - Wed, 02/22/2017 - 14:01
In the release notes of Xcode 8.2, Apple introduced features for their new version of Xcode. In this blog I will explain how to use these new features. Read more

New features in Xcode 8.2 Simulator

Xebia Blog - Wed, 02/22/2017 - 14:01
In the release notes of Xcode 8.2, Apple introduced features for their new version of Xcode. In this blog I will explain how to use these new features. Read more

First Steps in gRPC Bindings for React Native

Xebia Blog - Wed, 02/22/2017 - 13:54
When you want to use gRPC in your React Native app there is no official support yet, but that shouldn’t stop you! In this post I’ll show you how we designed an implementation with type safety in mind and successfully called a service remotely from React Native on Android. Read more

First Steps in gRPC Bindings for React Native

Xebia Blog - Wed, 02/22/2017 - 13:54
When you want to use gRPC in your React Native app there is no official support yet, but that shouldn’t stop you! In this post I’ll show you how we designed an implementation with type safety in mind and successfully called a service remotely from React Native on Android. Read more

Big Bang, Incrementalism, or Somewhere In Between

Line Segment Shutdown

Line Segment Shutdown

When making any significant change to a team or organization, deciding whether to take a big bang or incremental approach is important.  Both of these approaches–and hybrids in between–can work.  Big Bang and incremental approaches mark the two ends of a continuum of how organizations make a change.  The decision is almost never straightforward and organizations often struggle with how they should approach change.  The decision process begins by defining Big Bang and incremental implementation approaches in between the two ends so they can be compared.

Big Bang Implementations

A big bang adoption of a process or system is an instant changeover, a “one-and-done” type of approach in which everyone associated with a new system or process switches over in mass at a specific point in time.  For example, most of the bank mergers I participated in were big bangs.  The systems were all cut over on a specific date (lots of pizza and coffee was required for the cutover weekend) and the next business day all of the branches and ATMs began the day using a single system.

Big bangs are always the culmination of a lot of specific activities including planning, coordination, software changes, data conversions, and reviews.  All of these activities are focused on making the Big Bang successful.  Individually, the steps have little to no value if the final step fails.

Big Bang changes are sometimes equated to “bet the business” scenarios: if the change doesn’t  work, everything needs to be backed out or significant business impact will ensue.

Incrementalism / Incremental Approach

An incremental approach focuses on defining identifying and implementing specific pieces of work.  These pieces are generally smaller standalone pieces of work that progress an organization toward an overall goal but not generally all parts of one specific cohesive project.  For example, quality or process programs often use a continuous process improvement model in which practitioners identify changes or improvements which are then captured as part of a backlog and prioritized for implementation. This type of work is sometimes called continuous process improvement. In this scenario, lots of individual pieces of work accumulate over time to deliver a big benefit. Incremental changes generate a fast feedback loop which delivers enhanced learning. The small changes typically found in incremental approaches are useful for experimentation.

In Between or Phased Implementations

The term phased adoption can have alternate meanings.  The first (and in 2017 the most common meeting) is to break implementation into smaller pieces so that the organization has use of functionality sooner.  This is closer to an incremental approach (next) than a big bang.  Phased approaches break a bigger project into smaller projects so the adoption will happen in several steps. After each step, the system is a little nearer to be fully adopted. Phased differs from incremental generally in scope and the types of work in the backlog.  For example, in bank mergers, one phase might be to convert checking accounts and trust accounts in another phase.  In an Agile adoption, a phased approach might be to transform one team after another in a serial fashion.

The second possible use of the term is the famed waterfall approach in which analysis is completed before design all the way to implementation. This approach is far less common than it was in the late 20th century before the Agile movement, however, make sure you check by asking how the word phased is being used.

Which implementation approach makes the most sense will always depend on context.  The right choice requires understanding the goal of the change, resources available to make the change and above all else the organization’s culture.  The choice is not as stark as Big Bang (everything at once) or incrementalism (lots of continuous little changes) although these are the choices most often considered.

 

In the next entry in this theme, we will explore the pros of the Big bang approach.


Categories: Process Management

Design by contract using GraphQL

Xebia Blog - Mon, 02/20/2017 - 17:20
When interfacing between systems it is good practice to think about the interface design prior to developing the systems. GraphQL can be a useful tool to write down these design decisions using its schema definition language. Even when you are not using GraphQL itself in production. GraphQL’s schema can be used to generate a mock

Software Development Linkopedia February 2017

From the Editor of Methods & Tools - Mon, 02/20/2017 - 11:08
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about being a better leader and software manager, component teams, UX & Agile, writing less code, handling incidents, preventing Scrum to fail, test automation and lean principles. Text: How to be […]

SPaMCAST 431- Andrew Neitlich, Leadership is Core a Requirement

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 431 features our interview with  Andrew Neitlich on leadership.  We discussed whether leadership can be learned and if tech leadership is different than other kinds of leadership.  Leadership is a core requirement for making all teams, Agile or not, effective!

Andrew’s bio:

Andrew Neitlich is the founder and director of the Center for Executive Coaching (http://centerforexecutivecoaching.com), a leader in training and certifying executive and leadership coaches. He also leads his own executive coaching practice, with an emphasis on working technical leaders that sometimes get frustrated with engaging their teams and having more impact when they communicate. Andrew is the author of Coach!, Elegant Leadership, and Guerrilla Marketing for a Bulletproof Career. He received his MBA from Harvard Business School, and lives in Sarasota, Florida.

Re-Read Saturday News

This week we tackle Chapter 4 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  In Chapter 4, Dweck hits a home run by reflecting on how mindsets translate into action in the sports arena (thus the sports allusions).  Sports stories are one the most used metaphors in a business environment.  I bet that you can’t you to go to two meetings in any corporate environment without hearing a project likened to the exploits of sports teams or athletes. This an easy metaphor theme because most everyone has been exposed to some form of sports or at least a story about sports before they take a job. In Chapter 4, Dr. Dweck, scores (I can’t help myself) by using the exploits of athletes and sports teams to further illustrate the differences and impact mindsets deliver.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of someone pursuing an organizational transformation and also how to use the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Feedback on SPaMCAST 428 with Mark Bojeun.  Dan  Stafford wrote to Mark and said, “ Great talk Mark, insightful as ever.  Open and honest communication is such an important tenet.”   (Listen Now)

Do you have thoughts and comments you would like to share?  Email us at spamcastinfo@gmail.com

Next SPaMCAST

In the Software Process and Measurement Cast, we will feature an essay on the impact of leadership types on adopting and sustaining Agile.  Leadership style has a direct impact on an organization’s ability to adopt and sustain Agile.  Some leadership styles are more supportive and others evoke more of a  response that is epitomized by locking feral cats and dogs in a room (nobody wins).

We will also have columns from Jeremy Berriault, who brings his QA Corner to the cast.  Visit Jeremy’s new blog at https://jberria.wordpress.com/  Next, we will have a column from The Software Sensei, Kim Pries. Reach out to Kim on LinkedIn. Last, but not least, Jon M Quigley brings his column, the Alpha and Omega of Product Development, to the cast.  One of the places you can find Jon is at Value Transformation LLC.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

 


Categories: Process Management

SPaMCAST 431- Andrew Neitlich, Leadership is Core a Requirement

Software Process and Measurement Cast - Sun, 02/19/2017 - 23:00

The Software Process and Measurement Cast 431 features our interview with  Andrew Neitlich on leadership.  We discussed whether leadership can be learned and if tech leadership is different than other kinds of leadership.  Leadership is a core requirement for making all teams, Agile or not, effective!

Andrew’s bio:

Andrew Neitlich is the founder and director of the Center for Executive Coaching (http://centerforexecutivecoaching.com), a leader in training and certifying executive and leadership coaches. He also leads his own executive coaching practice, with an emphasis on working technical leaders that sometimes get frustrated with engaging their teams and having more impact when they communicate. Andrew is the author of Coach!, Elegant Leadership, and Guerrilla Marketing for a Bulletproof Career. He received his MBA from Harvard Business School, and lives in Sarasota, Florida.

Re-Read Saturday News

This week we tackle Chapter 4 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  In Chapter 4, Dweck hits a home run by reflecting on how mindsets translate into action in the sports arena (thus the sports allusions).  Sports stories are one the most used metaphors in a business environment.  I bet that you can’t you to go to two meetings in any corporate environment without hearing a project likened to the exploits of sports teams or athletes. This an easy metaphor theme because most everyone has been exposed to some form of sports or at least a story about sports before they take a job. In Chapter 4, Dr. Dweck, scores (I can't help myself) by using the exploits of athletes and sports teams to further illustrate the differences and impact mindsets deliver.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of someone pursuing an organizational transformation and also how to use the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Feedback on SPaMCAST 428 with Mark Bojeun.  Dan  Stafford wrote to Mark and said, “ Great talk Mark, insightful as ever.  Open and honest communication is such an important tenet.”   (Listen Now)

Do you have thoughts and comments you would like to share?  Email us at spamcastinfo@gmail.com

Next SPaMCAST

In the Software Process and Measurement Cast, we will feature an essay on the impact of leadership types on adopting and sustaining Agile.  Leadership style has a direct impact on an organization’s ability to adopt and sustain Agile.  Some leadership styles are more supportive and others evoke more of a  response that is epitomized by locking feral cats and dogs in a room (nobody wins).

We will also have columns from Jeremy Berriault, who brings his QA Corner to the cast.  Visit Jeremy's new blog at https://jberria.wordpress.com/  Next, we will have a column from The Software Sensei, Kim Pries. Reach out to Kim on LinkedIn. Last, but not least, Jon M Quigley brings his column, the Alpha and Omega of Product Development, to the cast.  One of the places you can find Jon is at Value Transformation LLC.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

 

Categories: Process Management

Mindset: The New Psychology of Success: Re-Read Week 4, Chapter 4 – Sports: The Mindset of a Champion

Mindset Book Cover

Today we rush into Chapter 4 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  In Chapter 4, Dweck hits a home run by reflecting on how mindsets translate into action in the sports arena (thus the sports allusions).  Sports stories are one the most used metaphors in a business environment.  I bet that you can’t you to go to two meetings in any corporate environment without hearing a project likened to the exploits of sports teams or athletes. This an easy metaphor theme because most everyone has been exposed to some form of sports or at least a story about sports before they take a job. In Chapter 4, Dr. Dweck, scores (I can’t help myself) by using the exploits of athletes and sports teams to further illustrate the differences and impact mindsets deliver.

Chapter 4 begins with the story of Billy Beane. Mr. Beane was a baseball player that was drafted and came through the minor leagues being viewed as a “natural” (someone that has all the talent in the world and will be a star).  Unfortunately, at the time, he had a fixed mindset, and when completion got tough he was not able to deal with the fact talent alone would not carry him forward.  The realization that he had to shift his mindset later led to the concepts discussed in the book and movie, Moneyball.  The statistical analysis Beane helped pioneer focused on identifying players with attributes, including many of the attributes we would recognize as a growth mindset, rather than raw talent. 

Chapter 4 goes on to highlight a wide range of other legendary athletes that illustrate that hard work and discipline are very powerful tools. All of the highlighted athletes became legends not just because they had awesome natural talent, but also because their mindset allowed them to see to benefit from learning from setbacks and hard work. It might be possible to make the argument that someone with a growth mindset can’t help learning from their experiences.  Something it took Billy Beane a long time to learn.  The top line takeaway of this chapter is that success is rarely just a reflection of ability.

An important reflection in the chapter is that humans seem to have a natural bias toward the belief that great athletes (and by extension other forms of genius) shouldn’t require effort to become the top of their field. This flies (another sports’ metaphor) in the face of the evidence that most “naturals” have only gotten to the top through discipline and learning from setbacks.  Dweck provides several examples ranging from Babe Ruth, Maury Wills, Michael Jordan, Tiger Woods, and Wilma Rudolph. A quote from Malcolm Gladwell is used to drive the point home, “People prize natural endowment over earned ability.”

Adversity is a feedback mechanism.  One of the descriptions of the behavior of Agile teams is that they pursue feedback (sometimes called running toward feedback) so that the team can learn how to change its behavior to deliver more value and customer satisfaction. Without a mindset that seeks feedback from even minor adversities, when you hit a major roadblock you may not be able to deal with it.

A person’s character (related to effort and discipline) is at least a partial reflection of the mindset the person has adopted.  The examples provided by Dr. Dweck in this chapter illustrate how the two mindsets help shape character.  Over and over, athletes with growth mindsets are better at dealing with adversity because they see setbacks as a tool to learn. In scenarios where top athletes don’t have a growth mindset, Dweck provides examples of how their inability to deal with negative feedback leads to failure.  Two athletes used to highlight the problems of fixed mindset were Pedro Martinez (baseball pitcher who imploded in playoffs against the New York Yankees) and John McEnroe (just one tantrum from YouTube).  While both athletes had their moment in the sun, I think we could ask just how good could they be if they had a growth mindset. Dweck contrasts the character of these two athletes with the character of Pete Sampras.  When asked how he could rally back to win after being at match point and down two sets (men’s championship tennis is typically the best of 5 sets) indicated he used adversity he faced overcome to remind himself about what possible and what he was capable of achieving.  With champions, when the going gets tough the tough get going. The examples in the book cherry pick, the most easily recognizable stars however even if mindsets don’t explain all variance in performance, mindset explain a large proportion.  

In this chapter the point that how we deal with feedback and whether we seek out feedback loops is a predictor of eventual success.  People with a fixed mindset eschew feedback and view setbacks as being victimized by outside sources.  When you are a victim it easy to decide that you do not need to take responsibility for your ability and control of your motivation.

Chapter 4 – From a Coach’s Perspective

Transforming a group or organization requires understanding the overall cultural mindset of the organization being changed.  Organizations often have a bias towards one mindset or the other.  For example, very early in my career, I worked for a firm that manufactured and sold junior ready to wear. At the time the organization had become the largest firm in the world in its category. They had achieved over a decade of phenomenal year-over-year sales increases. I recently found a transcript from one of their major sales meetings as things began to stagnate (they later collapsed).  It was amazing to see the evidence of how the firm rejected feedback from clients and successes described with “I” words rather than words that were inclusive of the whole team needed to deliver value to the clients and customers.  Words are an indicator of mindset both at an individual level and at an organizational level.  As you consider a path for a transformation, listen to how is performance is described in the organization. If these conversations don’t happen in the natural course of an assessment, illicit stories about performance and projects.  The words that are used will give you a strong indication of mindset.  For example, does the word “I” get used or the word “we” when describing a project?  Do people describe their identity though outcomes or effort (If I win I’ll be somebody if I lose I’ll be nobody)?

Identifying mindsets can be an important change management tool.  Change leaders can use mindsets to filter people who can be trailblazers and/or early adopters for the concepts being put forward in the transformation.

At the team level, listening is also applicable.  Use techniques like storytelling to elicit the markers of mindset.  I use this technique occasionally in retrospectives or when asked to help a team deal with behaviors that are impacting a project.  In the short term having a grasp on someone’s mindset is useful for knowing how to relate to the person and how they will react in certain situations. For a leader knowing a person’s mindset can be used to help a team member to accept the work that fits their temperament.  In the longer run, knowing which mindset a person emulates can help a coach to provide mentoring and training that can shift that mindset (if needed).

Previous Entries of the re-read of Mindset:

 


Categories: Process Management

Why don’t monitoring tools monitor changes?

Xebia Blog - Fri, 02/17/2017 - 12:38
Changes in applications or IT infrastructure can lead to application downtime. This not only hits your revenue, it also has a negative impact on your reputation. Everybody in IT understands the importance of having the right monitoring solutions in place. From an infrastructure – to a business perspective, we rely on monitoring tools to get

The 8 Leading Attributes of Trust, Leadership’s Most Important Tool

26303029941_b4376df9c4_k

Leaders require trust between them and those they lead to be effective. Trust is not a simple attribute like hair color.  Trust is a synthesis of several attributes. None of the attributes that impact trust are fixed at birth. As humans, we learn the attributes that generate trust based on the environments we are exposed to and hone them based on effort and importance we place on these characteristics. The 8 most important characteristics that shape trust in software development and Agile environments are:

  1. Competence – Trust is difficult in scenarios where there are significant mismatches in the combination of skills and experiences each individual brings to an endeavor. I recently observed a team in which a new, highly trained but inexperienced tester joined a Scrum team. There was not trust until the person had gained experience by interacting with the team for several sprints.
  2. Truthfulness – Trustworthy leaders will know and share the truth.  Deception, even when ‘harmless’ or even beneficial, will reduce the credibility of every statement going forward.
  3. Act as they think – Words, feelings, and beliefs match actions of the leader.  A popular adage is that if a leader “is going to talk the talk, they’ve got to walk the walk” in order to be trusted. 
  4. Integrity – Trustworthy leaders take responsibility for their actions and work and make sure that the work of other is attributed correctly.  A leader with integrity will link themselves to a set of moral and ethical principles that are known to the team and organization.
  5. Reliability – Trustworthy leaders say what they will do and do what they say they will do.  A corollary is that trustworthy leaders also do what they say they will do when they say they will do it.
  6. Loyalty – Trustworthy leaders are loyal to their people and organization (but not stupidly loyal).  All too often untrustworthy leaders will throw someone under the bus when issues are exposed or talk negatively about someone when they are not present.  Showing loyalty towards others is a prerequisite for receiving trust from others.
  7. Accountability – Leaders build trust by recognizing, admitting and accepting responsibility for their own mistakes.
  8. Just – A trustworthy leader is just to those on their team and with those outside their team. The actions of a just leader are predictable and measured rather than erratic and extreme. 

There are other attributes of trust; however, in a collaborative software development environment using Agile, these are often the most important contributors to trust in a leader.  A point that is often missed when discussing Agile or other decentralized frameworks is that leadership is dynamic. Therefore trust is important for anyone that might take up the mantle of leadership to foster.  I often recommend carving out time in retrospectives to examine trust to ensure that building trust is not seen as something that happens naturally or in random team building exercises.

 


Categories: Process Management

Serverless Architectures

From the Editor of Methods & Tools - Wed, 02/15/2017 - 13:46
Serverless architectures have been touted as the next evolution of cloud-hosted software. Indeed, the promise of resiliency and scalability without the need for infrastructure management sounds too good to be true! But what exactly does a serverless architecture look like? And what are the trade-offs to weigh up when considering using one on your next […]

Impact of Six Additional Leadership Styles on Adopting and Sustaining Agile

Leadership Styles

Leadership Styles

Leadership style has a direct impact on an organization’s ability to adopt and sustain Agile.  Some leadership styles are more supportive and others evoke more of response that is epitomized by locking feral cats and dogs in a room (nobody wins). In a previous entry we reviewed four common leadership styles; six additional styles include:

Laissez-Faire Leadership

A laissez-faire leader is hands-off and allows group members to make the decisions. The leader using this form of leadership will monitor what is being done and will communicate with the team on a regular basis. For this form of leadership to work team members need to be experienced, have discipline and be self-starters. Mature Agile teams can exist under laissez-faire leaders; however immature Agile teams will not receive sufficient leadership and control.

People-Oriented Leadership or Relations-Oriented Leadership

People/Relationship-oriented leadership is focused on organizing, supporting and developing the people on the leader’s team. The focus on the needs of the team is generally supportive of Agile practices. If this form of leadership is taken to extreme it can cause the leader and team to lose focus on the team’s goals.

Servant Leadership

The servant leader works to empower and serve the people s/he leads. Empowerment on an Agile team is removing impediments and coaching the team so it performs to its capability using Agile practices. Servant leadership is considered the most supportive of implementing and fostering Agile teams.  As we have noted there are downsides to servant leadership; however, most problems with servant leadership stem an over focus or mismatch of goals or conflict of vision. If these excesses are controlled servant leadership is an excellent match for Agile.

Task-Oriented Leadership

Task-oriented leaders focus on one thing: getting the job done.  This form of leadership can be perceived as autocratic.  Task-oriented leaders define work, roles and then assign the work. All of the versions of Agile that embrace the principles in the Agile Manifesto are structured around the premise that the team is motivated and can self-organize to address the work they have committed to delivering.  Task-oriented leadership is at odds with Agile principles. When this form of leadership is prevalent, Agile will have a tough time taking root in this environment, even though this form of leadership can be useful in extreme emergencies.

Transactional Leadership

Transactional leadership is built on the premise that team members agree to obey their leader totally when they take a job. Bonded, indentured servitude comes to mind when considering this form of leadership. For this fealty, team members are paid.  During my high school years, I worked in a department store warehouse.  I observed the foremen using this type of leadership “on” most of my fellow workers. As the high school kid, I tended to be treated differently floating between the two groups. This type of leadership caused both sides act out against the other. This form of leadership will stifle Agile and rarely has any long-term value. 

Transformational Leadership

A transformation leader inspires his (or her) team based on a shared vision of the future. This type of leader communicates (early and often) and they lead with enthusiasm, even though they tend to delegate responsibility throughout the team.  This form of leadership provides vision and then supports that vision by empowers others around them. This form of leadership is perfect for establishing Agile but in the long run is difficult to sustain the same levels of passion for a single transactional event.

There is no single perfect leadership style.  Often different leadership styles are used depending on context.  Highly Agile organizations often mix servant leadership styles with transformational.  The transformational style being used to tackle major changes within the organization while the day-to-day leadership style is more akin to servant leadership.  Even organizations with highly participative leadership styles may adopt more autocratic task-leadership styles in periods of great crisis in which consensus would take too long to develop. What is different from less mature or less participative organizations is that you very quickly retreat from this style when the crisis passes and they generally don’t feel good about the event. In order to get a sense how styles shift, ask a few people in that organization to tell you a story about the last crisis the team was involved in and then listen to the answer.  The stories that are told about major events are often very enlightening.

As a reminder, a comparison of the ten leadership styles review is shown above. The styles with the most filled in Harvey Balls are typically the most conducive to adopting and staying Agile.

The prevalent leadership style of an organization can impact both the ability to adopt Agile and then the ability to sustain Agile.  Autocratic, task-oriented and transactional leadership styles are as close to anti-Agile as can be.  While Agile might exist in protected pockets in organizations that these styles are prevalent they will not prosper. Instead, consider adopting kanban or Scrumban without the Agile principles in these environments and then slowly sell change by exposing bottlenecks and constraints.   

 


Categories: Process Management

New OnDemand Course - Scrum Overview

10x Software Development - Steve McConnell - Tue, 02/14/2017 - 18:23

Hello, Steve McConnell here. We are always updating our Construx OnDemand training, and I’m happy to announce a new course: Scrum Overview. Scrum enables software development teams to address complex adaptive problems, and in this course you’ll learn Scrum’s elements—its roles, events, and artifacts—as well as their purpose: how they’re all bound together to make Scrum hum. In short, you’ll learn what’s different about Scrum and what makes it so effective.

With the myriad Scrum courses available today, why would you take a course called Scrum Overview? If you’re a nontechnical stakeholder, such as an executive or sales and marketing staff or even a product owner, you might find value in getting an introduction to Scrum without diving into all the details, and the context that’s set in this course can very valuable. Even if you are a practitioner and you expect to get into the in’s and out’s of Scrum on a daily basis, it can useful to start with the context of Scrum so that you understand its full scope before diving into all those implementation details. Either way this can be a valuable introduction and overview of Scrum.

Your instructor in this course is Jenny Stuart. Jenny has been Vice President of Consulting at Construx for more than 10 years, and in that role she has overseen Construx’s work in implementing Scrum, and implementing Agile practices more generally, in organizations throughout North America and around the world. Jenny has worked effectively with individual contributors on Scrum teams, with Scrum Masters, and with executives who are supporting Scrum at the organizational level, and she has learned numerous lessons about how to support Scrum effectively by working at all those different levels. You’re in good hands with Jenny as the leader of this course.

  • Here’s the top-level outline for the course:
  • Introduction
  • The Scrum Framework
  • Scrum Roles
  • Requirements in Scrum
  • Agile Estimation
  • Plan a Sprint
  • Execute a Sprint
  • Wrap Up a Sprint
  • Adoption Pitfalls
  • Conclusion
If you want to go deeper with Scrum, follow this course with Construx OnDemand’s Scrum Boot Camp, which will teach you what you need to know to become certified in Scrum.

If you’re a Scrum Product Owner or want to become one, Product Owner Boot Camp drills down into the details you need to successfully plan releases, reflect stakeholder priorities, ensure the team builds the right product, and communicate with project stakeholders.

For more on developing requirements in Agile scenarios such as Scrum, see Agile Requirements Boot Camp, which teaches you how to use story mapping to define project scope, write user stories, size stories (agile estimation), and develop acceptance criteria for user stories.

Try Construx OnDemand for free today (no credit card required), and enjoy the course!

New OnDemand Course - Scrum Overview

10x Software Development - Steve McConnell - Tue, 02/14/2017 - 18:23

Hello, Steve McConnell here. We are always updating our Construx OnDemand training, and I’m happy to announce a new course: Scrum Overview. Scrum enables software development teams to address complex adaptive problems, and in this course you’ll learn Scrum’s elements—its roles, events, and artifacts—as well as their purpose: how they’re all bound together to make Scrum hum. In short, you’ll learn what’s different about Scrum and what makes it so effective.

With the myriad Scrum courses available today, why would you take a course called Scrum Overview? If you’re a nontechnical stakeholder, such as an executive or sales and marketing staff or even a product owner, you might find value in getting an introduction to Scrum without diving into all the details, and the context that’s set in this course can very valuable. Even if you are a practitioner and you expect to get into the in’s and out’s of Scrum on a daily basis, it can useful to start with the context of Scrum so that you understand its full scope before diving into all those implementation details. Either way this can be a valuable introduction and overview of Scrum.

Your instructor in this course is Jenny Stuart. Jenny has been Vice President of Consulting at Construx for more than 10 years, and in that role she has overseen Construx’s work in implementing Scrum, and implementing Agile practices more generally, in organizations throughout North America and around the world. Jenny has worked effectively with individual contributors on Scrum teams, with Scrum Masters, and with executives who are supporting Scrum at the organizational level, and she has learned numerous lessons about how to support Scrum effectively by working at all those different levels. You’re in good hands with Jenny as the leader of this course.

  • Here’s the top-level outline for the course:
  • Introduction
  • The Scrum Framework
  • Scrum Roles
  • Requirements in Scrum
  • Agile Estimation
  • Plan a Sprint
  • Execute a Sprint
  • Wrap Up a Sprint
  • Adoption Pitfalls
  • Conclusion
If you want to go deeper with Scrum, follow this course with Construx OnDemand’s Scrum Boot Camp, which will teach you what you need to know to become certified in Scrum.

If you’re a Scrum Product Owner or want to become one, Product Owner Boot Camp drills down into the details you need to successfully plan releases, reflect stakeholder priorities, ensure the team builds the right product, and communicate with project stakeholders.

For more on developing requirements in Agile scenarios such as Scrum, see Agile Requirements Boot Camp, which teaches you how to use story mapping to define project scope, write user stories, size stories (agile estimation), and develop acceptance criteria for user stories.

Try Construx OnDemand for free today (no credit card required), and enjoy the course!