A lot has already been written, and even more may come out in future; however, to the astonishment of most of you I find that in no way a structured SDLC or Project Management is different from (or inferior to) Agile / Lean approaches.
Let me first present the case for Project Management. The CMMi or any other structured approach provides only guidelines and general framework for Project Management. At no point it suggests that it should has to be done in THIS was only. As you would agree with me the implementation happens as per "interpretation / understanding" of the person / organization. Since, it is a human tendency to adopt what is readily available, without giving much importance to adaptability to given environment or need, we end up having an incompatible implementation. Since, the implementation itself is faulty; you cannot expect it to bring correct results to you.
Take the case of CMMi / PMBOK the activities suggested under each are not replaceable or optional; one needs to carry those out, irrespective of approach chosen. However, the difference lies in implementation. For example, will anyone suggest that the any of the following items are optional (not a complete activity list);
1) Project Initiation
2) Project Planning
3) Project Execution
4) Project Monitoring and Control
5) Project closure
I do not think so. As I have suggested earlier the difference lies in its implementation and execution.
The promoters of Agile approach suggest that CMMi or any other structured approach is rigid and hence is not compatible with today’s changing environment. However, the fact is, the environment was never constant, then why is that we are realizing it only now?
In my view the Agile / lean approaches are nothing but the best practices of Project Management evolved over a period of time, and even these approaches are structured. Let me explain how.
The preachers and practitioners of Agile approach suggest that it scores over structured approach as with this approach,
1) One knows that “What needs to be carried out, and in what order”.
2) We need to involve customer; customer is the focal point.
3) We need to have “iterative” approach.
4) We should be ready to adopt the change.
5) Things are simplified.
6) Team takes the ownership, and there is no hierarchical, role based activities distribution
7) It promotes trust….. (and may be some more)
Now have a look at the above mentioned points, and assess what CMMI or any other structured approach has to say about these points. Let us take each point in detail.
One knows that “What needs to be carried out, and in what order”
What it essentially means is that we have a goal to achieve, and we never loose the sight of the goal. If goal were to change over a period of time, so would our activities, to align with the goal.
Now, in any structured approach you document the goal, get a buy-in of all stakeholders (a formal artifact is more from an evidence perspective alone), and work towards the goal. Again, if goal were to change, we re-establish the goal and align the activities towards achieving the revised goal. Where is the conflict in two approaches?
The conflict starts, if the goals were documented and then had been forgotten. Now, it is a problem of the person, and the enforcement, and not a problem of the methodology or process. It is a common sense that if we loose focus on goal, the end result would be far from defined goal.
Now, people may ask, why is that we do not loose a focus in “Agile” approach, though it is very common to loose a focus in structured approach. I would say that the answer lies in span / duration; invariably the agile approach is applied on “short” duration projects, hence, it is easy to retain the focus. Take it a little further, and apply on long running projects (with multiple teams and stakeholders), and you would find that you do not have an option but to document and monitor it on a regular basis. So, where is the conflict?
We need to involve customer; customer is the focal point
It is said the customer involvement is critical to the success of the project; invariably in all projects a client representative works with the team.
Well, I could not find any incidence either in CMMi or any other structured approach, where it had suggested that customer involvement in non-critical or we can do away with the customer. In fact, Six-Sigma projects are driven through “Voice of Customers (VOC)”, and even in CMMi model, customer is the focal point, as we always maps the success of the project to fulfillment of customer needs. In fact, it suggests to plan for stated as well as non-stated needs.
Again, I have failed to find any conflict. We need to communicate with client, take and provide feedback, incorporate feedback, involve him / her in verification / validation process, on a periodic and event driven basis. This is the premise behind any project executed within CMMi or any other structured approach.
How frequently and diligently / sincerely do we do that; it's a personnel trait, and no process or methodology can take it to the acceptable level of projections. The enforcement is the key. If your enforcement polices / points can ensure involvement, you would not face any problem on this front; independent of methodology / practice used.
We need to have “iterative” approach
Again, I have not come across incidence where CMMi or any other model, where they have advocated a “Waterfall” model for all projects. Whether you need to adopt a “Waterfall”, or any “Iterative” (“Incremental”, “Spiral”) model, it all depends on clarity on requirements, project size and customer needs.
If the requirements are straight forward, project is of short duration, say two / four weeks, with as much effort; in this case even “iterative” approach would be a burden. Therefore, it would be naive to say that “Iterative” approach is the only approach for success. However, it may so happen that you (or your organization) had been managing only large projects, therefore, “iterative” approach seems more appropriate.
The choice for approach is “need” dependent, and has nothing to do with adopted model, i.e. structured or Agile.
We should be ready to adopt the change
It is true that we should be ready for change; however, it does not mean that those can be “taken-in” haphazardly. I’m sure even in “Agile” approach one would assess the impact of change from solution, dependency, cost, and time perspective. That is, whether it is feasible (the change / requirement), what is the impact on overall solution, where are the touch points, how much will it cost, and whether it can be adopted within given timeframe or would require more time.
What CMMi or any other structured approach suggests that we have to have a clearly defined change management process, which helps in easy monitoring and tracking of change. It may have mandate for approvals; however, that is there in “Agile” model too.
Now, people may suggest that in Agile the change is assessed and approved by team, and it is less time consuming. However, again, what prevents you implementing this in CMMi or any other structured model?
If the project size is small, and impact is also small, let the team (or any other representative) take a decision, and carry on with the task. However, again be it “Agile” or any other model, you cannot violate the basic rules of change and configuration management.
A well defined process is to ensure that changes are easy to take in, and implement. The “rigidity” is an external factor introduced by human psychology; it has no bearing with process or model. The rigidity comes from “fear of failure”; failure on any front, i.e. missing out on solution fitment, effort, time, cost, quality, productivity or anything else. If one is “insured” from these failures, all “changes” could be embraced willingly.
Therefore, we need to ensure that we address the “fear of failure”, we would find that even CMMi or any other structured model are as adaptive as any agile model can be.
Things are simplified
Things are simplified in Agile as compare to structured approach. I believe it is more because of “size” than any model enforced process.
No model suggests that you need to incorporate complex design, complex solutions, create a cobweb so that decisions get entangled under those cobwebs.
The processes are defined to make life simple; because, process is nothing but a set of sequence of steps, with identified inputs and expected output(s) / outcome(s). The problem starts when people equate process with “excessive” documentation. Please mind the world “excessive”. That is, we are aware of the fact that even “Agile” model cannot do away with the “documentation”; instead, it propagates “appropriate” documentation.
The reason being in the event of no documentation everything becomes person dependent, and trust based. However, the problem is no system in the world can operate (successfully and repeatedly) and grow, with having people dependency.
That is why the processes are defined and documented so that person dependence can be reduced (if not removed) to an extent where the replacement is “feasible” and relatively less painful.
Team takes the ownership, and there is no hierarchical, role based activities distribution
Again it boils down to “size” of the project, and interpretation and implementation; independent of model.
It is evident that if the project size is small, it makes sense to have a flat hierarchy, as activities can be overlapping and can also be shared, without impacting anything else. On the other hand, if the project size is big, the flat hierarchy would bring in chaos; and no one would be clear on “accountability”. Therefore, one needs to bring in “Operational” hierarchy, so that operations can be segregated (from accountability perspective); however, still no one prevents or directs / dictates that discussions and decisions can’t be collective.
The operational hierarchy is to facilitate the “production”; it is the “implementation” and “ego”, which deviates it from the “original” implementation. Therefore, if you introduce these two variants in “flat hierarchy” of Agile model, even in small projects, you would feel the pain of wrong, delayed, and bureaucratic decisions.
It promotes trust
I personally believe a trust can be formed over a period of time, if and only if people perceive that ones words match his / her action. This gets propagated if you work together, and if there are interdependencies.
The Agile model brings / necessitates closer association and working; as the model cannot work without it. But, the structured model is not opposed to it either. Whether you put two people or single person on a given task is your decision; model has nothing to do with it.
In fact with well defined processes, well laid out role descriptions, it should foster trust, as those should ideally be helping in more predictive outputs / outcomes.
To summarize, agile or so call structured approaches, there is no difference at “core”. The agile propagates the “best practices” of project management, which if implemented in structured approach would yield the same result. The reason being, at the end of the day even agile model follows some structure; as without pre-defined structure it becomes people dependent, and one cannot have any degree of prediction under those circumstances.
This has also been published by me at http://allpm.com/index.php?name=PNphpBB2&file=viewtopic&t=3011
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment