Roald Kruit on April 19, 2016
“Agile is a perfectly reasonable technique for exploring the uncharted space of the novel and new because you need to reduce the cost of change as change is the norm.” –Simon Wardley
Let’s say you have an idea for a digital product that would create a new revenue stream, or a way to better engage your customers that would differentiate your company. Because these ideas represent new and uncharted territory, turning them into value-driving applications requires frequent iteration and close collaboration between developers and the business.
That’s why Agile methodologies like Scrum are such a critical component of digital transformation. They facilitate the short feedback cycles required to rapidly develop, test and refine new ideas. And as Simon Wardley indicates, they provide a mechanism for coping with constant change.
As we’ve learned from helping organizations go Agile, though, there are a number of generally accepted Scrum principles that don’t work in practice with Mode 2 organizations. In this post, I will share some common pitfalls to avoid to ensure you properly apply Scrum within your Mendix team(s).
Traditionally, it was the Scrum Master’s role to shield the development team from outside distractions and interferences—often business stakeholders with input on the project. As feedback might conflict with other priorities, the Scrum Master would serve as the central point of contact to collect, process and prioritize input from the business.
In reality, digital innovation requires close collaboration between business and IT. By allowing developers to engage directly with business stakeholders, you can shorten feedback cycles and enable rapid iterations. At our customers, we typically see developers working on-site with business users, making changes on the fly based on their feedback. Of course, you will still need (bi-)weekly meetings to discuss conflicts and priorities that can’t be addressed in a 1:1 setting.
Most traditional Scrum teams are composed of developers with specific technical responsibilities, such as database, integration, security, UI, etc. In Mode 2 organizations using a platform like Mendix, this team structure typically leads to two fundamental issues:
Instead, we recommend building smaller teams of 2-3 Business Engineers who can do 80-90% of the work themselves (thanks to Mendix). Then, when necessary, you can bring fly-in experts for specific technical issues like integration or performance tuning.
In addition, project work should be divided based on user stories, a Scrum term referring to a specific piece of functionality written in in the everyday language of the end user. This limits dependencies and the need for knowledge transfer. And by empowering developers to build a full working piece of functionality each sprint, they’re able to focus on delivering business value versus completing tasks.
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, when in reality they’re on completely different pages.
That’s why it’s crucial to show a good working demo during each sprint review meeting. The demo should help validate existing business requirements and uncover new needs. This process is especially critical in the early stages of a digital innovation project. The longer you wait to validate requirements, the more time and effort you’ll need to course correct.
For the demo, it’s better to have fewer features properly demoed than the other way around. See my earlier post for additional demo tips and tricks.
In order to keep timelines as tight as possible, Scrum teams often focus their sprint planning and milestones around new features, leaving very little room to process user feedback. This defeats the entire purpose creating tight feedback loops to facilitate rapid iteration.
We recommend allocating 20-30% of a sprint to processing feedback on existing functionality. Another 10-20% should be spent refactoring the application to improve long-term maintainability. Of course, the percentages will be lower earlier in the project, where the focus is on new functionality, but they should serve as a general rule of thumb.
To help monitor and adhere to these guidelines, consider labeling your user stories with the following four buckets:
Scrum typically calls for two- to four-week sprints. However, because Mendix offers significant productivity advantages over traditional approaches, we recommend cutting that in half. Otherwise, assumptions made by developers early on can really propagate four weeks later when you finally demo the application.
At the beginning of the project, hold weekly sprints to facilitate rapid discovery and refinement of the business requirements. Then as the application starts to take shape, you can move to two-week sprints.
An agile methodology like Scrum is critical to digital transformation. Because requirements for innovative applications are typically unknown or unclear at the start, developers need to work in short, iterative cycles, building functionality, releasing it and iterating continually based on user feedback.
Avoid the pitfalls above when implementing Scrum to ensure you’re reaping the full productivity and agility advantages of a rapid application development platform like Mendix.
For more insight on how to best apply agile within your Mode 2 organization, register for your free Mendix World 2016 pass!
Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.