How to structure your sprints for a good system design
A good design makes it easier for businesses to embrace the new solution. Sprint-driven design enables users to be engaged in forming the to-be processes in accordance with the functionality offered by the new system. This approach facilitates gradual and sustainable change management. I have discussed this implementation methodology in another blog. Let's dive into how to structure your sprints to achieve a good system design.
Sprints are generally associated with agile development which is much different than packaged system deployments. First, we must take into account the fact that we are starting with a fully developed system. Our job is not to develop a new one (thus customize) but rather figure out whether and how it fits into the business. This is an art form. We need to get the business to experience the new solution on their terms, with their data and to-be processes.
This adaption process is very much like learning another language. At the start, you will think in terms of your first language and translate your thoughts to the second language before talking. After some time, you will start thinking in terms of your second language and stop translating your thoughts. This is when you think and talk fluently in your second language. The same logic is applicable to the new system. When exposed for the first time, business users will think in terms of their legacy systems and convert their as-is processes to the new system. You must take the business through several iterations until they think in terms of the new systems to run their to-be processes. This will eliminate unnecessary customizations.
A good sprint has five stages, namely shadowing, modeling, reviewing, rehearsing, and show & tell. During shadowing, you watch the business users using their legacy systems to conduct their as-is processes. This is the discovery stage of the sprint. Your job is to understand the process. During modeling, you configure the new system to execute the process you shadowed. It is important to model the to-be process at this stage. You cannot carry bad behavior. You must challenge the business to stick to the standard functionality. During the review, you go over your model with the users you shadowed. You run through it multiple times and get input from the users. You can study the exceptions and variations to the process. During rehearsing, you prepare for the final stage of the sprint. You can record the process in the system, document Standard Operating Procedure (SOP), and practice. The final stage is the show & tell. Each member of the team working on their set of processes present each other their model and to-be processes. You get input from the rest of the group, assess the readiness, and iterate as needed.
If you are interested in learning more, please connect with me on LinkedIn, follow me on Twitter, or watch me on YouTube.
My name is Cem and this has been another gem.
