Behavior Driven Development is more than Automation

Recently while working with an organization going through a large Agile adoption I had the opportunity to work with a team that was open to adopting BDD acceptance criteria story development.  One of the key differences for this team was that this was the first time that they had experienced a collaborative story development effort.  Prior to this most teams in the organization looked to the Product Owner to write all of the stories, which led to stories that were not contextually rich, had little to no acceptance criteria and were difficult to demo at the end of the sprint.

As I discussed the success of the teams use of BDD I was surprised to hear feedback that indicated the organization wasn’t ready for the heavy lift of using BDD and that I hadn’t moved the team into BDD because their final work wasn’t automated.

If that is your position then I think you are missing the point of BDD.  Yes BDD is great in that when you right acceptance criteria in the Given/When/Then format and build your example tables correctly you can obtain automation fairly easily with tools such as Cucumber, Fitnesse and a whole host of tools that have been developed to support this very successful way to build out what I call ‘contextually rich’ user stories.

However even if you don’t automate your BDD acceptance criteria, the value you get from understanding the behavior of the features you are going to build is invaluable.

BDD came about because Dan North realized that TDD and really great code meant nothing if it didn’t deliver the value or functionality that the stakeholder needed.  This concept was clearly illustrated for me at one organization I worked for when the Development Manager was lamenting about a Product his team was enhancing was pulled from the market because they didn’t deliver on time in order for the organization to stay competitive in the market.  He said ‘If only they could see all of the cool code that we’ve written’….To which I said ‘Business doesn’t care about code they care about delivery” no matter how great your product is from a code perspective it matters not at all if you don’t deliver it when your customer needs it.

For those of you who are exploring the use of BDD with your Scrum teams understand that there are essentially two separate efforts that effective teams are working on:

1. Team collaboration – Successful teams using BDD understand that they all need to be involved when building out user story context with Given/When/Then.  In fact I would argue that this is the most important element that drives a clear understanding of what we are building and guidance to when a user story is done.

2. Automation – One of key components of successful Agile teams is the development and maintenance of an effective automation suite.  Utilizing BDD provides an effective way for teams to obtain high levels of automation and do so within the Sprint that they are working in.  A common mistake of newer Agile teams is to develop in one sprint and test in the next and sometimes automate in the third.  Using BDD automation tools such as Cucumber with well written acceptance criteria (I’ll provide examples of well written BDD in my next blog post)

A third benefit of BDD is that a Scrum Team builds a clear understanding of the scope of the story.  Since everyone participates in the development of the acceptance criteria, if a scenario is missed, it’s a shared miss – No finger pointing, just manage the new scope with a new story and prioritize it in the backlog.

I’ve helped a number of organizations implement BDD effectively,  one of which did not have any automation at all.  The use of BDD acceptance criteria writing almost immediately improved the understanding of the features being developed and helped my QA team write significantly more test cases than they had been doing.  This effort led to a measurable improvement in Quality even before we added the automation suite later.

Having come from a waterfall world many years ago I can tell you that when you ‘get’ BDD,  it changes the way that you look at requirements and provides you with a mental framework that you can quickly use to model what is going to be built.

After a few months of using this format at Disney the Product Owners were uniform in their agreement that there simply was no other way that they would want to work with their teams.

Automation IS our goal, but it is not what defines BDD.

Being Agile – Say it, Do it, Prove it

I was working with a team recently and as we talked about all of the planning that Agile entails, I broke it down into very simple terms – Say it , Do it , Prove it.

That is really what Agile is about.  Anything else outside of these three concepts is noise to your ability to deliver product and services to internal and external customers.  As Product Owners in an Agile organization, you need to understand all of the effort and dynamics involved in getting your teams to Say it, Do it, Prove it.

Delivering what you say you are going to deliver is the best way to build credibility with your stakeholders.

For Agile teams, this translates into being effective at decomposing your stories into small enough increments so that you are confident in your understanding of the user story and estimates that the team believes in.

