Agile Program Management: Awareness Building and Knowledge Management

What is the role of Agile Program Management function in these two areas – ‘Awareness Building and Knowledge Management’?   These two areas go beyond generic training on new joiner induction or on-boarding. I am writing this post to explain how these two areas go beyond the normal on-boarding or induction process and why those two are important drivers in Agile Program Management.

Typically we get trained or certified team members to form cross-functional teams or we induct skilled team members and put them through appropriate additional training and/or certification programs. Once this happens, team members get into main stream iterative/incremental delivery. Teams that are self-enabled and high-performing experience perpetual learning that happens all the time. In small projects that involve one or two such teams, awareness building and knowledge management are intrinsic. Those who have been through this or those who imagine standalone or small teams may even wonder why someone would even worry about these two areas!  This is because Agile is about team learning and continuous improvement.

Well. That happens. That happens in small projects – projects that involve one or two or three cross-functional teams.  How about large projects or programs? – for example, programs that involve multiple hundreds of team members – 400 to 1000 team members with 40 to 100 cross-functional teams that are geographically distributed?

I am sure you got the context.  In most cases Agile Program Management involves complexity in terms of team size, variety of projects, geographical distribution and so on. This is when Agile Program Managers cannot afford to ignore ‘Awareness Building and Knowledge Management’.

Awareness Building and Knowledge Management are continuous activities. There have to be multiple mechanisms to promote or implement these two areas. There can be mechanism such as visual posters, lightening talks, regular or periodic sessions that involve topics related to technologies, domain concepts, and so on.  Gamification is worth considering in large teams to ensure continuous awareness building and knowledge management.

Unlike small projects that involve one or two cross-functional teams that last for about nine to twelve months, large programs involve tens or hundreds of cross-functional teams and last for multiple years.  Continuous focus on awareness building and knowledge management becomes a necessity to sustainable rigor in execution.  Remember, a 10 percent attrition in program of 500 team members is nothing but 50 people moving out and moving in year on year.  When there is a churn of this magnitude or higher, on-boarding or induction may become individual based but not team based because you don’t get to induct a team or train a group of individuals all the time. With consistent pressure on sustaining velocity trends or meeting release timelines, the focus on delivering would supersede everything else. This is where a continuous focus on awareness building and knowledge management can strengthen the ecosystem.

How can we going about this? Form a team of motivated individuals who want to contribute to this area. Focus on a) creating an infrastructure that radiates knowledge and improves awareness – these can be posters, email flyers, knowledge management portal, etc. b) budgeting time for periodic knowledge sharing sessions facilitated by team members for team members, c) involving geographically distributed teams by sharing content or inviting them to participate.  Also, include these in your program management radar or dashboard.  Do you have any additional ideas? Please share.

Have you seen a new project team in your program repeating the same mistakes that one of the mature teams came across couple of years ago?  Have you seen the same types of issues and conflicts happening in new teams year after year? Have you seen a newly inducted developer doing a wrong bug-fix most probably the same way someone did years ago and learned a better way through experience? If yes, I am sure you will understand how these incidents can be better understood and handled, and minimized - if applicable, through consistent focus on awareness building and knowledge sharing sessions. Also, I am sure you don’t assume that the initial induction program or training or certification can do the magic to stop these!

Tell me now. Don’t Agile Program Managers need to keep track of these two areas or have them represented in some form (probably through a measure or metric) on their program management dashboard?

Agile Program Management: Metrics and Dashboards

    

      From Agile Program Management perspective what metrics do you consider and how do you assemble them on a dashboard for periodic monitoring? I am writing this post to share a set of ten essential considerations on this topic.

