Mendix on August 18, 2014
Today’s guest post comes from Savan Vyas, Scrum Master and Mendix Business Engineer at LV= Insurance. This is the second post within a two-part series, throughout which Savan shares his advice on how to turn a successful pilot into a full-blown app delivery project.
In my last post, I set the stage for a pilot project we embarked upon at LV= to build a workflow management app for a broker department. I outlined some pre-requisites for ensuring that you deliver a production-ready app in one sprint. In this second part, I will focus on the important elements to keep in mind during the sprint to once again ensure a successful outcome, not to mention a more scalable approach to enterprise app delivery.
Once the project started at LV=, we initiated an agile approach, from collecting user stories in the sprint planning meeting and having the business log them in Mendix to doing testing everyday on what we built.
This helped us visualize exactly how many stories were done and what percentage of work was done, helping us to stay on track to complete the project in such a short timeframe. We strictly followed the time-boxing approach and did the entire daily scrum, sprint review and sprint retrospective meetings. The following are some of the things we made sure we took care of during the sprint.
Keep it independent: One of the things you want to do is make the pilot as independent as possible. With Mendix, you can do things quickly and easily but you have no control over third-party time and resources. Therefore, it is highly recommended that you keep third-party integrations to a minimum (or none at all, if possible). If you choose to do a third-party integration, I would recommend having all the necessary things in place before the sprint.
As Mendix is a rapid app development tool, it is common to need information and decisions from the business when development is mid-flight. More often than not, the business does not expect the request and cannot respond quickly enough, so we have to start building on certain assumptions. This is clearly not advisable so it is important when starting a project that you try to have all the required information even though you might not need it until the second or third week and that you ‘line up’ business stakeholders to provide rapid answers. This will help you stay on course and even finish things earlier. Hence, daily scrums are crucial; even though you might not think they’re necessary with a small team, they keep everyone on track. Also this is one of the main reasons to work on site with the business.
Although this might not be absolutely essential for long-term projects, I would highly recommend working on site with the business, especially for a pilot. We went to our Croydon offices to work on this pilot, and while the aim initially wasn’t to launch something by the end of the sprint, it quickly became achievable through the process of working with them on a daily basis.
Going into the project, we were a bit sceptical about the business doing all the testing and were worried that the application might have a lot of bugs. The key here is collaboration with the end users and having a two-way motivation stream. Because Mendix allowed us to fix bugs and deploy an updated application within hours, they got excited and tested it on the same day. We were getting rid of user stories and feedback at a rapid rate. When we had questions, we would just talk to them and get answers immediately but it’s also important to get it documented thereafter as proof. A production ready system simply wouldn’t have been released if we weren’t on site with the business to get questions answered on the spot and the team adaptation of agile wouldn’t have happened which was key to delivering the pilot. Working on site allowed us to interact with end-users which benefitted both of us in reducing impediments and increasing added benefits through a user friendly system.
The traditional project team would have consisted of a Technical PM, Business PM, Technical/solution Architect, Developers and business users compared to our Mendix team which was two Business Engineers who work directly with the business. Small, efficient teams help improve communication, reduce cost, and increase productivity. As Mendix business engineers, we are in a great position to have a deep understanding of the business as well as the technical capabilities of the platform to deliver most of the user stories without external dependencies. It’s also important that individual team members take ownership of the user stories throughout the sprint to reduce confusion and increase quality.
This is one of the most crucial pieces of the puzzle as this is what is going to allow the business to extend the application on their own and turn it into a project from a pilot.
The development of the application was done in such a way that pretty much everything can be managed by the business. This was something that we learned from our previous projects: the business doesn’t want to depend on IT all the time! So a lot of factors, like adding users, user roles, departments, agencies, activities, SLA times, products, adding non-working days and many more, are all managed by end-users. We created several user roles with different hierarchies giving them access to different parts of the system. We also created a well-documented user guide for managers and users to help them use the system once we were finished.
Once the pilot was delivered, we communicated back with the project sponsor along with the product owner and the team about next steps for the business to roll out the app to different departments. This was crucial as it gave the pilot wider acceptance around departments. Further, the roll-out was done completely by the business without any IT involvement.This comes from our core development principles at LV=: “If you are doing the same exact thing twice, there’s probably a better way of doing it.” This is the driving force behind our decisions to automate certain functionality, make apps more scalable and allow the business to be independent as possible. This also means that we develop things with a modular approach so we can use these components independently (by putting them in our private company app store) for other projects to reduce re-work.
A lot of the individual points I made might seem obvious but it’s the combination of everything coming together in a pragmatic way that has made LV=’s app delivery approach a huge success. Overall, you want to start your sprint planning session with the core baseline that you will release a shippable product by the end of the sprint and work your way backwards to get the operational readiness you need. Most of all, it’s important that you deliver something of business value even though it might be small but in line with the project’s business objectives.
Since delivering the one-week project, more than 10,000 work logs have been added into the system with further roll out in other departments. The pilot was subsequently turned into a project and we will be working through future sprints to extend it further. The business found the Mendix platform much faster and more flexible than anything they have ever seen, and they are also training a member of their reporting team on Mendix to explore the option of departmental development further along in the process. We have delivered a couple of pilots since than which are on the verge of becoming projects. So success is breeding more success.
I would especially like to thank Rod Willmott, my manager, who always encourages me to work on new and innovative projects, as well as Simon Black and the rest of the Mendix UK team who provide us with the constant support we enjoy during our more challenging pilots.
Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.