Being Agile and Managing a Program?


#1

Hey Folks,

As a scrum master moving into program management, I’d love to understand what an agile program looks like so that I can help all the teams in the program be more agile.

Do you have examples of a program being agile, what kinds of obstacles did you face, what lessons did you learn?


#2

Please forgive the shameless shilling, but ThoughtWorks has written a lot around the concept of Agile Program Management. I also have a 3-part post on my blog that discusses some of the issues that come up with change in teams and programs that might be helpful.



https://www.thoughtworks.com/mingle/scaled-agile/2015/07/28/why-programs-fail-scaled-agile.html

Also, this post by Jurgen lays out what I feel like are super important things programs need to consider.

Remember, there’s no checklist I or anyone else can give you to run your program. No framework will fix or run things smoothly. Dave Snowden’s Cynefin lays out the concept of managing navigating chaos the best but again its not prescriptive. Make sure you have a circle of people to be transparent with and openly discuss the ups and downs of your program.

Let us know how it goes, and best of luck!!! :slight_smile:


#3

@dmbennett, pardon the simple question, but I don’t want to assume too much. When you say “program,” are you using it as a collection of projects or something other? If so, I feel like the question I should be answering is … how do you scale agile and ensuring all teams are pointed in the proper direction and communicating well?


#4

@Tanner It’s more complicated than a collection of projects, it’s a combination of a collection of projects and teams. In some cases it’s a specially formed taskforce that is a collection of people from different teams that have different skills and knowledge that can help push forward a cross-functional initiative. There are over 300 engineers at Uptake, and we have roughly 3 large scale programs. I recently was tasked with kickstarting the 3rd. Rather than this being a scaling of the first 2 we have a politically diverse set of programs.

Mine is a little more complicated than others because it’s rolled into the tech-ops organization and recently we underwent an executive shift. The new executive wants me to work with the ops teams as well. So we have some purely customer service support folks, site-operations group that acts as site reliability engineers, we have some folks who development to automate infrastructure deployment and provide an infrastructure as code ability to the other 2 programs. We also have a delivery pipeline team, a continuous integration team, and an entire mini program of security engineers.

Across these groups some of the automation and delivery pipeline/ci teams are using scrum or kanban, for the ops group they are doing some old school change management and project management stuff–they’re mostly rapid response support for production.

And I’m wondering what it means to take a diverse group like that and begin working toward transforming them into a cohesive identity as a team as well as understand their development and delivery habits. My thinking is that folks providing examples here may help me reframe what I’m looking at and spur on some creativity. I’ve never faced anything like this before.


#5

What an interesting problem. And by interesting I mean I’m glad it’s not mine to solve. :wink: Here’s a few thoughts that came to mind as I read:

  • There sounds to be lots of component teams. How could those be brought closer to the customer and transformed into feature teams?
  • Travelers. I wonder if some of those would be useful to spread some of the highly specialized people?
  • What other coordination and integration techniques from the link above would be useful for your teams?
  • Which is the bigger problem. Cross-team communication or ensuring all teams are delivering the most valuable work to the customer?
  • Based on your description, it sounds like you’re not managing projects but creating a product or products. Knowing the difference could be a catalyst for shifting to a better mindset.

#6

Yo @dmbennett! Good to see you on the board!

I got to say, it doesn’t sound like you have been tasked with managing a program, but rather how to managing scaling Agile:) When I think about Agile program management, I think about a large initiative that several teams are working on in which cross team collaboration and integration is paramount. You been tasked with much more.given the summary provided.

“It’s more complicated than a collection of projects, it’s a combination of a collection of projects and teams. In some cases it’s a specially formed taskforce that is a collection of people from different teams that have different skills and knowledge that can help push forward a cross-functional initiative”

“Politically diverse set of programs”

I sense some anti-patterns from both these comments. What immediately comes to mind: is leadership aligned or are personal agendas driving dysfunction in the system such as:

  1. To much WIP
  2. Plan Driven Allocations instead of Value Based Focused Teams
  3. Bottlenecks in that only a few people can do certain tasks. See “Brent” from the Phoenix Project.

Throw in the whole tech-ops ask, and you really have cluster duck. I don’t know man, something just smells fishy…

Look forward to your response and more details


#7

@mccallam2 No doubt there are anti-patterns, I’m in the difficult position of navigating the art of the ideal and the art of the practical at the moment. For whatever reasons the arguments that surround SOA and full-stack development are prohibited (believe me I’ve tried)–at the end of the day the excuse comes down to a unique set of security constraints when working with Defense dept. contractors, our contracted SLA reqs, etc…

You’re absolutely right, very fishy. But not sure I have the social capital to make the argument for a different set of assumptions yet. Maybe I lack the vocabulary to make the alternatives compelling enough.

Given those restraints I still want to make what I can better. In the mean time I’m working on getting teams into a place of using a WIP limit. Raising questions of how we focus on value rather than implementations, and t-shaped skills.

Am I wrong in believing that this where real coaching comes in? Helping people recognize the need to move from smelly places to better places? The path is not always clear or the same, am I right?


#8

Hells ya! That’s exactly what coaching is all about. If you can create positive change for just one or two people, your winning. I was trying to peel the onion back to understand the context of the situation. A lot of the dysfunction created within organizations can be attributed to systemic issues that are driving peoples behavior. Hence my question about personal agendas. Truth is most coaches can probably identify the root cause fairly quickly. A quick" five whys" will get you close. But we too typically don’t have the social capital to make drastic change. It is our job to make others see it.

Here is where to start; transparency, transparency, transparency. And I’m not talking about confluence and Jira. But rather physical information radiators in prime spots where they cannot be ignored.

Two potential experiments come to mind for your given situation. First, create an overall view of the program about a quarter out. Perhaps per a release plan per sprint, or kanban view. Typically feature level works best. Flag what work is pegged for each team, calling out tech vs. business intatives. The bottlenecks and overloads will surface immediately. Make them very transparent.

Second look into Def of Ready for each intative. “No new piece of work can be started until this criteria is met.” It protects the teams from getting shit just dumped on them.