MANAGING ICT DEVELOPMENT:

Introduction to Agile, Hybrid and Waterfall

methodologies

Success is a Choice

2 © 2019 Midagon Oy

CONTENT

BACKGROUND AND PURPOSE 3

INTRODUCTION: FRAMEWORKS FOR MANAGING ICT DEVELOPMENT 4

The cyclical nature of management 4

Traditional components of managing development 4

DESCRIPTION OF THE METHODOLOGIES 5

Project 5

Brief history of the Waterfall 6

Waterfall project 7

V-model of quality assurance 8

Gate models 9

Continuous improvement 10

Brief history of evolutionary development 11

Agile development 11

Continuous delivery 14

Scaled agile development 15

Hybrid project 15

Program 17

COMPARISON OF THE METHODOLOGIES 18

Essential difference – Batch size 18

Differences related to project management components 19

Support for closed loop management 20

Decision-making style 21

Realization of business benefits 21

CONCLUSIONS 22

REFERENCES 23

3 © 2019 Midagon Oy

BACKGROUND AND PURPOSE

This white paper gives a description of the origins and nature of the Agile, Hybrid, and Waterfall methodologies for managing ICT development. The focus is in leading and managing ICT development, although larger transformations typically also contain other elements of the business or operational model. Waterfall projects, agile development, and hybrids between these all have their strengths and weaknesses:

• The waterfall project is well-known, even to non-technical people, and is the prevailing methodology for implementing configurable software products. It is, however, not the best approach in developing new software to less specified and changing needs.

• Agile development offers a flexible but still systematic approach in developing complex systems and a faster way to realize business benefits. However, in order to be very beneficial, it also requires a more agile culture on higher management levels.

• Hybrid projects can be used to increase flexibility in the execution phase, while at the same time maintaining the discipline of a project. If it is misused, it may allow the organization to pretend to be agile, while the central tools to enable this combination of discipline and flexibility are not adopted.

In addition to the basic alternatives listed above, selected means of scaling up the methodologies for bigger changes are addressed – namely the gate model, the Scaled Agile Framework (SAFe), the program, and Business Development Operations (BizDevOps). These are relevant in managing larger ICT transformations, whether they are related to the internal tools of the company or services to the customers.

A Midagon white paper on Complex ICT and Digital Transformations addresses the question of whether the choice of methodology makes a difference between success and failure in larger transformations. The success and failure factors seem to be independent of the methodology chosen. This means that selecting a certain methodology is no guarantee of success. According to research, however, the success and failure factors are primarily related to leadership and management. Therefore, the methodologies are compared against the phases of the general management cycle, as well as against the traditional components of project management.

This white paper gives an overview of the ICT development methodologies based on our experience, the literature and suitable web content. It describes them visually to make the differences easier to understand and remember. Furthermore, it serves as an introduction to the following white paper, Managing ICT development – Selection between the methodologies (COMING SOON) which gives guidelines in choosing the suitable methodology in different situations.

4 © 2019 Midagon Oy

The cyclical nature of management

Leading change is managing the change and preparing for the next one. Managing in general is cyclical by nature. Widely known in development and quality management is the Plan-Do-Check-Adjust (PDCA) cycle of continuous improvement by W. Edwards Deming, analyzed by e.g. Moen & Norman. Other variations include the “strategy loop” by Sull or the Build-Measure-Learn cycle by Ries. The idea of a cognitive cycle is the same. Picture 1 presents a refined universal process for managing development.

The phase names are broadened to fit any management level or methodology:

• A: Analyze/Adjust – Understand feedback; discover a new opportunity or threat through situational analysis; adapt to circumstances; learn from new ideas in the community; initiate a change; set the goals, create a vision or define the desired end state; report the situation and progress upwards; receive from higher management a purpose (WHY) and a mission (WHAT to achieve), as well as a possible initial plan.

• P: Plan/Propose – Analyze the mission and situation; generate and compare implementation options (HOW); give a heads-up to vendors or subordinates and engage them in planning; create a plan with the organized tasks, schedule, and cost; propose the options or plan for approval, if required.

• D: Decide/Do/Delegate – Choose the best option and decide to execute; do your own tasks; delegate missions to vendors or subordinates (our HOW becomes their WHAT); oversee and support their work; create the deliverables.

• C: Check/Complete – Test and demonstrate the deliverables; verify the value; receive feedback; raise issues; have the deliverable approved and handed over to the users; measure performance.

In most cases, leadership and management practices are the strongest of the success and failure factors affecting large transformations listed by Eskola & Töyrylä. The universal management cycle is used here as the common framework to connect the technical tasks of systems engineering and business management process phases. In a latter chapter of this white paper we compare the basic methodologies from the general management cycle perspective.

Picture 1: Universal PDCA management cycle in development

INTRODUCTION: FRAMEWORKS FOR MANAGING ICT DEVELOPMENT

From a business perspective, development has a purpose, the desired benefits and business case – the WHY. The mission delegated to the development team is to create deliverables like software tools – the WHAT – which can be used to achieve the benefits. The way to create the deliverables – the HOW – is the solution and the plan.

Traditionally, the three most important components in managing a project are Scope, Time, and Cost. These components need to be in balance for the plan to be realistic. A change in one component has an impact on the others. Different project management methodologies list three to six more components to manage. In this white paper, we address two more essential components, which are relevant in any ICT change: People and Quality. The following list

describes how these five terms are understood here:

• Scope (S) – Development work produces an output (WHAT to deliver), a “product” meeting the customer’s needs, as described by the functionality requirements and acceptance criteria.

• Time/schedule (T) – Development work may

Traditional components of managing development

5 © 2019 Midagon Oy

have a pre-planned total duration, tasks need to be synchronized between participants, and releases must be scheduled for the business.

• Cost (C) – The work needs to be funded, and the spend controlled.

• People (P) – As the key resource in ICT development, the team with its competence on substance matters as well as its capability to produce deliverables and quality.

• Quality (Q) – In this white paper, it is a term describing the ability to meet other requirements than the directly functional ones (included in the Scope): faultlessness, usability, simplicity, security, interoperability, modifiability, architectural compatibility, etc.

Scope as the output – the WHAT – are the delivered ICT tools which enable a change in a process or behavior, which again leads to the benefits and value. Scope is the component through which one can affect the revenue side of the business case.

People, Time, and Quality are about HOW to deliver the output in the scope. The Cost is the price that the business pays as an investment. The management of Risk and Change – often identified as components – is achieved in the following chapters by adjusting the above five components.

All the components mentioned above affect the ability of the company to achieve the desired business benefits – the WHY. The benefits of using a certain software feature can only be achieved when it is released for the users. As an example, shortening the

delivery Time of the feature may increase the Cost of development but decrease the Cost of delay more, and thus improve the business case.

