My name is Russ Martin and I have been using Mendix for almost three years as a Senior Software Engineer at Erie Insurance. We have used the Mendix platform to complete several projects and have been highly successful. I’d like to share the trials and tribulations we encountered when trying to shift our focus from a waterfall to agile project methodology, along with some tips on how to overcome them.
Introducing Agile to a Waterfall Team
As you can imagine when first introducing the concept of agile, there will be initial hesitation and concern from your waterfall team. This is expected, as change is difficult for many people, especially when shifting to something so different. What we found to be the two biggest hurdles were introducing the concepts of iterative development, and ongoing requirements.
Within many waterfall organizations, the common trend is to design and lay out the entire project prior to beginning development. If you are familiar with waterfall, then you know that this entails months of requirements gathering and design sessions before a team can even begin working on code. This also creates a disconnect between the disciplines, as it does not involve the entire team for these sessions, and also requires knowledge transfer. This process creates some heavy overhead and becomes quite time consuming. An agile process is a complete 180 compared to waterfall. When trying to shift people’s’ mindset to go against all their previous training and experience, there is going to be apprehension. This is normal and expected.
An Agile Process is a Complete 180 Compared to Waterfall. Apprehension About this Change is Expected; Normal Even.
To overcome this, I have found that showing the benefits of the agile methodology helps people to see its value. Begin by working on a small proof of concept. Take a small portion of your application, or one that is expected to take considerable time to replace, and see what you can accomplish within a few short weeks. Involve at least one individual from your different disciplines – Business Analyst, Software Engineer, Quality Assurance, etc. The reason for this is that you will need people with different perspectives in your corner to influence this type of change. If you can get several people to understand the new methodology, it is much easier to get the rest of the organization on board. Also, leverage the expertise of the Mendix team. They are experienced in dealing with this type of culture shift. By having an outside person there to help answer questions, you’re providing an extra layer of understanding which helps drive adoption.
The key to this proof of concept: TEAMWORK! You will be facing an uphill battle for sure. You will need your team taking part in a sprint zero exercise. This is where they will put together a few stories to decide what they want to see from the user interface. By involving all members of the team, they will be more invested in the outcome. They will feel they have a voice in the process. I can’t emphasize how important this is in the long run. Shifting from a documentation-heavy process to a story card approach is a foreign concept to many who are waterfall methodology practitioners. Be prepared for push back from your team members, it’s normal. Just remember this proof of concept is more of an experiment, a training exercise. It is not a full-blown project that will go to production, which helps to ease the concerns of many skeptics. Just remember from a developer perspective: if this is the project you plan to use in the long run then this is your chance to help lay the foundation for the full project, and save yourself time in the future.
Most People Over-Design Before they Have Even Started. Build a Ford Before Upgrading to a Mercedes Benz.
One concept that we used to help emphasize what we were trying to do was this: “We don’t need a Mercedes Benz to get from point A to point B. We just need to get there. So let’s develop the Ford. Then once we are on the road we can focus on the upgrades we would like in our vehicle.” This was a useful concept, because most people want the completed product. They want to over-design before they have even started. Starting on a smaller scale allows your developers to develop the “Pinto”, a minimum viable product that gets the job done. Then show how quickly you can upgrade your vehicle to the “Cadillac”, a full-fledged product with increased features and functionality. It lets your users get in the Pinto and provide feedback, after which you can show them how easy it is to develop those new features.
Shifting to the Project Work
Assuming all went well with the proof of concept and you now have the green light for the full project, you can look at some items you can incorporate into your project to help smooth the transition.
From a Business Analyst and Quality Assurance perspective, there are several things you can leverage to further enable the process of understanding. We found “amigos sessions” to be extremely helpful in the beginning. An amigos session is where the developers, analysts, and testers have an impromptu meeting to review the cards assigned for a specific sprint. This allows all participants to get on the same page as to what is being developed for each card, and provides a chance to ask specific questions around the work. These meetings should be informal, and take place in an ad hoc format prior to development. Then once development is completed, have another amigos session to review the finished coding. This allows everyone to review the work as it is being completed. At the same time, this allows developers a chance to show how quickly they can adjust to items that need to be changed. For example, an analyst points out a missed requirement in a final amigos review. This will allow the developer to make the change on the spot and show the corrected code on the screen, proving to team members the adaptability of the code base and the quick response time to change requests. This goes a long way to help others understand what you can do with the platform. The intention is not to have these continue forever. Initially, the amigos reviews should take place until everyone feels comfortable with the new process. At that point you should only need to leverage this technique at the end of story card development.
From a Quality Assurance Perspective, the Main Benefit of Agile is Test-Driven Development.
From a Quality Assurance perspective, the main benefit of agile is test-driven development (TDD). TDD is a well-known process used within the IT community. By using the Unit Testing module available in the Mendix App Store, developers can create several unit tests tied around each development sprint. The unit test module also lets you run reports with each deploy, showing whether unit tests are passing or failing (and help you as a developer ensure you didn’t create a new defect). This allows the QA team to see that the code is stable, and that previously tested code is still working. Of course they will want to do their own testing, as they should. But this method will provide some understanding that the code base is not being degraded with each completed sprint. This is important because they will be testing on an iterative schedule as compared to once at the end of a project. Anything you can do to let them know their efforts of testing were not wasted is a huge win for the long term.
From a developer’s perspective, we found code reviews crucial to any project’s success. The reasoning for this is simple: the more eyes reviewing the code, the less chance of mistakes. This also helps with implementing coding standards and processes for developers, which all members of the team can leverage. Being able to see what others have done to make coding more efficient can increase your time to market. It will also go a long way with people who are slow to adapt to agile. Why? Because they know that you are doing everything you can to ensure your team is creating solid code and will help decrease the amount of defects found in the system. The fewer defects you develop, the better your team will feel about this new agile approach.
What About Management?
Management doesn’t concern itself with the nuts and bolts of the team’s development, nor should they. They are more concerned with resources, speed, and quality. Well, how can we provide them something concrete to show we are developing a great system that is easily maintained? I highly recommend using the Mendix Quality and Security Management tool.
We were able to provide metrics of the system prior to making changes within the code base. By doing this we could easily show that an idea we wanted to implement provided value by raising our AQM score.
AQM leverages the use of the McCabe complexity by scanning committed code within your repository to determine a rating on a scale from 1 to 5. For those unfamiliar with the McCabe complexity measure, it is a software metric used to indicate the complexity of a program. The AQM tool breaks down your code base into eight different categories. These categories are very helpful from a development perspective as well. They allow you to see that your team is making items that are not overly complex and that are easily maintained. This is also helpful when onboarding new developers. It allows the team to see what level of understanding the developer has, and allows you to easily point out where they may have been coding incorrectly. This provides an opportunity to teach them the proper way to structure microflows based on your organization’s standards.
So what about management? We all know that management prefers short, concise, and to-the-point reports that provide easy to read graphs for use in meetings. The AQM tool offers several reporting options that provide insight into the code being developed. This has proven highly useful in our organization. We were able to provide metrics of the system prior to making changes within the code base. By doing this we could easily show that an idea we wanted to implement provided value by raising our AQM score. This approach also allowed us to remove some of our biggest violating microflows by showing a before and after metric to management.
AQM Allows You To See That Your Team is Making Items That Are Not Overly Complex and that Are Easily Maintained.
You can also set up the management team with user logins so that they can access these metrics and use them within discussions throughout the organization. Remember: the more comfort you provide people, the easier the buy-in will be.
Moving Forward
This is a high-level approach that I have provided to help change the culture of your organization. Be aware that it won’t be smooth sailing the whole way. There will be many ups and downs throughout the process. Just remember that it will be worth it in the end. Using these items will help everyone gain understanding and comfort in the new process. Consistency in repeating the process goes a long way with people. The more you release to your team from each sprint, the more they will see the fruits of their labor. These steps have significantly helped our development team to understand that the agile approach can be hugely successful.