A key business analyst skill is describing the future state of a project. After the dust settles, what does the customer get? What will the website do? Articulating answers to these open ended questions is a key ingredient to the project planning process.

Producing a future state document requires creativity and strong relationships with stakeholders. In this article, I will cover both of those areas. By implementing these ideas, you will be able to make a greater contribution to your projects.

In this global economy, facilitated by the Internet, Business Analysts are asked more and more to work with stakeholders who are located all over the world. Several issues can be challenging, such as setting up meetings that are convenient for all attendees, working on deadline when stakeholders are several time zones away, and understanding people whose native language is different than yours.

Time/Attendance Barriers

Depending upon the team's locations, workday hours can be problematic. While sometimes you will be able to wait a day to get a response to an e-mail or a document review request, occasionally you will have to work after-hours to accommodate a time zone difference.

Tight deadlines call for more creative measures. On a recent project, I worked with technical and QA teams in Manila, which is 14 hours ahead of New Jersey. Working with the QA team was particularly challenging when I was asked to be the test lead for User Acceptance Tests (UATs), and the turnaround for defects was three hours.
Since I was on-call 24x7 for the tests, I worked from home so I could sleep between defect calls. This enabled me to facilitate solutions within the short turnaround. If I hadn't done that, there would have been a one-day delay between issues and solutions, and even easily fixed items would have been dragged out. Working this way enabled us to get the work done on time, and the project met the go-live deadline.

Monday, 29 September 2014 00:00

3 Amigos in Agile Teams

Written by

I think it was George Dinwiddie that first coined the term “3 Amigos” in agile development around 2009. The analogy was akin to the movie from the mid 90’s by the same name. The Amigos in the agile sense are functional roles:

  1. Developer(s);
  2. Tester(s);
  3. and the Business Analyst or the Product Owner.

It could literally mean more than three as well. The point was, balanced collaboration in agile teams across these roles. George was alluding to these roles from an Acceptance Test Driven Development (ATDD) perspective. He wanted these three constituencies to be heavily collaborative (conversations) around the Acceptance Tests or Acceptance Criteria for each user story.

In my classes, I literally explain this as an “extension” of agile team pairing—in that I’d prefer the pairs to be converted to “Triads” around each story. Believe it or not, Ken Pugh leveraged the term Triad in his book on the same “ATDD-ish” driven topic (see the references).

3 Amigos Meeting

Recently I’ve heard of teams scheduling 3 Amigo style meetings as a part of grooming their backlogs. The idea is to create a checkbox for each user story where it has to be “3 amigo-ized” before it’s deemed ready for sprint execution.

I explored this notion of readiness in a previous blog post.

While I like this idea, and I certainly think making it a part of “Ready” is quite creative, I’m slightly troubled by the practice. I personally think the 3 Amigo’s analogy is less of a meeting and more of a collaborative mind-set.

So when do the “Amigos” meet?

Certainly they meet as part of Product Backlog development and grooming. I think that’s a given. But, I’d like to say continuously as well, for example:

  • Collaborating in the Sprint Planning meeting around how the stories fit into the Sprint and what the Sprint Review will look like from a cohesion perspective.
  • Chatting when each story is “first picked up” within the Sprint to ensure the team understands the nuance of the story and how to effectively design and test it.
  • During story development, the Amigos periodically check in together to ensure the story is on-track. Usually demo’s of partially completed code drive the discussions;
  • Once the story is complete, the Amigo’s gather around it and execute it. Going over acceptance criteria and other attributes, until the Product Owner is satisfied and “signs off on” the story;
  • But their role isn’t quite over. The Amigo’s play a strong part in demonstrating the story in the Review, gathering feedback, and digesting whether the story is truly complete. If so…they move onto the next, and the next, and…

What it’s not…

At the risk of “picking on” Jon Kruger (see references), I want to use part of his description to make a point:

Outcomes

The primary outcome of the three amigos are acceptance tests written in Given/When/Then format. Actually writing these out can take a little time, so we don’t do that with everyone sitting in a room. Typically a developer or a tester will work on it outside of the meeting, and once they have the scenarios all written out, then we do a quick review with everyone else that was involved in the original three amigos meeting to make sure that we all agree with what was produced.

I beg to differ with Jon. His description is much more focused on the 3 Amigo’s as:

  • Implying a meeting with specific, process-driven activity;
  • Implying exhaustive scenarios, written in advance;
  • Implying a prescriptive format of Given-When-Then;
  • Implying sign-off on acceptance tests, prior to the story entering the sprint.

What he, and many others seem to miss is the mind-set part of the Amigo’s that is continuously happening around the team. Please don’t loose that focus in your thinking.

Wrapping up

George, Ken and many others have struck on the collaborative power of these three roles within agile teams and their work. Don’t get caught up on it implying a meeting or any other ceremony, although those things may be outcomes of it.

Instead, consider it a role-based reminder of who needs to collaborate around the work that agile teams are producing continuously. Also think of it as a pairing surrounding sprint activity (the work) rather than a meeting-based activity (talking about the work). I think that was always the primary intent.

But please, do talk about “Amigos collaboration” early and often within your teams. The real point is that you’ll build better, more valuable, and more relevant software as a result. Now isn’t that something worth hollering about?

Stay agile my friends,
Bob.

References