Customer profiles are important to a successful implementation of customer validation. A customer profile identifies common traits in your target customers, including demographics, buying patterns, and areas of interest. The goal is to identify and select customers who meet the profile you are looking for and who are willing to provide feedback.


Start by inviting customers to just one end-of-sprint review or demo session and getting their input. Customers who have not experienced something like this before typically are impressed to see working software so early in a release lifecycle. If they like the first validation session, then invite them to the next end-of-sprint review and excite them by highlighting where you’ve incorporated their input. At this point, ask the customers if they want to participate periodically at a per-sprint cadence.

While there is significant benefit to the end-of-sprint review or demo, the customer is, in most cases, only viewing the working software at that point. Let us review the potential types of customer validation sessions and their attributes in more detail.

• End-of-Sprint Review/Demo—This is a type of validation that demonstrates the working software completed during the sprint, shown to customers in order to both highlight progress and gain the all-important customer feedback.

• Hands-on Experience—This is a type of validation where customers will exercise the software in a hands-on manner in a simulated or pilot working environment.

To get to a fully robust Agile organization, it is important for everyone to play a role in Agile. I have found that managing a successful project from an Agile perspective requires three core roles and but must include the many adjunct roles to ensure success.


You start with the Agile Team. This is made up of around 7-12 cross-functional team members who can architect, design, develop, build, technically write, and test. This is commonly made up of developers (who can architect, design, and code, but preferably some who can do all three), QA/testers (who can build and execute tests), tech writers, and CM/build personnel. The key is to ensure you have all of the roles you need to build a product on your Agile Scrum team with sufficient skills to get the job done. If you need DB talent, UI talent, or other talent, ensure you include them on your team.

Equally important is the role of Product Owner (PO). This Agile role should be played by someone within each product team that is customer facing to ensure everyone understands customer needs. This is often played by the Product Manager, Business Analyst, or someone who provides the business perspective and engages with customers to ensure the Agile Team is building something that is of value to the customer. Identifying the right customers for validation is the job of the Product Owner. To scale this PO role, the lead PO may introduce Product Owner Proxies (POP) who may be architectures, lead developers, or functional managers (the latter role may now have much less to do). The POP takes direction from the lead PO via the Product Owner Scrum of Scrum sessions to ensure all POs and POPs are on the same page. Then it is important to bring the Customer into the picture to validate that what the team is building is something that the customer actually wants.

The facilitator or servant leader for the team is the ScrumMaster. The ScrumMaster executes the Agile processes and practices, and ensures the team stays true to the Agile values and principles as articulated in the Agile Manifesto. The ScrumMaster helps the Agile Team and Product Owner remove roadblocks. This role also facilitates the Sprint Planning session, the Daily Stand-ups, Retrospectives, and the Agile Release Planning session.

If a project is made up of more than one Agile Team (e.g., for a project team of twenty you would want to break them into two Agile teams of approximately ten), then there is a need for an Agile Project Manager (APM) to manage the dependencies and risks across teams, remove roadblocks, and ensure they work in a concert. The APM also handles the interaction with the business governance of the organization.

In addition, it is important to have an Agile Coach who possesses deep Agile deployment knowledge to ensure the product teams are implementing Agile effectively. It has been established that training will only provide initial knowledge but team members can easily resort back to old traditional habits. The Agile Coach also understands both the short-term and long-term pitfalls of adopting Agile, that Agile is a culture shift and will take time, and can help the team move to Agile is a more effective and efficient manner.

Now we come to management. Middle Management must play their role where they gently back away from command-and-control and act more as servant-leaders where they trust their teams, help them remove road-blocks, and support the Agile practices. They must realize that their direct reports are now on Agile Teams so they cannot be assigned any additional work. They may attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality) vs. getting a status report. Often times middle management have less to do in an Agile world and may consider changing their roles to either more of a Resource Management or Product Owner Proxy.

Executives/Senior Management needs to play a leadership role as Agile champion. They must support Agile and understand that its primary intent is to build customer value which can ultimately mean more revenue for the company. They must also understand that they must get the Agile teams to feel ownership of their work and this requires leadership and not command-and-control style managers. They may need to adjust their staff if it already laden with too much command-and-control. They may also attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality).