The waterfall projects, agile development and hybrids between these are all ways to implement the change. Their mission is the same. They all manage the structure and size of the mission as well as the dependencies between the tasks, through adjusting these basic components. However, there are also differences between the approaches.

The differences are clearly visible in and emphasized by the terminologies used. The agile methodologies use words that might initially be difficult to understand by anyone who has not taken the relevant courses. These terminological differences appear to be a barrier in understanding and applying the agile principles and tools. The historical origins of different methodologies, as well as the similarities and differences in vocabulary, have been well-presented by Palmqvist et al.

Picture 2: The components of managing development

Project

According to one of the widely spread project management methods, PRINCE 2, a “project is a set of related activities within a temporary organization created to deliver one or more predefined products or services”. Projects are carried out under conditions where normal continuous business operations cannot deliver properly. This is because the desired product is unique and requires special skills to be created. A project is suitable for managing ICT development when it is related to an unusual situation like

• a replacement of an enterprise application suite,

• a replacement of an information storage platform or server infrastructure

• a merger of two companies.

A project automatically ends when the product is handed over to the customer. A PRINCE 2 project contains a few basic management phases such as Pre-Project, Initiation, Delivery (in phases), and Final delivery/Closure. The sequence is considered linear, as the project is set up to perform a one-off task. However, the management process naturally becomes more cyclical if several successive projects are done under a program. This will be addressed in the coming chapters. The simplified picture 3 (p. 6) shows the PRINCE 2 project management phases compared to the PDCA phases.

Benefits: A project offers the tools to handle a one-off task through logically refining the requirements into a working solution, no matter how unique the

DESCRIPTION OF THE METHODOLOGIES

6 © 2019 Midagon Oy

requirements may be. It enables the allocation of an especially skilled temporary team to the task thus ensuring the delivery. A project also includes the roles and procedures to focus management attention to the unusual task that would be unfamiliar to the management of the normal operation.

If the development team has the wrong idea about the requirements or does not understand the desired benefits and constraints, the product may turn out wrong.

A large project may be long-lasting but still delivering in one batch, which increases the risk related to changes in the environment and needs. Delivering incrementally may then be sensible. That also reduces the cost of delay for the customer waiting for the benefits.

A project as an organization is a temporary one. After the project is closed, the competence accumulated into the team may be lost. Project reviews may be skipped if there is nobody left to learn from them.

People sometimes tend to avoid projects because of the “bureaucracy” related to them. The management procedures included in project methodologies do bring discipline to the work of the “white collars”. Sometimes this discipline is exaggerated. Line work feels cozier and may even be more efficient.

On the other hand, sometimes there is an over-reliance on projects in the company. Even a poorly defined or unrealistic mission is expected to be completed successfully, when controlled as a project.

Setting a project with special management roles may also isolate the task inside a development function into steering group meetings, outside the attention of business management.

Picture3: Project management phases compared to PDCA phases

The people are only allocated for the duration of the project and can be freed to other tasks if there is no further need or business case to continue development. External resources can be acquired as needed with limited duration to control cost.

Pitfalls: The idea of handing over the product to the customer at the end of the project often means that, after defining their requirements, the customer is not present at the time the product is built. It may also be difficult for the customer to state their requirements without seeing an intermediate result.

Brief history of the Waterfall

The methodology commonly called “waterfall” has its origins in in a 1970 research report by Winston Royce, “Managing the Development of Large Software Systems”. He presented a logical sequence of software development phases. All the phases would be elaborately documented, first for the US Department of Defense (DOD) procurement purposes, and later for quality control and delivery approval. The customer was mainly present only in setting the requirements and in testing the result.

The sequence of tasks was later named waterfall because the development tasks each represent a project phase that is expected to finish before the next one can begin. In an ideal case, every phase would need to be done only once. As a comparison, building houses normally works in a waterfall style without any iterations: set the requirements, design, estimate, procure, build, control, and hand over. The picture 4 shows the sequence of technical software development stages, as presented by Royce.

Royce reported his experiences of using the method in implementing a large software system: “I believe in this concept, but the implementation described above is risky and invites failure.” The major problem was that any deviations from the requirements or expectations would only be revealed during the testing phase. Should the deviations be significant, the consequence would be returning to the origin and an overrun in the schedule and/or costs.

Royce presented and illustrated several improvements to the model, including prototyping, mock-ups to verify design, and iterative development. However, the latter pages of his report and these improvements were mostly ignored by people implementing his model, since the single-pass sequence was easier to explain and remember. The rigidly sequential, big design up front, big test at the end, single-pass, document everything waterfall approach was standardized by the DOD in 1985 (Zwinkau).

7 © 2019 Midagon Oy

Waterfall project

Waterfall can work well, if the requirements are very clear or can be predicted with high accuracy. The providers of enterprise software suites have worked for years in covering a wide range of industry specific processes and best practices. Therefore, they typically have their proprietary “cookbook” waterfall methods for implementation. The high level of data integration provided by enterprise software products often promotes elaborate design and planning up front and large go-lives. In a large ICT implementation, the other components of the system, such as the data center hardware and integration platforms require proper planning and architectural design.

Benefits: The customer and the development team agree on the deliverables early in the process. Since the scope is well-documented, the mission is clear. This makes planning and designing straightforward. Progress is easily measured, and the project execution can be very efficient.

The elaborate documentation of requirements and planning enable the detection of architectural dependencies and risks. They also enable the customer to delegate the development task to a special team and serve the financial estimation, the competitive bidding, and contracting the work.

Detailed plans enable the coordination of large numbers of interoperating components produced by several companies and teams. Project personnel can work on different topics, depending on the phase, and personnel can move between projects without much retraining. The methodology does not require the continuous engagement of the customer side experts working in their normal operations.

Pitfalls: The main pitfall of the basic waterfall approach is related to the requirements. The quality of the solution depends heavily on the good coverage and clarity of the requirements. It is often difficult for the customer to write them and for the implementation team to ask for them. According to Parnas and Clements:

• A system’s users seldom know exactly what they want and cannot articulate all they know.

• Even if we could state all the requirements, there are many details that we can only discover, once we are well into implementation.

• Even if we knew all these details, as humans, we can master only so much complexity.

• Even if we could master all this complexity, external forces lead to changes in requirements, some of which may invalidate earlier decisions.

In the case of a configurable software product, the task of requirements definition can be made easier by extensive demoing and iterative tuning of the functionality during a feasibility study phase preceding the actual implementation project or during the requirements definition phase.

Over-reliance on planning may invite decision-makers to set up a too large, complicated and long-lasting waterfall project. After the design and build phases, the documented requirements might not correspond to the actual business needs at the time of testing and deployment. Since the delivery is financially estimated and contractually bound to the requirements, any “changes of opinion” by the customer need to be managed as scope changes. Managing the changes is a common but often not an easy task, since the

