IT Governance and Agile


Standards for IT governance have emerged with the increasing need for control and compliance by businesses. Two popular IT governance standards that are worth exploring in the context of Agility are the CoBIT and ITIL standards. The impact of Agile on a governance process can be significant because the Agile Manifesto gives precedence to individuals and interactions over documentation. Consider however, the Sarbanes–Oxley (SOX) style compliance requirements, which state that there should be evidence of certain requirements and the sign-offs at the end of every stage of the project for audit. The need for auditable and formal documentation needs to be acknowledged and acted upon in practice—irrespective of the use of Agility in development. For example, formally documented requirements provide the basis for secure contracts. Specifications and documentations can also provide traceability of requirements, their testing, and their acceptance by the user. Thus, there is a need to merge the use of governance frameworks together with Agile principles. Such a merger improves the understanding among the business, developers, and even auditors.

The two common governance standards of CoBIT and ITIL are briefly mentioned in the context of Agile in the following.

Control Objectives for Information and Related Technology (CoBIT)
CoBIT (latest v 5.0) creates the opportunity for corporate governance to understand IT operations and vice versa. Agility has the responsibility and the opportunity to influence corporate governance. Organizations employing CoBIT usually customize it according to their IT infrastructure, business values, and risk profile (Moeller, 2008). Agility can be combined with controls and documentation of CoBIT to improve collaboration and understanding as well as providing documentation and control of organizational level activities. Considering the CoBIT activities in the context of Agility also encourages greater alignment of IT development with business goals. Business can specify their governance and control requirements, and developers can prioritize them together with business.

In projects, specifications and prioritization relate to the development of the functionality of the system. They do not play a role in the strategic decision-making process such as whether to buy an enterprise resource planning (ERP) solution. This is where business analysis and project management competencies play a part. Therefore, CoBIT has to be used to combine IT governance together with business analysis and Agility. A synergy between the methods that support the analytical methods and governance is required in implementing CoBIT.

Information Technology Infrastructure Library (ITIL)
Since ITIL focuses on the mapping of IT strategies with business strategies, it has substantial relevance to the discussion of Agile in practice. ITIL is a set of operational guidelines that evolved from a British Government initiative. The importance of ITIL is the help it provides to IT departments in improving their quality of service (QoS). ITIL (2009) has five core publications or disciplines made up of services delivery and support; planning and implementing service management; security management; managing IT infrastructure and applications; and managing overall software assets of the organization. These disciplines have initially focused only on IT operations. This, in turn, enables IT operations to increasing their QoS through uptime, rapid problem resolution, and improved security.

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

Software Processes and Agile


Formalizing these SDLCs leads to planned software processes. The core building blocks of these software processes are their roles, deliverables (with templates), activities, and tasks (Unhelkar). These building blocks are supported by guidelines for configuration into usable "components," "chunks," or "fragments." Within the composite Agile approach described here, they are called process maps. Eventually these process maps, as building blocks of a process, can be embedded in CASE tools. Three software processes, the RUP, Mentor, and OPEN, are described below in the context of Agile.

Rational Unified Process (RUP)
The focus of RUP is mostly on UML-based visual models rather than on text-based documentation. RUP enables all team members regardless of their role in the project to "share a common language, process and view of software development" (Rational Software, 2001). Notice how Agile methods focus only on sharing of code rather than on sharing of visual models. Furthermore, pure Agile methods also depend for such sharing on the specific motivation and skill of a team member. However, workers in RUP have roles in a project that are more elaborate and more formally defined than in an Agile process. Activities are assigned to a worker who formally owns and completes them. There is minimal formality in the assignment of tasks in Agile—and minimal individual ownership (as it is joint ownership). Artifacts, which are project deliverables, are primarily comprised of a code in Agile projects. Workflows in RUP provide higher levels of granularity for activities as they enable sequencing of a group of activities.

RUP claims to be incremental and iterative. According to Kruchten (2003), the iterations in RUP enable a more efficient use of resources and a high level of code reuse. This is in line with the Agile practices of iterations and refactoring. However, according to Chatterjee (2006), RUP is not able to manage enterprise-level issues and organizational issues too well. Agile on its own is also not able to manage organizational issues. RUP is a formal process that needs to be initiated and customized according to the "organizational assessment and the production of a development case" (Ambler, 2005). There is no such need for up-front work in configuring and using a process in Agile. Agile and RUP can work together only when Agile practices are embedded within the activities and tasks of RUP.

