DT Agile DevOps External PoV 20170316

IBM Design Thinking+Agile+DevOps
ITERATIVE OUTCOME DELIVERY POV

Version 1.0
Executive Summary
TODAY , software products and services evolve TODAY , a highly performant team can deliver
and transform **just in time** even as they are in game-changing improvements to a product in a
use. With the users’ needs growing and evolving, 2-week sprint. Facebook can release new code
they expect our offerings to grow and evolve twice a day. Amazon deploys new code, on
too––but if we fail to meet their needs, our users average, every 11 seconds. We’re seeing the
are free to end the relationship…. time between a design or development decision
or simply **unsubscribe** and a user outcome approaching to zero.
Marcel Greutmann
As our customers move from purchasing products to subscribing to services, **_we_ have to adopt a new
General Manager
AGILE Professional Services
understanding of the way we design, develop and deliver our software and services** How do we better
understand our users? How do we deliver quality outcomes? And how do we do it at the speed and scale
demanded by our users and clients?
While these three frameworks come from different backgrounds, we’ve come to a single conclusion: a world
of continuous change requires continuous conversation between our users, their needs, and the teams that
solve for them.
IBM Design Thinking AND Agile DESCRIBES THE CONVERSATION WE SHOULD HAVE.
DevOps PRACTICE ENABLE US TO MAKE THAT CONVERSATION CONTINUOUS.
WE HOPE YOU ENJOY THIS POV, AND APPLY WHAT YOU LEARN FROM IT ON YOUR UPCOMING CLIENT ENGAGEMENTS.
Iterative Outcome Delivery POV

© 2016 IBM Corporation 1
Contents
1 EXECUTIVE SUMMARY
2 CONTENTS
3 WHY WE NEED THESE TECHNIQUES ?
4 OBJECTIVES OF THIS POINT OF VIEW
5 THE E2E FLOW FOR ITERATIVE OUTCOME DELIVERY

6 STRATEGY & DISCOVERY
9 ITERATION 0
16 ITERATION 1 - N
26 HOW DOES THIS APPLY TO DIFFERENT TYPES OF ENGAGEMENTS ?
27 REFERENCES

Why we need these
techniques ?
Practitioners are unclear about why, when and how to
use IBM Design Thinking, Agile and DevOps on client
engagements. Therefore, we need to clarify how these
techniques interweave to deliver the best possible
business outcomes for our clients.
To date, many practitioners have held the belief that simply following Agile practices is enough
for iterative outcome delivery, but in fact this is not true. Agile empowers teams to be far more
responsive to the users’ needs, however, it does not help teams to focus on the user experience,
which is what IBM Design Thinking does so well. Further, simply using Agile to quickly get
outcomes is not necessarily going to lead to value gained by the end user, and for this reason,
Dev Ops techniques must also be employed. So, to put it simply, all three of these techniques
cannot be used effectively in isolation. A truly successful project delivery requires all three of
them used together. IBM Design Thinking, Agile and DevOps, are the three techniques or
practices which are essential for any user-centered client engagement and iterative outcome
delivery.

Objectives
When teams understand the power of these three techniques used together, they can deliver
user-centered outcomes that exceed client expectations, and which are iteratively delivered with
c ontinuous feedback from the client, and ultimately delivered to the market faster.
of This Point Of View Therefore, it is very important for all GBS service lines and IBM teams as a whole, to acquire a
common vision for how to approach client engagement and delivery of targeted outcomes, and
then confidently begin using these techniques to design and deliver those outcomes at speed
and scale.
The key objectives of this POV are to:
Clarify for our practitioners, the importance of using all three techniques together, and exactly
how all three techniques are interwoven
Explain how and when all three techniques are used on different types of engagements in
order to achieve the best possible business outcomes
Communicate a consistent message across all of GBS and IBM as a whole, on what is the
best approach to deliver user-centered outcomes; fast, and to
Empower our go-to-market teams with the right messages to communicate with our clients
regarding IBM’s value proposition for delivering user-centered iterative outcomes at speed and
scale

The E2E flow
To help illustrate the steps that are required end-to-end to design and deliver a user-centered
outcome, we developed the following flow. It depicts the different stages of outcome delivery starting
with strategy, then moving on into discovery and iteratively delivering outcomes that introduce value
for iterative outcome delivery to the end user.
End to end flow for

user-centered outcome
delivery through IBM
Design Thinking, Agile and
DevOps

Strategy & Discovery The E2E flow
for iterative outcome delivery
“Strategy & Discovery” in a client engagement is a core collaborative practice used to help a team
determine what to do next. It is a part of Agile at every step from portfolio to delivery.
The goal of Discovery is not just to answer the question what to do next, but to reach true shared
understanding across a group of people.
All types of discovery use the same basic steps —understand the current situation, decide where you
want to be, brainstorm and choose the way to get to the outcome and then get a sense of the work to
be done.
How much time you take on each step and what activities or techniques you use depends on your goal.
We will be referring to different techniques which include collaborative thinking techniques as well as the IBM Design Thinking Loop for understanding your users’
and clients’ world in order to get to know their organization. Depending upon where you are from a Strategy perspective, we often use the Accelerated Visioning
offering to collaborate with clients, to rapidly focus on the needs of users, journey them and outline a blueprint, roadmap and form of a prototype – all before we
ever get to decide if we’re going to take something into delivery – The Accelerated Visioning model has been “VERY SUCCESSFUL” and we’ve executed it with
dozens of clients.
The first step is get clarity on the idea and fully understand
“Where are we NOW?”
For new business opportunity discovery, you’re viewing the new market idea in relation to what we do now.
What are we doing now in this area? What are we missing?

It’s important to really dig into this using techniques such as silent brainstorming, affinity mapping, five (5) whys root cause analysis, so what? Impact analysis,
Value Stream Mapping, personas, empathy mapping, scenario mapping, assumption mapping— whatever techniques you believe shed light on the topic. Also,
this is where any design research data would be shared with the team. Additionally, user research may be conducted prior to discovery, or continuously
throughout. Again, this is an area where IBM Design Thinking plays an important role. It will be up to you and your team to choose the appropriate techniques
and activities in your toolbox.
Further, don’t cut discovery steps Resist the pull to jump to solution Next, the group uses all the insights you gained from the previous stage,
short even if you think you already ideas yet. Spend a good amount and focuses on the question “Where you want TO BE”. Come up with high
have a clear grasp of the topic on of time understanding where you level outcomes (hypotheses) which will describe your end state when the
the table. are NOW. idea has been implemented or the problem has been solved.
This is about high-level outcomes, not solutions. Where do you want to be,
not how will you get there? What will your company’s place in the market
be or what will the user be able to do or how will your team be functioning
once you’ve fixed the problem? Find a few outcomes and come up with
how you’d measure these outcomes and get a sense of where you want to
be in 6 months, 1 year, and 3 years.
Finally, you can start to think about how do we GET THERE? For this step,
you need to firstly figure out what will likely get in the way as you take
various approaches. What are the blockers you will likely encounter as
you move toward your identified outcome? Having a good understanding
of potential blockers will help inform the solution you eventually choose.
This is a good time for brainstorming—you don’t want to miss any
potential blockers. Again, don’t short change this.

Sometimes this process brings up other problems in your current situation that might affect your outcomes. Discovery is a technique for learning, and
sometimes it’s iterative and you have to go back and revisit previous stages.
Now you want to determine what is your path forward?

You want to develop a rough high level plan for how you will work your way to the outcome.
Keep the blockers in mind here.
How will you go over, under, through or eliminate your blockers?
At this stage, you should only be drawing a rough roadmap and picking the solution you will use.
Now that you’ve chosen the path to your outcome that avoids the things
in your way, you need to determine what do you need TO DO?
Again, use only the appropriate level of detail here: For business opportunity
discovery, you only need to determine the large pieces of work and ideas for a
Minimum Viable Product, if appropriate.
As this point, you are getting ready for Implementation and Delivery
Remember , these steps are just a guide. Sometimes you’ll find you need to
adjust or repeat some steps as you learn more. Just be sure you understand the
purpose for each and don’t lose the benefits. Each step is very important.