1. Set program level goals in such a way that the goals are measurable (SMART goals). Make sure that there are two to three important goals and focus on achieving them.  As and when you accomplish a goal, you can add one more goal to this list.  Align your dashboard to include a comprehensive list of parameters or metrics related to these goals.
2. Besides, show project level metrics that require attention at program level.  If your program consists of projects of different categories (software development, software maintenance, test automation, etc.), create a multiple views to show the state of these categories at a high-level.  These need not be exactly the status report or dashboard you show at project level.
3. Make sure that your dashboard is simple, visible and accessible to all stakeholders.  You cannot wait to see the dashboard of your car only whenever you stop for a refreshment break! You need to see it all the time.  Design a dashboard in such a way that it is visible, and accessible at regular intervals – A dashboard that gets updated daily can add more value to your program as compared to one that gets updated once or twice a month.
4. Include both lag and lead measures.  Velocity is a lag measure. You can measure it at the end of Sprints but you cannot control it in a Sprint that passed by. Identify lead measures related to Velocity. These are the measure or factors that impact Velocity. Make sure that your team spend lots of energy on improving these lead measures so that the corresponding lag measure can improve. Lead measures give life to your dashboard. Ignoring lead measures and focusing or showing only lag measures has very limited use or no use at all. What are your project level lead measures? What are your program level lead measures? Find answers.
5. Include the right metrics.  Is Velocity alone a good enough measure? Don’t we need ‘Cycle Time’? Or ‘Backlog Stability’? Or ‘# User Stories deployed in production environment’?
6. Your dashboard is not a static entity. What you include in your dashboard can change from program to program.  Also, it can change from one stage to the other in the same program. By ‘stage’ I mean a definite period during which the overall characteristics of a program remain the same.  For example, when you begin an Agile Program, ‘Product Owner Readiness’ can be an essential parameter to include in your dashboard because this is a leading measure to improve Velocity and Cycle Time.  Also, it is something that needs to be known to all stakeholders including your senior management to obtain necessary help or support in a timely manner when you are running with a very low value on this parameter.
7. The dashboard you design and implement needs to tell you whether the whole program is moving towards success or failure.  This is not simply the Red-Green-Amber status. This is about providing a view that shows all success critical parameters or metrics and relating them with a key message to demonstrate or authentically illustrate whether the program is winning or losing.
8. Practice reuse.  Attempt to reuse components across dashboards at different levels (project, program, engagement, etc.)  This will optimize efforts and ensure the same level of truth across dashboards.
9. Have a good mix of quantitative as well as qualitative information to reflect what is needed, what next, and whether action is happening on the ground or not.
10. Do not attempt to create a ‘perfect’ dashboard to begin with.  Start with a minimalist dashboard and add more to it gradually.  Practice continuous improvement!  A dashboard is perfect not when you don’t have anything else to add but when you don’t have anything else to remove from it!

Do you have anything add? 

Agile Program Management: Engaging with Stakeholders

Stakeholder management is an essential but challenging area in Agile Program Management.  Engaging with stakeholders is as important as team collaboration without which it is practically impossible to see tangible results when we manage multiple projects under a program. I am writing this blog to put forward some key aspects related to engaging with stakeholders.

What makes stakeholder management a complex thing in Agile Program Management?  One key reasons is that stakeholder management in Agile is a combination of several aspects.  When we understand those aspects, we get enough clarity during our attempts to engage with stakeholders. In my opinion, these aspects include

1)      Agile awareness and learning agility of stakeholders
2)      Change agility of stakeholders to adopt the new way of working
3)      Stakeholder KRAs, Expectations and expectation management
4)      Persona and leadership style of stakeholders

      These are eye openers that make us understand that stakeholder management in Agile Program Management is unique and different – and most of the times it is a big deal.   It is not about staying in touch with stakeholders in formal and informal ways and keeping them aware of the respective projects or the entire program.  This is about enabling them and making them understand the new way of working – short and sustainable iterations to delivery working software, continuous collaboration, feedback loops, team learning, continuous improvement, and so on.  It is about hand holding them to adopt the new way of working.  It is about the ability to understand, negotiate and manage their expectations. It is about doing all these with a good understanding of their persona and leadership styles and gradually helping them understand the power of Servant Leadership.

“My project follows traditional lifecycle in a phased manner.  It has been twelve months since we started. There has been a huge delay. Phase 1 and 2 must have been delivered by now. We did not meet the goals of Phase 1 on time. Phase 1 was about to get delayed by two months. We diluted the goals and ended Phase 1 with a delay of one months. Phase 2 started but the project is on fire because of several issues.   We want to transform this project into Agile.  The original planned delivery date is about eighteen months from now.  Will Agile help us move faster, become aggressive and delivery on time?”   This is what one of my stakeholders asked me years ago. He wanted me to take this troubled project, transform it into Agile and deliver.  I am sure you have come across situations like this.

In situations like these, where do we start? How do we proceed to handle such situations?  In addition to deep analysis, training, team building, coaching etc. one of the key factors that plays an important role here is Stakeholder Management aligned with agile values and principles. 

When we are into Agile project or program execution, we come across questions from our stakeholders. These questions relate to one or more of the key aspects we discussed earlier. Let me give you some examples.

