Back in the days I use to work in a RUP (Rational Unified Process), we've been taught to do the thinking up front, because mistakes down the line become costlier. As many shops have been moving towards Agile methodologies, the up front thinking has been reduced to at best example scenarios, and worst just 1 liners describing what the product owner wanted.
Recently, I came about the Three Amigos Meeting method, it promises to be a simple way of getting BA, QA, and Devs on the same page.
There are some things I like about it,
- It is easy to implement, and a simple process. Just tack an one hour time-boxed meeting sometime before sprint planning for the 3 parties to sit together.
- It promotes better understanding between the 3 parties. Things like technical difficulties, edge cases, and business drivers are often lost in simple tickets that are being cranked out.
- It gives a good structure and approach to doing more up front homework before code is written. Generally when I see code is written that does not conform to the realities of the business needs, I will see things where they try to keep the existing code structure while bending over backwards to make things work. For example, a schema might be designed, then at the point of realizing the mistake is made, a developer may write additional adapters to massage the data into the desired form before reaching the database.
Here are a few things I don't like about it.
- Because this is working in the context of a single agile team, where a company may have many. A lot of useful information is lost to those outside the agile team, but in the greater product / service team.
- In an information age and modern framework, actual time spent writing code is very little compared to research and learning how to approach the problem. I think a simple 1 hour workshop every 2 weeks, is not enough when it is more important to put more upfront effort into design than it is to simply type code.
Given these shortfalls, I still think this is a good idea. Most shops have very little interactions between Devs, QA, and BA's. And especially when Devs see only a small part of the entire product, having these short workshops can payoff big by promoting the business level and quality level understanding.