The mess within..

The easiest way to organize your stuff is to get rid of most of it

Same is the case with our Orgs. Many times we let various teams within an Org follow their own structure in their projects, which is good for them as it allows abstraction and flexibility but it leads to a huge mess within the Org as well. Well of course, democracy has its own downsides as well.

It is very critical to have a skeleton in place in order for an Org to run smoothly. We need some basic terminology so that everyone is talking the same language at the org level. Just imagine if every county starts their own color coding of traffic lights, what a mess it will become for a driver moving across. You see, it’s a very simple analogy, traffic lights have Red, Yellow, Green world wide where-in every intersection is free to have the counter for each color.

Similarly in Program Management, it is critical for an Org to have a common skeleton in place for it to report how it is functioning, how it determines a red, green and yellow status. In the longer term, it removes so much confusion from the overall reporting and a lot of overheads, requiring someone to sit down and figure out what is the status for the team.

Here are few principles that could form a basic skeleton for an Org

1.) Talk Numbers, keep emotions out!

We need to establish that the progress for any team is measured with a combination of #open work items and story point (weight) of each. Combining these two, we can draw parallel across teams and establish a true status at an org level. Here, the nature of work items and the workflow they follow could be absolutely independent to the team and gives them total freedom to function as per their own sprints.

Once we have established this, we have normalized each team and color-coordinated them. The red, yellow and green status for each team is now the same.

2.) Keep it simple!

The benefit of allowing teams to follow their own structures is great but the downside is also proportional. This is the epicenter of the mess. 

Create a common structure for all teams with the same nature of work. Allow flexibility to teams to have their own types and workflows but broadly, they must follow a simple & accommodating structure. 

For example - Implement a simple hierarchy like below. 

While each team can still define additional work item types, they can define their own workflow (lifecycle of a work item) but at an Org level, all of them are talking the same language.

At an org level, we can just look at all the Initiatives and Epics, along with their respective status, to see what the progress is. This will completely take away the fear of missing any detail because we know for sure that everyone is bound in a defined structure.

Oh wait, did you realize that we cannot bring a common structure (#2) unless we normalize all teams (#1). Doesn't it make sense?

3.) Automate! enable teams

Automation is expensive and must be weighed against the ROI. Now, imagine if all teams have different structures, they will be forced to automate on their own. Some would do it, some won’t due to a number of reasons. 

Bring in automation for redundant tasks & activities and not chase engineers for it. This is one of the most ignored investments, like a mutual fund, you just need to be diligent about it.

For ex - How do we know if someone is working on a work item? Once the status is “In Progress”, right? How many times have you seen engineers updating that status? Ignore, don’t answer that. 

Well, a simple fix could be, as soon as he makes his first check-in for the work item, go back to your tool and mark it “In Progress' '. Not rocket science, right? In the last check-in, an engineer could just pass a keyword like “Resolve” and automatically the work item is resolved and ready for testing. Similarly, resolve an Epic once all child tasks are resolved.

Hey, yet again. I am sure you realized that if and only if you took care of the above two points, only then you can bring in effective automation and suddenly the ROI on automation will be multi fold. 

4.) Data Hygiene

When teams start, they pay no attention to data hygiene (in their issue reporting tool) as the focus is on delivery. Soon they realize that they have created a huge pile of unhygienic data in their reporting tool that they just can’t figure out the right status. Then, just after they are done with a huge release, a much anticipated one, they sit down and clean up all the data. They do it without realizing that they are cleaning it up, just to mess it up again… it goes in full circle.

Automation helps to a very large extent in keeping the data hygiene but at the  same time, it’s not enough. An org must have some hygiene dashboards where they continuously need to review if their reporting tool is getting garbage in. Dashboards come handy in such scenarios as they point you to pain areas rather than going through the whole data. Of course they must really be a good one :). 

Wait, what… again. We cannot keep our data hygiene unless we have automation (#3) in place which in turn means we need a common reporting structure (#2) which is not possible without everyone talking the same language (#1).

Simple, wasn't it. I am sure you are wondering these are such basic things, nothing out the box. Tell me if you have these already in your Org...

Last but not the least, bring in effective tools which  really enable teams. We will talk about it some other time, but please do write back on what you think are the critical aspects for Program Management for an Org.