In the last blog post, Mindset In Software Development Organizations, we examined how the fixed and growth mindsets showed up in software development organizations. In this post, I’m going to describe how many organizations that have embraced the notion of Agile software development have let the fixed mindset undo most of the benefits of embracing Agile and how the growth mindset may provide a solution.
The Agile Manifesto
Look at how the values in the Agile manifesto line up with the growth mindset / fixed mindset dichotomy.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Valuing individuals and interactions over processes and tools requires trust in those individuals to eventually succeed even if they fail at first. In a fixed mindset organization, the first sign of failure would result in the imposition of more process and tools to prevent reoccurrence.
Valuing working software over comprehensive documentation and customer collaboration over contract negotiation means not being afraid to put working, but unfinished software in front of customers and potentially looking stupid because not all the functionality the customer wants is done yet. A fixed mindset organization, upon getting feedback from a customer that the software doesn’t do everything they want (yet), would request that a more detailed specification / contract be negotiated with the customer so that the customer will be completely satisfied when they finally see the finished software with every feature delivered. We know how that ends.
Valuing the ability to respond to change over following a plan means driving out risk with experimentation and potentially failing and/or changing direction many times on the way to a solution. A fixed mindset organization wouldn’t tolerate that kind of failure and would insist that, in the future, more detailed plans be developed to prevent such “failures”.
Agile Practices
A lot of the practices of agile teams presuppose growth mindsets to be effective. Extreme Programming (XP) practices like pair programming require being comfortable looking stupid in front of a peer because they’re watching you write code and are literally watching for mistakes to help you. A fixed mindset person wants to do the work alone to prove they can and wants to send only the finished, polished code out for code review, or worse, doesn’t practice code review at all. Practicing code review and pair programming means that you can’t hoard knowledge and be the one person on the team who knows a given component. There is also a misconception that the training aspects of pair programming only go one way — from the expert to the novice, but that’s only true when the expert isn’t looking to learn something.
Collective code ownership is difficult in fixed mindset teams. Taking ownership, shared or otherwise, of someone else’s code means being lost at first and looking inexperienced. A fixed mindset person who feels that they are a specialist in a particularly challenging component such as an optimizer might be insulted to be asked to share ownership of, say, a UI codebase, the documentation, or the tests. A growth mindset person would see this as an opportunity to stretch and learn outside their comfort zone and would not be afraid to look inexperienced.
Leaving slack in the schedule for things like skill-building runs counter to the fixed mindset. If you believe you already know what to do and don’t need to learn anything, taking time out to spend learning means you didn’t already know everything. A fixed mindset manager wants to see everybody working and a fixed mindset employee needs to look busy — so much for limiting work in progress. A fixed mindset employee also can’t be seen as falling behind on a project but doesn’t feel they can ask for help, so they work nights and weekends to deliver to when they estimated they’d be done — so much for sustainable pace.
Agile Ceremonies
Even the ceremonies / meetings that agile teams practice are impacted by mindset. People with the fixed mindset are either quiet in meetings because they don’t want to look like they don’t know something or they do all the talking in meetings because they want to look like they have all the answers. Growth mindset individuals on a growth mindset team are curious and not afraid to look stupid.
Think about the daily standup: you have to talk about progress and impediments in front of everybody. The fixed mindset individual hides problems because they see them as indicating internal flaws. The growth mindset individual raises impediments and is transparent and forthcoming about problems because they see these problems as opportunities to learn and not indicators of permanent weaknesses.
Look at how fixed mindset teams hold retrospectives. They either don’t hold them at all, or they use them to talk about successes, or they use them to blame external factors for failures.
In backlog refinement meetings, fixed-mindset dominant personalities in the room take advantage of fixed-mindset fear to sway the group towards a certain direction, design, or plan. Planning poker helps mitigate this because everyone has to choose their estimate before they see everyone’s cards, but I’ve still seen people whose estimate disagreed with the rest of the group simply fall in line without debate.
Look at how some teams do release and sprint planning. Some teams plan so much that there’s little difference from a traditional waterfall approach. Everything has an estimate and everything has a deadline. There’s little room for experimentation or responding to change in these perfectly crafted plans. This indicates a fear of failure and an attempt to mitigate with even more planning.
What Can Be Done?
So to be successful, part of adopting agile approaches means adopting more of a growth mindset. Go back to the values of the manifesto. Relate the ceremonies of whichever agile framework you use back to those values. A retro needs to be about not being afraid to look at problems and see what part you played in them, not to judge yourself but to learn from the event.
Sprint planning or backlog grooming or whatever process you use to get the whole team looking at the next set of stories the team will work on needs to be about honestly assessing the work involved and calling out what you don’t understand and not being embarrassed to say so. People need to feel safe to ask questions and honestly communicate when they don’t understand something about an upcoming story.
The daily scrum or standup needs to be about transparency and raising impediments in a timely manner. Work that carries over from day to day in unfinished state needs more than just an acknowledgement that it is still in progress. Again, people need to feel safe to talk about why something may be taking longer than expected or whether they feel stuck and whether they think they need the help of a peer. People need to see that estimates are not being treated as commitments and held against them.
If people have problems with shared code ownership, they need to feel safe enough to talk about why they feel that way. They need to see in their peers that sharing these feelings is welcomed. They need to feel that we’re all in this together, we have each other’s back, and we’re all just trying to help the customer and the business to be successful.
I would love to hear what you thought of the video, so feel free to comment below, on The K Guy Twitter, or on The K Guy Facebook fan page.