a group discussion.
In just two hours, we reached agreement on a set of screens that we could hand over to the IT team to begin breaking down requirements and estimates. This seemingly simple process of storyboarding the user interface gave the IT team clarity that was needed to accurately estimate the size and effort of what they wanted. All-in-all, the storyboarding process was highly effective in reaching alignment with the business because it provided valuable insight for the overall vision.
While engaging the business in face-to-face meetings to flush out design is productive, it can also get tricky. Typically, everyone embraces the idea of just-in-time design or just- in-time requirements. However, as the project progresses, the business frequently becomes less available to participate in design sessions and the methodology begins to breakdown. The trick is to keep the business engaged during the storyboarding exercise and focus on capturing the intent of what they want built.
Don’t attempt to storyboard everything in one session. Rather, break the work into manageable pieces and you’ll position the team for more successful outcomes. Half-day sessions are much more effective than full day sessions because the group will either lose focus or begin to worry that they are away from their regular jobs for too long. If you can manage to keep the business engaged during the white boarding exercise you’ll find it easier to keep them engaged through the remainder of the project.
Business Integration Builds Trust
The most important agile concept to introduce to the non-agile team is tight integration with the business. This is achieved by leveraging the above techniques and close examination of your organization’s requirements definition and management practices.
One way to measure whether you’ve achieved the required level of integration is to evaluate the trust that exists between IT and the business. If the necessary level of trust is not there, take the necessary steps to improve the relationship. Characteristics of a highly trusted relationship include increased levels of business productivity and a feeling as though the project team has captured the intent of the business need. Once intent is captured, the relationship will begin growing in a positive direction.
Regardless of the techniques you use, the end goal should be to predictably deliver business results and avoid an IT driven solution. Too often, the business asks IT to solve a problem by a particular date. Then, they let IT design the solution only to comment later, “That’s not what I wanted!”
One word of caution - if you’re going to implement pieces of agile, make sure the executives and stakeholders understand that you’re not claiming to be an agile shop. Rather, you are picking and choosing the pieces of agile that fit best in the organization. If you’re going to swap out a component of waterfall with an agile practice, make sure that it supports the overall goals of the project and you fully understand the role of what you’re swapping out.
For example, if you decide to not implement paired programming you may need to increase the amount of testing hours. Or, if you decide to not implement code refactoring during a development cycle because the overall design is not extendable, you may need to add additional time to the end of the project or an additional phase of the project after the production release.
All in all, the play list of the best of agile includes short development sprints; paired programming; done / done/done; story boarding and integration with the business. Before beginning your next project, consider how agile techniques can help you achieve the ability to: