Why Working Software is a Key Agile Principle

Why is working software one of the primary principles of Agile?

Because when we deliver something that was asked for we may or may not have gotten it right.

I know from my experiences the vision that someone has in their mind about how something should work doesn’t always align with what the development team has delivered.

Working software provides value to the development process by providing feedback – you asked for this now I delivered it.  Now you provide feedback – I asked for this but it isn’t working exactly the way I wanted to.

Agile accepts changing requirements as part of continual interaction between the customer(end-user) and the development team.  This is what we mean by accepting change as part of Agile.

Instead, this mindset is often I think taken as, I provided a large business requirements document that you must work from and commit to upfront, but at any time late in the project, I can change my mind about what I want and no matter the impact it causes you told me Agile accepts change. 

If that is your idea of accepting changing requirements late in the game, then you are playing the wrong game.

If your organization isn’t changing their engagement model to support these continual interactions between your users (or their proxy PO and business leadership) and development team and instead saves any interaction until near the end of the project, then all you have successfully done is shorten the cycles by which you are working in Waterfall, delivering your large project in 2-week increments and waiting until the end to review what the team has delivered and at that point telling us we didn’t get it right.

There is a reason that most of the Agile frameworks provide varying levels of engagement, from the team up to leadership.  The Agile Manifesto Principles expressly identify the value that can be delivered by having a high level of engagement – ‘Business people and developers must work together daily throughout the project.’

So if you are already working in Agile or considering adopting Agile as your delivery model then you must change the way you engage with the process if you want to have real success in your Agile adoption.

I still see too many organizations that have very little engagement with reviewing the work that their teams are delivering which means that we end up having a disconnect between the requesting and delivery process, which will cause lower productivity and quality while delivering lower levels of value.

You Know You Aren't Agile If

Thought I'd start off the new year and take a page from Jeff Foxworthy and use is famous tag line for Agile. Though intended to bring some humor to the question it really is something that every organization typically asks themselves. Please add more :)

You know your not Agile if:

• Your Product Owner drops by once in awhile to yell at the team for not giving them what they wanted
• Your Product Owner is entirely responsible for writing User Stories
• Your Development and QA teams are separate groups
• Your teams treat missed commitments like a Hollywood marriage
• Your team writes user stories in the current Sprint
• A daily Scrum looks like a bunch of stoners standing around
• Your product backlog changes more than Kim Kardashian changes her cloths.
• You think MVP was Kevin Durant last year
• You think BDD is something you do in the privacy of your own home

We spend a lot of time talking about what Agile looks like, should be etc... but at the end of the day Agile is about addressing the issues that keep you from being great and dealing with them in a manner which focuses on the what not the who.

There is no finger pointing in Agile (just like there is no crying in baseball).

Finding out what stops you from succeeding is a fundamental element of achieving greatness at anything.

You know your not Agile if you are asking yourself if you are or not.

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.