Process Mentor
Process Mentor is a platform for creating and modifying process architectures that cover the entire SDLC. This includes process support for concept exploration, alternative evaluation, business investigation, requirements analysis, system modeling, design, development, implementation, and testing (Process Mentor, 2009). The stages within Process Mentor include business investigation, requirements, modeling, design, development and testing, and project management. These stages are supported by road maps, process units, and roles. The development and implementation modules of Process Mentor are the ones that lend themselves to the use of Agile principles and practices. Thus, once again, the importance of Agility in this planned process comes from the way in which the activities and tasks of development are carried out, rather than their sequencing, tracking, and reporting.

Object-Oriented Process, Environment, and Notation (OPEN)
Object-Oriented Process, Environment, and Notation (OPEN) is a software development process framework. The OPEN process framework is made up of three main elements (Firesmith et al., 2005). These three elements are a metamodel, a repository of reusable method components (or method fragments), and construction and usage guidelines (OPFRO, 2009). OPEN is a flexible and tailored process framework that covers business, quality, modeling, and reuse issues within the SDLC (Henderson-Sellers and Unhelkar, 2002). A number of opportunities exist to embed Agility within the OPEN framework. For example, the "Build" method fragment can easily make use of most practices of Agile. Similarly, opportunities for inserting Agile principles and practices within the development and testing method fragments exist within OPEN. OPEN also bases itself on the fountain model of software development (see the sidebar). Hence, OPEN is inherently iterative and incremental.

Software Agile (Development)


Agile software development, as a method, subscribes to the Agile Manifesto. The focus of these methods is on producing a working code (or its equivalent). Individuals have substantial freedom in following these methods and, yet, they are considered an integral part of the team. Contemporary Agile, understood as a method, provides key guidance at the software project level. For example, through Agile principles, the users are made part of the development team. Such collaboration bridges the gap between specifications and the end product. Agile, through its short and sharp iterations, also ensures that the product reaches the users as soon as practicable. Since the methods are themselves Agile, the only Agile touch points of interest to these methods are the nonsoftware areas of work in the organization. For example, Agile principles such as simplicity, transparency, and courage become extremely interesting when they are applied in business functions such as accounting and HR. CAMS is interested in elevating and using the Agile values and principles across an entire organization and not just software projects. Thus, in CAMS, Agility also gets used in business analysis, testing, modeling, and architecture.

Business Analysis
Business analysis deals with elicitation of requirements, planning, and managing the requirements documentation, analyzing requirements, understanding and communicating business needs to all stakeholders continuously, and providing input into the solution. The practice of business analysis uses a wide array of techniques. For example, high-level business needs are explored using mind mapping, root cause analysis, and SWOT analysis. Detailed requirements modeling is undertaken with use case modeling, activity graphs, and Business Process Modeling Notation (BPMN) diagrams.

Understanding and modeling of the problem enables balancing the various factors (and risks) associated with a problem. This, in turn, enables a business analyst to arrive at an appropriate recommendation for the solution. Business analysis recommendations consider the fact that IT-based solutions may not be the only way to solve business problems. Business analysis processes aid decision making at the organizational level. For example, business analysis considers business needs and weighs it against the risks (e.g., through a SWOT analysis). The output of this analysis can assist business in taking the correct decisions. Agile values of collaboration and trust can be brought into this decision making. Business analysis is also undertaken in software projects at a requirements modeling level. Thus, business analysts model functional, nonfunctional, and interface requirements. Features can also be written as user stories written on story cards. The Agile touch points with business analysis are explored further in CAMS.