Picture 4: Waterfall (source: Winston Royce)

8 © 2019 Midagon Oy

approach has the built-in assumption of correct requirements.

The long duration often leads to a lack of control. Without milestones with demonstrations of results it is difficult to determine whether there is good progress or whether the solution will be a good one. The development team and project manager might lose time in the beginning without a sense of urgency.

The single-pass ideal and the large batch size of a waterfall project often create difficulties. All the requirements are assumed to be worked on in parallel through the project phases. Testing the solution is left to a late phase, and the management is thus also late in becoming aware of problems.

Another common pitfall of the waterfall project is the difficulty of estimating the size of the tasks. Highly elaborate calculation tools have been created in different industries, but exceeding the planned

schedule and budget is still common. Backward-facing control tries to clarify the reasons for the deviations, which often feels like a blame-game. However, the reason for a deviation might just as well be poor estimation as poor execution.

The risk of exceeding the budget can be managed by sharing it in the vendor agreement. Some industries and companies even prefer fixed-price agreements, which again puts more pressure on the documentation of the requirements. The enterprise software implementation cookbooks and estimation tools help to minimize these problems.

Should the project plan not be sound or the budget accurate, changes are sometimes difficult due to the company’s slow centralized decision making. This especially common among companies using gate models. These are discussed in a later chapter.

Picture 5: V-model of quality assurance

V-model of quality assurance

One of the improvement areas of the waterfall that Royce pointed out was quality control – how to plan, control and monitor testing. In the V-model, the validation of deliverables can be done systematically using test plans created during the requirements definition and design phases. The picture of the model (picture 5) shows the sequential phases of development arranged into levels starting from the customer and proceeding toward the developer and the smaller components of the software. The model visualizes the correction of possible problems as recursive loops, although late changes are not welcome in a waterfall.

The V-model is a common quality assurance approach and is valid for all methodologies alike. The unit test covers one coded or configured component of software and is typically done by the developer himself. The integration test covers the data and process flows across different components and interfaces. The user acceptance test (UAT) covers the whole product that is in scope for the project. Passing the UAT makes it possible to “go live” with the solution and release it to the users.

9 © 2019 Midagon Oy

Gate models

Larger companies commonly have their “gate models” for managing projects. They include more precisely defined formal criteria for approving the completion of the waterfall phases. These gate decisions are based on a set of document deliverables typically supported by officially approved templates. The technical development tasks are fixed into project management phases – approval decisions on the completed phases are made by the steering committee and cover the whole scope of the project. Furthermore, the gate models often cover the project initiation phase with the funding decision and may require detailed estimation and planning very early, even before any detailed requirements analysis.

The gate model is the ultimate application of the waterfall idea where all decisions have been placed into a linear sequence, at least visually ignoring the cyclical nature of management. The model is used as a tool to manage large transformations with larger investments, and large batches of deliverables are approved in the same gate meetings. Therefore, the gate decisions can only be made by managers or committees with higher authority.

Benefits: In addition to the actual ICT development – the execution phase of the project – a gate model also sets documentation requirements for the initiation, planning, and closing phases of the project. It forces people to work according to the company standards of governance and thus guides them toward better decisions. Setting project objectives and creating business cases are tasks that require support and tools to be well performed.

The gate model also invites the customer to familiarize themselves with the intermediate results of development, although the steering committee typically does this based on documents and status reports. The gates work as proofing points of management accountability, by e.g. reporting that “the requirements are done”.

Pitfalls: A common problem with the gate model is slow decision-making. Since the managers are typically very busy, the development team may find themselves wasting time waiting for approvals and permission to proceed. The deliverables of financial estimation and pre-planning are defined, but these early phases may not be time-boxed in any way. Getting the funding decision may take months or even years, and parts of the initial concept may be obsolete before the project starts.

The model can also place too much reliance on the guiding process and direct toward planning too large projects. The bigger the solution, the bigger the benefit, and the better business case can be written to obtain funding. It may make sense to gather a bigger collection of investment targets to ensure management attention and enough funding at one time. However, the bigger size comes with more complexity and risk. During the development, the large batch size of the waterfall may force the whole project to advance at the pace of the slowest component. In order to proceed, despite delays in some areas, the project management is often tempted to overlook some of the approval criteria.

Typically, the gate document templates have been improved and grown through the years. Sometimes they are very elaborate – an excel check list document on architectural compliance can contain a dozen tab pages. This means that the templates try to cover almost every situation imaginable and thus contain a considerable amount of irrelevant content. People tend to consider these templates a necessary evil and try to cut corners in filling them. This again leads to additional compliance expert work in supporting planning and inspecting and approving the documents.

Picture 6: Gate model

10 © 2019 Midagon Oy

Continuous improvement

ICT development is a part of normal continuous operations for a company that offers software or software-intensive solutions, like integration service or computing capacity to customers. As the services offered to customers in any industry are getting more digital, there are more continuous ICT improvement efforts besides the one-off exercises mentioned in the project chapter.

As it is necessary to improve the efficiency and profitability of continuous operations, it is important that the team performing the work learns by doing. This leads toward setting up a relatively stable and dedicated team for ICT development, as well as utilizing agile methods. Agility means increasing the pace of the learning cycle, and improving efficiency through faster reaction and correction of mistakes.

The cycle of learning and continuous improvement is a central principle of Lean thinking. It has been widely applied also to ICT development, as we can see in the iterative life cycle for software development or the build-measure-learn feedback loop for a Lean startup.

Continuous improvement is also relevant for large ICT transformations, in cases where the transformation is divided into smaller parts, or in cases where the first big one-off effort is followed by evolutionary improvement, based on user and business feedback. The picture 7 presents the common technical tasks of ICT development placed in the cycle as well as a feedback loop from operation.

Benefits: Understanding ICT development and the related management processes as cyclical activity emphasizes the meaning of customer feedback. The adjustments that follow lead to better quality. From the customer perspective, their high involvement and frequent communication within the team turns

ICT development into co-creation of value, rather than just delegating a task and receiving the result. A continuous development team is also more capable of handling operation incidents or urgent requests than a project team.

When a large solution is delivered in smaller batches through incremental development, useful functionality can be released earlier, and the benefits received sooner. This also reduces the risk of changes in the environment and in the customer needs. Changes can be reacted to sooner through regular reviews and iterative development.

Pitfalls: Continuous improvement and agile methods call for a development team that is trained to and capable of working independently. The development team members often prefer freedom to discipline. This may lead to a lack of accountability, since even any reporting of results can be considered non-value adding by them.

Having a stable team also means committing to the continuous labor cost. This means that continuous improvement does not suit areas where only small and seldom development is needed. A proper business case and planning provide the basis for decision making and control.