Then we bring in other peripheral roles like Sales and Marketing, Finance, and HR. While these roles do not need to work in an Agile manner per se, they use the same concepts of leadership, self-organizing teams, collaboration, streamlining and eliminating waste. Sales and Marketing are involved with bringing a product to market. They need to help the Product Owner with requirements input and clarification to ensure we are building something the customer needs. They need to understand that the Product Backlog and Release Goals are owned by the Product Owner, they must funnel requirements to the Product Owner, and avoid making commitments without the Product Owner in agreement. Finance needs to be flexible in understanding that they can still manage to cost because it is the scope that is the important variable. If performance objectives are part of the organizations processes, then it is important for HR to establish a performance process that allows for team goals. This is because as part of the Agile mindset, it is important to establish that it is the team’s responsibility to ensure the release is a success and not specific to individuals.

Ultimately everyone within the organization should be focused on understanding and delivering customer value every step of the way. Getting to that value oriented mindset is critical to the success of Agile. It takes teamwork to get there and that team is the entire organization.

----------------------------------------------------------------

You can see a presentation that covers many of these roles at: http://www.boston-spin.org/slides/boston_spin_slides_2010_09.pdf

Sometimes Agile gets branded as being the cowboy methodology. Some folks who say they are Agile, use it as an opportunity to abandon processes and documentation so that they can enjoy the wild west life. These cowboys know that they get away with pretending to be Agile since many folks, particularly their up-line management have no idea of what Agile really is. Some folks like to term whatever they are doing as Agile in order to be on the Agile bandwagon.

However, it is the cowboy and those that want to pretend they are doing Agile that propagated the myth that Agile is an undisciplined approach. Ultimately, these pretenders can give Agile a black eye in the organization and industry since others will believe that Agile means no process, implies an ad hoc approach, and is undisciplined.

For those that have followed the formal approaches of Scrum, Kanban, eXtreme Programming (XP), Test Driven Development (TTD), and more, realize fairly quickly that Agile instills much more rigor and discipline than most cowboys can tolerate and more many some folks realize. Some who follow Scrum for instance, learn quickly that there is much more discipline than they originally thought.

One of the early introductions to Agile practices is Sprint (or iteration) Planning. Imagine every two, three, or four weeks you revisit the backlog of work with pre-work of reprioritizing the backlog, then scrubbing each story, sizing the work, and committing to the work. This is meant to be a rigorous day of really understanding the work for the sprint where typically your brain will hurt upon conclusion of this day-long session!

Now let’s visit the Daily Stand-up sometimes known as the Daily Scrum. Imagine every day that someone asks you 'what you did yesterday' and 'what you are doing today', and “what are your impediments”. Imagine, every day this is occurring! This starts to get you into a laser focus of the work because you don't want to go for too many days saying you accomplished nothing.

Finally imagine that at the end of each sprint, you have to actually have working software per the end of sprint review (aka, demo). This means that within the end of a two, three, or four week sprint (aka, iteration), you need to build a function into a meaningful and viewable piece of functionality for validation by customers (and you cannot show customers junk, can you?). And to add to this, during the sprint each story (aka, requirement) you work on has to meet the rigorous “done criteria”. Done criteria can imply (for example) that each story that is worked on, must be checked out, incrementally designed, coded (following appropriate coding standards), possibly code-reviewed, built, unit tested, checked-in/promoted, merged, integration built, smoke tested, and system tested. Whew, is that enough discipline for you yet? All of this within a sprint so that you can have some tangible to show the customer so that they can validate if you are meeting customer needs.

Or course there are many more rigorous Agile practices. The discipline helps with the productivity and because we are empowered as a team, the discipline ensures we all remain focused on the work. So next time someone says Agile is undisciplined and ad hoc, it is clear that they certainly have never actually done Agile, but more importantly, explain to them the real rigors of Agile and if you have Agile practices occurring, invite them to sit in or participate.