Testing represents a wide array of activities that occur in both software and business processes as well as in projects, and across the organization. For example, testing can occur in an Agile project almost on a daily basis (continuously) whereas, in the same project, the user acceptance test may occur right at the end of a release. Testing may occur for the process of recording a customer complaint in a call center environment, or it may test the carbon emission of a process during business as usual (BAU). Testing needs its processes and frameworks that will help and guide the testing process. Depending on the project demographics as well as organizational situations, testing frameworks have to change to reflect those specific needs. Testing also has to relate to the QA activities being undertaken in a project as the QA activities are aimed at preventing errors (as against testing, which is focused on detecting errors). While standards such as the ISO9001 have been popular in the overall QA area, there are specific testing standards and frameworks for testing that are of interest to composite Agile. For example, the testing framework as assessed by the ISTQB has a positive role to play in providing formal testing activities and tasks that can be carried out in composite Agile. The ISTQB is working on a Testing Body of Knowledge (TBOK) 2 that provides a suite of principles for testing that can be embedded with the Agile principles and practices. For example, the formal activity of "test planning" can make use of the Agile principle of collaboration; and the "testing" activity itself can use the Agile practice of continuous testing as the code is being developed.

Modeling and Architecture
Modeling and architecture are primarily derived from the planned approaches to software development. They can also be applied in other nonsoftware projects where modeling is a mechanism of creating a blueprint of a problem or solution without actually developing the full solution. Therefore, modeling can significantly enhance the quality of a product—as it enables discussions, clarifications, and management of expectations. Architecture, which is also based on the creation of models, is aimed at specifying the constraints applicable in understanding a problem and putting together a solution. Thus, both modeling and architecture rely heavily on visual diagramming techniques aimed at enhancing problem solving. These techniques are discussed next with a view to understanding their standards and frameworks so that they can operate together with Agile principles and practices.

