I run into clients who believe they are applying agile project management. Yet they are seeing little benefit. Why? Typically these folks try to apply agile while still using a fixed mindset. In this article, I’ll give you core practices and tips for reaping the benefits of agile.
Fixed vs. Growth Mindset
In agile, we often think of having an experimental mindset where we try something, measure the results, retrospect and replan. We need to do that for our projects. And, as agile leaders, we need to do even more. We need to have the agile mindset.
In the agile mindset, we need to encourage people for their efforts, sometimes especially if they fail. We need to encourage people on our projects to ask for and offer help. We need to be aware of our biases for estimation. Why? Because we are not perfect at anything, never mind estimation. We are works in progress, getting better all the time.
Having an agile mindset can be challenging at times. The agile mindset is the growth mindset, named from Carol Dweck’s Mindset: The New Psychology of Success.
Here are two statements:
- We are born with the capabilities and talents we have.
- We can learn and grow, no matter how old we are. We may have some limitations, but we can always get better.
If you believe in the first statement, you have the fixed mindset. If you believe in the second statement, you have the growth mindset. In agile, we believe in the growth mindset.
The Growth Mindset in Action
How do you help yourself and your team acquire and build the agile mindset?
Early in Danny’s journey as an agile project manager, he facilitated a team. They got a feature wrong. Not surprising. The product owner blamed the team. The team was dejected by the failure. One of the developers said, “What if we’re not good enough to do this?” It was a problem.
Danny decided that he needed to do something or the team would fail. He said, “Okay, we didn’t do what we needed to do. But here is what we know now. We know what the product owner does want, right?”
Many of the team members nodded. Not everyone, but almost everyone.
“Okay, so we learned from this iteration. Maybe we should make our iterations shorter, so we can ‘fail faster’. What do you think? What if we got feedback from our product owner faster than we do now? What if we got feedback from the product owner every couple of days? How do you think we could do that?”
Some of the team members started talking among themselves. One of the members who hadn’t nodded before said, “Instead of this ‘failing’ business, why don’t we call it ‘learning’ instead?”
Danny agreed. He thought that was a great idea.
Sue, one of the developers who hadn’t nodded originally, spoke up. “You know, I was trying for perfection in that feature. I wanted it all done, wrapped up in a bow. I should have done something just enough, and gotten feedback, to know if I should have proceeded first.”
Tony agreed. “I could have worked with you to make tests to help you show something to our product owner faster.”
Danny didn’t say anything. He thought it was great that the team members were developing their own solutions. Sue turned to Danny. “How can you get the product owner to give us feedback and not blame us?”
“I’ll talk to him and see if we can reframe that business of blame to feedback. It’s all in how he says it, isn’t it?”
Danny didn’t realize it, but he was helping the team create more of an agile mindset with his first question. What did Danny do?
Make learning the goal
For every feature, and certainly if your team works in iterations, make learning your goal. When you schedule retrospectives, you can reflect on that learning. Yes, you need to make delivering value your first goal. In addition to that, make sure that your team realizes that even if the product owner doesn’t like what you deliver, that the goal of delivering the feature is that the team learned.
The learning is key to the team’s growth. Note that Danny asked, “We know what the product owner does want, right?” The team could take that question and continue from there.
Celebrate the learning that arises from success or “failure”
When you reframe a “failure” as learning, you can decide what to do differently the next time. This team had several ideas, including working together on features, providing the product owner more opportunity to see work as they developed it, and not trying to mind-read what the product owner had in mind.
You can talk about the effort that the team invested and about what the team learned. Danny didn’t do that. Here, the team decided it wanted more feedback more often from the product owner. The members realized they were not helping themselves with the way they worked with the product owner.
Help your team build resilience
Things will happen. Your estimates will be wrong. You will deliver something that doesn’t work. Murphy’s Law will come sit on your project. What happens when things go wrong?
With the agile mindset, with the growth mindset, you use resilience to help your team learn from what happened. If anyone blames the circumstances, that’s an example of the fixed mindset. If you hear that, see if you can reframe that to, “Next time we can try harder. What other ways can we try differently?”
Danny’s team didn’t blame the circumstances; they problem-solved. However, the product owner blamed the team. Danny has to work with the product owner to help the product owner realize that the team won’t get everything right the first time through. It’s the product owner’s job to provide feedback, not blame.
Reframe perfection to “Good Enough for Now”
Many team members want to be perfect. Instead of being perfect, help people reframe the notion of each person being perfect to doing something that is good enough for now, and releasing it. The idea is to provide value early.
Some team members will have trouble with this. The idea of agile is the ability to change. You can’t change the backlog or the project portfolio without being done for now.
Sue’s comment about “wrapping everything up in a bow” is typical of what many developers or testers feel when they transition to agile. Being able to do what people feel is partial work, or getting feedback about work in progress is a sign that people are transitioning to an agile mindset.
We are each a work in progress
No matter what happens in your team, remember that we are all a work in progress. We may have times of the fixed mindset–when we think we just can’t do it at all. That’s when it’s helpful to work in a team. Our team members can help us over that hump by working with us and providing moral support.
As a leader on the team, you–the agile project manager–can lead by exhibiting the agile mindset for yourself. When you work this way, you show others they can, also.