Monday, September 14, 2015

Planning and Agility in CAMS

"Responding to change over following a plan" says the Agile Manifesto. Practical experience suggests that the best response to change is possible only when there is a plan. Thinking outside the box is made possible only by a clear understanding of the box itself and its perimeter. Therefore, in CAMS, planning is given utmost importance. When there is a need to handle change, it is undertaken together with respect to the plan (Maharmeh and Unhelkar, 2008). Planning is associated with a certain wastage. This so-called wastage is the effort spent in preparing the plan and then shelving it in practice. CAMS considers the entire effort to draw a plan as an exercise in setting the parameters "of the box." Subsequently, even if the plan is shelved (and there is no reason to believe that every plan is shelved), there is still tremendous value gleaned in the very exercise of chalking out a plan. Eventually, the plan itself may not be put to full use, but the exercise of arriving at a plan is its use in practice.

Thus, the planned characteristics are more management focused, whereas the Agile ones are best served through leadership and facilitation. Therefore, planning in CAMS will be based on using lightweight artifacts to capture the essential aspects of requirements quickly; these requirements are then modeled in a prototype and the output used in further formalizing the plans.
Agile values lead to Agile development, which, if successful, leads to Agile management across the firm, finally creating the Agile organization (Dooley, 2009).

- Iterative and incremental composite Agile plans have two aspects to them. First, these plans aim to deliver the product in an iterative and incremental manner. Second, the plans themselves are updated incrementally—based on the development and delivery of an iteration. Miller (2001), also referenced by Ghanbary and Day (2010), discusses the risks associated with pure Agile approaches. The following is a brief list of those Agile characteristics, their associated risks, and the way in which a composite approach to Agility helps in handling them:
Iterative and incremental: Small software releases with rapid development cycles lasting 1–4 weeks. The potential risk here is the impact of each software release on the other parts of the system. Planning and modeling enable detailed considerations of impacts of releases on previous functionalities that have been delivered iteratively. Objective planning supports initial iteration but more like an exploration of requirements to enable formal planning rather than launching of actual development.

- Collaborative: The customer and developers, collaboration with each other constantly through face-to-face and close communication. While this works well for development where the stakeholders can get together physically, it can still be a challenge for outsourced development. Formal models of requirements within computer-aided software engineering (CASE) tools not only enable off-site collaboration but also provide the vital traceability required when the system moves to maintenance. Formality in collaboration works to enhance the overall output of collaboration rather than hindering it.

- Ease of learning: The practices associated with Agile methods are relatively straightforward and easy to learn. The challenge, of course, is the dissipation of the principles and values across the entire project. Furthermore, ease of learning does not always translate into ease of practice. Finally, while some practices work well during high-level understanding of business requirements, when it comes to undertaking detailed analyses, formal modeling techniques such as the Unified Modeling Language (UML) can play a major role. This usage of standardized and formal modeling techniques requires careful training and coaching including the training needed for an associated CASE tool.

- Adaptive: The Agile method should facilitate changes anytime during the development cycle. This factor works well in straightforward development when the teams are synchronized well, although, such ideal Agile team models are rare. In such cases, the adaptability of a method needs to be carefully balanced with the rigors of its activities and deliverables. Formal and proper modeling is also required to evaluate the change in business requirements and business rules and to enable controlled adaptation.

- Development centric: Indeed, all Agile methods are development centric. This means that the Agile values of sharing, team work, and expecting uncertainties all work well together in undertaking development projects. The risk in such understanding is that the development-centric nature of Agile approaches may not always work well in large-scale multidimensional and global projects. Nor will such approaches provide value during the maintenance phase of a product. Combining project management, business analysis, and governance-related activities of planned approaches together with subjectivity of Agile practices is the best way to ameliorate this risk.

Collaboration is at the center of Agile planning. As described by Coplien, the Lean secret is, "Everyone All Together, From Early On."[*] Agile planning techniques provide the basis for identifying risks and issues collaboratively. They mitigate risks by having frequent, high-quality communication among all stakeholders. Cost–benefit analyse, in particular, help provide insights into risks and trade-offs.

Taken from : The Art of Agile Practice: A Composite Approach for Projects and Organizations

No comments: