Module 1 Intro to Agile Software Development€¦ · • Introduction to agile software development...

© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved

Module 1 – Intro to Agile Software Development

Table of Contents

Module 1........................................................................................................................... 1 Study Guide .................................................................................................................................................... 2 Module Overview .......................................................................................................................................... 2

Outline ....................................................................................................................................................... 2 Learning Outcomes .................................................................................................................................... 2

Intro to Agile Software Development ............................................................................................................ 3 Introduction ............................................................................................................................................... 3 How Did We Get Here? .............................................................................................................................. 3 Agile Development Frameworks................................................................................................................ 5

The Agile Manifesto ....................................................................................................................................... 8 The Manifesto for Agile Software Development ....................................................................................... 8 The 12 Principles of Agile........................................................................................................................... 9 Declaration of Interdependence .............................................................................................................. 11 Which Method Is Right for Me? .............................................................................................................. 13

The Importance of User-Centric Design ...................................................................................................... 14 Introduction ............................................................................................................................................. 14 Why is Design Important? ....................................................................................................................... 15 Empathetic Design with Design Thinking ................................................................................................ 16 The Non-Linear Nature of Design Thinking ............................................................................................. 16

Summary ...................................................................................................................................................... 17 References ................................................................................................................................................... 18


Study Guide

Module Overview

The use of agile software development methodologies has exploded over the past 20 years. In fact,

several surveys indicate that agile frameworks are ubiquitous in most organizations and are used for

at least some of their product development work. As agile matures, the frameworks and techniques

used by practitioners have evolved as well with many company adapting agile to fit their project

environments. As a result, we have an explosion of fit-for-purpose methodologies, tools and

techniques that organizations can use to more effectively deliver human-centric software solutions. In

this section, we’ll introduce you to the history of agile, provide an overview of several of the more

popular agile methods, and orient you towards user-centric design.

Outline

• Introduction to agile software development through agile’s guiding vision, purpose and

principles

• How are the agile methodologies different?

• How do I select the right methodology?

• An introduction to user-centric design

• Using Design Thinking to understand what your users want

Learning Outcomes

The expected learning outcomes for this section of the course are:

• Learn what agile is and why it’s important

• Understand agile methods might be appropriate for a project

• Identify how user-centric design relates to agile

• Leverage Design Thinking to understand what’s important to your users


Intro to Agile Software Development

Introduction

As organizations increase their reliance on technology platforms, technology initiatives expanding or

enhancing existing capabilities, or enabling new capabilities, are growing ever more complex. A 2012

study conducted by the strategy consultancy firm McKinsey & Company found that half of all large IT

projects (more than $15 million in initial costs) vastly exceeded their budgets during implementation.

Their research showed that large IT projects run 45% over budget, exceed the expected project

duration by 7%, while only delivering 56% less value than predicted (Bloch, Blumberg & Laartz,

2012).

For decades, organizations have struggled with large IT project implementations. In 1995, The

Standish Group in their annual “Chaos Report” noted that American companies and government spent

$81 billion dollars on canceled software projects. At that time, the recorded success rate for IT

projects was a mere 16%, while challenged projects accounted for 53%, and canceled at 31%. Their

research showed that the three top reasons contributing to project failure included lack of user

involvement, lack of executive involvement, and poor articulation of requirements (The Standish

Group, 1995).

With a history of poor technology project implementations in a world of increasing complexity, how are

organizations responding? Let’s take a look at how technology projects have been traditionally

delivered and the need for change.

Video: Intro to Agile

https://player.vimeo.com/video/196638751

How Did We Get Here?

In the period after World War II, the statistician Dr. W. Edwards Deming went to Japan to work with

manufacturers on improving quality and efficiency in industrial processes. Deming popularized a

quality cycle outlined by Dr. Walter Shewhart in the 1930s, known as the Plan-Do-Check-Act (PDCA)

cycle (also referred to as the Shewhart or Deming cycle). The PDCA is the foundation of the total

quality management (TQM) methodology. The goal of TQM is to improve customer satisfaction by

https://player.vimeo.com/video/196638751


