How to Prepare the Business for Rapid, Iterative Mode 2 Development
Roald Kruit / March 30, 2016
Digital innovation happens at the intersection of a business person with an idea and someone with the technical aptitude to bring it to life. To ensure these ideas take flight and the resulting applications are delivered first time right, with better user acceptance, IT must actively collaborate with the business throughout the entire application delivery lifecycle.
Yet, according to Gartner’s 2016 CIO Agenda Report, culture/organizational structure and lack of IT-business alignment rank among the top five barriers to CIO success. These challenges stem, in large part, from traditional development projects, where long upfront requirements gathering and minimal business involvement during development were the norm.
A Mode 2 development team implementing an agile methodology and rapid application development platform must turn that process on its head. This blog will provide best practices for changing the culture of IT and effectively engaging the business in rapid, iterative and feedback-driven development cycles. Focusing on four key project meetings, I will share why and how to address the following elements:
- Defining and maintaining a constant focus on the business goal
- Defining clear rules of engagement for how you’ll work together
- Actively showing that you’re listening to the business
- Working together to continuously improve IT-business collaboration
1. Intake Workshop
The purpose of the intake workshop is to define the project business goal—not what you want to build but what you want to achieve. The meeting should include the Mode 2 sponsor, who can articulate the strategic value of the new approach; the business owner, who can describe the problem the application should address; and one or more power users.
While the business owner plays a crucial role, it’s important not to overlook the value of including power users. They have firsthand knowledge of the organization’s challenges and needs. Actively solicit their feedback, with the goal of identifying quick wins for making their lives easier as well as a “wow” feature for the application—something unexpected and high impact that you can celebrate later.
This type of interaction will help create a different attitude towards IT and set the stage with the rest of the organization. While this workshop alone won’t reverse years of distrust, getting the business to think “this just might work” is a victory that you can build upon.
2. Kickoff Workshop
The kickoff workshop should cover several topics, including project roles and responsibilities, a high-level delivery plan, agile awareness and a lean-and-mean Mode 2 governance approach. In terms of business engagement, start by sharing the strategic business goals and application goals, as defined in the intake workshop. Then show how you’re going to make the project a success by defining clear rules of engagement, with particular emphasis that you ARE NOT going to do the following:
- Follow a traditional development process – Be clear that there won’t be a long upfront requirements gathering process. Discuss how the agile methodology has a different way of managing requirements through user stories. User stories are simple, short and focus on expressing business value. This means that the better users can articulate the business value of their needs, the higher priority these features will get.
- Wait weeks to verify business requirements – Because you can build so fast with a platform like Mendix, you’ll need to validate requirements much more frequently. At the same time, it’s important to recognize that the business is busy and not accustomed to providing regular feedback. Instead of scheduling a lot of meetings, find other ways to interact, such as:
- Sitting together in the same room
- Discussing requirements over coffee breaks
- (Bi-)weekly meetings to discuss the overall project, including conflicts and priorities that can’t be addressed in a 1:1 setting.
- Have IT verify the application solves the business problem – The business knows their problem the best, so it only makes sense they verify that the functionality meets their needs. In practice, this implies that they do high-level functional testing early on in the project, typically before each sprint review meeting. Fortunately, the feedback mechanism in Mendix facilitates this process by automatically collecting metadata, such as the user, browser, page/form, etc., saving users time.
Once you’ve defined the new rules of engagement, work out the first 10-20 user stories as a team. Go through the exercise of having one person write a user story and someone else interpret it. This helps to create a shared vocabulary and understanding, including a definition of “ready” that indicates when the team collectively feels a user story is ready for development. As a last step, prioritize the user stories for the first development sprint.
3. (1st) Sprint Review Meeting
In each sprint review meeting, but particularly the first, it’s absolutely critical to show a good working demo. It’s better to have fewer features properly demoed than the other way around. If there is nothing to show, that’s a red flag, as the team may be too focused on a generic technical level instead of building functionality that supports the business goal.
Here are a few tips and tricks for the demo (for more, check out the book Great Demo!):
- Show how you solve business problems. Don’t just demonstrate features; tie the demo back to the business objectives and challenges shared at the onset of the project.
- Make sure the UI looks good. Users will judge the book by its cover, even early in the development process. Make sure they don’t tune out because you’ve underinvested in UI.
- Use good demo data. The data needs to be representative so that the demo feels real to business users. They’ll start to get excited for the impact of the new solution.
In your sprints, you should allocate enough time (~30%) to making user-driven enhancements, versus strictly delivering new features. The business is used to not being listened to in development projects. You want to set the tone that they’re being heard and that you’re able to incorporate their feedback remarkably quick. For the first time, they’ll feel they can truly make an impact on the project.
Lastly, the retrospective should look back on the project, including successes and lessons learned. Did the project achieve its business goal? Did you have the right people on the team? How well was the business engaged in the process?
It’s important to embrace all feedback, whether it’s perception or reality. Again, let the business know they have a voice and that their input is vital to improving future projects. Seek their advice on how to you develop a more structured Mode 2 development approach that further enhances engagement and collaboration with other business units.
One of the most important questions you can ask business stakeholders in the retrospective is “how would you tell your friends/colleagues about this project to make them enthusiastic?” This elevator pitch is great fodder for internal feedback and celebrating success, with the goal of implementing this approach more broadly across the organization.
Digital Innovation is a team sport
Remember: digital innovation happens at the intersection of a business person with an idea and someone with the technical aptitude to bring it to life. Therefore, it’s absolutely crucial to actively involve the business throughout the project lifecycle.
To effectively engage the business, though, you may have to reverse years of perception. The key is constant communication and proof. Once business users see that you’ve done what you said would do—and that they can have a significant impact on the project—they’ll quickly embrace this new approach.