Application of Agile
Abstract
This article decomposes Agile in order to make it clear what the prerequisites and gains from the use of Agile, and its different parts in a business. The Agile movement is all over and spreading widely and far from its origin in the software and IT sector, and its positive effects are reported extensively, there seems to be no stopping for agile. But originating from a software industry desiring to be more flexible, not every aspect of Agile is easy applicable in every business in various sectors eg. the construction sector has a whole different nature than the IT-development sector. Agile in its full form is covering various aspects as; way of structuring work, culture, management style etc. And while the use of iterative sprint increments can be opposed to the waterfall method, other parts as the management style is not opposed to the waterfall model. In this article Agile is decomposed into smaller parts by the use of the 12 principles of Agile. All of these parts of Agile is described in application, limits, gains and necessary setting for this to be applicable eg. limits due to the constraints of physicality. Lastly an overview model is presented highlighting the different aspects of Agile and their overlaps.This Article seeks to allow a business owners/consultants to analyze if Agile(or parts of Agile) is applicable to a business and rather throughout describe how to apply it.
Introduction
Gains from using Agile
Though originating from the software industry, in software development a success rate 28% bigger compared to projects based on a waterfall approach. This could be specified as The Agile Project Management framework vs Waterfall method, instead of saying just Agile. Besides the success in Software Agile has spread far from this sector. Respondents to the yearly “State of Agile” report using Agile is from sectors as; Technology, Finans, Healthcare and onto Industrial/manufacturing[S: version One]. In the “State of Agile” report, 61% of respondents from different industries, though mainly software, reports that “all” or “most” of their projects are successful.
The advantages of Agile is reported to be extensive [scmidt 66,] even in physical products. Some of the reported main advantages in physical product is “Increased transparency”, “increased internal learning”, “improved costumer understanding” but also onto very different parameters as “Shortened product development (Time-to-market)” and “Reduced risk for the product (eg. Technical feasibility, project failure)[Source]. Note that these statements are from applying Agile to physical products.
In 2001 the present understanding of Agile originated with the Agile Manifest posted by 17 authors behind the Agile Alliance. Prior to this several other understandings and contributions to Agile was presented, which can all be found at the https://www.agilealliance.org/agile101/practices-timeline/. The present understanding, which this article is based on, was presented though the Agile Manifest. The Manifest describes the fundamentals of Agile, in very broad formulations. Further detailed is this in the 12 principles based on the manifest outlining these a bit more. This version on Agile originated from the software industry that wanted more flexibility and felt limited by the classical way of managing projects. Originating from these values are many ways of practicing agile. How to practically do Agile, will not be covered in this article, but it can serve as a great start to introduction to overall concept.
In order to practice Agile, many framework is usable, famous ones to be mentioned could be; Scrum, Kanban, XP, ect. These all proved tools and practical ways of applying the principles of Agile. Some frameworks focus more on some parts of Agile some applying all and yet some only applying fewer.
There are many understandings of being Agile, practicing Agile or doing Agile. It is here noted that it is very possible to integrate some parts of Agile without the others. Also it is noted that one should be very carful then describing how practicing Agile or stating to be Agile, this can be interpreted on many ways by the receiver. Eg. Agile is often stated to be the opposite of the waterfall method[SOURSE], while The Agile Project management Framework (Agile Project management Life Cycle) can be opposed by this, it would be misleading to compare Agile as a whole to this.
Decomposing Agile into components
in 2001 the Agile manifest was posted online, having the following form, still available at AglimeManifest.org.
These four values is the baseline defining for all of the content labeled as Agile. Based on these are the 12 principles of agile [SOURCE AGILE MANIFEST]. These are outlining the four values from the manifest in more detail and taking the values closer to real life situations. Some are even quite practical and straight forward to understand in implementation. In the implementation of several of the principles, the Agile Project Management Framework is used[source: APM QG], originalle proposed by Jim Highsmidt [Creating Inno Prod, Jim].
This Framework as seen in FIGUR has an iterative nature, and Agile in general is often described as incremental as of this. This framework has 5 phases; Envision, speculate, explore, adapt and close. These corresponds to the 5 phases of the Waterfall method [SOURCE]; Initiating, planning, Executing, Controlling and Closing. The framework relies on the use of sprints that is smaller time intervals focusing on building a specific feature of the end product. Ideally each sprint should result in a part of the end product, the feature that can be delivered, tested and create value for the costumer[S: Jim, cre inno Prop].
In the many comparison of the Agile project management framework to the Waterfall approach, Agile is equalized to be the APM Framework. However, as the following will reveal, this Framework is not a part of several of the Agile principles. As the use of “being Agile”, “Working Agile” “Doing Agile” etc. is free to use for anybody, it is not clearly defined how many of the values or principles that have to be fulfilled. A business utilizing all of the principles not needing the incremental iterative approach might label itself as Agile, though other businesses may not share that view. In order to quicker analyze and provide more overview, these are analyzed in 3 different categories where they are found to have the biggest impact. These three categories is sole created for the purpose of this overview. The three categories is as follows; Management and organization, Mindset and Manner.
Management and organization
Principle no. 4 “Business people and developers must work together daily throughout the project”
The foundation of any project, is a business case[PRINCE2]. To ensure, that the business case stays in line with developed product Agile suggests the responsible people working alongside. Though there might be different practical structures in different industries and businesses, this principle is applicable everywhere there is both developers and business people.
Principle no. 5 “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”
Though this principle might be quite self-explanatory in its nature, the implementation can be quite difficult. The main thing needed to check of this principle, is motivated people. If the management success in hiring the motived people, then they can then do the rest.
Principle no. 11 “The best architectures, requirements and design emerge from self-organizing teams.”
Practically: Organize a team of individuals who are able to in collaboration make their own decisions and paths. Wanted results: Empowerment of the team with more ownership of the projects Needed Environment: A team of individuals organized in a manner allowing them to organize themselves.
Team structure, like joseph said “everybody want to find the best people” I remember something from the “quick intro” about the role of a manage to fertilize team performance.
ABOUT SOURCES: Theory: APM Quick start 45% + 43% cases: Musk maybe
Principle no. 8 “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”
Practically: Do not stress. Wanted results: Not to stress out people Needed environment: an project manager/leader/whatever
ABOUT SOURCES: Theory: APM QG 44%
Principle no. 12 “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Practically: could be organized and under management, could be just in the culture and under Mindset. Wanted results: Learnings -> better future results Needed environment Any.
ABOUT SOURCES: Therory: APM QC 50%
Mindset – the mindset in the organization
Principle no. 9 “Continuous attention to technical excellence and good design enhances agility”
Practically: As with mindset Is all over in every doing Wanted results: Better quality and design Needed Environment: The right culture in the firm About Sources: Thery: SOMETHING ON CULTURE - Laura cases:
Principle no. 10 “Simplicity, the art of maximizing the amount of work not done, is essential”
Practically: As with mindset it is all over in every doing Wanted results: overall effectiveness Needed environment The right culture in the firm About Sources: Thery: SOMETHING ON CULTURE - Laura cases:
Principle no. 6 “The most efficient method of conveying information is face-to-face conversations”
Practically: Make sure people talk to each other face-face. Will require the right organizational set up ass well as culture. Wanted results: More effective communication. Needed environment: Same physical location. About sources: Theory: Not much needed.
Principle no. 2”Welcome change, even late in development. Agile processes harness change for the costumers competitive advantage”
Practically: In Agile working with “speculating” instead of “planning” means in practice to not try to plan more, than you are actually able to plan. Often also related to sprints. Wanted outcome: To not make useless plans which are not followed, and allow costumers to figure out their wants along the way, as costumers often does not realize their full wants from the very beginning. Environment needed In theory, no particular environment. But depending on the case/sector/industry there might be big differences in whether it is affordable. Also it will depend on which degree the costumer will be able to foresee his/hers needs. ABOUT SOURCES: Theory:
Manner – in which manner is the job done
Principle no. 1 “Our highest priority is to satisfy the costumer through early and continuous delivery of valuable software(product)”
Practically: This relates to the organization of the work in sprints, refer to sprints. Wanted results: Satisfying costumer by constant delivery and a constant check if the companies and costumers expectations are aligned. Needed environment: A WBS that allows continuously delivery of value. Eg. The foundation for a building is not much worth, without the building on top. WBS packages or sprint features that allows testing somehow. Constranits of physicality. Though this might be difficult to apply in the most direct form, it might be worth a consideration to still, as often recommended, have a strong costumer involvements.
Principle no. 3 “Delivering working software(Product) frequently, from a couple of weeks to a couple of months, with a preference to shorter timescale”
Practically: Short sprints/small WBS Wanted results: Same as previously just with the focus that it is constantly Needed environment Same as above, just with focus on small WBS packages or short sprint
Principle no. 7 “Working software(product) is the primary measure of progress”
Practically: Measuring by deliverables delived Wanted result: Keeping focus on delivering and not everything els, eg. Planning Needed environment: In theory; non. But makes the best sense if it is steadily growing in delivering software/product. Eg. Measuring deliver among of building or what ever does not give a fulfilling picture of the process.
Overview of the parts of Agile
More stuff goes here