delivering high quality products through a systematic approach. The PDCA cycle advocates planning of

the work, performing (or doing) the work according to the plan, checking comparing work completed

against the plan, and acting to remove sources of variation in the process.

Over time, this approach to process quality in manufacturing was adapted to the software

development processes in the form of the software development lifecycle (SDLC). The SDLC is the

original “waterfall” process and follows a highly-structured sequence of events from analysis and

design, development, testing and release. The SDLC provides the underpinnings of the traditional

software development model, most popularly used in methodologies such as the Project Management

Institute’s project management methodology and the PRINCE2 method developed by the UK

government and widely used in Europe.

The waterfall model follows a basic five-phase sequential approach:

The primary criticism of this method is that requirements and design are performed up front when

little may be known about the desired outcome. The project team seeks to understand, define, and

document all project criteria before development work begins. While this method works well where the

project domain is well understood (like building a house!), it doesn't work well for projects where the

end result could be ambiguous.

Around the early 1990s, there was growing acknowledgment that the SDLC might not always be the

right method to deliver complex software development projects. Frustrated with the waterfall

approach, a number of practitioners set out to find ways to more effectively develop software


solutions. While the frameworks developed by these practitioners varied widely, they all centered

around an ability to "move quickly and easily" to achieve their goals.

Agile Development Frameworks

There are a wide variety of agile development methodologies available to practitioners. In this section,

we’ll highlight three different methodologies. Scrum is the most popular, since its framework is simple

and extensible. XP provides strong technical quality approaches that can be leveraged in any agile

framework. We use Lean/Kanban methods for continuous improvement and improving time to value.

Scrum

With its lightweight project delivery approach and applicability to different types of projects, Scrum

has rapidly become one of the most widely used agile project management methods. Scrum leverages

a simple iterative framework that is appealing to organizations looking to incorporate agile into their

development processes.

Jeff Sutherland and Ken Schwaber, the founders of Scrum, derived the methodology based on product

development improvement methods published by Hirotaka Takeuchi and Ikujiro Nonaka in the Harvard

Business Review in 1986. Takeuchi and Nonaka (1986) suggested that “a holistic or “rugby” approach

– where a team tries to go the distance as a unit, passing the ball back and forth – may better serve

today’s competitive requirements.” (p.137).

Sutherland began to apply the Scrum process to a software engineering project at Easel Corporate in

1993:

“We realized we needed a development process that fit an enhanced version of rapid

application development, where visualization of design could result immediately in working

code…Our…model was motivated by the Japanese approach to new product

development…What intrigued us was Hirotaka Takeuchi and Ikujiro Nonaka’s description of the

team-building process for setting up and managing a Scrum. The idea of building a self-

empowered team where everyone had the global view of the product on a daily basis seemed

the right one…The primary driver for beginning the first Scrum was absolute commitment to a

date, where failure would break the company…I told the CEO that in adopting Scrum, we set

the objectives at the beginning of what Scrum refers to as a spring. It is the team’s

responsibility to determine how best to meet those objectives. During the sprint, no one can


bother team members with requests. At the end of a spring…working code will be

demonstrated so you can see the progress made. You can decide to ship anytime or do

another sprint to get more functionality. Visible working code provides more confidence than

extensive documentation with no operational system.” (Sutherland, 2004).

Scrum structures work into cycles called “sprints” of typically no more than 30 days in duration.

During a sprint, the development team selects customer requirements from a prioritized list called the

product backlog. This allows the team to focus on functionality that will deliver the most value to the

customer. The goal at the end of each sprint is to demonstrate incremental functionality to the end

users for feedback. Sprints roll into a pre-determined release schedule; a release may encompass

several sprints.

eXtreme Programming (XP)

XP is a software development methodology that focuses on rapid analysis, design, coding and testing

cycles within short iterations, typically one week in duration. The emphasis on face-to-face

collaboration eliminates the need for the team to run through long requirements, design and testing

phases. Within each iteration, the team selects several user stories and completes all development

phases for each story. The software is deployed on a weekly basis for review and feedback. A key