A team that does not deliver enough value is not a good investment. Relying too much on the capability of the team might lure the management into not giving them proper direction, targets and requirements. Furthermore, in case of a larger crisis or a business discontinuity issue, the mandate of the team and the resources available fall short, and the management may need stronger direction and one-off actions to regain control.

Picture 7: ICT development as continuous improvement

11 © 2019 Midagon Oy

Since the 1950’s, large software intensive system deliveries have been managed as iterative and/or incremental development (IID), as reviewed by Larman & Basili. The early decades saw a wide variety of approaches. Many of them combined both incrementing and iterating, and some even engaged the customer tightly for feedback. The following pictures (pictures 8-10) illustrate the idea of incremental and iterative development (Jeff Patton & Steven Thomas).

Incrementing starts with a fully formed idea and builds a bit at a time. Incremental ICT development means dividing the solution into smaller and more manageable parts and releasing them to be readily usable.

The development of the solution may be incremental and iterative at the same time. This kind of ICT development is common, when using modern agile methodologies.

Picture 8: Incremental Mona Lisa (source: Jeff Patton)

Picture 9: Iterative Mona Lisa (source: Jeff Patton)

Brief history of evolutionary development

Picture 10: Incrementally iterative Mona Lisa (source: Jeff Patton)

In the 1980’s, many publications promoting IID (against the prevailing waterfall) were written, and the principles became public in the systems engineering community. The first formal evolutionary development methods were developed, such as the Spiral Model and the Cleanroom and Evo methods. The emphasis was on the cyclical learning after the original requirements definition and the delivery of useful software in time-boxed increments. The increments at the time typically lasted several months.

In the 1990’s dozens of new methods were developed, such as Rapid Application Development (RAD), Dynamic Systems Development Method (DSDM), Extreme Programming (XP), and SCRUM. After disappointments in applying the waterfall method, the US Department of Defense also renewed their standard in 1994 encouraging evolutionary acquisition and IID. The IID tools and procedures have since been tried, improved, and combined to form the modern agile development and hybrid project methodologies. The preferred length of a time-boxed increment or iteration was shortened into a few weeks.

Agile development

With the agile development mindset, programming is viewed as a craft, rather than a mechanical, industrial process. In 2001, a group of systems engineers representing different formal methods got together and publicized the Agile manifesto to declare they valued:

• individuals and interactions over processes and tools

• working software over comprehensive documentation

• customer collaboration over contract negotiation

• responding to change over following a plan.

Agile development also embraces, to an extent, the Lean principles that have their origins in

Iterating allows you to move from vague idea to realization. Iterative ICT development builds a rough version, validates it and then gradually builds up quality.

12 © 2019 Midagon Oy

Picture 11: Agile development iteration on the team level, “sprint” (source: Stigasoft)

manufacturing after the Second World War. These principles include creating value for the customer, eliminating waste, optimizing value streams, empowering people, and continuously improving. These principles lead towards faster and more flexible practices. Changes in the customer’s requirements are welcomed, even at a late stage, since they are considered improvements to quality and customer value. Elaborate longer term plans that will turn obsolete immediately after the start are considered waste, since they require constant updates and re-approvals.

Agile development methods were widely adopted in the 2000’s and 2010’s. As a comparison to waterfall, they have the following characteristics:

• Requirements are characterized up-front but assumed to be changing.

• Systems evolve during a series of time-boxed iterations (“sprints” in SCRUM), where requirements analysis, design, coding, testing, and deployment into the productive system happen in each iteration.

• Customer participation is required during each iteration for guidance and approval of the delivery.

• Documentation is developed only as needed to describe what was produced and is often tailored for that purpose.

An agile and self-organizing development team includes a Product Owner as the “voice of the customer” and a Scrum Master facilitating the work and ensuring effective governance. The other members of the team may be e.g. a service designer and the developers for software logic, databases, user experience, and hardware, as well as a tester.

The features to work on are selected by the product management from a larger set called a “product backlog” that contains all the requirements related to a certain area or a sellable product. The starting point of a time-boxed increment, a “sprint”, is the selection and estimation of requirements. Based on a release plan and the prioritized list of features, the team selects a set of most valuable and otherwise suitable requirements, “user stories”, to form a sprint backlog. The sprint backlog limits the amount of work to what can be completed within the duration of the sprint.

A sprint is typically time-boxed to last 2 to 4 weeks and broken down into a series of daily work assignments (often called tasks) for the development team. Progress is controlled in daily checks, “standout meetings” (or “daily Scrums” in the SCRUM method) in which the developers shortly describe what they

have done, what they are going to do next, and whether there is something preventing them from progressing. The picture 11 by Stigasoft describes agile development on the team level.

The code or configuration produced is continuously unit tested and integrated into the existing solution. A principle of “daily builds” ensures that the latest development results are available for end-to-end testing after each day. The validation of completeness and value happens at the end of the sprint by demoing the result to the customer. After an approval, the software functionality can be deployed into the productive system for use. Any possible unfinished work is returned into the backlog. The sprint ends with a “retrospective”, a session of discussing lessons learned. This facilitates the continuous improvement of the team’s skills and closes the small-scale PDCA loop of management.

In order to manage larger software solutions, the agile approach has been scaled upwards with a hierarchy of backlogs. A series of sprints produces a larger whole of inter-connected functionality that can sensibly be released to the users. Therefore, the product backlog is prioritized, and a smaller batch of most valuable requirements are selected to the “release backlog”. The release backlog is further prioritized in order to select the sprint backlogs. The picture 12 shows this idea of governing and controlling the development work through iterative and/or incremental deliveries.

Benefits: Agile development enables the close control and support of the delivery through the daily standout meetings. Time-boxing the delivery and the demos at the end of each sprint, ensures that the work starts progressing immediately, even though the release deadline is far away. Through incremental delivery, value is delivered and frequently to minimize the cost of delay.

Prioritization of the customer needs in the backlogs leads towards delivering the most valuable features. Customer requirements can be refined based on seeing the early versions, which is especially

13 © 2019 Midagon Oy

beneficial in cases where the product is not defined but is created through innovation. Changes in the needs are reacted to, by frequently supplementing and reprioritizing the backlogs.

Pitfalls: Reducing the amount of up-front planning and documentation might lure people into not defining the requirements at all. Thus, the development work is not based on any reliable estimate of customer value either – there is no business case. As a result, the features and user stories might not be properly described with acceptance criteria, and the development team might have a hard time figuring out what they should do.

If the Product Owner does not know the methodology or otherwise does not work effectively, the tasks of this role might in practice be assumed by the development team. We call this “developer anarchy”. In this situation, the team develops what they like, instead of what the customer needs. The team might for example spend all their time in refactoring, instead of developing new features.

Avoiding excessive documentation is good, but it may lead to no documentation at all. Skipping documentation on what was done increases the dependency on single persons. The team might also reject documentation as not “compliant with the method” or as a non-value adding activity. If the documentation is valuable for e.g. sales, it should to be written into the backlog as requirements.