The E2E flow
Iteration 0 for iterative outcome delivery
At the start of any project, there are lots of very important things that the team has to do so that, at the start of the first Iteration, they can hit the ground running.
This is why we have an Iteration 0 at the start of new projects. The duration of Iteration 0 completely depends upon whether this team is already formed,
whether they have been working on similar things, or whether there is new development technology that needs to be set up.
As a rough guide, at best it’s 1 iteration long (that is, 2 weeks), at worst,
you wouldn’t want to take longer than 3 iterations, which is 6 weeks. Generally, 2 iterations or 4 weeks is the norm for new teams.
It is important to start building customer value quickly, but you can’t skip
important pre-work a team needs to do. “Just enough" means “no more”
but it also means “no less”. Some teams dive into coding too quickly. They
find out too late that they were building the wrong thing, and they need to
do some more planning ahead before they started. Some teams spend too
much time on design up front. They try to get everything figured out before
coding. In order to avoid either of these situations, your team needs to
discuss and strike the right balance.
First do whatever is necessary to set up the teams. For example, if this is an

existing team with technological tools already set up, some of these won’t
apply.
However, if it's a new team, the team will need to take the time to “form” as
a team. They should discuss collaboration standards, processes and tools
for working together. They’ll need work out a Social Contract. In most cases
for new teams, there is an evolution and harmonization period required for
any team to advance their fluidness and working relationship.

The E2E flow
Does the team need any training in
Agile ? IBM Design Thinking Training ? Any other training ?
They’ll need to set up team walls such as risk and issue walls.
Do they have the development and test environment they need, such as an automated delivery pipeline for continuous integration and deployment setup? Are
these tools in place? Are their client challenges with VPN access? Remote, or distributed teams that need to align and work together? Forming empathy for
each other and focusing on team building exercises can significantly improve the overall output of a newly formed team.
These tasks are essential to be effective on the first day of Iteration 1. We list them here at the start but they can be done whenever it’s appropriate anytime
throughout Iteration 0.
Another very important element is for everyone to share a team-wide sense of purpose. Some type of presentation is needed to get this shared understanding
and clarity of the desired outcome of the project.
The team needs to understand the Goals and Strategy of the project. The next step is to build on and elaborate on the insights that came out of the
They need to understand the Hills that have been defined, what they Discovery process.
will be delivering and why. This is often where executives put the work The team should take the high level guidance from the Discovery team, confirm
in the context of the high level strategy for the whole group. or adjust the assumptions, and break down the work to the Story level.
Here is where an IBM Design Thinking workshop fits perfectly, as it helps to develop a common vision upfront.

The E2E flow
Keeping in mind the preliminary epics and features which came out of Discovery, an IBM Design Thinking workshop, such as an Accelerated Visioning
Workshop, will help the team diverge and ideate, exploring a range of ideas: they will think about the user with Personas and empathy mapping, explore further
with story boarding and experience mapping.
As the team breaks down the work into near team and long term user experiences, the Minimum Viable Products (or MVPs) begin to emerge.
The team then continues to converge by constructing Hills that will guide the first releases of the project.
Once the team converges on a first draft of the Hills, they can move on to
revisit the Epics and Features that came out of the Discovery process.
The epics and features that came out of Discovery were used to estimate
the kind of work that would be needed for the purposes of validating the
business idea.
Now the team has gathered much more understanding and should rework these Epics and Features in light of the focus the Hills provide.

The E2E flow
These features are then mapped into a Release Plan.

The team should then move the features from the release plan to the product backlog.
The features for the first release, MVP 1, show now be broken into stories.
Then the highest priority stories, enough for about 2 iterations, should be elaborated with acceptance criteria.
This is also the right time to do wire-framing and design work (assets) on just these top priority stories. The goal here is to get these top
priority stories ready for the development team to begin building at the start of Iteration 1.

