What does Agile Program Management have to do with Emerging
Architecture? Isn’t Emerging Architecture
a pure technical issue or concern? Why should it be under the purview of Agile
Program Management? This blog post is to
discuss these two areas and find answers to such questions.
Think about a program consisting of multiple projects and
technologies. Let us assume that most of the projects – if not all, are running
in Agile mode. Obviously, programs include
related or interrelated projects and program management requires significant
focus on dependency management. This is
because something happening in one project may have some impact on one or more
projects. Things can get very complex at
times too.
An emerging architecture can result in dependency
issues. This is how it can. Let us assume that Project-A comprising of 5
releases and running in Agile mode involves emerging architecture. After Release-4 the project team figures out
that they need to do a significant rework on some of the architectural
components and that work requires an additional iteration or two. The project team of Project-B is surprised
and concerned because their project is dependent of Project-A. There is a dependency issue here. Can this happen? Yes it can. And it happens
all the time.
Why? Probably because, in Project-A there was no systematic
way of measuring Technical Debt and paying it off at regular intervals. Probably in the name of ‘Emerging
Architecture’ the team was accumulating technical debt and was unaware of the
magnitude and impact. It occurred to them after Release-4 – may be someone
noticed it while trouble shooting or it surfaced during technical discussions
and eventually it resulted in significant rework. And that rework is going to
involve rework at various places. That means a delay in schedule.
So what is the point?
At program management level this has to be a focus area – ‘Emerging
Architecture’ and its possible impact in terms of rework because of lack of
Technical Debt Management. Well, in that sense ‘Technical Debt Management’
itself can be a focus area – I am ok with this idea as long as we know about
all the sources of ‘Technical Debt’ and pay attention to all those sources.
We accumulate technical debt from several sources or at
several levels. Here is a list. If you
want to add more items here, let me know.
a)
Emerging Architecture
b)
Pending or Ignored Technical Decisions
c)
Inadequate Designs
d)
Messy Code
e)
Legacy Code
f)
Inadequate Test Automation or Lack of Test
Automation
g)
Inadequate or unstable environments
This means that Agile Program Management teams need to ask
the right questions to know if dependency issues can surface across projects
because of lack of focus on any of these sources in one or more projects. For example, the function of Agile Program
Management is not to be a mute spectator of Emerging Architecture assuming that
that is how Agile projects work. There
has to be leading questions to find out ‘So how are we tracking technical debt
related to emerging architecture and paying it off at regular intervals?’
Emerging Architecture is a pure technical concern. However,
it has and it can have significant bearing on Agile Program Management. I think
it should be under the purview of Agile Program Management. And this applies
to all sources that can lead to or result in technical debt.
Have you come across projects or programs that ignored these
sources or aspects? What were the impacts or results?
