Further, in my article about Agile, I would like to elaborate on the "mastery" aspect. I deeply believe that an Agile process cannot reach the required altitude, because the crew may have a lack of the "mastery", which means that they do not have enough experience with the tools and appliances. Bad thing here is that the crew may not realize all the risks of doing the flight on the lower altitudes. Sounds familiar? Thankfully all cabin crew is deeply trained on simulators to ensure passenger safety. Simulators provide an opportunity to touch devices, buttons and knobs in the test mode.
It can be a fair illustration of the reason to practice an Agile process on the simulator before going live. There are number of ways to do it: “power point” trainings, exercises, short imaginary simulations. Each method has its advantages. Choosing between those formats, I like more interactive sessions without deep theoretical monologues, but with a focus on interactivity and teamwork. Let call it real-time compressed simulations. Do you remember that interactivity prompts an interest while tactile senses provide greater efficiency in the information assimilation? The individual, after all, slowly remembers that he have heard and seen, but more intensively assimilate situations, when he moves through space, arguing with other participants and, perhaps, even been in a conflict situation. Another important aspect of such interactive workshop may be a connection of the structure to the real content like requirements, time zones, and architecture.
“Why one have to do it” – you may ask? There are a variety of real and negative examples of how the lack of attention to the expected delivery process like Agile, leads to the delivery outages. Approach, when we "start with something, and then to think about the process" in most cases leads to "start with something, and then extinguish the fire". There is no need to describe in the details those negative examples, when we start with “cowboy coding” process and then we find ourselves in pretty limited circumstances to revisit our process approaches. This is well illustrated on the "adoption chart" where the efforts shows non-liner growth over the time. Agile simulator typically have to be launched during investigation phase which potentially reduces the risks of possible "Abandon" scenarios during "Trial\Pilot phase".
Real world example
Let’s focus on positive example of my coaching work. It was with one team in Luxoft. They wanted to try implementing an Agile process, but was not sure if they can get it. Customers in San Francisco, including a broad range of managers, came to Kiev in order to discuss the development strategy with local teams. As a coach of the Luxoft Agile Practice, I was invited to help with their needs and to demonstrate example practices to show how they could go on with Agile. Three sessions with three different teams were planned for them. I have almost no time to think how the sessions can be conducted. Therefore, as a quick fix for the first session, I opted for "to show and talk" and "Q&A" formats. But in the end, I radically changed approach, because of the low involvement of a large number of people and not very positive response.
What have I changed? First of all, I was advised to sel ect more spacious room, where the participants had the opportunity to move more freely. Second, I changed my role. Now I was not an expert, but rather a facilitator, the person who sets the rules and time boxes, and keeping the audience in the right direction. Along the way I was giving the teams only the absolute minimum of the theory required for the next step. We chose Scrum as methodology to try with. For that we found all the required roles: Scrum Master, the Team, and Product Manager fr om SF was signed for Product Owner role.
As a result, in one day, we went through almost all the stages and events of the Scrum Development process. We tried all of the Scrum artifacts, as well as practices for the requirements elicitation. But the most important thing is that everyone was equally involved into workshop, working with the real requirements and tools.
As a result all participants were enjoyed the second session. It was a clear opportunity to understand how Scrum methodology can work in reality. And what are the difficulties they likely will face. By the end of the workshop, we have a time to discuss the risks associated with Scrum approach. Customers and the team were discussing all potential risks and how they are going to mitigate them. Interestingly, many of the ideas, which have been introduced during workshop, subsequently were adapted when the team moved to the scrum. The workshop gave more confidence that the Scrum approach can work successfully.
Let’s recap the message. Unlike "listening" sessions, interactive Agile Simulator motivates to participate, and in turn to train and acquire required skills. Acquired skills are motivating to do real job better. What do you need in order to conduct a similar workshop? First of all, invite a good facilitator who is aware of the most details of your chosen methodology. Plan with him a workshop purpose, teams, individuals, and expectations. Second, find a large meeting room in your office. But the most important thing here is that real Product Owner and other crucial roles should be sitting together in one room. After all, this won’t work without a real team work and real conclusions. Agile simulator should answer the question if we can take off or not.