An agile team may work well internally but not in managing the dependencies in a large transformation. The team might have the attitude that sharing the

plans with other teams does not create value. This is especially harmful if the dependencies are critical or making changes is highly expensive.

Agile development, therefore, does not yet guarantee that the features chosen are the most valuable ones possible. The prioritization of the backlogs by the product management can be based on personal opinions, political motives, and unverified assumptions on user preferences. Closing the feedback loop from users to release planning enables more fact-based decision-making. This is discussed in the following chapter.

The benefits of agile development are limited, if the deployments to production are not continuous and the releases to the users frequent. The benefits of a software tool are only achieved through using it.

Likewise, it is difficult for the development team to be agile, if the company’s financial planning and control works according to the waterfall ideal. Typically, this means detailed cost estimates, time-consuming approval rounds for changes, and continuous comparison between the originally planned and the actual figures. Moving from waterfall methods to agile development is itself a demanding transformation.

The approach does not fit situations where a specified one-off solution needs to be delivered by a task force within a strict deadline, for example in a company merger or with a regulation change. Instead, it supports a constantly allocated team that selects a sustainable amount of work from a flexible scope.

Picture 12: Agile development with a hierarchy of backlogs

14 © 2019 Midagon Oy

Continuous delivery

A step further in increasing agility by reducing the batch size is Continuous Delivery, also called Development Operations, “DevOps”. In this approach, the newly written code is comprehensively tested automatically, continuously integrated (CI) into a common integration test system for end-to-end testing, and continuously deployed (CD) into production. The development and operation processes are tightly connected, in order to make the whole delivery pipeline fast and to continuously produce value.

The main difference between continuous delivery and agile development is again the batch size: While agile development continuously integrates the newly developed functionality, the deployment to production is only done at the end of the sprint. In continuous delivery, the deployment to production can happen immediately after the necessary tests have been run. No sprints time-boxed to last some weeks are used, but deployment can even happen once every hour. Instead of working on a sprint backlog, the team uses a Kanban board and manages the flow of single changes in the queue.

The two important decisions are the “technical” decision by the development team to deploy the change (to a productive or staging system), and the “business” decision to release the change or feature to the customers. The release to the customer may happen as a consumer service subscription, an equipment maintenance update, or in a product made to order in the factory, all depending on the industry. In order to close the management loop for effective innovation and good customer service, a feedback flow of usage data, maintenance experiences, and problem correction requests must be arranged back to the development team.

A large ICT transformation is not really enabled by DevOps – rather, DevOps is a large transformation.

Moving into cloud hosting platforms makes it easier, as frequent and even forced updates are the rule in modern cloud services. More frequent releases also mean changing the way customers are served and the way they act. This change is happening all around. In a company that has software embedded into a hardware product, applying DevOps may reveal the need to transform the product offering for modularity, simplicity, and less version compatibility problems and cost.

Benefits: Continuous delivery optimizes the flow of new features and value to the customer, according to Lean thinking. It forms a bridge across the organizational silos of the company and improves the speed and effectiveness of a company operating in a software service or software intensive industry.

The practices of continuous integration, automated testing, and continuous deployment can be used with a variety of development methodologies – except for the single-pass waterfall. Any development process of an incremental and iterative nature can be speeded up by continuous deployment. The main reason to use time-boxed sprints is now often to better manage scheduled releases.

Continuous delivery is a way to organize the development and maintenance responsibility of the solution to the same team. The original developer is typically the best one to correct any problems in the software (although he might not prefer tedious work like that). Furthermore, much of the work in operations is unplanned – reactions to performance spikes, system outages, and compromised security. These events demand an immediate response – naturally by the responsible development team.

Pitfalls: Arranging the continuous deployment and release on demand may require significant investments in the company’s information system

Picture 13: Continuous delivery

15 © 2019 Midagon Oy

platforms. The legacy systems with their outdated tools and version management often make frequent updates difficult. The several steps of thorough testing before the deployment need to be automated, in order to avoid unacceptable costs.

The potential problems related to feature backlog prioritization mentioned in the chapter on agile development also apply to continuous delivery. The feedback flow back to product management and to the development team must work properly, in order to get the full benefit of this approach. The feature

prioritization decisions should rather be based on usage metrics and facts than personal opinions or political motives.

Continuous delivery can be further scaled up, by creating a Lean startup style innovation process, “Business Development Operations”. This means completing the management loop with the feedback flow and enabling experimental business and solution planning with hypotheses. This approach is further discussed in the white paper on Selecting the methodology to manage ICT development (COMING SOON)

Scaled agile development

A currently prominent holistic methodology of agile development is the Scaled Agile Framework, SAFe. It uses two-week sprints, and includes on top of the team level a program level and, if necessary, a large solution level or a portfolio management level or both. SAFe combines the agile coding practices with a holistic Lean ideology and the DevOps practices of continuous testing, integration, and deployment. 16

SAFe combines five sprints into a “program increment,” where the last sprint is dedicated to review, solving problems, and planning the next increment. The whole development of the company is in a “cadence”, synchronized across the portfolio to the same pace of program increments and sprints. SAFe uses proprietary terminology, like “epic,” which means a larger collection of requirements close to a releasable batch, and “agile release train” meaning a team of teams.

Benefits: SAFe combines many sensible management practices developed in recent decades. It paces all the development activities in the company to work together, even including three management layers on top of the development team, and thus improves synchronization and coordination. As a

holistic framework, it helps a larger development organization in adopting agile development methods.

Pitfalls: Because of the large amount of new ideas, new tools, and new terms used, applying SAFe typically requires courses and expert support (although it comes with an implementation roadmap). The framework with its multiple layers can seem complicated and heavy: Applying it in a larger company requires training the management extensively to fill the numerous roles and to effectively connect business management with ICT development.

Pacing the development to program increments of five sprints and 10 weeks is not directly compatible with the normal business management cycles of months and quarters. This makes engaging the business managers and synchronizing objectives more difficult. With its focus in software development, SAFe alone is not enough to close the loop of management in providing user feedback and data to business planning. SAFe presents some sound principles for investment decision-making, budgeting, and controlling. However, it still offers few practical tools to arrange an agile financial management.

Hybrid project

A hybrid project follows the tradition of IID described earlier. It combines practices from both waterfall and agile methodologies and is also called Disciplined Agile. Development can be either incremental, iterative or both, as required. The method contains a thorough requirement analysis, and possibly a collective design phase done as a “design sprint”. Typical examples requiring a comprehensive design are the high cost of change, demands for system interoperability, or regulations.

The execution phase of the project is managed in time-boxed sprints. The content of the sprints is