Within the software domain, the earliest modeling effort was through flowcharts and programming sheets. This effort was quickly followed by entity-relationship (ER) and data-flow diagram (DFD) techniques, made popular during the relational database (RDB) era. Later, in the mid-1990s, the Unified Modeling Language (UML, current version 2.0) of the OMG ( became the de facto modeling standard for analysis and design. Modeling, through the UML, can be carried out in understanding the problem, casting the solution, and understanding the background constraints and limitations. Thus, the modeling effort in UML occurs in problem, solution, and background spaces (Unhelkar). The UML came about as a combination of the three most popular methodologies of that time: Booch (1994), Object Modeling Technique (OMT) (Rumbaugh et al.), and Objectory (Jacobson et al., 1993). Later several other methodologies merged into it, resulting in the current, formal UML version 2.0. This has resulted in 13 official diagrams in the UML—some of which offer excellent opportunity to boost Agility in practice. The rigors of the UML metamodel and the opportunities through model-driven architecture (MDA) can provide the robustness, and the Agile principles and practices provide the flexibility in a composite Agile project. Combining the collaborative and customer-centric principles of Agility with the formality of UML diagrams provides excellent value and quality in practice.

Consider, for example, the four different ways in which UML is meant to add value in software projects. These four ways of UML usage can benefit the use of Agile principles and practices as briefly discussed.

1. Visualizing: This is the primary purpose of the UML; its notations and diagrams provide an excellent industry standard mechanism to represent pictorially the requirements or business processes, solution, and architecture. Placing UML models on large, visible charts within software projects can be a useful way of applying Agile practice. Use case diagrams and activity diagrams also provide excellent means to present the requirements of a user. Combining these formal visual techniques with the story cards of Agile provides both control (traceability) and flexibility of a project.

2. Specifying: Together with visual representations, UML also facilitates specification of some of the artifacts. This includes specifications for actors, use cases, classes, attributes, operations, and so on. Specifications can provide the details of a model and thereby open up opportunities for applying quality techniques. Although pure Agile approaches are not too keen on in-depth specifications, Agile principles such as simplicity in design and acceptance of changes can be carried out in a much easier manner through detailed and formal specifications. For example, specifications of a feature on a user story can be inserted in the specifications of a use case and, thereby, formalized and controlled in a project.

3. Constructing: UML can also be used for software construction as it is possible to generate the basic code (C++, Java, VB, Smalltalk) from UML visual representations, depending on the CASE tool being used. The current literature on Executable UML also suggests that UML can and will be increasingly used in construction of software. This "construction" usage of UML comes closest to what the Agile methods talk about. Agility can play an important role in promoting the construction of software using UML—as it is much easier and faster to use Executable UML as against an executable code.

4. Documenting: With the help of UML, additional and detailed documentation such as requirements, architecture, design, project plans, tests, and prototypes can be provided to enhance specifications and visual representations. Agile, as understood in software domain, is not focused on creating substantial documentation. However, the composite Agile approach pays' significant attention to documentation. 

The architecture provides the basis for structural stability that can apply to both BAU operations of an organization and the new initiatives and projects. Architecture can be understood as an abstraction of the systems and processes in an organization. Specific architectural frameworks, such as TOGAF and the Zachmann framework, also include people, in addition to processes and mechanism, to change/transform an organization.

Agile methods recommend just enough architecture and design. There is no detailed and long-drawn art architectural exercise in Agile projects. This may well work for straightforward development projects. However, creation and adherence to architecture is important in any kind of project. Typically, an EA provides a bird's-eye view of all of the IT assets of the organization. An EA can be an all-encompassing model of an organization's technical (IT) architecture, systems, contents (databases), interfaces, applications, networks, and solutions. Such a view enables understanding and balancing of risks in taking technical and business decisions. EA can also enable alignment of these aforementioned elements with the business strategic objectives and vision (McGovern et al., 2004). Thus, architectures enable consideration of the enterprise-wide effect of technical decision making. Architectures are made up of a suite of guidelines, patterns, and corresponding frameworks. These frameworks standardize the application of architectures within an organization and also help their understanding across an industry.Here is a brief mention of TOGAF primarily from its Agile touch points. TOGAF is based on the following four layers of architecture.

1. Business architecture defines business strategy, governance, organization, and key business processes; Agile principles can be used in order to collaborate with key business stakeholders to arrive at the business architecture. The governance and organizational structure of the business can also benefit by the application of Agile principles and practices that enable change.

2. Data architecture defines the structure of an organization's logical and physical data assets and associated data management resources; prototypes and UML's class models can be used together to create models (schema) of data architecture.

3. Application architecture specifies individual application systems and their deployment—which can be supported by Agile's iterative and incremental releases and flexible requirements capturing; UML's package and component diagrams can be used to create a distributed application architecture.

4. Technology architecture specifies the software infrastructure intended to support the deployment of core, mission-critical applications. UML's state diagrams can be used for real-time modeling and deployment diagrams for modeling the overall technology architecture.

Creating and using visual models of the above architectures provides the basis for discussions of constraints and limitations on how the user stories or features are developed. These architectural considerations enable an understanding of the dependencies that stories have on each other. Furthermore, EAs are not created specifically for an Agile project; instead, they are organizational-level models that provide the basis and input for Agile projects.

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

Installing Git


Before you start using Git, you have to make it available on your computer. Even if it's already installed, it's probably a good idea to update to the latest version. You can either install it as a package or via another installer, or download the source code and compile it yourself.

This book was written using Git version 2.0.0. Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently if you're using an older version. Since Git is quite excellent at preserving backward compatibility, any version after 2.0 should work just fine.

Installing on Linux

If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you're on Fedora for example, you can use yum:
$ yum install git
If you're on a Debian-based distribution like Ubuntu, try apt-get:
$ apt-get install git
For more options, there are instructions for installing on several different Unix flavors on the Git website, at

Installing on Mac

There are several ways to install Git on a Mac. The easiest is probably to install the Xcode command line tools. On Mavericks (10.9) or above you can do this simply by trying to run git from the Terminal the very first time. If you don't have it installed already, it will prompt you to install it.
If you want a more up-to-date version, you can also install it via a binary installer. An OSX Git installer is maintained and available for download at the Git website, at

You can also install it as part of the GitHub for Mac install. Their GUI Git tool has an option to install command line tools as well. You can download that tool from the GitHub for Mac website, at

Installing on Windows

There are also a few ways to install Git on Windows. The most official build is available for download on the Git website. Just go to and the download will start automatically. Note that this is a project called Git for Windows (also called msysGit), which is separate from Git itself; for more information on it, go to
Another easy way to get Git installed is by installing GitHub for Windows. The installer includes a command line version of Git as well as the GUI. It also works well with Powershell, and sets up solid credential caching and sane CRLF settings. We'll learn more about those things a little later, but suffice it to say they're things you want. You can download this from the GitHub for Windows website, at
Some people may instead find it useful to install Git from source, because you'll get the most recent version. The binary installers tend to be a bit behind, though as Git has matured in recent years, this has made less of a difference.
If you do want to install Git from source, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you're on a system that hasyum (such as Fedora) or apt-get (such as a Debian-based system), you can use one of these commands to install all of the dependencies:
$ yum install curl-devel expat-devel gettext-devel \
   openssl-devel zlib-devel

$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
   libz-dev libssl-dev
When you have all the necessary dependencies, you can go ahead and grab the latest tagged release tarball from several places. You can get it via the site, at, or the mirror on the GitHub web site, at It's generally a little clearer what the latest version is on the GitHub page, but page also has release signatures if you want to verify your download.
Then, compile and install:
$ tar -zxf git-1.9.1.tar.gz
$ cd git-1.9.1
$ make configure
$ ./configure --prefix=/usr
$ make all doc info
$ sudo make install install-doc install-html install-info
After this is done, you can also get Git via Git itself for updates:
$ git clone git://

Taken from : Pro Git, Second Edition

Agile Project Challenges


At the software project level, numerous challenges emerge in the use of Agile. For example, project managers in charge of software development and maintenance projects are interested in formal requirements documentation, scoping, and estimation of the work required in the projects. Agile methods, based on the Agile Manifesto, give far less importance to these project factors. An upfront and detailed business analysis is also eschewed in an Agile approach although its significance cannot be overestimated. Outsourced projects find it difficult to get a user on board the project as expected in an Agile approach. Component and third-party services developers face similar challenges when it comes to Agile projects.

An important aspect of an Agile approach is the phenomenal importance it gives to an individual. Therefore, people, their skills, motivation, and communication are crucial ingredients of a successful Agile project. Cockburn and Highsmith (2001) stress amicability, talent, skill, and communication as critical factors for Agile success. How to implant these attributes within a Agile project team? This requires greater understanding of the sociocultural aspect of a project than its technical aspects. Facilitation, leadership, and personal contacts assume far greater significance in a pure Agile approach than in a planned approach to a project. In contrast, formal methodologies in software projects (particularly large-scale software projects) separate an individual's subjective elements (e.g., motivation) from the actual process. Formal or planned methods typically create a work breakdown structure and assign resources to the tasks within the project.

The issues specific to the use of Agile methods mentioned at the start of this chapter need to be considered in the context of the already known issues and challenges that are faced in software development. These issues have been discussed by a range of practitioners as they are encountered right from the start of the project. (See Dooley [2009b] and the interesting discussions on information technology [IT]-related issues in Agile Software Development in Large Organizations [Brenner; Lindvall et al., 2004].)

Some of these specific issues and challenges in IT projects are as follows:

- Requirements: One of the most common challenges in a project from the very beginning of software development is the lack of formal and sufficient requirements. Bennatan (2009) highlights the most common requirements problem as insufficient information at the beginning of the project. An Agile project officially kicks off much earlier than a traditional, planned project in terms of its requirements modeling exercise. Lack of sufficient information is quite acceptable at the start of Agile projects. This, however, compounds the original challenge of lack of information and formal requirements in any IT project. The importance of early requirements capture, modeling, and analysis cannot be discounted in a software project. In addition to scoping the needs of the user, formal requirements modeling also identifies dependencies among the requirements. These dependencies may not be evident unless a majority of the project requirements have been understood and modeled at the beginning of the project.

- Changing purpose of software: Software systems are developed for a specific business purpose; however, that purpose keeps changing, thereby requiring changes to the software to make it adapt to the new business requirements. Changing the software to reflect continual business adaption is a major challenge. Continual demand for changes can lead to errors, poor service, and business resentment. As the number of users increases, the difficulty of adapting to change also increases. In a pure Agile approach, the purpose of the software also evolves as the development progresses. The complexity of a system in operation (such as the number of users, performance, and scalability) requires to be understood in development through a formal, planned methodology.

- Rework: Most software products undergo rework after the project is completed. The business needs identified at the start of a project usually change by the time it is completed. Agile projects are quite comfortable with these changing requirements. These requirements, however, are encapsulated in story cards pasted on visible charts and walls. Changing the requirements later in the life of the system, reworking the code written by someone else, and tracing the changes from requirements to code lead to major challenges in software projects. The question of how these story cards can be used when the system moves into maintenance needs to be explored in much greater detail than has been done thus far.

- Budget and resource relationship: While the budgets and costs appear as precise figures, the resources (typically human resources) are very difficult to quantify. Therefore, a loose relationship emerges between costs and resources for a project. Managing budgets without tight correlation to resources can skew the entire project.

- Scope creep: This is a challenge even after formal requirements have been captured and documented. Slowly increasing scope, or changing scope, can easily derail a project—mainly because the effect of scope creep is not linear. A small increase in the required functionality can result in affect the plans for its data conversion, integration, and testing. This, in turn, results in time and budget overruns. While the well-intentioned demand for a new functionality has to be accommodated (and is done so quite well in an Agile approach), extreme care is required in modeling, discussing, and agreeing on the changes and the corresponding effect till the end of the development life cycle.

- Technology creep: This can be an interesting and challenging factor that emanates from the availability of newer technologies than the ones used at the start of the project. While the scope creep appears from the business user's side, the technology creep can appear from the developer's side in a project. As the original technology with which project estimates were made is superseded, this creep factor can throw the entire project estimate off balance. The time, resources, and deliverables based on a new development environment, test tools, and deployment can be dramatically different. The need to incorporate the newer technology or its newer version may be justified; but it is important to model or prototype the change as well as reevaluate the project plans and cost benefits in the context of the new technologies.

- Soft issues: These are the people issues that invariably exist in a software project. Morale and motivation, and leadership and facilitation—these issues provide a major challenge to a software project mainly because they are very difficult to quantify. For example, interactions among team members, personal motivation and goals, and changing personal circumstances—all of these impact a project, but most of them remain hidden underneath the facade of a person. Project managers are not trained in handling these soft issues and yet their impact is substantial. The role of a developer and a project manager is quite blurred in an Agile approach. The two roles are distinct in practice. This leads to a mismatch between the expectations of a product owner and the development team. Developers may not necessarily be managers, and vice versa—leading to further challenges in terms of soft factors.

- Inaccurate estimates: A vital challenge in software projects is the need to make estimates for the project to be sanctioned. And these estimates are to be made at an early stage, with minimal information about the project. Use of previous projects data (metrics) and experience in the domain can help alleviate part of this challenge.

- Tracking slippages: While time slippage is an inevitable part of a software project (due to some of the issues above), a crucial aspect of project management is to incorporate those slippages back into the project plans as soon as possible. This "feedback" of slippages and missed deliverables requires a detailed project plan to start with, and the ability of project managers to incorporate the changes quickly. Similar to the scope and technology creep factors, the slippages in time, budgets, and deliverables are also not linear; every delay in the delivery of a module can have multiple ramifications on other deliverables, people, and user expectations of the rest of the project.

- Version control and release: There is a significant amount of unpredictability in terms of version releases, especially in large and complex systems made up of multiple packages. Lack of sophistication of version control during development, testing, and operation can all add to the challenges in software projects.

In addition to the general challenges in typical software projects, there are some specific issues that appear in Agile approaches in those projects. While Agile projects subscribe to the Agile Manifesto and have some excellent principles and practices to guide them, these pure Agile approaches also have corresponding challenges. Some Agile-specific issues and challenges are as follows:

- The priority is to satisfy the customer. While this can be achieved through early and continuous delivery of valuable software, there are many practical situations that prevent early delivery of a working code. For example, there may be requirement dependencies that cannot be easily elicited through user stories; without due consideration to these dependencies, a working code may not be easily delivered to the customer's satisfaction.

- Capitalize on changes to the customer's advantage. This is achieved by welcoming late, changing requirements. Yet such changes impact the budget and business operations. Third-party software development may only occur when requirements are fixed and any change needs to be subjected to stringent change-control requests. Handling of multiple parties involved in a project requires legal contracts and controlled changes that are not easy to implement in Agile projects.

- The need to demonstrate and deliver working software every couple of weeks to a month has always been the desire of developers from the beginning of computing. Prototypes and mock-ups have been used in the past; and even today, these are standard tools for customer engagement, requirements gathering, and expectation management. Agile approaches thrive on developing and extending prototypes to full-scale products. Yet, at times, a continuously working software may not be feasible because of factors such as technical dependencies or changing requirement

- Developers and business stakeholders must work together in a collaborative style on a daily basis throughout an Agile project. This collaborative working style exposes business experts to the product development cycle (Thomsett, 2009). This may not always be convenient or logistically possible as the key business stakeholders are also focusing their attention on running the business. Agile development scenarios in which the whole team is co-located is inevitably more efficient in its communication than the other extreme, in which team members are distributed all around the globe (Dooley, 2009a). The logistics of getting the team together not only across geographical boundaries but also across those of cultures, language, time zones, and value systems heavily impact Agile project communications. Motivated and self-aligned individuals are the key to a project's success, irrespective of the methodology being used. Should it then be really a privilege of Agile only? The nonavailability of such individuals was one of the root causes for large and complex projects to follow formal, planned, and mature software development life cycles (SDLCs) in the first place.

- Practicality of face-to-face conversation needs to be considered. While a face-to-face conversation is indeed the most effective method of conveying information, its practicality is always question. For example, in some instances, such as while dealing with offshore projects or third-party services development, this conversation is not possible. In other situations, even if such conversation is made possible, it is not binding. For example, a verbal agreement between the user and a developer in terms of a field positioning is quite acceptable in an Agile project; but if that field position has compliance requirements associated with it, then it has to be documented formally.

- A working software may not always be the primary measure of progress. There are numerous and vital activities that need to take place in real-life projects that do not necessarily produce a working software, for example, work on modeling requirements with use cases. Another example is the creation of detailed architectural diagrams that do not directly produce a working software. Yet, these (and similar) activities are vital for the project. Focus on sustainable development is important but indexing it to a working software can be a challenge in itself.

- Team commitment, especially as part of Agile planning, can be highly subjective. Extracting team commitment to developing a certain number of stories can defeat the basis of the Agile Manifesto. Yet, without some indication of the development effort, the rest of the planning within and around the project can suffer.

- Self-organized teams cannot always be "designed." Good self-organized teams have to "happen" on the basis of establishment of working relationships, trust, and common understanding. Such "happening" of a self-organized team is an absolutely crucial element to the success of an Agile project. Large and complex projects do not have the privilege (in terms of time as well as quality of personnel) to enable the "happening" of a self-organized team.

- According to the Agile Manifesto, "Responding to change over following a plan," is important. Therefore, locking a development effort to a plan is against the Agile value. Yet, how many projects in real life can progress without a firm baseline that is indeed lockedin? In practice, even pure Agile projects need a certain amount of commitment and planning before the development begins—albeit it is not fully documented as done in planned projects.

- Setting a goal in a sprint (specific to the Scrum method) is an important aspect of that sprint. Yet, this goal can be based on a subjective understanding of the team in terms of what the user wants. There is usually a need for explicitly stating the goals as is done in planned methods. For example, the stories within a sprint are geared toward a goal. However, during the actual sprint, new ideas and values may be discovered that would change the goal. Does the team have the liberty to change these goals? In practice, the team may not have the privilege to change the goals—especially if the project is an outsourced development where contracts for delivery of software have been signed.

- Planning in Agile projects (especially Scrum) can be based on project velocity. This project velocity is the number of stories a team can actually deliver ("done") per sprint with normal speed. There is no commitment in ascertaining the project velocity and, therefore, there is a constant struggle between the Agile and planned elements within a large project.

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

"Big Agile" and "little agile"


There are two types of Agile, "Big Agile" and "little agile." Big Agile is the philosophy; the business theory and perspective of how we want to work with others that supports why we would make this process change. If you truly intend to alter the way you think about why you do projects and how you do them, you cannot merely buy a toolkit, stick up a few Agile posters, or pay for an Agile course, and then automatically have an Agile team. What makes the things you do truly Agile is the way you do things and the reasons you have for doing them that way. In other words, you cannot "do" Agile, you have to "be" Agile.

Calling Agile "Big" and "little" is in no way related to relative value or success when used within a project. It is taken from the image that a large umbrella encompasses the philosophy and principles of Big Agile, which are more general and less decomposed into tools and techniques. Little agile refers to various approaches that are more specific to certain types of projects and industries, but which are still formed to fit under the big, overriding ideas.
So, Big Agile is the philosophy. Since Agile is intended to be modified and customized for each industry, organization, and small team need, we will never see a time where all the processes are the same and we can memorize them in clear steps, like we do now when studying for the PMP exam.

The group of practices that we call "little agile," on the other hand, do embrace a specific methodology to improve the success and quality of project outputs. These are the tools, techniques, and activities that people use to implement the big ideas. They are sometimes also referred to as "productized" processes. There are books written about the specific practices and the cyclical steps to take, for-profit classes that prepare you for certifications and carefully differentiated roles, and websites, associations, blogs, and webinars dedicated to this particular brand of little agile. The little agile process has become a product in and of itself.

Productized process sets are most frequently found in both software development and web development areas, although there are also specific techniques that have been adopted and customized through experience for manufacturing, as well as other more product-oriented industries. These approaches still provide for increased team flexibility, but within a standardized, repeatable set of guidelines that are driven under the hood by the Big Agile philosophy. Remember, despite the customization, the intent is that what you do on a daily basis is not as important as the changes in your thinking that drive the why of what you are doing.

With little agile, it is important to follow all of the steps, for example, the steps of a Scrum software development process. Picking and choosing only a part of the Scrum plan will negate the outstanding value that organizations using Scrum are gaining.

For now, let's discuss and understand the Big Agile concepts. Later, there is an overview of some of the little agile tools and practices you might encounter like SCRUM, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) which is especially popular in Europe, Lean Manufacturing, Kanban, Crystal, TPS, Lean Software Development, Rational Unified Process (RUP), and Feature Driven Development (FDD), where there is great value to doing specific things in a cyclical order.

Since our goal is to find ways to integrate the best of the attitude shifts of Agile in our non-IT type projects, we will focus on the ideas that are encompassed in Big Agile, and then look at what we can borrow from the little agile skill sets to enhance our own projects.

So, when we talk about Agile, think about synonyms like "more flexible," "adjustable," "adaptable," "changeable", "quick", and "resourceful." The word Agile should evoke the image of an easily alterable process in which teams can quickly respond to change. They are able to adjust to changes in the project requirements, business environment, or regulatory changes, whether in the organization or in a merger environment. Today's teams need to provide fast responses to shifts, whether in customer fads or unexpected stock market adjustments.

When asked about the benefits of implementing Agile in a State of Agile Survey from Version One (2011), 84% of respondents said the number one advantage was the ability to manage changing priorities. The next most highly ranked value was in improved project visibility (77%), followed by 75% of those surveyed who found increased productivity was important to them. Improved team morale was reported by 72% of the respondents, while 71% said they saw a faster time to market as a result of changing to Agile. And, 68% found it gave them a better alignment between the project and its business objectives.1 Granted, these were software development implementations, but if these positive and enviable changes were found in this area of the organization, there have to be similar benefits in some amount for non-IT projects, too.

Project managers are chasing a shifting target due to constant changes in today's business environment. If any of you are hunters, servicemen or women, archers, or even if you only have the Paper Toss app on your iPhone where you try to toss a wadded up paper into a wastebasket, you know about trajectories. If you are trying to hit a moving target, whether with a bullet, an arrow, or a wadded up piece of electronic paper, you cannot aim straight in front of you where the target is now. You must adjust for the wind, and the speed of the target if it is moving, and aim your throw ahead to where it will be in the future.

Our job today is to point ourselves and our projects toward where we need to be in the future in order to hit the business targets. Not only do we have to change where we are headed, we have to lead the change. One change, most definitely, is toward a more flexible process to manage projects. We need to embrace the Agile philosophy and principles regardless of the department in the company where we lead projects.

Taken from : Agile Practices for Waterfall Projects: Shifting Processes for Competitive Advantage

Subscribe to Computing Tech

Enter your email address:

Delivered by FeedBurner

Alltop, all the top stories
All Malaysian Bloggers Project
Add to Technorati Favorites Top Blogs
Computer Blogs - BlogCatalog Blog Directory blogarama - the blog directory Top Computers blogs Software TopOfBlogs Information Technology, SEO Technology