component of XP is the sophistication of the team’s testing practices, which are highly automated.

While not widely used as a standalone development methodology, XP's technical practices are often

integrated within other delivery frameworks, such as Scrum.

XP is based on four core values – simplicity, communication, feedback and courage – and twelve

supporting practices:

• Planning Game

• Small Releases

• Customer Acceptance Tests

• Simple Design

• Pair Programming

• Test-Driven Development

• Refactoring

• Continuous Integration

• Collective Code Ownership

• Coding Standards


• Metaphor

• Sustainable Pace

(Shore and Warden, 2008)

Kanban

Kanban (a Japanese term loosely meaning “visual signal”) is also a technique used within lean

manufacturing methods. Kanban is a component of a pull system, designed to increase flow within a

workstream. The purpose of a pull system is to control the movement of work-in-progress. This keeps

work from piling up at different points in the process.

Applied to software development, Kanban is a method for managing projects with an emphasis on

continual flow of work. Depending on which source you reference, there are between three and six

agile Kanban principles. Here are the most commonly cited:

• Visualize workflow: by making information visible to the project team, it becomes easier to

communicate, organize and manage

• Limit work in progress (WIP): within Kanban, teams often use a Kanban board to help them

visualize workflow and monitor the work in progress; tasks are placed in different stages of

work, as work is completed new tasks are selected; the team can easily see what’s being

worked on and where it is in the development cycle; the approach helps teams to not commit

to too much work at one time

• Enhance flow: the visualization of WIP helps the team create flow in their development

process; flow is represented by a continuous workstream with no or limited delays or

interruptions to WIP; this increases team productivity

• Make processes explicit: within lean, flow is established through standard work; that is,

standard operating procedures defining the work process are defined and understood by the

project team; process consistency helps the team streamline their work effort

• Improve through collaboration: since the team owns their process, they should work together

to identify and promote improvements in the process

As we go throughout the course, we will utilize all three frameworks in our course project.


The Agile Manifesto

In 2001, several leading practitioners and proponents of these “light” software development

methodologies convened at a resort in Utah. The group shared best practices, identified common

themes, and ultimately outlined a common purpose for agile practitioners. This purpose statement

became The Agile Manifesto and established the grounding principles behind the Agile philosophy for

software development.

The Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. (Beck et

al., 2001)

Let’s briefly take a look at each pair statement:

• Individuals and interactions over processes and tools: This principle highlights the value

of people the core of the project’s success. Processes and tools are important, but people get

the work done. Agile emphasizes teamwork and collaboration.

• Working software over comprehensive documentation: Agile’s focus on delivering

customer value places an emphasis on getting working software into customer hands quickly.

Achieving customer value takes priority over tasks (like documentation) that may not add

value to the project.

• Customer collaboration over contract negotiation: A primary difference between

traditional waterfall methods and agile is that the customer a critical ongoing resource to the

http://agilemanifesto.org/


delivery team. In an agile project, customer needs drive delivery. This is a counterpoint

to viewing requirements as a contractual obligation, regardless of whether those requirements

are actually relevant at the time the project is delivered.

• Responding to change over following a plan: Agile’s original intent was to facilitate better

delivery of working, relevant software to end users. Anyone who has worked on a software

project knows how quickly requirements or business needs change. The ability to adapt to

customer needs is a critical point of difference in agile.

The 12 Principles of Agile

In conjunction with the four agile values outlined in the Manifesto, there are 12 principles for agile

that help reinforce the core concepts:

• Our highest priority is to satisfy the customer through early and continuous delivery

of valuable software.

o Agile teams continuously deliver working software into the hands of their customers.

Customers determine the meaning of value by prioritizing their needs.

• Welcome changing requirements, even late in development. Agile processes harness change

for the customer's competitive advantage.

o Unlike waterfall methods, agile projects adapt to (and expect!) changing requirements.

The ability of the team to quickly respond to customer needs provides competitive

advantage in the delivery of relevant software.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a

preference to the shorter timescale.

o While the delivery cycles may be variable for different teams, they are designed to be

