We’re Agile, You’re Agile, Why are We Struggling?

So, here’s the scenario: Your organization wants to purchase packaged software to support a key business function. Your team thoroughly evaluates several products and chooses the best fit. During discussions with the vendor, you discover they “use Agile.” This is great because your organization “is Agile” too! Awesome! Contracts get signed and we all get to work.

Then, things start to go awry as your assumptions jump out of the dark corners and startle your progress. Communication crumbles, messages are confused, processes and practices differ, team dynamics and what even is “a team” seems to be a huge struggle. You soon discover that the most basic agile terms being used do not mean the same thing! Your version of Agile does not align with your vendor’s version of Agile.

Ah….as a project team we have gotten trapped into defining agile vs. being agile in the face of chaos. When we try to work things out, all the definitions, contracts, processes, and promises lean us towards anti-agile patterns to clear up the confusion. Instead, we may need to focus more on being agile as a team.

I’ve seen many 3rd party relationships crash and burn during their first implementation effort simply because they did not discuss, up-front, what being an agile team means. You need to go beyond “We are Agile” and really did into the details. Here’s how to get started:

1. Describe the team structure. Many vendors are agile only within their team and practices once they get contracted work from the client until they hand it back. This can be a huge problem if the project team overall expects all teams (client and vendors) to work together as a single agile team. Many agile mindset patterns are broken once two teams “hand off” to each other.
   Questions you should ask the vendor: How do you integrate your team’s agile practices with the client teams? How do you envision the teams working together in an agile way? What challenges have you previously had working with other agile organizations and how did you resolve them?
2. Describe practices/methodologies. Again, agile is really a mindset, and approach. Under the Agile umbrella there are many methodologies and practices. You should compare your practices to your vendor’s. Discuss how you will fill any gaps.
   Questions you should ask the vendor: What does Agile mean in your organization? How do you elicit and mange requirements? What’s your approach for code development? How do you support testing? What does implementation look like?
3. Discuss deliverables/artifacts. The output from agile teams can vary dramatically: some teams might generate reams of paper or gigs of data for each iteration, other teams might generate a wall of sticky notes, and some teams produce zero artifacts…their only deliverable is the working product. If your organization has requirements for product documentation, you need to know if the vendor can meet these expectations. Make sure your governance needs are discussed.
   Questions you should ask the vendor: Does your company produce any project documentation beyond the working product? What documentation is created, when, by who, and for what purpose? How do you document issues, priorities, test cases, etc.? What documentation is expected from the client team to work best with vendor agile practices?
4. Discuss roles. Some Agile teams subscribe to a strict Scrum methodology, and some are Scrum-like, using aspects of Scrum, but not as a methodology. When working with an agile vendor, roles and responsibilities should be clear to ensure efficient communication and collaboration. Make no assumptions on what roles and titles do, and make sure the vendor is not making assumptions of your roles either.
   Questions you should ask the vendor: What support roles will you provide? What are their functions? How do they align to our team structure? What roles do you expect our team to have and how will they work together with your roles?
5. Define Terms. Terms often mean different things across organizations. In some places, a scrum might just be a daily project meeting. In other places, the word is used to define an entire philosophy or methodology. Ask your vendor to define the terms they use when discussing their agile approach. Other terms that I see often confused: Sprint, Story, User Story, Task, Acceptance Tests, Requirements, Defects, and Backlog.
   Questions you should ask the vendor: What does Scrum mean to you? How do you define a sprint? How do you define the start and end of an iteration? What is the definition of done? What is your definition of Epic (User Story, Feature, Task, etc. . . .)? How would you describe a retrospective?
6. Discuss theory versus practice. Even if you share similar definitions for each term, take your questions one step further to understand how your vendor applies these terms in day-to-day work.
   Questions you should ask the vendor: What does a daily scrum meeting look like? What does testing look like? How long are your average sprints? How do you prioritize the items for each iteration?
7. Dig into user stories. User stories also vary dramatically by organization. They usually encompass multiple pieces of a solution to get to the essence of value to a user. Therefore, your vendor user stories might only reflect a small part of one user story (the part they deliver) for your organization. This is a common issue and means value is not aligned between vendor and client, and this will cause a multitude of issues for the project and solution.
   Questions you should ask the vendor: What do your user stories look like? What level of detail do they go to? How do they integrate with other user stories in my organization? Could I see a sample user story? What techniques does the team use to elaborate on the detail of the user stories? Whose role is it to create the user stories?
8. Describe collaboration. Collaboration is a key component of the Agile Manifesto. Many teams who use an agile approach require the team to sit together in one room for the majority of their working hours. Other teams collaborate once per day during their daily Scrum and then go back to their cubes and work independently, all day (not recommended!).
   Questions you should ask the vendor: What does collaboration look like in your organization? How do teams share information with each other and with other teams? How does communication happen within a day and day by day? Are meetings planned or spontaneous? What do meetings typically look like? Could we watch one of your teams work for a few hours?
9. Discuss testing scope and terminology. User testing often means something different to your vendor. Their focus can be quite narrow as they are focused only on their small piece of your organization’s end to end solution.
   Questions you should ask the vendor: What does user acceptance test look like? Does the vendor support processes required to integrate their product to other systems?

Obviously, the depth you go to in investigating the agile practices of your vendor depends on the scale of the relationship you are forging. Small package software projects might require just a short discussion related to key support functions provided by the vendor. Large scale partnerships involving integrated teams, high risk, high costs, lots of custom code, or hundreds of user defined settings require deeper discussions about agile practices.

Either way, don’t make the mistake of focusing only on the product and its features. Spend some time understanding how your vendor approaches team work, collaboration, requirements, development, testing and implementation. Collaborate and talk through it together, before the contract is signed. Don’t assume your Agile and their Agile is the same.