The E2E flow
The product owner should make sure the backlog is properly prioritized.
Architectural and test strategy design should be done at this stage as well.
Once the work of Iteration 0 is complete, and the team is prepared to start work in Iteration 1, the team conducts a review of all the work done using what is
known as an “Iteration Playback”. In this case, the team is ready for Playback 0, which is the Playback for all work done in Iteration 0. During Playback 0,
theteam shares their work with the stakeholders. The goal of Playback Zero is to align stakeholders around a very concrete, shared objective, defined in terms
of the user experience and the user outcomes, and to validate that and any plans to support it, before moving into actual delivery.
Be careful to time-box where you can and work as efficiently as you can.
This is why teams do much of Iteration 0 in a face to face workshop. It’s not
very efficient or effective to do this kind of intense work remotely.
Again, the guiding concept here is "just enough to get started." No more, no less.
How much architectural design is needed? Only enough to get started.
How much database design? Just enough to get started.
How much UX design is needed? How much UI design is needed?
Only enough to get started.
No more. No less.

The E2E flow
This architectural, UX and UI design will continue throughout the Delivery stage, emerging as the team learns more and more about
what the market is looking for. Work to strike the right balance between planning ahead and letting design emerge, with a preference
for emergent design.
The IBM Design Thinking loop of "observe, reflect and make" is a continuous The loop continues through every step of Delivery, cycling through
process that doesn't end with a design workshop, but continues on an Observe, Reflect and Make.
essential part of the Delivery stage.
User tests, Playbacks, and interaction with Sponsor Users provides feedback to the team. That's the "Observe" in the loop. Every design session and backlog
refinement meeting is "Reflect". Every collaboration with designers and coders completing a story, refactoring work based on user feedback is "Make."
Technical, UX and UI design and redesign based on user feedback is an integral part
of the work of any delivery team. Designers are a core part of agile teams. Let’s look at
how design works in an Agile flow of work.
Designers work on design side by side with the Coders. Designers may need to work
ahead of the coders a bit—a few days or a couple iterations on features coming up—but
they should work on the same agile teams fully collaborating and connected to directly
create user value. They should not be in a separate group creating a hand off situation.
Further, it should be noted that once delivery is underway, there needs to be room for
discovery work while others continue with delivery work. If you consider developing a
commercial Software-as-a-Service property such as Google.com - many years after its
minimum viable product release, discovery continues today on this property. This type
of innovation is the result of ongoing discovery that takes a portion of the available
multi-disciplinary skills away from delivery on an ongoing basis.

The E2E flow
At this point, our agile teams are formed and working with the product Our teams have also developed working agreements and established core
owners, sponsor users and stakeholders to discuss doing the right work principles of our methodology. We’ve also agreed upon the appropriate
and have a clear sense of the outcomes this work will produce. time box for each iteration; typically, we are seeing about two weeks.
Additionally, we have set up our architecture, determined what automation tools we are going to use, how we ensure quality and what our DevOps
strategy is. We will revisit DevOps in the next segment. We have identified Capabilities, Epics, and User Stories from the Hills and Sub-Hills. We
have built the backlog and are actively working with our product owners, stakeholders and designers to prioritize appropriately.
Next, we have identified further discovery and research that we

may have to do and created spike stories to accomplish these
items. We have also identified what a Minimum Viable Product
look likes, what a release looks like and when we should release
our MVP.

The E2E flow
Iteration 1 - N for iterative outcome delivery
As the first iteration starts, we gather the teams to review the backlog, continue the learning and refining
Ready, Set, GO!!! process, and selecting those stories that should make up the first iteration. We may have stories that
are technical, stories that address dependencies, non-functional stories and just plain old user stories.
These build to enable capabilities that lead to the outcomes we have identified. We also have stories
called spikes – these are stories that allow us to allocate for research and discovery in our designated
times boxes but typically don’t deliver any capability.
The team should keep in mind that we are developing the solution with just the right capability that
enhances the user experience – no more, no less. Because we have understood the problem up front,
we can focus the team on what is valuable to the customer and use this to drive outcomes.
Remember The Loop? MAKE encompasses this part of agile where we are working on
stories, obtaining feedback and refactoring the capabilities that will enable the outcomes our users are
seeking.
The team then starts to work the iteration backlog, collaborate with the product owner and other teams
as well as the designers that are focused on achieving the next best experience for our user.
During each iteration, the team is focused on developing functionality that enables the elements that
contribute to the user experience. In a typical agile iteration, the team is constantly providing the
product owner with small demos of functionality that is built This fosters collaboration until the story
meets expectations and a definition of done.

