Injecting Transition iterations into your Release plan
From the Disciplined Agile Blog
by Tatsiana Balshakova,
Mark Lines, Mike Griffiths, James Trott, Bjorn Gustafsson, Curtis Hibbs, Scott Ambler
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.
View Posts By:
Tatsiana Balshakova
Mark Lines
Mike Griffiths
James Trott
Bjorn Gustafsson
Curtis Hibbs
Scott Ambler
Past Contributors:
Joshua Barnes
Michael Richardson
Daniel Gagnon
Valentin Tudor Mocanu
Kashmir Birk
Glen Little
Klaus Boedker
Recent Posts
DA 5.6 is released
Disciplined Agile 5.5 Released
Choose Your WoW! Second Edition Is Now Available
Requisite Agility applied in Project Management
Disciplined Agile and PMBoK Guide 7th Edition
Categories
#ChoiceIsGood,
#ChooseYourWoW,
#ConsumableSolution,
#ContinuousImprovement,
#CoreAgilePractices,
#experiment,
#Experimentation,
#GuidedContinuousImprovement,
#Kaizen,
#LifeCycles,
#ProcessImprovement,
#TealOrganizations,
Adoption,
agile,
agile adoption,
Agile Alliance,
Agile Business Analyst,
Agile certification,
agile data,
agile governance,
agile lifecycle,
agile metrics,
agile principles,
agile transformation,
Agile2018,
Agile2019,
Agile20Reflect,
AgileData,
Analogy,
announcement,
Architecture,
architecture,
architecture owner,
Articles and publications,
Asset Management,
Atari,
Backlog,
Barclays,
being agile,
benefits,
bi,
blades,
book,
Branching strategies,
Browser,
Business Agility,
business intelligence,
business operations,
capex,
Case Study,
Certification,
certification,
charity,
Choose your WoW,
CMMI,
cmmi,
Coaching,
Collaboration,
Communications Management,
Compliance,
Compliancy,
Conference,
Construction,
Construction phase,
Context,
Continuous Improvement,
coordination,
COVID-19,
Culture,
culture,
Cutter,
DA,
DAD,
DAD Book,
DAD discussions,
DAD press,
DAD roles,
DAD supporters,
DAD webcast,
DADay2019,
Data Management,
database,
dependencies,
Deployment,
Development Strategies,
DevOps,
disaster,
Discipline,
discipline,
Disciplined Agile,
disciplined agile delivery,
disciplined agile delivery blog,
Disciplined Agile Enterprise,
disciplined devops,
Documentation,
Domain complexity,
dw,
DW/BI,
Energy Healing,
Enterprise Agile,
Enterprise Architecture,
Enterprise Awareness,
enterprise awareness,
Essence,
estimation,
Evolving DA,
Executive,
Experiment,
facilitation,
FailureBow,
feedback-cycle,
finance,
Financial,
FLEX,
Flow,
foundation layer,
Funding,
GCI,
GDD,
Geographic Distribution,
gladwell,
global development,
Goal-Driven,
goal-driven,
goals,
Governance,
GQM,
Guideline,
Hybrid,
Improvement,
inception,
Inception phase,
India,
information technology,
infosec,
Introduction,
iterations,
Kanban,
large teams,
layer,
lean,
Lean Startup,
learning,
Legal Project Management,
LeSS,
Lifecycle,
lifecycle,
Manifesto,
mark lines,
marketing,
MBI,
Metaphor,
Metrics,
metrics,
mindset,
Miscellaneous,
MVP,
News,
News and events,
Non-Functional Requirements,
non-functional requirements,
Non-solo development,
offshoring,
Operations,
opex,
Organization,
Outsourcing,
outsourcing,
paired programming,
pairing,
paper,
People,
People Management,
phases,
Philosophies,
Planning,
PMBoK,
PMI,
PMI and DA,
PMI Chapter,
Portfolio Management,
post-format-quote,
Practices,
practices,
Principle,
Process,
process improvement,
process tailoring,
Product Management,
product owner,
Product Owners,
productivity,
Program Management,
Project Management,
project-initiation,
Promise,
Quality,
quality,
rational unified process,
Refactoring,
Reiki,
Release Management,
release management,
Remote Training,
Remote Work,
repeatability,
requirements,
Requirements Management,
research&development,
responsibilities,
retrospectives,
Reuse,
Reuse Engineering,
ride for heart,
rights,
Risk Management,
Risk Management,
Risk management,
Roles,
RUP,
SAFe,
sales,
Scaling,
scaling,
scaling agile,
Scheduled Workshops,
SCM,
scorecard,
Scrum,
ScrumMaster,
SDLC,
Security,
security,
self-organization,
SEMAT,
serial,
skill,
solutions software consumable shippable,
Stakeholder Management,
strategy,
Support,
Surveys,
Teal organizations,
team development,
Team Lead,
team lead,
Teams,
Technical Debt,
Teleconferencing,
Terminology,
terraforming,
test strategy,
testing,
time tracking,
Tool kit,
Toolkit,
tools,
traditional,
Transformation,
Transition iteration,
transition phase,
Uncategorized,
Upmentors,
Using PMI Standards,
value stream,
velocity,
vendor management,
Virtual Training,
Workflow,
workflow,
workspaces
Date
For complex agile projects, deploying (or transitioning) the release to a “live” environment for the users is seldom a trivial exercise. Most large enterprises have defined milestones, gates, and or reviews that need to be coordinated with many diverse stakeholder groups such as users, governance bodies (such as Project Management Offices), DevOps, and marketing before the application can be released. In DAD we therefore describe a distinct set of activities to prepare our stakeholders for the release and support of the new application. This could include activities such as user training, data conversion, documentation, hardware deployment, preparing customer support, database tuning, and last minute defect fixing. To recognize the clear difference from a typical Construction iteration, we describe iterations dedicated to deployment as “Transition” iterations. The illustration shows how we can inject iterations into our release schedule to deploy increments to the user community. In this example, after the fourth Construction iteration, we may have an additional set of features representing a minimally marketable release that is worthy of a Transition iteration to deliver the value to the users.
When we have an application that needs to be delivered over multiple releases, following the Transition phase we may start work on a new release by continuing the Construction phase. Since we would typically have an existing work item list (backlog) of outstanding requirements, we can simply pull more requirements off this stack and continue to build more functionality. In this way, it may not be necessary to have another Inception phase unless the vision has materially changed and needs to be revisited. Your organization may, however choose to run small Inception iterations at the beginning of each new release.
In this example, after the fourth Construction iteration, we may have an additional set of features representing a minimally marketable release that is worthy of a Transition iteration to deliver the value to the users.
Some people mistakenly interpret DAD as one deployment to the customer at the end of the project. If possible, we prefer to deploy frequently, in support of the agile alliance principle “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. Our minor quibble with this principle is that what we deliver to the customer is a “solution”, which may not only include software, but also business process changes, training, or marketing activities, for example. Our experience is that large projects typically involve a lot of work beyond the software itself which can also benefit from agile collaborative practices.
Injecting Transition iterations to deploy increments to customers
While the illustration refers to each iteration delivering a “potentially shippable” increment, which is what the agile community typically calls it, we actually prefer to use the term “consumable” to indicate that it not only works, but it is also actually usable by the customer.
Posted
by
Mark Lines
on: January 07, 2012 04:40 PM |
Permalink
Comments (0)
Please login or join to subscribe to this item
Please Login/Register to leave a comment.
|
Waiting for the time when I can finally say that this has all been wonderful but now I'm on my way.
- Phish
|
