We often see new partners or customers try to divide tasks this old way because it's how they've always worked — and as we all know, old habits die hard. One of our outsourcing partners took this approach early on and the initial progress was less than anticipated. The knowledge transfer and documentation required between different tasks created a lot of overhead and noise, which resulted in low productivity and lack of business agility. Once each business engineer took full ownership of a user story within a certain domain, we saw a dramatic increase in productivity and quality. In addition, the knowledge and understanding of functional aspects of the application increased significantly, resulting in better collaboration and working software.
3. Provide working demos or prototypes every sprint. Systems design can be a very abstract exercise. Two people can literally sit in the same room for hours and think they're talking about the same thing, but in reality be on completely different pages. That's why it's crucial to show working functionality (whether a demo or prototype) during each sprint. The demo/prototype should be used to validate requirements and assumptions (knowingly or unknowingly made) to discuss possible changes because needs or other factors have changed. Changes can even be implemented during or at the end of the meeting to show the business stakeholder what impact it will have.
This process of validating major assumptions by showing working functionality is especially crucial in the early stage of the project. The longer you wait to validate business requirements, the greater the potential disconnect and the more time and effort you'll need to course correct.
At a large project for a church with 2,000,000 members, the functional requirements for a new application were specified by the church's volunteers. As soon as business engineers implemented the flow for moving a person to another address, the volunteers asked, "How do we move the whole family at once?" This important feedback highlighted the fact that the concept of families was not addressed properly in the functional requirements. By providing the prototype, the missing requirements were identified within two weeks and the client was able to take the necessary measures to embed into the system.
4. Implement daily "walk-in" hours to validate assumptions and synchronize with the business. There is technology that enables you to rapidly develop new applications and functionality. No matter how precise the upfront requirements are, there will inevitably be points where requirements conflict or business engineers don't understand something, have questions, or envision a different way of doing something. If that's the case, they may start to make assumptions that end up needing to be reworked or thrown away altogether.
Sign up for CIO Asia eNewsletters.