Therefore, it's important to ensure there's an opportunity each day for developers to interact with the business, discuss ideas, and validate assumptions. This may be perceived as a strain on the business but in practice it's not. When the developer works on site, this can be done quickly during lunch or a break. In other words, it can be fit into the schedule of the business user, creating little to no burden or disruption. And that quick check will save rework down the road.
We've found that when their input is put immediately into the product, business users become more much motivated and enthusiastic. They realize it's worth the time and effort and they start to make a mental business case for themselves to spend time with the developers. Very often, the change in demeanor is apparent from one meeting to the next. By the second or third meeting, they've gone from reluctant participants to willing and enthused advocates.
5. Model complex business rules and forms together with the business. There may be times when daily "walk-in" hours are not sufficient, and closer collaboration and knowledge sharing between developers and business users is needed. In these instances, there is technology that is ideally suited to facilitate cross-functional pair programming where business users — instead of the traditional process of writing requirements documents — are paired with business engineers to co-develop complex business rules and forms.
If you think about it, it's nearly impossible to envision every possible situation or scenario up front. Therefore, once an application or piece of functionality is developed using traditional methods, you have to validate whether the developer understood the requirements correctly, which results in a large and lengthy testing procedure.
This can be avoided by the business engineer and business user modeling the application together. While one-off sessions are a great starting point, many customers take it to the next level by physically locating the development team in the business for the duration of the project, facilitating continuous conversation and collaboration. The business engineer can stop and ask questions about different scenarios, helping to identify and resolve any misunderstandings or issues on the spot versus waiting weeks or months until the application is already built. This way of working enables your team to build the right product faster.
A great example is a pharmaceutical company that developed a site monitoring application as part of its clinical trial process. Because the company's process was so unique, extensive interaction with the business was required. Therefore, the development team sat with the business and directly collaborated with the business owner to build the application, with no detailed specifications up front. The application was delivered in a fraction of the time and cost compared to the alternative: an off-the-shelf clinical trial management system (CTMS) that would have given them exactly what the competition had.
Sign up for CIO Asia eNewsletters.