The Neuroscience of Agile

Over the past year, my interest in neuroscience has grown and one of the interesting things that have come out of my learning is that the brain, as it turns out, spends quite a bit of energy thinking (subconsciously) about what might happen in the next moments in time. 

Historically it had been thought that the brain reacted to stimuli and then formulated a response (think fight or flight).  But the brain is much more active in its planning whether or not we will need that type of response. Our brain is constantly evaluating what we are doing at the moment and trying to predict what our response will need to be in the upcoming moments.

That implies that our brains are tuned to short-range planning, so it should not be surprising that humans are not all that good at predicting what will happen further in the future. 

That’s not to say our brain doesn’t look at what has transpired historically and provides us an ability to guess what the future of something might be, but ultimately we simply aren’t wired for success in long-term predictive planning.

So given our brain is good at predicting what will happen in the very near term, I find it interesting that software development processes evolved over the years to encourage long-term planning, asking people to say today what they will do 6 months from now, especially given all of the unknown variables that exist in complex software development work.

At best we are guessing about what we will need to do 6 months into a 12-month project.  The brain simply isn’t set up for the successful long-range planning that Waterfall requires because we can’t anticipate what might happen as it is too far out into the future.

I suppose all of the Waterfall gates and approvals are designed to provide us some level of comfort or false confidence against the unknowns we accept as a risk to our projects.

Software development is a complex thing, you are asking people to develop in or on top of a complex environment where everything can’t be known upfront and the human brain no matter how much you try to plan for the future, really must be focused mostly on the more current aspects of their project, eg - what am I doing today and tomorrow and at most next week.  Sound familiar?  Short incremental development cycles followed with an inspect and adapt check-in?

So if our brains have developed to be very good at short-term planning why would we not want to adopt Agile as a way to deliver our software development efforts?

Agile aligns to a natural strength, short-term planning with fast feedback loops, which provide us an ability to react and respond to what we are seeing and learning. 

Those fast feedback loops inform everyone as to what just happened and what is about to happen so that if needed, we can react and change our course.  Our brains are set up for this type of behavior. Asking us to plan tasks months in advance is asking for failure on multiple levels, be it productivity, quality, context, or value.

As you either consider adopting Agile or making your current effort more successful, spend a good amount of time redesigning your planning process top to bottom, to support a short-term planning cycle.  You will find everyone more supportive (and happy) of working this way and you will see more value being delivered.

To learn how you can be better at Agile contact me at Michael@soundagile.com

Rear View Mirrors aka Mater Vision (Retrospective Habits for Agile Teams)

One of my favorite movies is Cars and specifically the character Mater, rusty and crusty but full of humorous and unintended sage advice.

During one point in the movie, Mater starts driving in reverse, on the road, off the road and Lightening McQueen is very impressed and asks Mater how he drives so well and his answer was, Rear View Mirrors to which he adds I don't need to know where I'm going if I already know where I been.

I started thinking about how this applies to high functioning Agile teams and their ability to provide predictability to their organizations.

More specifically I'm talking about how Retrospectives act as our rear view mirrors providing us with key visibility to where we were just at and an opportunity to reflect on where we want to go.

As an Agile team we constantly reflect (via Retrospectives) on where we were just at so that where we are going is incrementally improved, much like Mater and his rear view mirrors.  He's constantly reflecting on where he's been such that he's already where he needs to be before he gets there...

For organizations that are starting to adopt Agile ensuring that your teams utilize the Retrospective process is key to seeing the types of productivity improvements that Agile can and should deliver.

Retrospectives need to be both a no holds barred conversation about what did and did not work, but the team needs to ensure that it's also a safe place in which to talk about the issues that keep us from being really successful.  As a manager or management team you need to back away from the team and give them room to organize themselves.  As I've said before if a team feels empowered and is clear on the vision of the organization they are capable of solving both team and organizational issues that you didn't think were easily solved.

Traits and habits of good Retrospectives are actually very simple:

1. Have it consistently after each iteration.
2. Hold the Retrospective right after your demo while all of the iteration context and issues are fresh in your mind.
3. Each Retrospective should start with review of any action items from the previous sprint.
   1. Scrum Master - Ensure that this happens as this is the key to having the team feel like the issues that are causing problems are actually being addressed.
   2. Scrum Team - You need to commit to addressing the action items identified in a Sprint to ensure that you are applying continuous improvement to your teams processes.
4. Working Agreements - The team needs to have a set of agreements by which their Retrospective will be run, follow these agreements, which should include:
   1. Respect your team members - Allow them to call you out if necessary if you were in fact a blocker (I have been and no it's not nice to hear that, but your teammates are relying on you to make sure that they are successful.)
   2. Attack the problem not the person - This is key, you all want to be successful, don't take things personally, ask questions and come up with solutions that might work.
   3. Understand that not every idea you have will make things better, be prepared to fail.
5. Keep the Retrospective to the members of the Team that are responsible for delivering the work (aka Individual Contributors).  Managers and Stakeholders should not attend.  As a Scrum Master you may have to tactfully address this if these individuals want to attend.
6. Relax, we aren't trying to solve world peace.

Continuous Improvement leads to predictable velocity providing you with the ability to be like Mater.