Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
© 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
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
• 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.
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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.
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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.
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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.
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
• 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.
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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!).
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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.
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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)
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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
© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved
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