Sunday, December 4, 2016

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?

Friday, November 18, 2016

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? 

Saturday, May 21, 2016

Agile Program Management: Engaging with Stakeholders



1)      Agile awareness and learning agility of stakeholders
3)      Stakeholder KRAs, Expectations and expectation management
4)      Persona and leadership style of stakeholders








Sunday, February 21, 2016

Agile Program Management: Independent Verification Teams

  • The purpose or goal of cross-functional teams and IVTs
  • The tools they use
  • What can go wrong with IVTs
  • Ways to maximize the benefits of IVT
  4. Defect Trends:  Trends of defects reported by IVT

Friday, January 29, 2016

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?