Written by Let’s talk about selecting a project lifecycle for a project. All projects are not the same. Some come with a considerable amount of uncertainties. Uncertainties about the scope of Burchard resources and others are where things are pretty much predictable.
How do we decide a respective lifecycle for a project, and primarily how do we determine what type of projects should be using Agile? Before they get into a project life cycle, let’s discuss two types of processes and how we control them.
The first process is a defined process that is pretty much simple where there is a fraction system where things are in operation; you have a predictable step. You’d produce a predictable output. It’s like a defined operation. If you want to control those operations, you can control those defined processes by asking at what time the outcome will come and how much cost it is taking. You want to control the time and cause you to want to increase the operational efficiency.
If things are pretty defined, your focus goes towards confirming the standards and ensuring operational efficiency, and there are other types of empirical processes. These processes are applied when we are not clear about the inputs we need to produce the desired code. Even we are not clear about output at the end, for example, if we want to increase sales by 20% by using a better conversion or a better layout at our website. Still, we don’t know the target layout because we can only know when we experiment with our set of customers. So it’s an empirical process as it can take three months or may take four months, but we do have a time range in mind. But it’s difficult to predict precisely how much time it will take? We do have a budget in mind, but it’s again difficult to predict exactly how much money it will, so in such kinds of processes, we run some exploration cycles, and we learn from those explorations. We apply that learning, and we move forward.
An empirical process cannot control them by time variance, cost variance, and by controlling the output because the output is not yet defined, you will figure out what the output is needed. So that brings another problem: how do we ensure that the team is focused enough and aligned sufficiently towards the goal while following the empirical process. Then we can’t use those operational efficiency matrices to control it. Hence, the solution comes with three things that help us manage the process, transparency, inspection, and adaptation.
Transparency makes sure that whatever is going on inside this team is transparent to all the stakeholders. Stakeholders can come and see what is going on? You put many visual indicators on board and show the status, learning, and progress until now. Even if everything is transparent, you can’t just rely on that at the end of a project. We will have a successful product. There should be a process that helps us in inspecting and adapting. So instead of having a process driven by historical data, an empirical approach where the learning is coming primarily from your project activities generates the required information that can be inspected back and adapted and corrected and produce better output.
Empirical processes are controlled by transparency inspection and adaptation, and whenever we talk about Agile, we primarily look at whether we have an empirical problem to solve? Do we have to follow an empirical process, and if the answer is yes, Agile makes the perfect sense. If the answer is that we do have a goal, but we don’t know what it takes to achieve it, we do have a direction, but we need to explore and then figure it out are going in the right direction, agile makes the right choice.
Suppose you look into dimensions of scope uncertainty and tools uncertainty, as usually in software projects, the delay comes either from the requirement or from the technology we will use in a given project.
If I put these two dimensions in place, I have one dimension that talks about how uncertain the how part is, and the other is what part of the scope is pending. So if there is no uncertainty, there is very little uncertainty in what and how we can follow a productive life cycle.
A productive life cycle in project management indicates that things are predictable. First, you have baseline data that helps you estimate and allocate work. Second, you do have baseline data that tells you what to do next and, finally, a predictable output that can be accepted by the customer and understood well by the producer.
If you have that situation, you can use a productive life cycle now. If things are not predictive, you may not need to use it again and again, and that comes the second type of life cycle, which is iterative. So we have an iterative life cycle where we talk about laundry work in a predictive life cycle. We don’t even plan for things which we are preparing today are going to be changed. We think that whatever we are forecasting is going to be a reality after 2-3 months. So an iterative life cycle, we don’t look at the complete project at one go; we work on one exploration cycle at a time. We execute that exploration cycle well means in one iteration of three months or two months. We do everything in that one or two months. We plan the iteration well, and finally, whatever comes, we show it to the customers, take the feedback and then move next.
When things are not sure, we follow an Iterative process. When things are more on searching, we increase the frequency of iteration. We treated things rather than waiting for two months three months and learning every week rather than making a four to three months plan. We only make plans for two weeks or four weeks, and that is a life cycle which we use called adapting life cycle. It is like an Agile Where we are adapting, why you are adapting so fast, why you are doing so much rework because we are solving any problem whenever we iterate.
Whenever we show things, we remain open to change. So we are inviting changes and inviting rework. But that rework is cheaper because we are doing it now. Suppose they don’t ask for that rework today. In that case, we produce something that doesn’t sell because we are not clear what is needed and reduce that risk to reduce the wastage of significant investment we iterate. In a project, this happens concisely at the start and after showing results, taking those feedback into account, moving on next, and saving a significant amount of value for the future.
If our what and how part is uncertain and dealing with new product development, your “What” is debatable. For example, during discussions in organizations, people talk about the fact that we have a defined requirement. Should we use agile? See, we are developing a new product, and we are assuming we have defined requirements. Having defined requirements for a new product itself is a big myth, or itself is a big mistake because we don’t know what is needed till the time we see it. It’s a very abstract concept, and once you feel it, only you can tell what is required.
But another problem is that we may have one project lying here; we may have one project not lying here. So even in an adaptive cycle, you may have one project line here now; we may think that we can apply Agile in all three. Yes! We can use Agile. Still, the type of Agile or rigor of inspecting and adapting may differ as your uncertainties go high; your iteration length should become shorter if things are specific for a long duration you can work.
Now the exact process is not recommended. You don’t have a very defined adaptive life cycle, which tells you that this is how it has to be done. Why? Because there’s no defined process, that adaptive life cycle also needs to depth it when you follow a particular way of doing things. So, for example, you do an inspection or that not only on the product but also on a process. By inspecting and adapting, you create a better way and better approach for solving your project management problem. So an adaptive life cycle does expect you to adapt even for your project management-related activities. So this is all I wanted to talk about, giving you a context on which type of project is suitable for Agile.