short so that customers can get their hands on working software throughout the

project. Methods like Scrum typically use one month iterations, while XP may deliver

on a weekly basis.

• Business people and developers must work together daily throughout the project.


o Agile brings the business and technology groups together, avoiding go-betweens and

poor translation of requirements. The business is engaged throughout the project, and

often shares the same physical space as the team.

• Build projects around motivated individuals. Give them the environment and support they

need, and trust them to get the job done.

o Agile trusts and empowers the people that perform the work. Agile teams are self-

organizing and determine how the work will be performed. Management’s

responsibility is to create an environment where these teams can work effectively, free

from organizational barriers.

• The most efficient and effective method of conveying information to and within a development

team is face-to-face conversation.

o Informal conversation forms the backbone of agile projects. Communication is

transparent across the team and takes place in the open.

• Working software is the primary measure of progress.

o Unlike plan driven delivery approaches that rely on a significant amount of

documentation deliverables that can quickly become out of date, agile projects focus

on working software.

• Agile processes promote sustainable development. The sponsors, developers, and users should

be able to maintain a constant pace indefinitely.

o The concept of creating a sustainable pace is key in agile. Teams develop a rhythm in

their incremental delivery that reduces the need for the last-minute push at the end of

a project. This helps the team reduce burnout.

• Continuous attention to technical excellence and good design enhances agility.

o A focus on quality and design upfront makes it easier for the team to reuse or adapt

their work.

• Simplicity--the art of maximizing the amount of work not done--is essential.


o While embedded in all agile methods, this is particularly important in Lean, with its

ruthless focus on minimizing process waste and maximizing customer value.

Everything the team does should be value-add to the customer.

• The best architectures, requirements, and designs emerge from self-organizing teams.

o Self-organizing teams decide how the work will be done and who will work on it.

• At regular intervals, the team reflects on how to become more effective, then tunes and

adjusts its behavior accordingly.

o Agile retrospectives at the end of each iteration allow the team to identify what works

well (and should be maximized) along with what can be improved. The team

continually improves their processes throughout the project.

(Beck, et al, 2001)

Declaration of Interdependence

In 2005, many of the original authors of the Manifesto convened with other project leaders to continue

developing the core principles behind agile delivery. The output of that meeting was the Agile

"Declaration of Interdependence": a set of guidelines focused on management principles beneficial to

achieving an agile “mind-set" in product and project management.

The purpose behind the declaration is simple: Project teams form an interdependent group and are

not merely a group of individuals. The declaration recognizes that projects expand beyond

development teams and encompass a broader customer and stakeholder community. The absence of

this interdependence, according to the authors, is likely to result in project failure.

We are a community of project leaders that are highly successful at delivering results. To achieve

these results:

• We increase return on investment by making continuous flow of value our focus.

• We deliver reliable results by engaging customers in frequent interactions and shared

ownership.

• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.


• We unleash creativity and innovation by recognizing that individuals are the ultimate

source of value, and creating an environment where they can make a difference.

• We boost performance through group accountability for results and shared

responsibility for team effectiveness.

We improve effectiveness and reliability through situationally specific strategies, processes and

practices. (Anderson, et al., 2005)

Each value is important on its own, but together form an interdependent set of principles. The

concepts of value, interactions, anticipation, empowerment, shared accountability, and adaptability

together form the agile approach to software development projects. The importance of delivering

reliable results is emphasized through the creation of value through the delivery lifecycle.

In the Declaration of Interdependence, Jim Highsmith states: “Each of the means statements conveys

what this group thinks are the most important aspects of modern dynamic to fit the needs of projects

and teams. Other styles of project management are more prone to standardization and prescriptive

processes.” (Anderson, et al., 2005)

Principle Description

We increase return on investment by making

continuous flow of value our focus.

The focus of the effort should be on

providing customer and business value

versus task completion.

We deliver reliable results by engaging

customers in frequent interactions and

shared ownership.

Customers should be engaged with

frequently. Ownership is shared across

the project team and the customers.

We expect uncertainty and manage for it

through iterations, anticipation, and

