Agile For Project Management An Introduction
Fri 19 Aug 2016 10:41
Agile For Project Management – An Introduction
In the recent times, as technical advancements keep being introduced by leaps and bounds – and on a consistent basis - rendering quality into a product today may or may not require great skills. However, designing and developing a product in a pre-defined timeframe and ensuring that it adheres to stringent quality standards may indeed prove to be a difficult task for most manufacturers. With pressing end user requirements, increasing levels of market competitions, and the need to keep working overheads low, it has become increasingly important for organisations to change traditional working processes and introduce new ones which can enhance business models and help to deliver business value more often, and in a more reliable manner.
While talking about changes, Agile tops the list of project management methodologies that support “change”. Agile was conceptualised because there was a need to find a better way of managing project such that they could be developed in less time and in a more efficient way. Perhaps the most important thought put behind the conception of Agile was to introduce empiricism into project management – something that was not done before prior to 2001 when Agile took birth in a ski resort, in the Wasatch mountains of Utah. Agile focuses upon making decisions based upon “what is” rather than “what is proposed” i.e. what best can be done with what we have currently with us. And another aspect that Agile focuses upon is to start work with very little or unclear set or requirements – you can keep on building and improving your product over time as more information is available from the client and end users. This can be a great asset to organisations as you don’t have to wait for comprehensive paperwork and documentation to get started with Agile. Moreover, you can start with an idea and keep on building it, but you need to develop it in a manner such that whatever you produce is useful and has a certain business value attached to it. So how does Agile do this? How does it work? It’s interesting to know how Agile can be effectively used to control projects that are big or small, whether they are simple or complex in nature, and if they have to be executed for a few months or for years at a stretch.
What is Agile?
Agile is a framework that focuses upon early product deliver. The products could be any - physical products, processes, software, or even running an activity or an operation. It can be understood as a set of methods and practices, stated in a manifesto, which act as guidelines, and teams have to follow those methods and practises in a proper manner to deliver the goal and objectives to somebody - usually the client. In Agile, solutions are obtained by self-organizing teams which collaborate, discuss, and constantly strive to improve their working process and become more effective in what they do. Another feature of Agile is that the teams are cross-functional i.e. each team member is skilled in more than one core activity that he or she specialises in. The teams can start working even if very little information is available regarding the product to be developed. In Agile, the entire product is not delivered to the client "at one go". Rather, the product is developed in stages. After each stage is completed, the client is invited to verify that the development delivered by the team fulfils what he or she had anticipated at the time of project inception. Valuable product features are delivered by the team to the client regularly, on a consistent basis through product incremental cycles known as sprints. The sprints keep on functioning until sufficient product features are successfully developed, tested, and shipped to the client.
The unique aspect about Agile is that it focuses primarily upon the delivery of business value to the client. Agile emphasises more upon how much a particular product feature is worth to the client in terms of its financial worth in the market. Important features should be developed first, followed by less important ones. When sufficient product features are developed and successfully tested, they are integrated to form a minimal viable product or an "MVP" which demonstrates the usefulness of the product and how it is likely to fare in the market. The objective of developing an MVP is to get enough inputs from the process so the management and the technical teams can decide the projects actual worth in the market, how difficult it is going to be to develop a "sellable" version having enough features so end users can use it to their benefit, how long it is likely to take, and how much capital is needed to sustain the product development process over the months.
Instead of developing the entire product and releasing it in the market after a prolonged duration, Agile concentrates upon releasing several versions of the product at regular intervals of time. Each “release” is sellable, therefore, the client can start recovering the capital invested in the project very early as compared to traditional project management methods. There are many advantages of Agile processes:
Early recovery of capital
In case of traditional models, one has to wait for the entire product to be completed before it can be shipped. The investors can subsequently start earning from the project. This can take a lot of time – often months. The investors cannot recover a single cent from the project in the meantime. In Agile, a release can be availed in as soon as a couple of months since the client can go ahead with a version with limited product features and launch it in the market. It is true that the financial worth of such a release might not be substantial, but, nonetheless it can help the client to start recovering some of the capital pumped into the project development activity. Therefore, the investors benefit from a steady trickle of cash flow till the full-fledged release is developed in the near future that can help them to earn bigger profits.
Planned profit generation
There is a certain risk involved with almost all traditional project management systems. The success levels of the product cannot be determined unless and until it is developed fully and launched in the market. As the development process takes a lot of time, there could be instances of market conditions changing in the meantime. The investors may well face a scenario wherein the conditions may have changed drastically and a competitor might have already launched a similar product. If such were the case, the bulk of the market share may be captured by competing products and investors may fail to churn out significant profits from the product. This does not necessarily happen with Agile. Several releases can be planned over the months, with each release offering a more advanced set of product features. Managements can design a well-planned sales strategy catering to each release and target specific customers to fulfil the sales goal for each release. This also helps to mitigate several types of risk factors generally associated with large scale projects.
High product quality
One of the biggest advantages of Agile is that the testing and QA activities are done on a consistent basis after each feature is developed in a sprint. A feature can be considered as shippable only after it is tested by the QA team members and approved by the product owner. In addition, the client too reviews the features and may reject their development if he or she feels it does not fulfil the product vision. Agile processes offer quick feedback regarding the product quality. This is because all Agile frameworks are uniquely conceptualised to define and deliver the business value contained in the project.
Proper risk management
Risks are an inherent part of any project, and project management models should try to minimise their occurrence if they are to be effective. Risks keep on multiplying if they are not identified in time, and they can also lead directly-indirectly to technical debt. The basic advantage of Agile is that you don’t work with the entire product at any given instance of time – you engage with a certain feature, or a set of features, and develop it during the sprint. It is easy to test for and identify risks when individual features are checked for their reliability and this is what Agile proposes to do. Agile teams are cross-functional i.e. a developer or a programmer may double as a QA tester, while, certain teams may include professional testers who carry out unit tests, manual tests, Selenium tests, and even use automated testing software to check for redundancies and bugs in the software code. Regression is checked for at the time of feature development, and if a particular feature fails to perform as per the acceptance criteria stated in the QA conditions of the feature, the said feature is rejected at the time of review and transferred back to the backlog for redevelopment. Another positive aspect about Agile is that its principles categorically state to avoid rework which can leads to waste, or money and efforts spent over activity that consumes time and does not produce any positive results.
Responding to changes and market conditions
Project development takes time. Large projects may take months before they can be deployed in the market. Considering the dynamically changing market trends, it is quite possible that some product features may become outdated by the time the project is launched. This is a typical scenario in case of projects using traditional “staged” project management methods in which product features or their scope cannot be changed once finalised. Waterfall methods are irreversible, therefore, it becomes very difficult to incorporate changes in the product design once the documentation is done. this limitation is removed since the framework is specifically envisioned to respond dynamically to changes occurring in the product design induced due to changing market trends. The main advantage you have is you develop a small part of the project at a time in incremental cycles known as sprints. If a product feature is developed and it is later realised that it does not totally fulfil end-user requirements, or if the requirements have changed over time, using Agile it is possible to update the particular feature by taking it up in a sprint and redeveloping it as per new requirements and acceptance criterions.
Increased client satisfaction levels
Client satisfaction depends primarily upon how much he/she gains from the project, and in terms of project development, how a project will fare in the market and earn high ROIs. Apart from the financial aspect, another factor which contributes towards increased client satisfaction levels is up to what extent the management or the client feels happy with the development activity. Often clients have product visions which teams fulfil partially or fail to satisfy. A primary reason why this happens is the client fails to convey a proper vision to the team, or the team fails to understand it properly. The teams may offer productivity which the client does not actually desire but realise the fact only when the project is deployed. This is because traditional management methods do not encourage client participation to a great extent. In Agile, each product feature can be considered as “Done” only when it is approved by the client. The client is very closely involved in the product review activities, and the team may have to do rework on a particular feature if the client is not satisfied with a particular feature development. The client feels very much in control because he or she is closely involved with the project and remains updated regarding recent developments.
Long term project sustenance
Market trends indicate end users having specific requirements are not ready to compromise upon, or wait for indefinite periods of time to fulfil their work related needs, primarily because they have other options available in terms of newly emerging brands and start-up ventures. Competition is rising, and will continue to do so in the near future as new development technologies keep on being introduced in the market. Vendors don’t have many choices but to develop products that focus totally upon end user requirements and satisfy them. This means whatever products they develop have to include a plethora of features and offer them at competitive rates to beat the competition. This also means development will take time and projects will extend over months before a MVP is developed, tested, and modified to produce a saleable version. It is easy to scale Agile by adding or removing team members depending upon the project complexity and product related requirements. Managements can control the production costs by investing or scaling down development resources since the development activity is carried out in sprints in Agile framework, and Agile supports such changes. You can speed up the release date, as per needs, or postpone it to a later date if new features are to be added in the production plan. It is very difficult to do this using Waterfall methods since the scope of the project is predefined and resources cannot be scaled up or down. Moreover, if the project is rescheduled to extend for more months, it could run out of funds and employers may not be able to support the project any longer.