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

Agile is a way of doing project which has shown great results. Agile originates in the software industry, but has proven succesfull in other industries aswell. In the software development a success rate 28% bigger compared to projects based on a more classical project management approach.

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/manufacturingwrite .

The advantages of Agile is reported to be extensive 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). Note that these statements are from applying Agile to physical products.

Introducing Agile

In 2001 the present understanding of Agile originated with the Agile Manifest posted by 17 authors behind the Agile Alliance. The Manifest describes the fundamentals of Agile, in very broad formulations. 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, the fundamentals needed in order to maintain overview when later choosing framework.

From the 4 values the 12 principles of Agile is created, outlining a bit more how to do Agile. The principples cover the same, only the detail level and contretness differs, the main part of this article will take ins ofsrping in the 12 principles. KOMMENTER MERE PÅ FIGUREN

Further detailed than the principples is found in the Frameworkes used to practice Agile, famous ones to be mentioned could be; Scrum, Kanban, XP, ect. These all provid 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. These Framework for different sectors and industries. The different frameworks of Agile might differ a lot from the values and principples on some points, though being somehow based on these. Agile is not just the these famouse frameworks but a whole umbrella of different ideas based on the same idea . Nor is there a simple formula and easy steps, that will ensure succes

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.

Introducing the Agile Project management Delivery Framework

In the implementation of several of the principles, the Agile Project Management Framework is often used, originalle proposed by Jim Highsmidt 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 ; 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 .Though this is often interpreteted as Agile, it is noted than this is only a framework to practice Agile. As of this, projects not using this framework might also be labeled Agile.

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.

Decomposing Agile into components

The 12 principles of Agile 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 following the 12 principles of Agile will be analyized in terms of practicallity, wanted outcome and needed environment to run a project in line with each principle. When comparing to a specific business the reader will be able to see what parts of Agile is applicable to that. After having this overview and this knowledge the reader might proceed into finding a fitting framework covering the applicable parts of Agile for that specific business. 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

The following Principles are placed in the category of Management and organization, as they are found to have the biggest impart on that part of a business.

Principle no. 4 “Business people and developers must work together daily throughout the project”

The foundation of any project, is a business case. 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.

MÅSKE NOGET MED COMMUNICATION

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. Agile believes in people over tools and process, therefore getting the right people is even more crucial. According to Jim Highsmith, it should be prioritized over both product and process.

MÅSKE NOGET MED AT ALLE IKKE KAN FÅ DE BEDSTE FOLK

Principle no. 11 “The best architectures, requirements and design emerge from self-organizing teams.”

Wanting the best requirements, architectures and design is an obvious want for every project leader but though self organizing-teams might sound relaxing for the manager, he or she has a significant role in making these work.. The self-organized teams manages their own schedule, workload, effectiveness, however they are not to be precived as "self-directed" as the project manager still puts out the direction leading the team. Self organizing team Implies relying on and insisting on; Self-discipline, accountability and trust among other, which makes requirements to the behavior of the team members, which can also be fertilized by the project manager. This naturally requires both the employees, the right manager for this task is needed as well. If eg. a business employs people with a general lack of self-discipline or has very controlling project managers, this principle will be very hard to apply.

MÅSKE CASE MED MUSK

Principle no. 8 “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”

Using many of the Agile principles, can imply stress on the developers accountability from the self organizing teams, the many sprints used at the APM Framework. In this the role of the project manager is to watch out for stressed out employees. Besides this, the process schould not be stressed i general so that any of the above listed cannot maintain pace.

MÅSKE MOGET MED SPONSERS OG USERS

Principle no. 12 “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

A common way to secure learning is to evaluate team performance after a project, or if using the APM Framework after each sprint. Advantages of using APM Framework in this relation is that the evaluations is often and continually making it possible to apply the leanings i the rest of the project. However, it is of cause also possible to evaluate on an ongoing basis without using APM Framwork, eg. a monthly team evaluation meeting.

MÅSKE UNDER MINDSET, MEN FIND KILDE

General

In general this part of Agile does not have many specific needs in terms of environment, the constraint is in the management and the people employed in the organization. The people employed, the culture and their mindset is very closely related. The line between mindset and organization is not clear and often both is needed, Eg. learning might be difficult if the management does not schedule time for the learning but equally difficult if employer does not have a mindset with a negative attitude towards learning. As of this many of the principles discussed under Management and organization could be discussed in Mindset and vise versa.

Mindset – the mindset in the organization

EVT FORBINDELSE TIL OVENSTÅENDE AFSNIT

Principle no. 9 “Continuous attention to technical excellence and good design enhances agility”

As being in every detail, this principle is dependent on the mindset of the employees. One way of ensuring quality in design, is through "Ruthless Automated Testing". With this method, bad design will show early and keep cost of changing them low. This is one way of applying this though there is many ways of doing this, but generally the objective is to keep quality low and cost of change low.

Principle no. 10 “Simplicity, the art of maximizing the amount of work not done, is essential”

One of the offspring for the creation of Agile, was the idea to not make plans into a level of detail that could not be followed anyway - work done for no use.[APMQG intro] Other examples of work often done for no use, is documentation. Doing less unnecessary work relies energy to do more valuable work and lowering cost. Furthermore cutting bureaucratic task can have a positive effect on engineers motivation.

Another field to implement simplicity, is in the design. In this the main aim is to design for what is known and not what is expected, in order to not make wasted work.

Minimizing work not done, can be done in every organization - the more unnecessary work done, the greater potential for not doing it. In order to do so the right mindset is needed in the organization, but also the support and trust from the management. The more the empolyees and managers trust each other, the less documentation needed. To obtain trust and less beucraty the right mindset is needed, which the management can also affect.

Principle no. 6 “The most efficient method of conveying information is face-to-face conversations”

Besides for the obvious need of being co-located in order to talk face-to-face, the employees need to acturally go talk to each other. It needs to be in the mindset of the organization.

Principle no. 2”Welcome change, even late in development. Agile processes harness change for the costumers competitive advantage”

During the lifetime of a project the outer environment changes and the underling business case can be affected by this, or even create a new business case. Allowing customers to introduce accordingly changes or new features will allow them a competitive advantage. But costumer wants can also change as the actual product or part of it is delivered/presented. Some costumer will be better at describing their needs than others and some business better at understanding costumer needs. This interpretation can be related to the value prioritizing "Costumer collaboration" over "Contract negotiations".

Welcoming change can also be interpreted as an attitude towards planning. Planning into to much detail, can be useless as circumstances change and nobody is able to predict the future. Instead, a less detailed plan can be made knowing that there will be changes to that plan, enabling the plan to fit the new circumstances

In this relation, the nature of the project can be very determining. The less predictable the project is, the lower level of detail can be predicted and the organization will take advantage of welcoming change to the plan. Sticking to a plan that does no longer make sense can be very costly. Also relevant is the cost of changes, which is always raising during the project. In some sectors, as construction, can be extremely costly and almost impossible, where as software does not have the same constraints of physicality. A fundamental software structure might be costly to change, but a changing a huge concrete foundation is almost impossible to change.

As of this, business should carefully consider how applicable this principle is to their case.

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