adaptation.

Instead of following a rigid plan or

approach, anticipate using the

information you have at hand and adapt

through interaction and feedback.


We unleash creativity and innovation by

recognizing that individuals are the ultimate

source of value, and creating an environment

where they can make a difference.

High performing teams are enabled by

empowered individuals. Provide an

environment where team members are

supported and encouraged.

We boost performance through group

accountability for results and shared

responsibility for team effectiveness.

Teams that encourage shared

accountability are more likely to work

together to solve problems and

complete the work at hand.

We improve effectiveness and reliability

through situationally specific strategies,

processes and practices.

While the methodology provides a

framework for project delivery,

recognize that any approach will require

adaptation to meet the needs of the

project and team.

Source: Anderson, et al., 2005

Which Method Is Right for Me?

Agile methodologies are not appropriate for all types of projects (even software development!) or

organizations, and using an agile methodology is not a guarantee of project success. Agile delivery

works best in environments where organizations can adapt and flex as needs change, delivery teams

are comfortable with ambiguity, and the organization has a customer-first focus.

A 2018 survey of 1,492 technology professionals identified the most popular methodologies utilized by

the software development community (VersionOne, 2018). Scrum and Scrum variants are by far the

most popularly utilized methodologies. Interestingly, not only are a large percentage of companies

adapting the methodologies to fit into their organizations, but we’re also seeing an increase in hybrid

methodologies that leverage right-sized practices from several of these methods to about 28% of

organizations surveyed (including waterfall!).


How you select a methodology depends on your organization, your culture, and the type of project

that you’re working on. If you’re new to agile, Scrum may be a good place to start as it provides a

simple framework that can expand and scale as your team gains confidence and maturity.

While the primary users of agile are software developers, keep in mind that the agile philosophy grew

out of consumer product goods companies with strong design practices, so agile is applicable to more

than just software development.

For an example of how you might select an agile versus a waterfall project management methodology,

check out the five-minute video below:

