Agile Program Management: Emerging Architecture

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?