1. Say it = Release Planning and Backlog Grooming –
   1. Starting at a high level, the Product Owner is responsible for saying what is important to the organization from a value standpoint and beginning the process of developing a user story backlog that supports this vision.
   2. User story decomposition is so important to effective Agile teams and the Product Owner must start with a set of well-formed stories that provide context to the team.
   3. What is ‘context’?   Context is anything that provides definition.  It is basically what the product should do from a functional standpoint.  One of the biggest mistakes many teams make is writing declarative stories that start with the ‘How’.  This,\ in turn,  puts the technical team on the defensive as they may have many different ways to implement the feature.  As a Product Owner, be sure to steer clear of writing stories that define how you think the feature story should be implemented.  I know that as we all become well versed in technology there is a strong desire to show off our technical chops, however, as a PO you need to provide context from a business standpoint that your tech teams can consume. I’ve heard time and again from engineers that they would really like to understand how what they are developing delivers business value or solves a particular pain point for the customer.  The team works much more effectively when they are completely grounded in the business context of what they are building.
2. Do it = Sprint execution 
   1. An important element for teams to address once they are ready to take stories into a sprint, is that the goal during the Release Planning and Backlog Grooming activities was to begin to build out the context of ‘How’ the story will be implemented.  It is so important for teams to understand that there is essentially a handoff from the PO to the Scrum Team and that each of them is responsible for building what I call contextually rich user stories.  Gojko Adzic calls this Specifications by Example.  Effective teams who deliver fast and with high quality work closely as a team.
   2.  I believe that the combination of User driven stories and context driven specifications (examples) forms an extremely strong definition of both Ready and Done. which is why I coach my teams to utilize BDD as the basis for developing their User Story acceptance criteria.  The team works together to complete BDD acceptance criteria forming a clear understanding of the boundaries of the feature.  This provides the PO with a concise view of what to expect during the Demo.
   3. Another key benefit of writing BDD as part of your user story writing is that the test automation engineers can easily consume this as part of their code development for the automation.  PO’s should push to get to this level of context as it also means that your test engineers can start developing their test automation code once the story is ready for development.  They can essentially perform TDD in that they can write their automation before the feature is actually developed.  Once developed the automation should run cleanly and both speed and quality are attained.
   4. The goal of teams should be to deliver user stories that do not require much further elaboration once the sprint begins.  You want your teams focused on delivery ,not on discovery.
3. Prove it = Retrospective
   1. You have done all of the work to clearly define your user stories with high levels of context.  With all of this effort, the Retrospective should be an easy affair to show the work that was defined in the stories.  The PO should not have any surprises.  In fact, if the team misses any test scenarios after the story has been started, the PO should consider that more of a missed requirement over anything else.  Since the entire team developed the stories,  there can be no finger-pointing at anyone.  It was a shared miss and everyone must accept it.

It sounds really simple when broken down into these 3 basics phrases.  The truth is that ‘Being Agile’ is much more involved than simply ‘Doing Agile’.

“Being Agile” means exposing all of the inefficiencies in your product development processes.  It requires that the organization be completely honest in assessing what is not working and committing to letting the teams that do the work fix these processes.  You cannot top down drive the type of organizational change that is required for Agile continuous improvement.  Real organizational change is fostered at the top but truly owned by the Scrum teams that form in support of any Agile adoption.

Building great products

A long time ago I left college with the notion that I wanted to ultimately run my own business, my job experiences were purposefully diverse, giving me experience in Sales, Banking, Management and ultimately IT and luckily I’ve been able to do that several times.

While I wasn’t always engaged in the world of technology during some of its growth, I’ve always been involved in building and delivering great product.

What I learned during this time is that building great products is much like writing a symphony, you have many instruments that you can choose from for your piece, but if you don’t bring them together in the right way, if you don’t understand the limitations of those instruments you don’t end up with a masterpiece, but rather something that might sound like noise.

I have often used the concept of a symphony as an example for the way that we manage software project delivery.  You have an individual, Conductor, who is responsible for ensuring that everyone in the symphony is playing their parts correctly, are watching the conductor for queues on changes that might be made in the middle of the concert.  When everything comes together correctly you get beautiful music, when it doesn’t…..not so nice.  Building software in an Agile world is much like this, the Conductor is the Product Owner and the delivery teams are the musicians who watch the conductor for their queues when small changes are made in the delivery.

Understanding your craft, be it song writing, engineering, sales, etc….is an important element of you becoming great at what you do.  The craft of building great products is being able to master how to manage all of these different crafts in order to bring about something great.  My wife, who is an Arts Manager, has often likened software development as just as much as artists realm as an engineering one.  I have another post I’m writing that explores this in more depth.

