The agile methods come at software development by challenging many of our status quo practices. The first one is the engagement level of the ‘customer’.

It’s my experience that most waterfall or traditional projects allow the customer to disengage after they start the project and provide an initial version of the requirements. After some time…later…they appear at the end of the project to receive their prize. Usually they’re disappointed in the end result—finding the functionality not living up to their original vision & expectations.

This sort of “end-points” behavior leads to many project failures due to a lack of clear communications, misunderstanding, and missed expectations.

But it has a simple solution. The customer should stay engaged during the entire project. They should be available for trade-off discussions and for demo’s. They should provide ongoing feedback on interim deliverables. They should even understand the teams’ capabilities and implementation challenges. In a word, they should become a “partner” to the team and not simply a “stakeholder”. They need to have continuous skin in the game if the project heads south and they need to be a part of trade-off and scope adjustment decisions.

The agile methods have several ceremonies or tactics that are intended to draw the customer into the team; to foster their inclusion and to gain their insights. In this post I want to review and emphasize the importance of these practices and the need for overall customer engagement.

Backlog Grooming

You all know that a prioritized backlog of work items (features, tasks, key functional and non-functional requirements) is what drives the agile ‘machine’. The list is dynamic in nature with items being added, removed and changed nearly continuously during the lifetime of an agile project.

Many represent the central nature of the backlog as a pyramid or iceberg. It follows then that at the ‘tip’, the highest priority items are found. They are also defined at the clearest and finest level of granularity. In other words, these items are ‘ready’ for execution. The team has sized them and broken them down. They have talked about them several times as they’ve done this.

This activity is typically called ‘grooming’ the backlog. It’s where the team repeatedly revisits the backlog, refining it from multiple perspectives and getting elements ready for execution. The Scrum Product Backlog is not only a list of features, but it’s effectively a work breakdown structure for all of the work necessary to complete a product or project release.

By involving your customers and stakeholders in backlog grooming and making it transparent, you’re engaging them at a base level of requirement management and planning. Both are areas where your transparency can and should pay-off in increased interaction and feedback on the backlog—pre execution.

It also results in a better understanding on the part of the stakeholders on the level of complexity and difficulty that the team is encountering. I probably hear pushback 3-5 times in every grooming session around how easy they thought a feature would be to complete. Why, we almost do it now, so it can’t take more than an hour or so to extend the feature…right?

Then the team, usually patiently, tries to explain why the design is more complex and how the estimate for the story is extended by the “real world” they deal with every day. Or why a single day implementation might need three days of testing because of data security concerns. So having the customer involved in grooming and planning (next) can really help them understand why things take as long as they do, while also drawing them into powerful trade-off discussions.

Sprint Planning

Rarely does an approach to software development include customers and stakeholders in planning the project. At least not in the nitty-gritty details of the effort. But in Scrums’ Sprint Planning ceremony the customer is welcome to attend as the team considers the work and plans their execution.

The meeting has a two-phased approach. Phase one is focused towards the Product Owner sharing the sprints’ focus with the team. They review the body of stories targeted for this sprint and answer any late-binding questions the team may have about them. Quite often, the questions vary from specific behaviors to how the team might design and implement the feature set for the sprint.

Once phase one is finished and the team fully understands the work, they then dive-in and begin to break down each of the stories into work tasks. Keep in mind that these are ALL tasks associated with the work—for example: development, testing, design, inspections & reviews, documentation, etc. Every bit of work required to deliver the story to completion is identified by the team and the effort associated (hours) are estimated.

So you might ask, how does this help the customer engage? It allows them a view into the planning & execution dynamics of the team in order to deliver on their requests. They gain a glimpse into the level of difficulty associated with each feature—where are the hard ones, fraught with risk. And conversely, where are the easier ones.

They gain insight into the strategy the team will be using to deliver the features. Who will be working on which features and why? How is the team planning on handling dependencies and overall feature testing? How are they planning on handling risks? And if the team is operating as part of a larger group, how are they interacting with other teams on dependencies, integration, and collaboration?