1)      Why can’t we cut down on travel and use only video conferencing for the entire project?
2)      Why do we need more than one video conferencing room?
3)      How can we see a 30% increase in productivity over the first year in our program?
4)      Why aren’t we following best practices such as Earned Value Analysis?
5)      Whether we call it Agile or not, how can we deliver the whole thing in three months?
6)      How about considering industry benchmarks or organizational baselines in our project or using Function Point estimation? What can we do to standardize across board?

In order to deal with such questions, we need to understand the learning agility and change agility of stakeholders and their ability to adopt to the new way of working.  We need to understand their KRAs and expectations. We need to negotiate and make sure that the expectations are realistic and suit the new way of working.  This will require some changes in leadership styles as well.

How do you engage with stakeholders? How do you align them with the new way of working? What are your top challenges?
 

Agile Program Management: Independent Verification Teams

How do Independent Verification Teams (IVT) relate to Agile Program Management? Should Program Managers consider IVT as yet another team and limit their responsibilities to focusing on traditional program management activities or do something different such as understanding the purpose of IVTs, key issues, and related metrics?  Let us find answers to these questions in this post.

Independent Verification Teams? What? Agile teams are cross-functional. Agile teams deliver tested software. Why do we need IVT?  Are we crazy? Are we going back to erstwhile non-Agile methodologies? Are these your questions?

Good questions!  When we run large projects consisting of multiple cross-functional teams, we do need IVTs – at least one or two IVTs.  Typically, an IVT is a team of 7 to 10 with one leader and team members. Obviously all of them are experts in testing and test automation.  In an ecosystem like this, each cross-functional team would deliver working software.  When we create an integrated build of software delivered by multiple cross-functional teams, don’t we need a team to test the integrated build? Yes.  Of course, Yes.  We need Independent Verification Teams for this.  When we program manage multiple related projects, yes, we will need Independent Verification Teams.

The number of IVTs would depend on the size of the project or program.  When we see from Agile Program Management perspective, it is important that program managers know

• The purpose or goal of cross-functional teams and IVTs
• The team size, composition, and distribution of team members in IVT
• The tools they use
• The right approach to measure their progress -  IVTs are not going to produce working software but they need to have tangible deliverables with ‘Definition of Done’
• What can go wrong with IVTs
• Ways to maximize the benefits of IVT

Yes. With IVT in place, cross-functional teams can’t renounce their responsibility of unit testing and let IVTs find and report unit level defects. Also, they can’t burden IVTs because of their attempt to deliver as many user stories in every iteration. I mean, cross-functional team can’t attempt to deliver extra user stories by cutting short on unit test automation and/or perform selective unit testing.

When IVTs spend time in finding and reporting unit level defects, IVTs may not get sufficient time to perform their role effectively and end up accumulating technical debt.  This can happen because of lack of or delay in test automation.  This can happen because of ineffective tool usage – for example, lack of traceability of test cases or scripts to corresponding user stories. Sounds familiar?

Also, delays in tool identification or any decision to change tools late in the game is not going to enable IVTs in accomplishing their goals.  Tool identification, adequate training and effective tool usage are very important for the team to focus on the product or applications under development.

IVTs require significant expertise in terms of thought leadership as well as execution.  Their test strategy needs to be clear enough in terms of tools, test data generation, team composition, and all essential parameters including the technical approach they decide to adopt.  In other words, the goals of IVT are not limited adopting tools and implementing test scripts. There is more to it.   A shared vision among all team members in terms of ‘what’, ‘why’ and ‘how’ of their goals is essential.

1. Program managers need to know all these factors and select the right kind of measures to know if IVTs are delivering or not.  Here are some guidelines to do this.
2. Automation Goals:  Measure automation %. This is typically a function of number of test cases automated versus total number of test cases
3. Traceability: This is a function of number of test cases versus the number test cases that are traceable to user stories
4. Defect Trends:  Trends of defects reported by IVT
5. Defect Quality:  Number of unit level defects reported by IVT versus total number of defects reported by IVT
6. Execution Trends:  Number of automated scripts executed versus number of manual test cases executed
7. Post-release or post-production defects (Defect removal efficiency)
8. Technical Debt - more specifically, testing debt accumulated in terms of inadequate automation, design flaws in test automation suite, and so on.

Consider Independent Verification Teams! IVTs are valuable! We need them in large-projects as well as program consisting of multiple interconnected projects. Does this synchronize with your experience and thoughts?  Let us discuss.

 

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?