Someone once asked me, “How do you handle a missed deadline?” We have to own the problem and inform using the appropriate channels on time, not days before the deadline. However, this outcome is preventable by using Scrum or any Agile method. I started working with agile methods some time ago when I was desperate to comply with my deadlines, and everything seemed out of place. The first technique that I used was workcells. Workcells are used in lean manufacturing; one workcell combines resources to execute a process, and several workcells create cellular manufacturing. According to Investopedia: “The goal of cellular manufacturing is to move as quickly as possible, make a wide variety of similar products while making as little waste as possible.”
One of the main characteristics of this methodology is the short cycles of manufacturing implemented in the workcell. I started with this technique by accident. I studied using workcells in supply chain management because I had to deal a lot with warehouses’ replenishment. One of the arguments presented was that short cycles were essential to assess performance and instill confidence in the workcells team. In the end, a team that sees positive results from its work becomes highly motivated. Another argument presented was that the process of following up short cycles becomes easier and promotes accountability. The faster we get results, good or bad, the quickest we can act to move on to the next task or to resolve the issue at hand. This assessment resonated with me in a big way. I used to implement ERP’s, which may take at least a year, and most of my projects lasted about two years. As an outsider to the companies that I worked for, I knew that my first task was to gain credibility.
I accomplish this first task by breaking up the project into smaller projects based on processes—one process is equivalent to one sub-project. Then I chose the project that had the highest likelihood of success in the shortest time. The next step was to sell this project as priority number one to the different stakeholders. I sold the idea using the following arguments: the team will learn the implementation process; the team will also learn how to communicate, and who the decision-makers are (in practice, decision-makers may appear in the most unusual places); finally I contended that a quick result in one area would boost the credibility of the process in all the other ones. In most cases, if we got this small project done on time and with positive results, the rest of the implementation generally would go as planned. Thus, the concept of short cycles seemed the solution that I was looking for.
However, using short cycles does not mean that planning for the long run becomes invalid. Over the years, I experienced that a clear roadmap with rough estimates of time sets the final destination journey. The stakeholders should clearly state this road, and it should have deadlines and milestones, and the details of how to reach each milestone may vary over time. If I had a two-year project at hand, I could not address a detailed plan on achieving the goals for the next year. The only fact that I knew for sure was what I could do for the next three or four months, so I planned for the processes that I could implement in that period. Even if I planned for three or four months, I focused only on what could be done in a month. The month concluded with a meeting with the stakeholders to deliver a sub-product. The primary purpose was to show progress. I would hold a weekly meeting with the team; the purpose was to address the week’s deadlines and the week’s problems before. Those who have worked on Scrum can recognize the agile framework in this approach. For me, being agile means short cycles of one or two weeks of work (the sprint), a clear long term goal (the vision), monthly deliverables to show progress to different stakeholders (the release), and milestones to accomplish to get to my goal (the roadmap).
I translate the agile mindset into one phrase: plan top-down, execute bottom-up and be prepared to change your plans without losing perspective of what the main goal is. The most challenging part of this approach is learning to deal with change and plan with big empty boxes that will be filled later. This planning must be done with some experience at hand because only if the planner has plenty of experience, he or she will know how to draw a rough estimate. That’s why the stakeholders should perform this critical activity. The combined experience of the team will deliver an informed estimate of the plan. Each subject matter expert will estimate without delving too much into the details. The plan should address everybody’s concerns. For example, the technical team’s subject matter expert may say that implementing a reliable database in AWS for the project at hand could take up to two months. Planning is always risky, but as a rule of thumb, the team should consider three scenarios: the worst-case scenario, the probable-case scenario, and the best-case scenario. The team should decide which one should be taken for the plan or parts of the plan. However, the best-case situation is usually used as a starting point. Choosing this scenario is not recommended. How does the team choose? Well, that is a complicated question that every book that I read about management answered with this phrase: “it depends.” Indeed, it depends on the circumstances: Is the project critical? Are the available resources sufficient for the project? Is there a need to hire people, and how long would it take to hire them? What are the levels of expertise of the team members implementing the project? Is there a team already formed, or is it a new one, and how long would it take to be fully functional? As many as they can address, the stakeholders should make many questions to create a reasonable plan. The final result of this activity that may take several meetings, is a plan that resonates with all the parties. Now that we have our project, with a vision, a roadmap, and milestones, no details, and fully approved, we can start with the next three months.
The work done in the first three months is the most important because the results from this work will set the rhythm of the project. This period will contain the preparation stages of the project. The product owner and the business analysts will prepare the stories for the first stage of the product. The technical team will have its own technical stories to execute, like servers, databases, and languages to be used. The product owners will focus all their attention on the first sprint’s details, the first release, the first retrospective, and of course, the first celebration. The end of the first sprint should be a motive to celebrate, and I would recommend doing it in a simple yet meaningful way. This kind of activity generates goodwill in the team and creates a commitment towards the goal. I do celebrate the first sprint, the releases, and of course, the realization of the vision. The last one is a major celebration, a well-deserved congratulation, and a good excuse to introduce the new vision to be executed next.
We have discussed how to do agile, but doing agile is not the same as being agile. Being agile is a mindset that enables you to plan for big things and still stay focused on the next sprint in everything that you do. Being an agile practitioner is hard, and it is harder for people that have been involved in the technical fields for some time. Programmers and good software architects tend to be detail-oriented and need to know how everything is going to fold. The anxiety that comes with uncertainty is hard to overcome, but it is doable with practice. First, start small and simple. The creation of the agile mind is what makes a good agile team successful. If the team believes in the methodology, then a big part of the work is already done. I heard someone saying that he had a board with all the chores and projects needed at home. He picked the tasks that could be done over the weekend. If he could do some work on weekdays, he chose something that he could do in a couple of hours. This description is the simplest way of depicting an agile mind. Another example is using agile to get a college degree. The vision is a four-year degree, the milestones are eight semesters, the sprint and the focus is what we can do with the best possible results in the next week ( tests, homework, and projects), and the retrospectives can be done after each major project or midterms, what we could do best next time and how are we going to do to get on track with the grades. The most important part of this exercise is to keep focus in the sprint. Do the best, with the resources at hand, to execute the work for this week. One week at a time, and then all over again. Believe it or not, it is working with my first-year college daughter.
To sum up, being agile means having a vision with a roadmap to be followed, marked by milestones and expected changes –planning top-down. The secret to finishing the road is to know how you will do the next couple of yards. Something may appear in this short distance that will change how you will approach the next ones. Stay focused in this sprint, do not worry about the next one, wait for change, and don’t forget where the road is going, the vision –executing bottom-up. Practice makes perfect; thus, try to get an agile mind in every project, personal and professional, that you do and keep it simple. Adapt to your circumstances, and some ceremonies may need some change for your particular needs, be agile, stay agile, do your retrospectives and start all over again.
References
Kenton, W. (2019 Jun 30). Work Cells. Investopedia. Retrieved from https://www.investopedia.com/terms/w/work-cell.asphttps://www.investopedia.com/terms/w/work-cell.asp