The E2E flow
The team has a planned daily meeting called a Daily Stand-Up. During this meeting, the team efficiently
Observe discusses what was accomplished since the last standup, what is planned to be accomplished in the
next 24 hours and any blockers or impediments that may be present.
As we work through the iteration, we gain acceptance of user stories to meet the iteration goals. At the
end of the iterations, we should have a working product in slices of capability, completion of a research
or design spike, technical underpinnings or similar outcome. Keep in mind that our designers are
continually working on discovery; this may be within the current engagement or part of a new piece of
work.
Showing our Stuff

At the end of the iteration, we hold an iteration playback and review where the team shows what they
have accomplished. This can manifest in the form of a traditional agile demo with story review or an
iteration playback. Both have their focus areas and can be accomplished separately or in tandem.
Let’s keep the loop fresh in our mind – this is the OBSERVE part where our Sponsor Users, Product
Owners and Stakeholders have an opportunity to interact, provide feedback and hold discussions on
design. We also evaluate if our work is meeting the user expectations and providing them with the
experience that they are seeking.
The focus of a traditional iteration review is to demonstrate the stories, how the definition of done was
met, demo the capability where appropriate, and ensure that the product owner, the business and
stakeholders love the capability and its presence in the end product.

The E2E flow
We can also show to a similar audience, through an iteration playback, what we have built and obtained
Retrospective feedback on the design and if the user centric outcome was achieved. In some cases, we may not
perform the iteration playback after each iteration; as stated before the purpose is to solicit feedback
as to the achievement of user centric outcomes to ensure the that experience is as expected and
meets the hill goal.
Although we may not have playback at the end of each iteration, it is essential that we plan a delivery
playback and demo at the end of iterations when we feel that we have met the outcomes for a release
and the MVP. This playback should meet the outcomes of a hill, or a sub-hill, and provide a quality user
experience.
The Care and Feeding of the Team

Just like athletes that are agile, we need to care for and feed the team. At the end of each iteration, after
our iteration review and playback, we host what is called an iteration retrospective. In this ceremony,
we discuss what went well during the iteration, what didn’t go so well, how we can adapt to become a
stronger team and possibly, changes that we may need to implement.
As with the release playbacks, we also have a release or delivery retrospective. We again gather the
entire team, celebrate our success and identify where the team can and should improve. This is a
perfect time for a happy hour and celebration – you’ve earned it!

The E2E flow
Where do we go next?
Reflect
Once we complete iteration and ‘closing’ ceremonies, we return to the backlog as well as the design
and our discovery. We take the time to review the hills and sub-hills, discuss design with our team and
sponsor users, and work with the Product Owner to incorporate our learnings and refine design into
both the hills and backlog at the epic and story level.
Once we have incorporated these items, we again start to refine the backlog. We must revisit our
understanding of the problem and use that knowledge as we refine and prioritize.
Additionally, we can hold new design sessions to refactor our thinking and learning. REFLECT
completes our loop as we hold those conversations and design sessions. Our goal is to accelerate
the right outcome at the right time. Now remember, discovery is a continuous process as we are always
learning about our capabilities, users and the market.
We also need to look again at the Release and MVP. Are we still doing the right things? Are we still on
track? Is our user going to have the next best experience possible?
We need to be transparent with our organization; agile gives us the ability to predict when a capability
will be enabled to meet the outcomes needed for the experience.
We should exit backlog refinement and iteration planning with a renewed product backlog that is
refined, prioritized and estimated for the next one or two iterations if possible. We really don’t want to
work too far down the backlog; we want our stories to remain fresh. Once we have the iteration backlog
agreed upon, we are ready to go again.