For those of us who build a product with software we define our vision, much like a composer will do.  Once the vision is identified then we determine what components (or instruments) we will need to accomplish our vision.

What are the types of instruments that we use build product with software?

1. Product Owners/Managers
2. Product Developers
3. Product Testers
4. Software – Java, .Net, etc…
5. Hardware – Servers, Databases, etc..

What is our endgame with these ingredients?  Build product with software that delivers functionality that customers want and are willing to pay for.  If our instruments aren’t aligned with this primary goal, we’ll waste time and money and deliver quality that isn’t what the customer expected.

When we talk about quality in the software world, we talk about defects, code quality, etc…, however from a holistic standpoint none of this matters if you haven’t delivered a product that people want.  Your first goal as a Product Development team is to understand and align yourself to this completely.  If you focus more on delivering technical quality then you aren’t delivering the quality that the customer is expecting. Using the example of a restaurant, I can cook and deliver the absolutely best Pasta Primavera to you, but if in fact you wanted a Steak, then I have missed your quality expectations.  It doesn’t matter how good the food was, how well it was delivered, it failed to meet your expectations so the entire element of how you perceive the quality of my business is affected.

I think we are moving towards understanding this with concepts such as Personas, however I’ll be honest I’ve been in only one place  where we paid attention to these personas as we built our product,  I think many of our high-tech companies that have evolved over the past 10 years are much more focused on the technical aspects of the product over what the customer wants.  Example?  Facebook, Google.  They release new features and then gauge response and then remove or modify the product features based upon feedback.   I think long-term this is not the paradigm that will bring success to most organizations, eventually you need to be driving your company based upon what your customers want, not what seems cool and technically challenging.

Building great product has absolutely nothing to do with technology.  Technology is merely the enabler of a product that customers want and are willing to pay for.   If we could find a different way to deliver the product without technology (or at least the technology we have in place today) we would do that in a heartbeat.

If we are to re-align our instruments as a technology team delivering quality what would they look like?

1. A clear understanding of what the customer wants, ensuring that whatever we work on is aligned to that need.
2. A clear set of requirements that support that need.  Agile provides a process for capturing user needs with User Stories, however the key miss I see with most user stories is that they aren’t written to align to the customer need.
3. A set of software specifications that support the User driven stories.
   1.  What do we mean specifications? Using tools and processes such as TDD and BDD to define the user story at the technical level.  Again another big miss I see with teams who write user stories is their acceptance criteria stays too high level to understand the technical elements we need to delivery as part of our technical quality.
   2. Though Agile is about conversations over documentation, we really can’t deliver high quality software unless we build a shared understanding of the user stories and a depth of understanding via specifications.
4. A feedback loop that delivers customer feedback to everything we do.

Notice, in the new set of instruments there is no mention of technology, how you deliver a feature is entirely up to the technologists.  Their responsibility is to deliver customer features, the expectation as professionals is that they will do it with quality.

Delivering great products comes from the intersection of  customer needs and high quality technology.  Great product can survive from lack of technical quality in the short team but it can never survive the lack of focus on features driven by the customer.

Agile Certifications – Why they aren’t neccessary

Agile started many years ago with some basic (note I do not say simple) concepts related to how we should work together to build better software products.  Though I struggle with the notion that mere communication among individuals can deliver quality software, it can provide a product that is closer in alignment with the product owner’s vision.

I remember as Agile unfolded there was a debate on whether we needed things such as certifications.  I recall the argument that the very process of creating certifications for things such as Scrum would defeat the very benefits that the Agile manifesto was attempting to address.

Now many years into the manifesto I have to say that these certifications have brought an element of rigor that ‘can’ be beneficial but I think often stifle the creativity that can come out of Agile teamwork.  Certifications do not make you a great Scrum Master nor a Product Owner, they merely convey that you have taken a 1-2 day class that has provided you with the  evolved standards that Scrum has been defined to be.

I’ve been involved in a number of Agile transformations along with working in already high performing agile organizations and none of them are alike.  One thing I have taken  away is that teams who are provided space to try new things often find creative ways to solve the unique challenges they face.