different, based on whether the design, integration testing or both are combined or broken down into single sprints. The picture 14 shows a sample project structure with the design, build and testing all included in the sprints.

The first important difference compared to a waterfall, is the reduction of batch size – a large ICT transformation is divided into more manageable parts. There is an argument that an agile sprint is a mini waterfall – a sprint does contain a major part of the activities of software development. Through the division into increments, a sense of urgency

16 © 2019 Midagon Oy

is created for the team, and initial results can be demoed and evaluated, even though they were still not ready enough for deployment.

In addition to the incremental delivery, sprint planning may include the re-prioritization and supplementation of the release backlogs – the customer needs can evolve during the project execution. When the planned releases are done, the project is closed.

As the second important improvement, the proven agile practices of team management are applied. The agile methods of continuous testing, continuous integration, sustainable pace, and daily meetings can all be applied in a hybrid project. At the single developer and team levels, it is important that the series of sprints corresponds to a queue of requirements, and all the tasks within a sprint are systematically managed as a queue, instead of considering them all work in progress (WIP).

Naturally, the customer is expected to participate actively in the development team. The roles can be adjusted flexibly. As the “business owner” of the solution, a Project manager can act as the Product owner, or vice versa. The approach is commonly used, when a company with a traditional waterfall culture needs to acquire work from a development partner with an agile culture.

Benefits: A hybrid project contains the waterfall-style up-front design and documentation, when they are necessary. The management of dependencies in large and complicated solutions works better than with pure agile methods. On the other hand, execution control, visibility and reliability are enhanced, compared to the waterfall methods.

A hybrid project adds flexibility from a functional perspective, by fitting together the agile practices of technical systems engineers with a waterfall project culture of the business management in directing development and prioritizing the investment portfolio.

A significant business benefit with the hybrid project is the capability to rapidly acquire mature technology and to deliver capability in increments, while recognizing up front the need to refine the requirements on the go. Each increment can be directly useful, and thus operational capability can be designed, built, deployed, and sustained with less risk. Naturally, the hybrid projects can be placed under a flexible program management.

Pitfalls: Although using hybrid projects fit well together with a waterfall culture in directing and funding development, some knowledge of agile methods is needed in the management. Leadership effectiveness is based on the management defining requirements, planning, and instructing the team on the appropriate level of detail, not micromanaging. Too often the management only expects an incremental delivery with all the releases providing a final solution. This idea overlooks the needs for iterative improvement and does not provide the flexibility required to solve a fuzzy problem.

Using hybrid projects as the preferred methodology might lead to fixing the requirements and scope as a habit. This fixing could also occur in situations where it is not necessary. Waterfall-type financial management may also hinder some of the flexibility. A simple way to overcome this pitfall is to reserve a major portion of the funding for must-have features, with the rest reserved for optional features, e.g. with a 70-30% division.

An experienced development team can be very self-organizing, when allowed to make decisions on solution details in pursuit of the mission. As a downside when compared to waterfall methodology, a hybrid approach too often acts as an excuse for not planning the releases and even for not documenting the requirements and their approval criteria properly. The backlogs should describe the requirements and their acceptance criteria with the same accuracy as a waterfall work breakdown structure, if not more accurately.

Picture 14: Hybrid project with execution (design-build-test) in sprints

17 © 2019 Midagon Oy

Program

A common way to organize a large ICT transformation is to add a program level on top of several traditional projects or other types of development. Program management provides the necessary coordination, as the different development teams share the same larger purpose.

A high-level program plan or “roadmap” is used as an input to lower-level plans. The implementation of a large solution can be done using different methods in parallel – waterfall for the clearly defined or outsourced development, and a hybrid project or agile methodology for the iterative problem solving.

After each project delivery, the business benefit is validated, and the project is reviewed in order to learn and continuously improve. Similarly, the frequent reviews of agile development provide feedback and situational information to the program level.

A program adds flexibility by running continuous cyclical program management and dividing the large solution into smaller parts. The initiation of a change and the selection of a course action (or “operational concept” or “solution concept”) are considered program level activities.

Whether to call an ICT transformation a program or a large project with sub-projects is sometimes a question of taste. Both serve in managing the size and complexity of the transformation – the alignment of development tasks with their common and different schedules, their prerequisites and dependencies. A program is a more suitable name, if the scopes of the single projects can be adjusted based on feedback, or if continuous line work and agile development need to

be managed together with the projects as parts of the same transformation.

Benefits: A program can contain waterfall execution, if the team really relies on the documented requirements and design. This is typically the case, for example, with offshore ICT development. At the same time, a stable on-site team can solve more fuzzy problems related to the same business objectives using agile methods.

A program approach is useful in allowing some central persons that know the requirements to move between projects and to only participate in the requirements analysis and approval (if their absence in between does not pose a significant risk).

A program also serves in managing continuous improvement. After an initial project delivery, we may have many improvement requirements to the initial solution. A colleague once sarcastically said that “a program is a project that failed”. In practice, after a failure in completing a large transformation as a single project, the management may just need to continue with the development using a more flexible approach. A project turning into a program is a way of recovering from setbacks.

Program management as a process and a management layer enables connecting the development efforts to the cyclical business management. A business plan can contain an initiative for an operational change which is the documented outcome expected through an ICT program. “Doing” on the program level means communicating the mission and overall roadmap to

Picture 15: Program combining various types of development

18 © 2019 Midagon Oy

the project teams and supporting them. “Checking” on the program level means collecting the feedback from the business users, as well as the performance metrics and experiences. Thus, the roadmap can be adjusted before launching the next project.

Pitfalls: A common driver for setting up a program is financial – a common budget is received for several projects, even though sometimes the projects have nothing else in common. Including development efforts may mean delegating them out of sight. Setting up a program should not mean less management attention compared to waterfall projects – vague

articulation of objectives or overlooking the parts that require pre-planning. The additional management layer also does bring additional cost.

There are bad reasons for setting up a program. We might want to look more important and larger than what we really are. A program sounds fancier than a project, and Program Manager, not to mention Program Director, sounds fancier than Project Manager. Seeking higher status may cloud our judgement and make us apply the wrong kind of management practices on projects.

COMPARISON OF THE METHODOLOGIES

Picture 16: Waterfall project with all requirements moving together

Picture 17: Incremental waterfall delivery

Picture 18: Agile development

Picture 19: Hybrid project with execution in sprints

Essential difference – Batch size

Waterfall projects, agile development and hybrid projects all have the same technical tasks: analyze the requirements, design the solution, build, test, and

deploy into productive use. The following pictures (Picture 16 - Picture 19) show the different handling of requirements in batches.

19 © 2019 Midagon Oy

In enterprise system implementations, the software providers and partners often have their “cookbooks” of best practices in waterfall projects. They work well, if the requirements are clear. A more agile approach is more suitable, if the requirements are unclear

Differences related to project management components

