- First let's talk about synchronizing development.
Well what's an Agile Release Train?
Well it's a bit of an abstract concept.
It's illustrated here for sure.
But it's really all of the above,
so all of this stuff constitutes the Agile Release Train.
Teams, many teams, team practices, team iterations,
actual program implements with PI planning,
program execution at these boundaries
using features of neighbors and then
there processes continues exploration,
continues integration, continues appointment,
that's what it all is.
So it's really an aggregation of all the teams
and the key stake-holders that need to deliver value.
Long-lived, self-organizing team of agile teams.
So first for organization often now
could be physical organization meaning
it could be a line management organization
or product organization.
And for those that are of traditional
kind of IT background we start to think about
the solutions as products,
those typically move that way.
But we call it virtual for reason because
we're not sure exactly how long-lived it's gonna be,
we're creating a new construct that's gonna deliver value,
we're gonna discover that it can't
do some of the things that it needs to do.
50 to 125 people, why?
Because it's fundamental kind of law of social physics.
That many people I can know and care about,
and below that number I can sure know and care about them
but I can't really build a big system.
Above that number I can't really know and care about them
so I can't really build a big system.
We're gonna have multiple ARTs to do that.
We're gonna use this term called a program increment, a PI.
It's just a label for a fixed time box.
Default in safe is 10 weeks,
but that default is customizable.
I've seen PIs as short as six, maybe even four in one case,
as long as 12, longer than 12, generally too long.
To much change happens, right?
Not enough opportunities to synchronize again
into a current plan of record.
Within that the iterations are synchronized
and across trains the PIs are synchronized true.
They're aligned to a single mission
via a single program backlog, one program backlog.
The team has their backlog for sure,
all the local stuff they care about,
but new stories in that backlog
are driven by the program backlog.
Architectural and UX guidance, how come?
You really want from feature to feature
the user to have an entirely different user experience?
I don't think so.
Do we want this common single sign on
across all the applications in that tool suite?
We absolutely do, so we're gonna provide
architectural and UX guidance to help
align the teams to a common outcome,
a common way of working,
common way of working for them
and a common way of working for their customer.
And each Agile Release Train frequently produces
valuable and evaluable system-level solutions.
In other words they go through the steps
of defining a functionality,
implementing that functionality,
acceptance testing and deploying that
as quickly as they can.
That's the purpose of an ART.
We're gonna see how devops feeds into that
because that's gonna be a consistent flow
of small batches that go through the system
all the way to release.
Now we talk about cadence and synchronization,
we need to have a little further discussion here,
which is that we need both.
We need the teams to have the same cadence
and the same synchronization point, and here's why.
If we don't have that, and it's not unusual
to have teams that maybe have
a three week sprint length,
or maybe this is a three week sprint length,
and this is two week sprint length
and maybe this is a two week sprint length
and that looks pretty good.
So why should I bother to have them
start and stop on the same date?
Well, they're gonna develop their work here and here,
and we're gonna come to a point where
we'd like to integrate.
Well if we've done any branches, even small branches,
or even the integration requires work
and it doesn't get done,
for example maybe this integration
requires work that doesn't happen until here,
it's impossible to synchronize that.
So what happens is we have this common anti-pattern,
which is the teams are sprinting
and they might even feel good about that process,
but the system isn't, the system isn't sprinting.
It's still in a monolithic, waterfall-like world,
it's not been integrated.
So until we align those splints
and get the ability to create kind of
necessary force integration cycles,
we just go with that the slowest component
drags a train, which is always true,
but most importantly that we
don't have any integration points.
The teams are sprinting, but the system isn't sprinting.
Common anti-pattern and a real issue
and I'll bet anything you've seen that in your organization.
So instead we synchronize that,
we synchronize those sprints,
we make sure that the teams are lying
on a common sprint life.
We provide continuous integration
because we're gonna need that
to support a dev operated process.
And now we probably also discover
that it's very difficult for a feature team
to recessarily integrate the whole system.
That might be true in a small desktop application,
it's not gonna be true in a really, really large system.
And the bigger the system is
the more likely it is that we're
gonna need help from them.
And we have them helping a little bit, running the gears,
we can start making sure that the system is sprinting
and because it's a line we can
add system demos at that point.
And we'll talk a little later on
about how what's essential in essential safe
and one of those things is the presence of a system demo,
so this gives us the tools we need now.
So with a little help from the system team
or maybe it's a group of individuals
that came together through the integration,
maybe it's a different team entirely
but that was on the train.
And we can integrate and integrate continuously
and provide really fast feedback
of the system, not just the individual component
or feature that the team is building.