As someone who started in Agile from the project management perspective I quickly realized that I was not your standard project manager who managed against a project plan, happily disconnected from my team.  No I was always learning, asking questions, it is how I went from a project manager into QA, because I took an active role in being in helping my team deliver great software.  Through out it all I was most focused on getting feedback from my team in order to improve our processes.

In those early days there were no certifications, we just took the concepts and did what worked and continued to evaluate how and what we did.  With certifications there is almost a cookie cutter approach to engaging Agile that I don’t believe was the intent of the original writers of the manifesto.

Scrum and the processes it provides are extremely important, I’m not saying that these don’t bring value.  What I am saying is that you don’t need certifications in order to be good at Agile and Scrum.

I always tell my teams, Agile isn’t easy, it will highlight every weakness in your delivery process and force you to ask hard questions about how much the organization is committed to changing the way they deliver a product.  Having a Scrum Master or Product Owner certification does not help in these situations.  What does help is working with an experienced Agile coach who has been in the trenches, who is experienced in the demands that Agile and the transformation present.

As an organization looking to adopt Agile, getting certifications for your team is not a requirement to working the concepts that so many teams use to be successful in Agile.  Don’t let certifying your team be a precursor to moving toward Agile.  At one organization I worked at we took this approach and ultimately it wasn’t necessary as the majority of the people who were ‘certified’ were not involved in working in daily Scrum team activities.

An experienced coach will be able to guide you through how to work as a team, manage communication and change the way that you deliver software products and your organization.

And yes I have several certifications including CPO and CSM and know that these are now almost standard requirements for anyone wanting to work in an Agile environment However if you are just starting Agile don’t assume that someone who has been certified is necessarily an experienced practioner.  When looking for help in adopting Agile you should look for someone who has been involved in more than 5 different Agile implementations or organizations, perspective is worth it’s weight in gold.

Product Discovery – Uncover your backlog in Agile

Much of the writing and learning that you gain about Agile focuses on the day to day nuts and bolts part of execution, however I think that teams are missing a much greater opportunity to improve the quality of both execution and delivery if they spent more time developing their backlog.

My teams consistently hear me talk about getting contextually rich user stories  as part being able to delivery quickly and with high quality.

In order to get to the point that we have contextually rich user stories teams need to spend some dedicated time building out their product backlog.

Whether you are developing an entirely new product or simply adding features to your existing product, taking the time to fully investigate and build out your User Story backlog is important.

Much is said about doing just enough documentation to get the job done, but what I’ve seen over the years is that teams that fail to build out user stories that have a specific set of information in them will spend more time trying to figure out what they are doing IN the sprint which negatively impacts quality and the teams velocity.

There is nothing wrong with spending time before a set of sprints building a strong understanding of what the team is going to do.

You wouldn’t try to build a house without a certain level of planning ahead of time.  Agile teams often arrive at the start of their Sprints with nothing more than a set of ideas.  If builders showed up at a job site to start building your home with only a rough idea of what you wanted, they couldn’t go very quickly nor would they build something of quality that met your needs and expectations.  You might get what you want, but probably not.

Agile teams need to take this approach a bit more, spending time with their Product Managers to not just flush out the features that are wanted, but more importantly the lower level details needed to provide the team an ability to plan more effectively and deliver high quality products.

If a builder shows  up and wanted to pour a basement, they need to know more than that.  They need to know the size of the basement (ie how much concrete do I need) , if the site has been prepared, has drainage been considered, etc…. Building anything of quality requires planning before you can deliver.

Agile I think too often believes that you can go lite on the planning and still delivery quality.  If you think that refactoring is the golden ticket for lack of planning, it’s not.  Rarely do teams have time to do the amount of refactoring they require to keep their applications clean and scalable.  This leads to applications that grow in complexity requiring even more time to add features, all the while thinking that we can go lite on planning.

As you consider Agile as a development process, don’t forget that Product Discovery is an important element of delivering high quality product quickly.

Agile, Change and the things we can do

We home school our children and a few years ago my wife decided to utilize stories and a Kanban board to manage the kids work flow every day.

Doing this provided her the ability to build a backlog of work tasks that our children were going to work on (no we didn’t have them perform estimations or commitments 🙂 )  Each day she puts up the work that they need to complete in the Not Started column and then the kids can decide which ones that they want to work on and pull the ticket into the In Progress column.

