Application of Agile
(→Introducing Agile) |
(→Discussion of sources) |
||
| (53 intermediate revisions by one user not shown) | |||
| Line 6: | Line 6: | ||
| − | Agile Project Management(APM) is a way of doing | + | Agile Project Management(APM) is a way of doing projects which has shown great results compared to classical ways of managing projects. Agile originates in the software industry but has proven successful in other industries as well. In the software development it has a success rate 28% bigger than projects based on a more classical project management approach<ref name=''Chaos2015''> The Standish Group International, Inc. ''Chaos report 2015 p. 7'' </ref>. |
| − | Respondents to the yearly “State of Agile” report using Agile | + | Respondents to the yearly “State of Agile” report using Agile are from sectors ranging from; Technology, Finans, Healthcare and onto Industrial/manufacturing.<ref name=''STAp6''> VersionOne'' State Of Agile 2018 p. 6'' </ref>. |
| − | + | ||
| − | 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)<ref name=''Schp66''> | + | 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)"<ref name=''Schp66''> Schmidt, T. S., Weiss, S. and Paetzold, K. (2018) ''Agile Development of Physical Products: An Emperical study about Motivations Potentials and Applicability p. 66'' </ref>. |
===Introducing Agile=== | ===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.<ref name=''AMaFe''> ''https://www.agilealliance.org/'' </ref> This version on Agile originated from the software industry that wanted more flexibility and felt limited by the classical way of managing projects.<ref name="A101"> ''https://www.agilealliance.org/agile101/'' </ref> Founded on these values there are many ways of practicing | + | 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.<ref name=''AMaFe''> ''https://www.agilealliance.org/'' </ref> This version on Agile originated from the software industry that wanted more flexibility and felt limited by the classical way of managing projects.<ref name="A101"> ''https://www.agilealliance.org/agile101/'' </ref> Founded on these values there are many ways of practicing Agile. |
| − | How to practically do Agile, will not be covered in this article, but it can serve as | + | How to practically do Agile, will not be covered in this article, but it can serve as an introduction to the overall concept - the fundamentals needed in order to maintain overview when choosing framework later on. An overview that can also be helpful to readers already familiar with Agile. |
[[File:ManifestPrinciples2.jpg|center|900px]] | [[File:ManifestPrinciples2.jpg|center|900px]] | ||
| − | ''Figure 1: Agile Manifest and the 12 principles'' | + | ''Figure 1: Agile Manifest and the 12 principles. This figure has content found at https://www.agilealliance.org/'' |
The Agile manifest is the absolute core of APM, with its four values and their counterpart in classical project management prioritized as the authors phrase it "while there is value in the items on | The Agile manifest is the absolute core of APM, with its four values and their counterpart in classical project management prioritized as the authors phrase it "while there is value in the items on | ||
| − | the right, we value the items on the left more". From the 4 values the 12 principles of Agile | + | the right(Bottom in figure 1 left) , we value the items on the left(Top in figure 1 left) more". From the 4 values the 12 principles of Agile are created, outlining a bit more how to do Agile<ref name="A101" />. The principles cover the same, only the detail level and concreteness differs, the main part of this article will take its offspring in the 12 principles. |
| − | Further detailed than the principles is found in the frameworks used to practice Agile, famous | + | Further detailed than the principles is found in the frameworks used to practice Agile, famous examples being; Scrum, Kanban, XP, ect. These all provide tools and practical ways of applying the principles of Agile. These frameworks have different focuses within Agile and will be appropriate in different sectors and businesses within these industries. The different frameworks of Agile might differ a lot from the values and principles on some points, though being somehow based on these. |
| − | Agile is not just the these famous frameworks but a whole umbrella of different ideas based on the same values<ref name="A101" /> . Nor is there a simple formula and easy steps, that will ensure success, Agile | + | Agile is not just the these famous frameworks but a whole umbrella of different ideas based on the same values<ref name="A101" /> . Nor is there a simple formula and easy steps, that will ensure success, Agile needs to be fitted to the specific case.<ref name=''CIPp12-13''> Jim Highsmith'' Creating Innovative Products p.12-13'' </ref> |
[[file:VPFT.png|center |600px]] | [[file:VPFT.png|center |600px]] | ||
| − | ''Figure 2: Value, principles, frameworks and tools model.'' | + | ''Figure 2: Value, principles, frameworks and tools model, no specific inspirational sources are used for this figure.'' |
| − | 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 | + | 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 careful then describing how one is practicing Agile or stating to be Agile, as this can be interpreted in many ways by the receiver. |
===Introducing the Agile Project Management Delivery Framework=== | ===Introducing the Agile Project Management Delivery Framework=== | ||
| − | In the implementation of several of the principles, the Agile Project Delivery Framework or just Agile Project Management Framework is often used<ref name=''AOPQG''> '' | + | In the implementation of several of the principles, the Agile Project Delivery Framework or just Agile Project Management Framework is often used<ref name=''AOPQG''> ClydeBankBuisness'' Agile Project Management Quickstart guide, chapter 3'' </ref>, originally proposed by Jim Highsmidt <ref name="CIPp89"> Jim Highsmith ''Creating Innovative Products p.89'' </ref> |
| − | This Framework as seen in | + | This Framework as seen in figure 3 has an iterative nature, as of this Agile in general is often described as iterative. This framework has 5 phases; Envision, speculate, explore, adapt and close. These correspond to the 5 phases of the Waterfall method <ref name=''AOPQG''> ClydeBankBuisness ''Agile Project Management Quickstart guide, chapter 2'' </ref>; Initiating, planning, Executing, Controlling and Closing. The framework relies on the use of sprints which are 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, a feature that can be delivered, tested and create value for the costumer <ref name="CIPp89"/> .Though this is often interpreted 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. This explanation serves only as background for reading the following decomposition, for information on the actual implementation and a detailed description on this framework more research is needed. |
[[file:Pladsholder.png|center|600px]] | [[file:Pladsholder.png|center|600px]] | ||
| − | ''Figure 3: APM Framework'' | + | ''Figure 3: APM Framework. This figure is inspired by the models in Jim Highsmiths "Creating Innovative Products" '' |
| − | In the many | + | In the many comparisons 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 necessarily 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 must 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== | ==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 | + | 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 analyzed in terms of practicality, 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 | + | 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 are solely created for the purpose of this overview. The three categories are as follows; Management and organization, Mindset and Manner. |
===Management and organization=== | ===Management and organization=== | ||
| − | The following Principles are placed in the category of Management and organization, as they are found to have the biggest | + | The following Principles are placed in the category of Management and organization, as they are found to have the biggest impact on that part of a business. 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. |
=====Principle no. 4 “Business people and developers must work together daily throughout the project”===== | =====Principle no. 4 “Business people and developers must work together daily throughout the project”===== | ||
| − | The foundation of any project, is a business case<ref name="Prince2proDef"> '' | + | The foundation of any project, is a business case<ref name="Prince2proDef"> ALEXOS ''PRINCE2 p.30'' </ref>. 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 as long as there are 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”===== | =====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 | + | Though this principle might be quite self-explanatory in its nature, the implementation can be quite difficult. The main thing needed to apply this principle, is motivated people. Agile believes in people over tools and process<ref name="CIPp52-53"> Jim Highsmith ''Creating Innovative Products p.52-53'' </ref>, therefore getting the right people is even more crucial than in classical project management<ref name="CIPp52-53"/>. According to Jim Highsmith, it should be prioritized over both product and process. It is needed both to find motivated people and keep them motivated, but this principle is applicable basically everywhere. |
| − | + | ||
| − | + | ||
| − | + | ||
=====Principle no. 8 “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”===== | =====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 | + | Using many of the Agile principles, can imply stress on the developers; accountability, self-organizing teams, the many sprints used at the APM Framework etc. In this the role of the project manager is to watch out for stressed out employees<ref name="APMQG"> |
| − | + | ClydeBankBuisness ''Agile Project Management Quick Guide chapter 5'' </ref>. Besides this, the process should not be stressed in general so that any of the above listed cannot maintain pace. This principle should be applicable for almost any business. | |
| − | + | ||
=====Principle no. 11 “The best architectures, requirements and design emerge from self-organizing teams.”===== | =====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 | + | 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.<ref name="CIPp52-53"> Jim Highscmidth ''Creating Innovative Products p.51-61'' </ref>. The self-organized teams manage their own schedule, workload, effectiveness, however they are not to be perceived as "self-directed" as the project manager still puts out the direction leading the team. Self-organizing teams implies relying on and insisting on; Self-discipline, accountability and trust among other and makes requirements to the behavior of the team members, which can be fertilized by the project manager. This naturally requires both the right employees and manager for this task. If e.g. 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. |
| − | + | ||
| − | + | ||
| − | + | ||
=====Principle no. 12 “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”===== | =====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 | + | 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 are that the evaluations is often and continually making it possible to apply the learnings in the rest of the project<ref name="CIPp259-261"> Jim Highsmith ''Creating Innovative Products p.259-261'' </ref>. However, it is of course also possible to evaluate on an ongoing basis without using APM Framework, e.g. a monthly team evaluation meeting. Learning is a key point in APM in order to secure growing efficiency and continuos development and adjustment of the teams. |
| − | + | ||
| − | + | ||
===Mindset – the mindset in the organization=== | ===Mindset – the mindset in the organization=== | ||
| − | The people employed, the culture and their mindset | + | The people employed, the culture and their mindset are very closely related<ref name="hof118"> Dag Ingvar Jacobsen & Jan Thorsvik ''Hvordan Organisationer fungerer p. 118'' </ref>. The line between mindset and organization is not clear and often both is needed, e.g. learning might be difficult if the management does not schedule time for the learning but equally difficult if employees have a mindset with a negative attitude towards learning<ref name="hof319"> Dag Ingvar Jacobsen & Jan Thorsvik ''Hvordan Organisationer fungerer p. 319'' </ref>. As of this many of the principles discussed under Management and Organization could be discussed in Mindset and vice versa. The principles in this section are dependent on the mindset in the organization which is a complex matter to change and create, but definitely possible to affect. Depending on the current mindset in a specific business, this will be more or less complex to affect and complexness of applying the following principles will be accordingly complex. |
=====Principle no. 9 “Continuous attention to technical excellence and good design enhances agility”===== | =====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"<ref name="CIP115"> | + | 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"<ref name="CIP115"> Jim Highsmith ''Creating Innovative Products p.115'' </ref>. With this method, bad design will show early and keep cost of changing them low. This is one way of applying this though there are many ways of doing this, but generally the objective is to keep quality low and cost of change low<ref name="CIP115" />. If prioritized and in the mindset, this is possible in almost any business. |
=====Principle no. 10 “Simplicity, the art of maximizing the amount of work not done, is essential”===== | =====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<ref name="APMQG"> | + | 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<ref name="APMQG"> ClydeBankBuisness ''Agile Project Management Quick Guide chapter 1'' </ref>. Other examples of work often done for no use, is documentation<ref name="CIP40"> Jim Highsmith ''Creating Innovative Products p.40'' </ref>. Doing less unnecessary work releases energy to do more valuable work and lowering cost. Furthermore, cutting bureaucratic tasks can have a positive effect on engineers' motivation. |
| − | Another field to implement simplicity, is in the design<ref name="CIP218"> | + | Another field to implement simplicity, is in the design<ref name="CIP218"> Jim Highsmith ''Creating Innovative Products p.218'' </ref>. 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 | + | 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 employees and managers trust each other, the less documentation needed. To obtain trust and less bureaucracy the right mindset is needed, which the management can also affect<ref name="hof116"> Dag Ingvar Jacobsen & Jan Thorsvik ''Hvordan Organisationer fungerer p. 116'' </ref>. |
=====Principle no. 6 “The most efficient method of conveying information is face-to-face conversations”===== | =====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 | + | Besides for the obvious need of being co-located in order to talk face-to-face, the employees need to actually 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”===== | =====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 | + | During the lifetime of a project the outer environment changes and the underlying 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<ref name="CIP10"> Jim Highsmith ''Creating Innovative Products p. 10'' </ref>. But costumer wants can also change as the actual product or part of it is delivered/presented. Some costumers will be better at describing their needs than others and some business better at understanding costumer needs. This interpretation can also be related to the manifest value of prioritizing "Costumer collaboration" over "Contract negotiations". |
| − | Welcoming change can also be interpreted as an attitude towards planning. Planning into | + | Welcoming change can also be interpreted as an attitude towards planning. Planning into too 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<ref name="CIP10" /> |
| − | 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<ref name="CIP70"> | + | 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<ref name="CIP70"> Jim Highsmith ''Creating Innovative Products p. 70'' </ref>. Also relevant is the cost of changes, which is always raising during the project. In some sectors, as construction, it can be extremely costly and almost impossible, whereas 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. | As of this, business should carefully consider how applicable this principle is to their case. | ||
===Manner – in which manner is the job done=== | ===Manner – in which manner is the job done=== | ||
| − | In this section the manner in which the work is executed and structured will be described. The application of these along with APM | + | In this section the manner in which the work is executed and structured will be described. The application of these along with APM Framework(Figure 3) is often beneficial. These principles are to a large extend easier fitted into software development than hardware development. |
=====Principle no. 1 “Our highest priority is to satisfy the costumer through early and continuous delivery of valuable software(product)”===== | =====Principle no. 1 “Our highest priority is to satisfy the costumer through early and continuous delivery of valuable software(product)”===== | ||
| − | Commonly this is done using the APM Framework, breaking work down into sprints delivering a valuable feature to the costumer that can be tested and validated by the costumer. In software development can be implemented in already existing products | + | Commonly this is done using the APM Framework, breaking work down into sprints delivering a valuable feature to the costumer that can be tested and validated by the costumer. In software development it can be implemented in already existing products e.g. a new update to an online game or a new feature in a mobile operating system. In some industries, this is just not possible e.g. the medical industry<ref name="CIP29"> Jim Highsmith ''Creating Innovative Products p. 29'' </ref>. |
| − | However, in some cases prototypes, simulations, virtual reality etc. can serve to allow testing and alignment of requirements and expectations<ref name="CIP10"> | + | However, in some cases prototypes, simulations, virtual reality etc. can serve to allow testing and alignment of requirements and expectations<ref name="CIP10"> Jim Hihscmith ''Creating Innovative Products p. 31'' </ref>. The feedback from the costumer can guide the product in the right direction, even if this is abandoning the project<ref name="CIP35-37"> Jim Highsmith ''Creating Innovative Products p. 35-37'' </ref>. Many features might not be valuable in the sense of creating actual value that can reach the end user immediately. |
| − | Delivering prototypes or simulations on an ongoing basis can still serve the purpose of satisfying costumers and giving valuable feedback. For example experiments could be made where nurses are | + | Delivering prototypes or simulations on an ongoing basis can still serve the purpose of satisfying costumers and giving valuable feedback. For example, experiments could be made where nurses are equiped with VR to test the design of a new hospital allowing them to give feedback on the design. While this will save no lives, it will provide the project with valuable feedback and satisfy the costumer by allowing them to see the actual progress in the design. |
| − | The implementation of this specific principle is very case specific. For example the construction phase of a hospital, no value is obtained for the costumer by seeing a foundation, nor does is provide any feedback. On the other hand a quick feature release on a software product might be crucial for the business case. | + | The implementation of this specific principle is very case specific. For example, the construction phase of a hospital, no value is obtained for the costumer by seeing a foundation, nor does is provide any feedback. On the other hand, a quick feature release on a software product might be crucial for the business case. |
=====Principle no. 3 “Delivering working software(Product) frequently, from a couple of weeks to a couple of months, with a preference to shorter timescale”===== | =====Principle no. 3 “Delivering working software(Product) frequently, from a couple of weeks to a couple of months, with a preference to shorter timescale”===== | ||
| − | This | + | This principle is mostly a repetition of the above, only focusing even more on the time scale, as this can be of great value. In software development releasing a version 1.1 instead of waiting until version 2.0 is done can be extremely valuable for the costumer and provide the developers with great feedback for version 2.0. |
=====Principle no. 7 “Working software(product) is the primary measure of progress”===== | =====Principle no. 7 “Working software(product) is the primary measure of progress”===== | ||
| − | To ensure focus on the product, APM prioritizing looking at the amount of software(product) delivered. By measuring only on working software, the developers | + | To ensure focus on the product, APM prioritizing looking at the amount of software(product) delivered. By measuring only on working software, the developers are fully incentivized to get the job done instead of doing any other not as valuable task. |
==Overview of the parts of Agile== | ==Overview of the parts of Agile== | ||
| − | As shown above, the applicability of Agile Project Management is both depending on the nature of the specific business and on which | + | As shown above, the applicability of Agile Project Management is both depending on the nature of the specific business and on which aspect(s) of Agile that is considered to apply. While some business will experience great value of applying a specific aspect of Agile it could be disastrous for others. Some business might be able to fit all aspects easily, while others only will be able to apply fewer. In any case, is it important to be aware of what parts of APM that is desirable for a specific business and why - and then follows how to implement it. |
| − | The categorization of the 12 principles is only guiding and created in order to analyze the principles in a structured way and providing the reader with | + | The categorization of the 12 principles is only guiding and created in order to analyze the principles in a structured way and providing the reader with an overview. The borders between these categories are overlapping as shown in the 3M model. Some aspects of certain principles will influence all areas, some two areas and some only one. Depending on the reader, the business and the interpretation of the principles the same principle could be argued to have different location in the model. This is for the reader to determinate. |
| − | Having this overview, the reader should have an offset for finding out which part of APM that is applicable to | + | Having this overview, the reader should have an offset for finding out which part of APM that is applicable to their business. However, in order to do so it is advisable to find a fitting framework and also fit this framework to the specific business. Jim Highsmith implies that hybrid frameworks of combinations of tools from different framework might very well be the best solution to some businesses. This article is to serve only as a foundation for further investigation of APM and how to implement this. |
[[File:3M.png|center|550px]] | [[File:3M.png|center|550px]] | ||
| − | ''Figure 4: 3M overview model'' | + | ''Figure 4: 3M overview model, no specific inspirational sources are used for this figure. '' |
==Discussion of sources== | ==Discussion of sources== | ||
| − | For referencing larger recognized studies are used for statistics and published books for theory. | + | For referencing larger recognized studies are used for statistics and published books for theory. Jim Highsmiths is one of the founders of the Agile Alliance and his ''Creating Innovative Products'' is an important work in Agile theory and widely used in this article. ClydeBuisneses ''Agile Project Management Quick Guide'' is used for referencing of basics about Agile. Dag Ingvar Jacobsen and Jan Thorsviks ''Hvordan organisationer fungerer''(~''How organizations work'') describes generally how organizations work but not specifically for Agile organizations specifically, the general info though is still very useful. |
Only one website is used, The Agile Alliances official website which is considered very trustworthy and stable. | Only one website is used, The Agile Alliances official website which is considered very trustworthy and stable. | ||
| Line 142: | Line 131: | ||
One Danish book is used due to availability. | One Danish book is used due to availability. | ||
| − | References | + | References are done as precisely as practically possible. |
| − | All figures are made for this article with the help from fellow student Nicoline Hvidt | + | All figures are made for this article with the help from fellow student Nicoline Hvidt. Inspirational sources are credited in the figure text if applicable. |
==References== | ==References== | ||
<references /> | <references /> | ||
Latest revision as of 08:19, 3 March 2019
[edit] 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.
[edit] Introduction
Agile Project Management(APM) is a way of doing projects which has shown great results compared to classical ways of managing projects. Agile originates in the software industry but has proven successful in other industries as well. In the software development it has a success rate 28% bigger than projects based on a more classical project management approach[1].
Respondents to the yearly “State of Agile” report using Agile are from sectors ranging from; Technology, Finans, Healthcare and onto Industrial/manufacturing.[2].
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)"[3].
[edit] 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.[4] This version on Agile originated from the software industry that wanted more flexibility and felt limited by the classical way of managing projects.[5] Founded on these values there are many ways of practicing Agile. How to practically do Agile, will not be covered in this article, but it can serve as an introduction to the overall concept - the fundamentals needed in order to maintain overview when choosing framework later on. An overview that can also be helpful to readers already familiar with Agile.
Figure 1: Agile Manifest and the 12 principles. This figure has content found at https://www.agilealliance.org/
The Agile manifest is the absolute core of APM, with its four values and their counterpart in classical project management prioritized as the authors phrase it "while there is value in the items on the right(Bottom in figure 1 left) , we value the items on the left(Top in figure 1 left) more". From the 4 values the 12 principles of Agile are created, outlining a bit more how to do Agile[5]. The principles cover the same, only the detail level and concreteness differs, the main part of this article will take its offspring in the 12 principles.
Further detailed than the principles is found in the frameworks used to practice Agile, famous examples being; Scrum, Kanban, XP, ect. These all provide tools and practical ways of applying the principles of Agile. These frameworks have different focuses within Agile and will be appropriate in different sectors and businesses within these industries. The different frameworks of Agile might differ a lot from the values and principles on some points, though being somehow based on these. Agile is not just the these famous frameworks but a whole umbrella of different ideas based on the same values[5] . Nor is there a simple formula and easy steps, that will ensure success, Agile needs to be fitted to the specific case.[6]
Figure 2: Value, principles, frameworks and tools model, no specific inspirational sources are used for this figure.
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 careful then describing how one is practicing Agile or stating to be Agile, as this can be interpreted in many ways by the receiver.
[edit] Introducing the Agile Project Management Delivery Framework
In the implementation of several of the principles, the Agile Project Delivery Framework or just Agile Project Management Framework is often used[7], originally proposed by Jim Highsmidt [8] This Framework as seen in figure 3 has an iterative nature, as of this Agile in general is often described as iterative. This framework has 5 phases; Envision, speculate, explore, adapt and close. These correspond to the 5 phases of the Waterfall method [9]; Initiating, planning, Executing, Controlling and Closing. The framework relies on the use of sprints which are 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, a feature that can be delivered, tested and create value for the costumer [8] .Though this is often interpreted 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. This explanation serves only as background for reading the following decomposition, for information on the actual implementation and a detailed description on this framework more research is needed.
Figure 3: APM Framework. This figure is inspired by the models in Jim Highsmiths "Creating Innovative Products"
In the many comparisons 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 necessarily 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 must 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.
[edit] 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 analyzed in terms of practicality, 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 are solely created for the purpose of this overview. The three categories are as follows; Management and organization, Mindset and Manner.
[edit] Management and organization
The following Principles are placed in the category of Management and organization, as they are found to have the biggest impact on that part of a business. 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.
[edit] Principle no. 4 “Business people and developers must work together daily throughout the project”
The foundation of any project, is a business case[10]. 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 as long as there are both developers and business people.
[edit] 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 apply this principle, is motivated people. Agile believes in people over tools and process[11], therefore getting the right people is even more crucial than in classical project management[11]. According to Jim Highsmith, it should be prioritized over both product and process. It is needed both to find motivated people and keep them motivated, but this principle is applicable basically everywhere.
[edit] 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, self-organizing teams, the many sprints used at the APM Framework etc. In this the role of the project manager is to watch out for stressed out employees[12]. Besides this, the process should not be stressed in general so that any of the above listed cannot maintain pace. This principle should be applicable for almost any business.
[edit] 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.[11]. The self-organized teams manage their own schedule, workload, effectiveness, however they are not to be perceived as "self-directed" as the project manager still puts out the direction leading the team. Self-organizing teams implies relying on and insisting on; Self-discipline, accountability and trust among other and makes requirements to the behavior of the team members, which can be fertilized by the project manager. This naturally requires both the right employees and manager for this task. If e.g. 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.
[edit] 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 are that the evaluations is often and continually making it possible to apply the learnings in the rest of the project[13]. However, it is of course also possible to evaluate on an ongoing basis without using APM Framework, e.g. a monthly team evaluation meeting. Learning is a key point in APM in order to secure growing efficiency and continuos development and adjustment of the teams.
[edit] Mindset – the mindset in the organization
The people employed, the culture and their mindset are very closely related[14]. The line between mindset and organization is not clear and often both is needed, e.g. learning might be difficult if the management does not schedule time for the learning but equally difficult if employees have a mindset with a negative attitude towards learning[15]. As of this many of the principles discussed under Management and Organization could be discussed in Mindset and vice versa. The principles in this section are dependent on the mindset in the organization which is a complex matter to change and create, but definitely possible to affect. Depending on the current mindset in a specific business, this will be more or less complex to affect and complexness of applying the following principles will be accordingly complex.
[edit] 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"[16]. With this method, bad design will show early and keep cost of changing them low. This is one way of applying this though there are many ways of doing this, but generally the objective is to keep quality low and cost of change low[16]. If prioritized and in the mindset, this is possible in almost any business.
[edit] 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[12]. Other examples of work often done for no use, is documentation[17]. Doing less unnecessary work releases energy to do more valuable work and lowering cost. Furthermore, cutting bureaucratic tasks can have a positive effect on engineers' motivation.
Another field to implement simplicity, is in the design[18]. 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 employees and managers trust each other, the less documentation needed. To obtain trust and less bureaucracy the right mindset is needed, which the management can also affect[19].
[edit] 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 actually go talk to each other. It needs to be in the mindset of the organization.
[edit] 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 underlying 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[20]. But costumer wants can also change as the actual product or part of it is delivered/presented. Some costumers will be better at describing their needs than others and some business better at understanding costumer needs. This interpretation can also be related to the manifest value of prioritizing "Costumer collaboration" over "Contract negotiations".
Welcoming change can also be interpreted as an attitude towards planning. Planning into too 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[20]
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[21]. Also relevant is the cost of changes, which is always raising during the project. In some sectors, as construction, it can be extremely costly and almost impossible, whereas 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.
[edit] Manner – in which manner is the job done
In this section the manner in which the work is executed and structured will be described. The application of these along with APM Framework(Figure 3) is often beneficial. These principles are to a large extend easier fitted into software development than hardware development.
[edit] Principle no. 1 “Our highest priority is to satisfy the costumer through early and continuous delivery of valuable software(product)”
Commonly this is done using the APM Framework, breaking work down into sprints delivering a valuable feature to the costumer that can be tested and validated by the costumer. In software development it can be implemented in already existing products e.g. a new update to an online game or a new feature in a mobile operating system. In some industries, this is just not possible e.g. the medical industry[22].
However, in some cases prototypes, simulations, virtual reality etc. can serve to allow testing and alignment of requirements and expectations[20]. The feedback from the costumer can guide the product in the right direction, even if this is abandoning the project[23]. Many features might not be valuable in the sense of creating actual value that can reach the end user immediately.
Delivering prototypes or simulations on an ongoing basis can still serve the purpose of satisfying costumers and giving valuable feedback. For example, experiments could be made where nurses are equiped with VR to test the design of a new hospital allowing them to give feedback on the design. While this will save no lives, it will provide the project with valuable feedback and satisfy the costumer by allowing them to see the actual progress in the design.
The implementation of this specific principle is very case specific. For example, the construction phase of a hospital, no value is obtained for the costumer by seeing a foundation, nor does is provide any feedback. On the other hand, a quick feature release on a software product might be crucial for the business case.
[edit] Principle no. 3 “Delivering working software(Product) frequently, from a couple of weeks to a couple of months, with a preference to shorter timescale”
This principle is mostly a repetition of the above, only focusing even more on the time scale, as this can be of great value. In software development releasing a version 1.1 instead of waiting until version 2.0 is done can be extremely valuable for the costumer and provide the developers with great feedback for version 2.0.
[edit] Principle no. 7 “Working software(product) is the primary measure of progress”
To ensure focus on the product, APM prioritizing looking at the amount of software(product) delivered. By measuring only on working software, the developers are fully incentivized to get the job done instead of doing any other not as valuable task.
[edit] Overview of the parts of Agile
As shown above, the applicability of Agile Project Management is both depending on the nature of the specific business and on which aspect(s) of Agile that is considered to apply. While some business will experience great value of applying a specific aspect of Agile it could be disastrous for others. Some business might be able to fit all aspects easily, while others only will be able to apply fewer. In any case, is it important to be aware of what parts of APM that is desirable for a specific business and why - and then follows how to implement it.
The categorization of the 12 principles is only guiding and created in order to analyze the principles in a structured way and providing the reader with an overview. The borders between these categories are overlapping as shown in the 3M model. Some aspects of certain principles will influence all areas, some two areas and some only one. Depending on the reader, the business and the interpretation of the principles the same principle could be argued to have different location in the model. This is for the reader to determinate.
Having this overview, the reader should have an offset for finding out which part of APM that is applicable to their business. However, in order to do so it is advisable to find a fitting framework and also fit this framework to the specific business. Jim Highsmith implies that hybrid frameworks of combinations of tools from different framework might very well be the best solution to some businesses. This article is to serve only as a foundation for further investigation of APM and how to implement this.
Figure 4: 3M overview model, no specific inspirational sources are used for this figure.
[edit] Discussion of sources
For referencing larger recognized studies are used for statistics and published books for theory. Jim Highsmiths is one of the founders of the Agile Alliance and his Creating Innovative Products is an important work in Agile theory and widely used in this article. ClydeBuisneses Agile Project Management Quick Guide is used for referencing of basics about Agile. Dag Ingvar Jacobsen and Jan Thorsviks Hvordan organisationer fungerer(~How organizations work) describes generally how organizations work but not specifically for Agile organizations specifically, the general info though is still very useful.
Only one website is used, The Agile Alliances official website which is considered very trustworthy and stable.
One Danish book is used due to availability.
References are done as precisely as practically possible.
All figures are made for this article with the help from fellow student Nicoline Hvidt. Inspirational sources are credited in the figure text if applicable.
[edit] References
- ↑ The Standish Group International, Inc. Chaos report 2015 p. 7
- ↑ VersionOne State Of Agile 2018 p. 6
- ↑ Schmidt, T. S., Weiss, S. and Paetzold, K. (2018) Agile Development of Physical Products: An Emperical study about Motivations Potentials and Applicability p. 66
- ↑ https://www.agilealliance.org/
- ↑ 5.0 5.1 5.2 https://www.agilealliance.org/agile101/
- ↑ Jim Highsmith Creating Innovative Products p.12-13
- ↑ ClydeBankBuisness Agile Project Management Quickstart guide, chapter 3
- ↑ 8.0 8.1 Jim Highsmith Creating Innovative Products p.89
- ↑ ClydeBankBuisness Agile Project Management Quickstart guide, chapter 2
- ↑ ALEXOS PRINCE2 p.30
- ↑ 11.0 11.1 11.2 Jim Highsmith Creating Innovative Products p.52-53
- ↑ 12.0 12.1 ClydeBankBuisness Agile Project Management Quick Guide chapter 5
- ↑ Jim Highsmith Creating Innovative Products p.259-261
- ↑ Dag Ingvar Jacobsen & Jan Thorsvik Hvordan Organisationer fungerer p. 118
- ↑ Dag Ingvar Jacobsen & Jan Thorsvik Hvordan Organisationer fungerer p. 319
- ↑ 16.0 16.1 Jim Highsmith Creating Innovative Products p.115
- ↑ Jim Highsmith Creating Innovative Products p.40
- ↑ Jim Highsmith Creating Innovative Products p.218
- ↑ Dag Ingvar Jacobsen & Jan Thorsvik Hvordan Organisationer fungerer p. 116
- ↑ 20.0 20.1 20.2 Jim Highsmith Creating Innovative Products p. 10
- ↑ Jim Highsmith Creating Innovative Products p. 70
- ↑ Jim Highsmith Creating Innovative Products p. 29
- ↑ Jim Highsmith Creating Innovative Products p. 35-37