The E2E flow
Historically, Dev and Ops teams were separate and were completely independent silos. Developers
DevOps built applications and threw them over the wall to operations, who had to make sure the application was
kept up and running all the time. This resulted in a lot of friction between the Dev teams and the Ops
teams. Over the years, the culture has been gradually changing to provide more visibility across Dev
and Ops. But what we have found is that born on the cloud companies take this concept to a whole
new level – where there is no separation between development and operations.
On the cloud, infrastructure is code, and capacity is available on-demand. Within minutes, a person can
make API calls to create a virtual server, and set up the monitoring for it. This is common among
startups building new services on the cloud. They have small integrated teams that are responsible for
the full lifecycle – from user experience design, to development, to deployment and also on-going
operations. This is a huge transformation – since the traditional distinction between Dev and Ops no
longer applies. It is just “DevOps.”
One of the key practices in DevOps is Continuous Integration and Continuous Delivery. The main value
of Continuous Integration is to minimize code integration challenges. Through the practice of
Continuous Integration, developers merge their code into the main branch frequently, and keep these
changes small – thus making integration much easier.
Similarly, the main value of Continuous Delivery is to create functionality in small incremental chunks
that can be tested and deployed into production. Smaller, more frequent releases are less risky, and
any problems detected become easier to isolate. This allows development teams to show their coding
results very quickly to their stakeholders and sponsor users, gather feedback, and improve their
offering.

The E2E flow
To enable Continuous Integration and Continuous Delivery – the team has to set up the required build
Test Driven Development automation framework, and continuous delivery pipelines. When the code is integrated into the Main
Branch, a build is automatically triggered, and build verification tests are run. Once the build passes,
the Continuous Delivery pipeline can trigger the deployment of the build artifacts into various testing
environments where system integration tests and performance tests are performed. Once the code
passes the test quality gates, it is ready to be deployed into production.
To ensure the best possible code quality, some teams find it useful to adopt the practice of “Pair
Programming”, where developers work in pairs to write the code. This allows an extra pair of eyes to
review the code and improve it as it is being written – thereby enabling knowledge transfer, and
improving code quality. Another practice is called test-driven development (TDD). A key principle of
TDD is that tests are written first, before any code is written, with the assumption that each test will
initially fail and only enough code is written to make it pass. In this process, developers make
technology choices to ensure that the code is as simple as possible, and doesn't implement functions
that are not part of the Minimum Viable Product.
One of the key concepts that we should clarify here is the relationship between Continuous Delivery
and Release Management. Traditionally, Release Management was used to manage large scale
change. There was a lot of ceremony around large releases due to many changes happening at once.
And because of this overhead, it was only viable to deliver larger releases very infrequently – typically a
few times a year. As the rate and pace of innovation and competition, heat up on the cloud – doing
yearly and quarterly releases is just not competitive enough, and hence we see a wide spread adoption
of Continuous Delivery, especially for cloud services. We see industry leading cloud teams deliver
code into production multiple times a day.

The E2E flow
In such an environment, how do we reconcile the speed of continuous delivery with traditional release
Continuous Delivery management?
With Continuous Delivery, the goal is to deliver changes to production in small incremental chunks, on
a frequent basis. But what if all the components are not ready at the same time? This is where the
concept of “Feature Flags” come in. With Continuous Delivery, code can be tested and delivered into
production with “Feature Flags” around the new code. Using these techniques, those features can be
made visible to specific audiences to allow testing of those features in a production environment. The
act of going Live can happen via a Release Event on a later date when the Feature Flags are turned on
in a coordinated way across multiple components, and the new feature is made publicly visible.
Another way to mitigate the risks of changes to applications in production is via the use of a technique
called “Canary Testing”. Here the features are activated only for a small percentage of users, and the
application performance and adoption results are measured. If those results indicate that the change
is good, then it is ramped up to the rest of the user population. If the change is not good, it is rolled
back.
Using a combination of these techniques, DevOps teams balance the needs of continuous delivery
with the requirements of Release Management.