Once they are done with a ticket my wife reviews the work and if accepted moves the ticket to Accepted.  This approach provided our kids with some level of control over their work flow and also an understanding that they weren’t done until Mom signed off on their work.  This way of managing their work provide them visibility to how much is left for the day and more importantly the topics that cause them more trouble.

Now that my daughter is working on her first business/website (she’s 13) we are using an Agile Discovery process where we are building a User Story backlog (she’s learning VOC) and developing low-fi wireframes (she’s learning design) for her website where she will be selling her customized jewelry made out of recycled products, photography of the animals she has seen across the country and raising awareness of animal conservation.  She’s now comfortable with an Agile process because we laid the groundwork during school.  I think in many ways teachers could utilize this process which would provide visibility to high performing individuals and those that are struggling.  Taking a page from Scrum perhaps the high performing individuals can provide support to the ones that may be struggling, just like we would expect our Scrum teams to do when someone is struggling with a particularly gnarly code problem.

Agile is most commonly associated with Software Development, but really the iterative continuous improvement concepts apply to anything you want to focus on.

Agile can be applied to changing your habits.  For example if you want to lose weight, write an Epic stating that value of losing weight, then write several thematic user stories with your intermediate goals and then write stories for your sprints with specific activities you need to accomplish (exercise, etc…) put it on the wall for your Kanban tracking.  If necessary have a standup with people who are supporting you so you can report on your progress, impediments (Ben and Jerry’s is right next to my office…)

An underlying principle of Agile is the need to change behavior, not just of the teams building your product but those that want them built.  You can’t have a smooth running organization if you don’t address the intrinsic  behavior of people in general.  Agile can provide the framework for helping make this change by providing a shared language.

When we work in an organization we may think we are all working towards an end goal (ie making great products, making money, etc…) but as soon as an organization begins to grow people who don’t know each other and who may have no shared experiences need to start communicating.

I recently completed McCarthy’s Core Protocol training  and one of the things I came away from it was that getting people to have a shared framework of communication is the most important thing that high performing teams and organizations should focus on, the rest will come as a result of this effort.  If you deliver this you deliver the ability for these teams to produce great product anywhere/anytime.

Think about it this way – We are all organic systems, who behave based upon the experiences that we take in over our life time.  Since no two humans are organically the same ( not even your own family) we end up with an ineffective communication driven by our life experiences and trained responses.

Core Protocols and in my mind Agile, provide a framework to establish a common language, just as we do with disparate technical systems (isn’t that what a service based architecture is all about?), we write code that provides a common communication protocol between them, removing the impediment their different languages pose to having them communication effectively.

As you begin to start to adopt Agile understand that though the practices you read about, such a Release Planning, etc… are extremely important, the need to provide your teams and organizations a shared communication framework are equally important to long-term success.

Sound Agile – Aligning Agile with Soundness

As I indicated in my last post I renamed my blog to Sound Agile and I’ll be writing about Agile from the perspective of Soundness and how organizations should be evaluating their Agile adoption.

I spent quite a bit of time trying to decide what I wanted to name my consulting business and blog (both are called Sound Agile) and I ultimately wanted to convey what I have seen as successful with respect to the teams and organizations I have worked with over the past 10 years.

Thanks to my wife for providing me a word that when I looked at it provided me with the right context to what I had been trying to convey.

Sound: 

adjective

1. free from injury, damage, defect, disease, etc.; in good condition; healthy; robust: a sound heart; a sound mind.

Supporting Manifesto – Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

a. Free from Defect – Speaks to Quality that we strive for in Agile.
b. Healthy – Speaks to your employees health and well-being
c. Robust – Speaks to building scalable products.
d. Sound Mind – Speaks to teams keeping a clear and open mind to improve

2. financially strong, secure, or reliable: a sound business; sound investments.

Supporting Manifesto – Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

a. Sound business/investment – Speaks to the value proposition that Agile focuses on.
b. Financially strong, secure and reliable – Speaks to the ability of Agile teams to delivery products that are foundational to your organizations long term health and security.

3. Competent, sensible, or valid: sound judgment – This speaks to trusting that the people that you are hire are compentent and when following Agile ceremonies such as Standups, Retrospectives and Planning are able to deliver product that is built on solid decisions.