In a word, the plans are totally transparent and open for discussion and adjustment. The team simply wants to deliver on its commitments, so constructive ideas are welcome—especially the empathy that stakeholders should realize by becoming part of the teams’ planning.

You see—software is rarely as simple or easy as most bystanders believe.

Daily Stand-up

All of the agile methods have the notion of a daily team meeting for sharing progress, challenges and making real-time adjustments to the teams’ committed goals. In Scrum this is known as the Daily Scrum and it’s where a customer can gain real-time insight into the “inner workings” of their agile team(s).

I remember a team implementing some features in an eCommerce application. To her credit, their VP of European Operations would attend the meetings whenever possible as they were developing the interfaces to Amazon UK. She would listen intently to the discussions, but wouldn’t interrupt the team with questions as she was a compliant ‘chicken’ in the stand-up meeting.

However, after the more difficult conversations in some of their daily scrums, she would pull me aside and ask me questions regarding what she had ‘heard’ in the stand-up. Were they in trouble? How could she help? And, could they adjust some of their scope commitments in order to assist the team? Were very typical questions she asked. In some cases, her concerns were unfounded. In others, they were absolutely right on.

The stand-up was her window into the teams’ work dynamics that she had never had before. No longer was she relying on written or e-mail status reports that were interpretations of progress. No! Now she received unfiltered, raw data from the team themselves. She encountered the highs and lows. She clearly saw the teams’ challenges and, more importantly, how they approached resolving them.

She didn’t need a report to tell her where the risks were. Instead, she viscerally understood them by interacting with the team. She also saw the opportunities present themselves where she could assist the team in making adjustments while still achieving their & her overall goals.

It was incredibly powerful and frightening at the same time. It enticed, no encouraged, no demanded her to engage as an ‘owner’ with the team.

Sprint Review or Demo

One of the core agile manifesto points is “working software over jabbering about working software”, and I paraphrased a bit here. You see an incredible emphasis in agile teams, and I think it appropriate, to discuss most of your designs, requirements, and product commentary while looking at working software. There’s literally nothing else like it.

In Scrum, there is a Sprint Review or demo ceremony at the end of each sprint or iteration. In the demo, the team is responsible for showing off their working software that was focused towards their established sprint goal(s).

This ceremony is a “big deal” in Scrum teams. At iContact for example, we have sprint reviews for our teams every three weeks. We have them in our largest conference room. We literally invite the entire company (yes, we’re relatively small) to the event. Usually over half of our C-level team is in attendance and the room is typically standing room only.

Each team takes its turn to demonstrate their efforts for the past sprint. Team members all get a shot at speaking to their efforts. The audience is engaged. Asking questions and providing immediate feedback on the functions and features demonstrated.

Often the feedback extends beyond the demo. Folks will follow the team back to their seating areas and provide additional feedback and/or ask to see a particular feature again. I often see our CEO whispering his reactions to our product managers during and after the demo as he guides the vision he’s personally looking for in our product.

But beyond feedback for our teams, it shares information with our sales, customer support, and account managers. They become familiar with what’s being developed in real-time and can communicate those “coming attractions” directly to our customers.

Wrapping Up

One of the keys to engaging the customer is showing them you’re listening to their feedback. That it matters to you and you’ll take relatively immediate action on it. This loop of:

  • Listen To Feedback
  • Develop/Change Software
  • Demonstrate
  • Listen Again

is a wonderful device for agile teams to assure they’re on the right track.

It also draws in their customers. It engages them in the process because they feel more like a partner in the teams’ efforts. Now not all customers will embrace this behavior. Traditional customers will be taken aback and you’ll hear excuses—mostly that they don’t have the time for it. You’ll need to be patient and, over time, draw them into your efforts. Working software that demonstrates solutions to their most challenging problems can be…well intoxicating.

Agile Project Managers maintain their teams’ focus on the heartbeat of delivering value and work hard to PULL the customer into the fray. Why? Because it’s their software, they need to care, and you need their feedback. So just do it!

Thanks for listening,

Bob.