The E2E flow
In the world of DevOps, it is not just the application features that are built this way. All of the operations
Continuous Avaliability automation is also built in a similar fashion. Operations automation stories and site reliability
engineering stories are prioritized in the backlog along with regular feature development. For example,
the team creates the deployment automation scripts and performance monitoring scripts, and stores
them along with the source code of the application. As part of the Continuous Delivery process,
multiple instances of the application are automatically deployed to maintain high availability, and the
performance monitoring scripts that match the new build, are deployed to the monitoring tool.
When there is a failure of the application, global operations teams quickly triage the incident to
understand if it is an infrastructure issue or an application issue. In parallel, the automated monitoring
and alerting systems also notify the DevOps engineer on-call at that hour. This approach builds
empathy in the developers towards the unique challenges of providing 24x7 and 365 days of
operational support – and this helps the developers make sure that when they write code, the code is
sufficiently tested to ensure high quality, and that it is logged and monitored to detect faults, and quickly
recover from faults.
This new approach towards Continuous Availability represents the industry-leading best practice for
integrated DevOps teams – where developers don’t just throw the code over the wall to operations, but
are an integral part of building the operations automation, and ensuring the operational success when
delivering the service.

The E2E flow
With the advent of continuous delivery – enterprise customers worry that it is also possible to
Continuous Security continuously introduce security vulnerabilities. Over the years, various secure engineering practices
have been developed, that provide guidance to developers on how to build secure code. These
practices are being integrated into the Continuous Delivery process. Source code scanning tools, and
vulnerability scanning tools are run automatically when new code is built and tested, and issues are
flagged if they are detected. Periodic network penetration testing is done to ensure that no
vulnerabilities are introduced by configuration changes to the infrastructure. This ensures a culture of
“Continuous Security”.
Once the code is released, the goal is to learn from actual usage in the field to determine how to
enhance and improve the product. To enable this, product teams have to prioritize the addition of
usage analytics along with the feature development. In some scenarios, for example, when changing
the user experience on a site, it is often not clear which exact design would be the most successful. In
such cases, DevOps teams adopt a technique called A/B testing. In an A/B test, some set of users
are directed to one implementation of a feature, let’s call it the A version, while a different set of users
are directed to a different implementation of the feature, let’s call that the B version. This allows DevOps
teams to evaluate different implementation options for a feature, and pick the one that works the best in
the field, by measuring actual usage. The data from usage analytics is then used to influence the
priorities of the remaining stories in the backlog.
This kind of rapid iteration of design, code, deliver, run, manage, and learn – is a virtuous loop that is
central to rapid innovation on the cloud. We have documented a collection of best practices, DevOps
tool chains and application architectures to enable this type of enterprise transformation

The E2E flow
To help illustrate the different practices side by side, we mapped out the following swim lanes diagram, which shows how the practices interweave and work
together at different stages of the outcome delivery.
Swim lanes for IBM Design Thinking, Agile and DevOps Practices

How does this apply to different types of
engagements ?
Different clients have different needs. However, some clients already have working Agile delivery teams well established into their business, and we need
to acknowledge that and adapt our approach to fit within their framework.
Other clients have a well-established DevOps platform, and are committed to a set of tooling.
Therefore, our approach should be tool agnostic and should work well with any kind of tooling.

References
• IBM Design Thinking:
https://www.ibm.com/design/thinking/
• IBM Garage Method:
https://www.ibm.com/devops/method/

THANK YOU!

DT Agile DevOps External PoV 20170316

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

DT Agile DevOps External PoV 20170316

Caricato da

Copyright:

Formati disponibili

IBM Design Thinking+Agile+DevOps

ITERATIVE OUTCOME DELIVERY POV

Iterative Outcome Delivery POV

3 WHY WE NEED THESE TECHNIQUES ?

4 OBJECTIVES OF THIS POINT OF VIEW

5 THE E2E FLOW FOR ITERATIVE OUTCOME DELIVERY

26 HOW DOES THIS APPLY TO DIFFERENT TYPES OF ENGAGEMENTS ?

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

The key objectives of this POV are to:

Iterative Outcome Delivery POV

End to end flow for

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Now you want to determine what is your path forward?

Iterative Outcome Delivery POV

First do whatever is necessary to set up the teams. For example, if this is an

Iterative Outcome Delivery POV

Does the team need any training in

Agile ? IBM Design Thinking Training ? Any other training ?

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

These features are then mapped into a Release Plan.

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Next, we have identified further discovery and research that we

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Showing our Stuff

Iterative Outcome Delivery POV

The Care and Feeding of the Team

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

Iterative Outcome Delivery POV

• IBM Garage Method:

Iterative Outcome Delivery POV

Potrebbero piacerti anche