4. Having no defect as to truth, justice, wisdom, or reason: sound advice. – This speaks to the continuous improvement and Retrospectives that drive this effort.

5. Of substantial or enduring character: sound moral values – Speaks to team commitments, believing and supporting themselves, the foundation of Scrum.

We spend so much time writing and talking about things that we should, could, might do to deliver Agile,  We hear people talk about how ‘Agile’ are you, tell people that doesn’t ‘Sound Agile’ and I think we have muddied the waters of what Agile should be.

When you hear Sound Agile you may be inclined to add an additional adjective ‘Sounds Like Agile’ and to some degree that is expected.  My focus however will be on the soundness of Agile from the perspective of organizational change an area that isn’t really talked about as much as the other elements of day to day Scrum.

I look forward to comments and input to my blog as my writings will form the basis for the types of coaching and consulting I hope to do in the future.

New Blog Name – Sound Agile

As you may have noticed I updated the name on my blog to better reflect where I am going with content and my overall beliefs about what sound Agile practices should be.

Sound Agile is derived from the attributes of sound:

sound

1. free from injury, damage, defect, disease, etc.; in good condition; healthy; robust: a sound heart; a sound mind.

2. financially strong, secure, or reliable: a sound business; sound investments.

3. competent, sensible, or valid: sound judgment.

4. having no defect as to truth, justice, wisdom, or reason: sound advice.

5. of substantial or enduring character: sound moral values.

I’ll be overlaying my writing on top of Sound to reflect the need I believe to focus on sound judgement over growing process.

You will see my website http://www.soundagile.com take shape in the next few weeks, please check it out.

Contextually Rich User Stories – The Importance of Details in Small Increments

Every software product that we build begins with a set of requirements.

Teams or organizations who have utilized traditional requirements documentation efforts such as Product or Business requirements documents (PRD’s or BRD’s) typically have issues with translating their requirements process into user stories.  Instead of writing long passages of descriptive requirements that are heavy on the use of ‘the user shall’ we move to a smaller specification document that convey details to a specific individual feature.

What teams fail to realize is that their old requirements documents weren’t all that good at conveying the necessary details that allow teams to delivery their product quickly and with quality.  You see evidence of this lack of clarity with the large number of change requests that are raised during waterfall projects.  In my pre-Agile years it was not uncommon for a typical 6 month project that I led to have over 100 change requests generated to convey the changing nature of the requirements (business, technical and UX).  The Agile manifesto addresses this reality by saying we accept change, why?  Because it’s there it will happen, to deny it would be to deny the reality of product development, as we learn more we need to change our approach.

User stories, though small in format, need to have a specific level of detail if a team is to have the ability to accurately estimate and delivery the feature.

The basic User Story:

• Story
• Conversation
• Acceptance Criteria

Can be deceptively simple to those who are just starting

In one organization I worked with as we moved into an Agile process the team looked at the User Story statement  as THE requirement.  It took awhile to get them to learn that successful teams use the User Story format as a specification and not a loose statement with no context associated with it.

An example of a solid User Story specification would look like this:

Another important thing to note with this format is that the team is also collaboratively building Story acceptance criteria by using Behavior Driven Development (BDD) which directly feeds the test automation frameworks that most Agile teams utilize (Cucumber, Fitnesse, to name a few).

There are other efforts/processes that feed into getting the right amount of detail into the story such as Discovery and Pre-Planning and if these are missed you will not obtain the benefits of this format.

Over the past 5 years, teams I have engaged with, who have used this specific format for developing their User Stories have had a much greater success with both delivering on time and more importantly with higher quality.

At my last organization I asked a Scrum team to utilize this process during the Pre-Planning phase of their project.  After the project I learned that the Product Owner had been very worried about the team using precious ‘development’ time to talk through the work and build out the context of the user stories. After the project was completed he could state without reservation that taking the time to build out contextually rich user stories with the team had produced two key results:

1. The team delivered on time and with more features than he had originally promised the client.
2. When he delivered the demo to the client he had high confidence in the product as it met all of the context that had been build out and there were only 2 minor UI issues that were identified during the 3 iteration project.

Take away – Don’t run before you are ready and get the context right before developing.

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.