<<GENESIS CONSULTING VIDEO>> (https://www.youtube.com/watch?v=jL1VOF5JgPQ)

Common barriers to agile adoption include:

• Ability to change the organizational culture

• Trying to go agile in a non-agile framework

• Resistance to change

• Availability of skills

• Management support

These top challenges all deal with elements of organizational and cultural changes, which is why it is

critical that the organization is committed to creating an environment where an agile team can be

successful.

The Importance of User-Centric Design

Introduction

Noticed how we started our module with an introduction into software delivery methodologies? That’s

helpful if we know what we’re going to build, who were building for, and why it’s important, but it’s

not an ideal starting point. In fact, the real starting point is to create a design for your product that

delights users. Before we can start building our product, we need to define and design it from a user-

centric perspective. In this section, we’ll look at why design is important and provide an overview of

Design Thinking to get us started on our product development journey.

https://www.youtube.com/watch?v=jL1VOF5JgPQ)


Why is Design Important?

The discipline of design thinking emerged out of traditional product design work as a way to put

design concepts within reach of a broader audience. The process facilitates a new way of designing

products and services that address real customer needs and desires.

Design isn’t just about how things look: It’s about how things behave. One designer defines design as

a discipline: “The creation of a product our service with the intention of improving human experience

with respect to a specified problem” (Olsen, 2017). Our goal with design is to improve the human

experience. The spectrum of design represents the products and services we create and how humans

interact with those products and services.

Consider an example:

An airline company is looking to reduce the number of complaints received after customers

miss their flights. A design thinker might consider the anxiety a person feels when they miss a

flight and how that anxiety might be reduced by providing quick, frictionless access to

customer service. To the design thinker, the objective is not to try to reduce the complaint

rate of passengers in general, but to reduce the pain points and improve the experience of

individual passengers. A corporate objective of reducing complaint rates would likely be

achieved, but the design thinker believes the quickest and most reliable way to get good

aggregate results is by focusing on improving individual experience. (Olsen, 2015)

Design thinking focuses problem solving around the customer, a practice called empathetic design.

Empathy is the human emotion that helps us channel others' experiences in a way that we can use to

improve that experience. The empathetic process of design thinking involves learning from others

through direct research - conversations and interactions - with our users. When the design process

addresses the needs and pain points of your intended audience, you're likely to come up with a

solution that more specifically addresses their needs.

“Design thinking intimidates people – it almost feels like it’s a different skill set than what us

normal people can do. When you think of design, your mind immediately goes to fashion, and

I can’t even pick out two things that can be worn at the same time. But what we’re really

trying to do here is make sure we’re building something the way a buyer would like to have

it.” - Dave Jarrett, CPA (Liedtka & Ogilvie, 2011)

https://medium.com/the-design-innovator/https-medium-com-the-design-innovator-so-what-is-design-anyway-4f99128b51c4

https://medium.com/the-design-innovator/https-medium-com-the-design-innovator-so-what-is-design-anyway-4f99128b51c4


Design is an important aspect of everything around us. “Design makes ideas tangible so that they can

be understood and evaluated before committing them to reality.” (Wodtke, 2017)

Check out this short video on Why Design Matters: https://youtu.be/J6LtABooE2c

Empathetic Design with Design Thinking

Design Thinking is a design methodology that provides a solution-based approach to solving problems.

It’s extremely useful in tackling complex problems that are ill-defined or unknown, by understanding

the human needs involved, by re-framing the problem in human-centric ways, by creating many ideas

in brainstorming sessions, and by adopting a hands-on approach in prototyping and testing.

Understanding these five stages of Design Thinking will empower anyone to apply the Design Thinking

methods in order to solve complex problems that occur around us — in our companies, our countries,

and even our planet.

In his 1969 seminal text on design methods, “The Sciences of the Artificial,” Nobel Prize laureate

Herbert Simon outlined one of the first formal models of the Design Thinking process. Simon’s model

consists of seven major stages, each with component stages and activities, and was largely influential

in shaping some of the most widely used Design Thinking process models today. There are many

variants of the Design Thinking process in use today, and while they may have different numbers of

stages ranging from three to seven, they are all based upon the same principles featured in Simon’s

1969 model.

This course focuses on the five-stage model proposed by the Hasso-Plattner Institute of Design at

Stanford (d.school). d.school is the leading university when it comes to teaching Design Thinking. The

five stages of Design Thinking, according to d.school, are as follows: Empathize, Define (the problem),

Ideate, Prototype, and Test.

The Non-Linear Nature of Design Thinking

In this section, we’ve outlined a sequential Design Thinking process in which one stage leads to the

next with a logical conclusion at user testing. However, in practice, the process is carried out in a

more flexible and non-linear fashion. For example, more than one stage may be conducted

concurrently by different groups within the design team, or the designers may collect information and

prototype during the entire project so as to enable them to bring their ideas to life and visualize the

https://youtu.be/J6LtABooE2c


problem solutions. Also, results from the testing phase may reveal some insights about users, which in

turn may lead to another brainstorming session (ideation) or the development of new prototypes.

It is important to note that the five stages are not always sequential — they do not have to follow any

specific order and they can often occur in parallel and be repeated iteratively. As such, the stages

should be understood as different modes that contribute to a project, rather than sequential steps.

However, the amazing thing about the five-stage Design Thinking model is that it systematizes and

identifies the 5 stages/modes you would expect to carry out in a design project – and in any

innovative problem solving project. Every project will involve activities specific to the product under

development, but the central idea behind each stage remains the same.

In our first assignment, we’ll focus on the Empathize phase of Design Thinking. This helps us gain an

empathic understanding of the problem we are trying to solve. This involves consulting experts (your

users or target audience) to find out more about opportunity areas through observing, engaging and

empathizing with people to understand their experiences and motivations This process allows you to

immerse yourself in the physical environment to have a deeper personal understanding of the issues

involved. Empathy is crucial to a human-centered design process such as Design Thinking, and

empathy allows design thinkers to set aside his or her own assumptions about the world in order to

gain insight into users and their needs.

Depending on time constraints, a substantial amount of information is gathered at this stage to use

during the next stage and to develop the best possible understanding of the users, their needs, and

the problems that underlie the development of that particular product.

Summary

With agile software development becoming a de facto delivery standard, agile frameworks are now

widely used by companies across all industries as a software development and implementation best

practice. Agile seeks to improve the interactions between development teams and stakeholders,

provide working software to customers on a frequent basis, promote communication and collaboration

internally and externally from the development team, and help the teams effectively manage and

adapt to change in the project environment. Agile differs from waterfall project management methods

in its approach to incremental delivery, acceptance of change throughout the project, customer

collaboration and team empowerment. Many organizations adapt agile practices to fit their


environments, and may even incorporate elements of traditional waterfall methods alongside agile

frameworks.

A key tenet of agile is user-centricity. We take that user-centric approach by framing our initiatives

around what’s important to our customers. The Design Thinking framework helps us gain that

understanding so that we can design and develop products that people love.

References

Anderson, D., Augustine, S., Avery, C., Cockburn, A., Cohn, M. et al. (2005). Declaration of

Interdependence. Retrieved July 1, 2013, from pmdoi.org

Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W. et al. (2001). The Agile Manifesto.

Retrieved July 1, 2013 from agilemanifesto.org

Bloch, M., Blumberg, S. & Laartz, J. (2012). “Delivering large-scale IT projects on time, on budget,

and on value.” Retrieved online

from http://www.mckinsey.com/insights/business_technology/delivering_large-

scale_it_projects_on_time_on_budget_and_on_value

Liedtka, J. & Ogilvie, T. (2011). Designing for Growth: A Design Thinking Toolkit for Managers. New

York, NY: Columbia University Press

Olsen, T. (2015, January 14). “Design thinking, unboxed.” Retrieved from: https://medium.com/the-

design-innovator/design-thinking-unboxed-1476f7c88641

Olsen, T. (2017, March 03). “So, what is design anyway?” Retrieved from: https://medium.com/the-

design-innovator/https-medium-com-the-design-innovator-so-what-is-design-anyway-4f99128b51c4

Shore, J. & Warden, S. (2008). The Art of Agile Development. Sebastopol, CA: O’Reilly Media

Sutherland, J. (2004) “Agile Development: Lessons Learned from the First Scrum.” Retrieved online

from: https://pdfs.semanticscholar.org/8f37/973e26b11fc1120ad1291df2c83df67704b6.pdf

http://pmdoi.org/

http://agilemanifesto.org/

http://www.mckinsey.com/insights/business_technology/delivering_large-scale_it_projects_on_time_on_budget_and_on_value

http://www.mckinsey.com/insights/business_technology/delivering_large-scale_it_projects_on_time_on_budget_and_on_value

https://pdfs.semanticscholar.org/8f37/973e26b11fc1120ad1291df2c83df67704b6.pdf


Takeuchi, H. & Nonaka, I. (1986) “The New, New Product Development Game.” Harvard Business

Review 64, no. 1 (January-February 1986)

The Standish Group (1995). The Chaos Report. Retrieved

from https://www4.in.tum.de/lehre/vorlesungen/vse/WS2004/1995_Standish_Chaos.pdf

VersionOne (2018). The 12th Annual State of Agile Development Survey. Retrieved online from

https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report

Wodtke, C. (2017, August 26). “How I stopped worrying and learned to love design thinking.”

Retrieved online from: https://medium.com/@cwodtke/how-i-stopped-worrying-and-learned-to-love-

design-thinking-f1142bab60e8

https://www4.in.tum.de/lehre/vorlesungen/vse/WS2004/1995_Standish_Chaos.pdf

https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report

https://medium.com/@cwodtke/how-i-stopped-worrying-and-learned-to-love-design-thinking-f1142bab60e8

https://medium.com/@cwodtke/how-i-stopped-worrying-and-learned-to-love-design-thinking-f1142bab60e8

Module 1 Intro to Agile Software Development€¦ · • Introduction to agile software development...

Documents

Transcript of Module 1 Intro to Agile Software Development€¦ · • Introduction to agile software development...