or likely to change. The following table presents a comparison of the waterfall and hybrid projects and agile development in relation to the management components traditionally associated with projects (partial source PMI).

“Cookbook” – Waterfall Hybrid project Agile development

Scope

• Requirements are well- defined, communicated, and understood early

• Scope consists of the planned deliverables

• Scope changes are unwelcome and not expected

• Must-have requirements clear, otherwise open to discussion

• Planned deliverables divided into feature/release backlogs

• Features can be fine-tuned, new ones added on the go, or lower-value ones left out

• Requirement details unclear

• Requirements constantly open to change

• Features valuable to the customer are delivered based on a hierarchy of backlogs

• Reprioritizations are frequent, lower-value features are left out

Time

• Start and end dates set, timeline commitment required early

• Schedule planned according to the total set of deliverables and their estimated workdays

• Start and end dates set, timeline commitment required early

• Schedule planned to deliver must-have features with certainty and to leave room for optional ones and possible iterations

• No preset date for the delivery of a complete scope

• Delivery schedule of a certain feature may vary when adapting to changes and learning

• Doing overtime is possible but typically not preferred in the developer culture

Cost

• Commitment to cost through the planned deliverables and the allocation of people

• Detailed estimates based on scope, schedule, and allocation of people

• Commitment to labor cost based on delivering must-have features and leaving a buffer for optional ones and iteration

• Commitment to cost through the labor cost of the team

• More detailed near-term estimates – only rough long-term estimates

People

• Team preferably highly experienced with the task – mature approach, repetitive tasks

• People often allocated to many projects

• Team may be dispersed by geography and time zones

• Customer mostly involved during requirements analysis and delivery acceptance

• Allocation of people planned according to the deliverables and schedule

• Fairly experienced team, but uncertainties with e.g. technology

• Implementation team preferably fully dedicated

• Team co-located or using collaborative tools

• Customer involved regularly and consistently

• Allocation of people based on collective deliverables and backlog prioritization

• Team not experienced with the task – new process or technology

• Team fully dedicated

• Team co-located or using collaborative tools

• Customer involved regularly and consistently

• Allocation of people based on the backlog prioritization

Quality

• Comprehensive and detailed up-front documentation of requirements and design form the basis of testing and approval.

• Clear requirements and acceptance criteria for the must-have features

• Up-front documentation of critical design and dependencies

• Approval based on demoing a working solution

• Clear requirements and acceptance criteria,

• Quality related to more complicated dependencies and interoperability more difficult to handle

• Less documentation on design – document reviews replaced by demonstration and approval of a working solution

20 © 2019 Midagon Oy

Support for closed loop management

The time spent, the information handled, and the tools used in each phase of the PDCA cycle vary, depending on the methodology. However, in general all the phases should be included. For good management, it is essential to have a closed loop – information needs to flow from the previous phase to the following one. Without a working feedback flow and reviews, decisions won’t be based on facts.

Phase & output Waterfall project Hybrid project Agile development

Adjust, Analyze

a Clear mission

Good support:

Clearly understood, detailed, and documented requirements form the basis of all further work.

Good support:

Clearly understood, and documented requirements form the basis of further work, at least for the critical features.

Very good support:

Analysis on several levels. Product backlog to be elaborated into features and user stories. Recurring and flexible prioritization of backlog items to work on.

Plan, Propose

a Doable & flexible plan

Very good support:

Feasibility through detailed planning based on the scope and design. Long-term estimates. Risk control through agreements and buffers.

Very good support:

Increased planning flexibility through reducing batch size and possibly iterative development. Backlogs may be re-prioritized and supplemented.

Rough high-level plans. Queuing and task allocation in the sprints are simple after the requirements analysis. Team commitment due to self-organization. Handling complicated dependencies difficult. Longer-term release planning requires a program level.

Decide, Do, Delegate

a Reliable execution

Efficient when the tasks are clear. Allows minimal customer participation during the build phase. Exceptions cause re-planning, which is a step backward and considered undesirable.

Good support:

Agile-style close control of progress. Smaller work packages help keeping the momentum. Continuous unit testing and integration.

Good support:

Close control of the queue and progress. Continuous unit testing and integration to enable end-to-end testing and to produce ready-to-use code and functionality.

Complete, Check

a Updated understanding

Test cases based on clearly documented requirements, but only after the longer build phase. Management through exceptions, comparing actuals to plans. Validation of benefits possible, but only after the deliverables have been released.

Good support:

Better control through frequent testing. Incremental deliveries with quicker wins. Earlier warnings about the need to revise the plan. Possibility to iterate and improve quality.

Very good support:

Continuous end-to-end testing, demoing, evaluation & feedback to ensure high value. Continuous delivery and customer value added Possible. Review/ retrospect at the end of every sprint.

Next cycle round:

Account for, Adjust, Analyze...

Slower cycle because of the large batch, and slower reaction to problems. Learnings for the next project?

Good support:

Faster cycle for the build, test, and deploy phases. Learnings/improvements during the project.

Very good support:

Faster cycle overall. Continuous learning and improving possible.

Not having a closed loop is a weakness with waterfall projects, if they are run as one-off exercises, leaving the post-completion analyses undone. On the other hand, agile development enthusiasts may skip some necessary planning steps, because they consider them non-value adding work. The following table describes how well the three basic alternatives support the closed loop management process, based on their common benefits and pitfalls listed earlier.

21 © 2019 Midagon Oy

The table shows that the more agile methodologies in general better support the closed loop management process. This comes with a cost: More management attention is typically paid to a hybrid project and agile development, than to a waterfall project. The difference is explained through the regular customer participation in demos during the implementation

phases, and a higher density of communication in general. The common analysis and design phases of a hybrid project do also require some effort. Provided the waterfall project is planned well and is not caught by surprises, it is the lightest alternative regarding the management time spent.

Decision-making style

It is in general beneficial for a company to unleash their leadership potential by delegating decision authority to lower levels of the organization. From the ICT perspective, understanding the challenges and decision-making can happen naturally on all levels of the organization. The decision-making style depends on size of the change and the situation and culture of the company. The basic methodologies differ in how well they work with centralized or decentralized decision-making.

Team self-organization is expected and facilitated in agile development. The prioritization of features and user stories is done together in a team. A hierarchy of backlogs naturally supports decentralized decision-making on several levels. Furthermore, as the agile methodology has Lean thinking embedded, the management participating in ICT development may favor empowering their people.

The waterfall project culture traditionally favors a more centralized approach to decision-making. As the batches of work are large, so are the decisions on approvals and changes. This requires a steering committee with enough power and authority. The elaborate planning and the following management by exceptions phase provide a chance to micromanage. This needs to be avoided through good governance and rules for delegating authority.

