Helping you drive digital innovation
Subscribe
RSS Feed of the Mendix Blog
Thanks for Subscribing

Keep an eye out for Mendix resources coming straight to your inbox.

How to Prepare the Business for Rapid, Iterative ‘Mode 2’ Development

on March 30, 2016

Share:

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 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.

4. Retrospective

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 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.

For more information on bimodal IT, download this Gartner report which dispels the myths surrounding this practice.

Subscribe to Our Blog

Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.

RSS Feed of the Mendix Blog
Roald Kruit

About Roald Kruit

While my co-founders and I were in business school, we saw firsthand how painful and frustrating it is to be involved in the application development process from the business side. So we set out to improve collaboration between IT and the business and to make development radically faster and simpler while ensuring project success.

  • Gunnar Eriksen

    Hi Roald, I am Gunnar Eriksen, I just started to look at the Mendix site and I am impressed. I will comment on your 4 key project meetings.
    1. Intake Workshop. I fully agree with the need for this. Before the workshop, certain business executives need to bless this, and show sincere interest. Mode 2 Sponsor is the most important, because he has accountability. I also feel that when specifying what needs to be achieved – instead of what’s will be build – the reason must be clear, it must serve a real business need, not a “nice to have”, and it must be presented with the metrics to measure achievement. Key IT participants must prove their business knowledge, it is unrealistic to expect business folks to have sufficient IT knowledge. The IT folks must speak business.
    2. Kickoff Workshop. While I agree with all you say here, I’d rather put focus on what will be done, instead of explaining what will not be done. Business people want results, and talking about what will not be done could start discussions with the IT folks as well, who might not buy in totally on the Agile method. Focus on WHAT WILL BE DONE, and why.
    3. Sprint Review Meeting (first), Totally agree.
    4. Retrospective. Once they have the result of the project, the importance for the business people – and the IT folks as well – is that going forward, the project contributes to added value that can be measured. The go-live sets the stage for some kind of business transformation that justifies the project. If this does not happen, it does not matter how the project execution was handled, that’s just academic.

    Thanks for a real good blog, and for the opportunity to comments – shows what quality form Mendix is.