The hybrid project enables the elaborate planning required to manage complicated dependencies or large risks. Therefore, the big decisions of launching projects and for approving critical deliverables are central by nature. However, within the implementation phases the team can adjust and improve their work more freely, as well as experiment and iterate with optional features.

Realization of business benefits

ICT development needs to deliver value to the company by enabling improvements that lead to business benefits. Enabling the benefits is the purpose – the WHY – of development, as described in the first chapters of this white paper. A development team that does not understand the business benefits, or does not keep up with the changing needs, may produce something that is disappointing for the users and useless for the business.

With a waterfall project, a failure in achieving the business benefits may happen because of starting up with poorly described requirements or having overly optimistic expectations when targeting a large solution scope, the large batch. A failure may also result from extending the plan and business case very far, reacting slowly to changes in the environment, and sticking with the original plan too long. The elaborate planning, on the other hand, can be used to lower the risk related to the investment. The measurement and validation of benefits may be a part of the company’s project methodology. However, having a feedback loop to learn for the next effort usually requires program level management.

In agile development, a failure in delivering value may happen because the development team has too much independence. They might rush into development without considering a business case. They might also favor a certain technological approach or prioritize features that are interesting to develop instead of the ones that are useful to the Customer. If the Lean principle of always providing value is followed, this should not happen. However, the development team does need the clearly stated requirements to work on. The practice of describing the user stories helps with the effective determination of the requirements.

When using a hybrid project and elaborate planning, we can avoid costly risks and ensure the benefits that require a combination of different solution elements to work together. However, through incremental development and frequent releases we can reduce the cost of delay, and thus improve the business case. In addition to that, delivering optional features and experimenting with fuzzy problems we can provide value in ways that could not be foreseen when writing the business case. In planning for value and describing acceptance criteria, the good practices of agile development a naturally available.

22 © 2019 Midagon Oy

There are some differences in the tools used in analyzing requirements, but the desired measurable benefits and approval criteria should always be stated. Furthermore, the effective delegation of development tasks and thus ensuring the business

value means clearly communicating the purpose and mission to the development teams. This applies irrespective of the methodology chosen. Good practices for this are discussed in the following white paper on selection between the methodologies (COMING SOON))

CONCLUSIONS

The three basic methodologies, the waterfall project, the hybrid project, and agile development have been developed to respond to different kind of challenges in ICT development. They all have their benefits and their pitfalls. Therefore, they are suitable in different situations and offer different capabilities in managing smaller development efforts as well as large transformations.

A company typically has a preferred methodology to apply, and the new one is often considered suitable for everything as the old one is considered useless. However, being dogmatic about methodologies and tools is dangerous. A methodology should be selected according to the task at hand and adjusted to fit the real-life demands. Different types of tasks can also be performed simultaneously using different methodologies.

The different basic methodologies originally come with different tools to connect ICT development with business management. However, the need to describe the requirements, to prioritize based on value, and to communicate the purpose and mission to the team is common to all of them. Selecting the right methodology for the task will help in ensuring a successful delivery and the achievement of the business benefits.

We address the situations demanding a certain methodology and the prerequisites of making them work in the white paper Managing ICT development - Selection between methodologies (COMING SOON)

Picture 20: Realization of business benefits

23 © 2019 Midagon Oy

REFERENCES

1. Evolution of the PDCA Cycle, Ronald Moen & Clifford Norman, Associates in Process Improvement, 2009

2. Closing the Gap Between Strategy and Execution, Donald N. Sull, 2007 – available in https://sloanreview.mit.edu/article/closing-the-gap-between-strategy-and-execution/

3. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Eric Ries, 2011, page 75 – The build-measure-learn cycle is close to the PDSA and PDCA cycles. The book is also referred to in relation to the term “Lean startup”.

4. Why large and complex ICT and digital transformations fail? Framework for managing success and failure factors, Lauri Eskola & Ilkka Töyrylä, 2018, available in https://www.midagon.com/app/uploads/2018/10/Midagon_Whitepaper_Why-large-and-complex-ICT-and-digital-transformations-fail.pdf

5. Parallel Worlds: Agile and Waterfall Differences and Similarities, M. Steven Palmquist et al, Software Engineering Institute, 2013 – available in https://apps.dtic.mil/dtic/tr/fulltext/u2/a610501.pdf

6. PRINCE2 is a project management methodology and a registered trademark of Axelos – A brochure summarizing the methodology available in https://www.axelos.com/Corporate/media/Files/Brochures/PRINCE2_Product_Brochure_Conference_Version_v1.pdf

7. Waterfall, Andreas Zwinkau, article, 2018 – Winston Royce presented his original report on paper. Zwinkau has copied the essential graphs and analyzed the text in a reader friendly format, available in http://beza1e1.tuxen.de/waterfall.html

8. A Rational Design Process: How and Why to Fake It, David Lorge Parnas & Paul C. Clements, IEEE Transactions on software engineering, 1986, pp. 251-257 – available in http://web.engr.oregonstate.edu/~digd/courses/cs361_W15/docs/IEEE86_Parnas_Clement.pdf

9. Lean thinking, Wikipedia – lots of sources available, an overview presentation to start with available in https://en.wikipedia.org/wiki/Lean_thinking

10. Iterative and incremental development, Wikipedia – Lots of variations available, a very good simplified picture on managing software development “Iterative development model” available with this topic, https://en.wikipedia.org/wiki/Iterative_and_incremental_development#

11. Iterative and Incremental Development: A Brief History, Graig Larman & Victor R. Basili, a cover feature in Computer, 2003 – available in http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf

12. Revisiting the Iterative Incremental Mona Lisa, Steven Thomas, 2012 – Thomas summarizes the principles of iterative and incremental development using pictures by Jeff Patton, available in http://itsadeliverything.com/revisiting-the-iterative-incremental-mona-lisa

13. Manifesto for Agile Software Development, Beck et al., 2001 – available in https://agilemanifesto.org/

14. Agile software development, Wikipedia – Lots of sources available, an overview in https://en.wikipedia.org/wiki/Agile_software_development

15. The SCRUM Process, Stigasoft – Lots of pictures available, this is one of the best, http://www.stigasoft.com/agile-scrum-methodology.html

16. SAFe, a methodology and a trademark of Scaled Agile – Elaborated descriptions available in https://www.scaledagileframework.com/

17. Disciplined Agile, The foundation for business agility – Lots of material available, this site gives an overview: http://disciplinedagiledelivery.com/

18. Agile versus Waterfall, Jason Fair, PMI conference paper, 2012 – An evaluation template used to compare the reasons to select an “innovation” or a “cookbook” approach presented here: https://www.pmi.org/learning/library/agile-versus-waterfall-approach-erp-project-6300 and inspired our analysis with the hybrid project included.

© 2019 Midagon Oy

Keilaranta 102150 Espoo

Business ID: 2058234-3www.midagon.com

Success is a Choice