Manifesto for Agile Line Managers

Managers? There’s no Managers in Scrum!

Its true the Scrum Guide makes no provisions for Managers, and really in single team Scrum (in a vacuum) there isn’t a need for a manager at all. However, the reality of most situations is that there will be management around any given Scrum team. Most Scrum teams are transformations in traditional organizations, which comes with management. Most organizations still require someone with the title of “Manager” to handle HR tasks like hiring and firing, approving time off, doing wage adjustments, etc. In certain scaling frameworks, this is even recognized and suggestions are made to ensure teams are able to self-organize and take control of what they do.

In LeSS, this is the concept of the “Line Manager”. They suggest a 100-to-1 ratio for each line manager, with the thinking that if a Line Manager has that many people to support, they will be too busy to interfere in the day to day operations of teams.  However, this doesn’t always happen over night (or at all), and managers may have the time and capability to be involved with team operations. In Agile, we recognize that many “traditional” management activities in Waterfall actually can be detrimental to a Scrum team.

OK, but a Manifesto?

I’ve recently been thinking quite a lot about the line manager, and how to help “command & control”-aholics kick the habit and act in a manner that will help uplift and grow teams. I did some google searches, and looked through various other sources, but I didn’t see anything that I liked, that I could provide to a line manager to use as I personally use the Agile Manifesto; something which helps codify where value is found, and what principles I believe lead to effectiveness.

So, I did what most people would: I created my own. I cribbed off of the Agile Manifesto, and came up with my own “Manifesto for Agile Line Managers”.  Now, I’m not a line manager, so I expect I probably got it wrong. I hope, having been in positions of authority, and having coached people in those positions, I’m not too far off.

I would have preferred to have taken a bunch of successful Agile Line Managers up to Snowbird, Utah and locked them in a room for a few days to come up with it, but A) I don’t have that kind of money or time, and B) I don’t know that many successful Agile Line Managers.  So I look to the community. I will cast out what I have created, hoping it sparks discussion, or at least one or two people find it useful.

All right then, let’s have it!

OK, here goes:

Manifesto for Agile Line Managers

We learn and discover better ways to allow teams to develop software in line with the Agile Manifesto for Software Development. We therefore have come to value:

Enabling Learning over Enforcing Rules

Empowering Teams over Insuring Delivery

Providing Vision over Delivering Directives

Taking Measured Risk over Avoiding Failure

While we can have success and find value in ideas on the right, we believe the ideas on the left will lead to greater overall success.

Principles behind Agile Line Management

Our highest priority is to enable Agile teams to deliver valuable software early and often.

We welcome changes to processes and rules, even long-standing ones. Agile teams learn by doing, and we must harness this change for the good of the organization.

Act quickly on required changes. Items which disempower teams will quickly cause loss of motivation and flow.

Managers and teams must collaborate to solve issues in ways that are both effective and understood.

Allow motivated individuals to form teams to deliver great results. Give them the environment and support they need, and trust them to get the job done.

The most effective method of communication is in person. Face to face communication and highly visible physical artifacts promote and enhance transparency and trust.

High functioning teams delivering working software is the primary measure of effectiveness of an Agile Line Manager.

Agile Line Managers enable sustainable development, through enabling learning and empowering teams to set a constant pace balancing growth, development and support.

Agile Line Managers allow teams to exercise technical excellence, and provide teams with the ability and support to continue to improve technical skills to enhance team Agility.

Simplicity in Management is essential to self-organization. Always apply the least amount of authority possible, with a bias towards empowerment and encouraging learning.

The best teams, rules, and procedures emerge in self-organizing organizations.

At regular intervals, Agile Line Management teams review their effectiveness, and reflect on the results of their actions, then use this reflection to adjust and tune behavior and technique.

That’s it?

That’s it. It’s not a replacement for the Agile Manifesto, rather and enhancement and refocusing of ideas towards Managers (or others with positional authority) working with Agile teams. I welcome your feedback, and hope it may be found useful by someone.  It’s probably not the last iteration of this idea either, I’m just one person, but maybe it gets people talking, and maybe as a community we come up with something great.

I’ll put image versions below. Please feel free to iterate on them, and share as you see fit.

LineManagerManifesto

PrinciplesBehindLineManagement

Advertisements

What Charity Showed Me About Flow

The other day, I participated in a charity event for Feed My Starving Children. This post is not to show how good of a person I am, for one does not do charity for recognition’s sake (the actual act of charity is reward enough). However, before I talk about some of the things that struck me as I was participating, I’d like to note that FMSC is a very worthy organization, worthy of one’s time, and if you see fit, worthy of one’s donation.

A FMSC event, at least as I have seen, is organized thus: they come in and take over an organization’s large room, and fill it with packing stations. At these stations, teams of around 10 (not sure on exact number) work together to measure out an amount of various ingredients, which make up a single meal, into a bag. The bags are then sealed, boxed, and sent to be placed on pallets, loaded up and shipped out. Folks participate in a two hour shift. They do a brief training before, and a brief after action review. Super high level view, but I think you get the idea. Here’s one of their videos, if you’d like to see some in action.

During my particular shift, I was working “Warehouse”, which is designation for the folks who support the table crews. I thought, firstly, that it might require less attention and activity than a packing table job (I was wrong!!). I also thought it would be interesting to see the flow of activity from place to place (I was right!). I was also joining a buddy of mine, who had worked the previous shift (his wife helps organize this whole event through the church of which they are a part, so shout out to Alicia and Journey of Faith church in Redondo Beach) doing this job by himself, for the most part.  It didn’t sound too difficult, however, we expected higher volume this shift due to crew makeup (more adults), and so we had a third gentleman as a member of our little logistics crew.

The finishing table consists of weighing each box as one of the “runners” delivered it to us, to ensure it was in the acceptable weight range (and therefore correctly packed based on quality controls no doubt done at the filling stations), sealing the boxes, marking the date and shift, and loading them onto a pallet. Once a pallet was fully loaded, another crew took our product and finished it for shipping. We quickly decided on roles, I would weigh and verify the boxes as they came in, my friend would settle and seal the boxes tightly, and the third member would mark the boxes once sealed, and load them onto the pallet.

Off goes the horn, and away we go. We have a bit of lag time at the beginning, as the teams begin to get their bearings and begin production. As the first few boxes begin to arrive to us, our flow works well, and the first few boxes go off without a hitch. However, the teams are now getting their stride, and runners are bringing full boxes more quickly. We run into our first issue, when multiple runners arrive at the same time. Only one box can be weighed at a time, so the runners dropped the boxes and moved on to the next. Unfortunately, the input and output stream get mixed, and we have no way to tell which boxes have been already weighed. Therefore, I needed to reweigh a few to ensure they were all correct, and none were missed. Quickly, we shifted, and I grabbed a marker, figuring that if I marked shift and time as I verified boxes complete, then we would know what can be sealed without me having to watch.  We powered through our bottle neck, and got back on track. In a lull between some boxes, we discussed the change as a team, so we all knew how boxes were shown as verified. Yay, problem solved!

We kept ticking, and fillers kept filling. We were receiving boxes from one a few at a time (which would be a great study on asynchronous delivery, but I will try to stay just where I was for now), but our process held up, and we were processing items through pretty well, continuing flow. That is, until there was an issue with one of the pallets that we had already finished, and my buddy had to pull off to help get that fixed. While we adjusted, and worked the best we could, this had multiple effects. For example, we’d suddenly lost a large portion of our processing ability, and we both had to fill in his role, while still trying to do our part, which from positioning was inefficient. Our team was too small to handle losing a member, and our process too tightly coupled. Due to this, we developed a bottleneck nearly immediately. Since work was piling up in the center of our process, when I went to help with that, work began to pile up at the beginning of our queue. This also had an effect the efficiency of the runners, as we were not as prepared to accept work from them. My friend was only away for about 5 minutes, but we had piled up about 7 boxes into our bottleneck by the time he’d returned. When he returned, we still had items mid process, and it took us about 15 more minutes to clear out our bottleneck and get back to a state of flow, where we were processing input as it arrived (about 3 times as long as he was gone!).  From this, we learned that if someone stepped off for an issue or a break, we had a member of the support crew (who could fill any role, as they were from FMSC) fill in. They may not have been as efficient, as they had to adapt to our flow, but it helped avoid major bottlenecks.

There were other various instances of inspect and adapt during the process, that I was aware of: reordering the table gave a visual indication of flow direction (improving the experience for the runners, and limiting mixing of processed and unprocessed data), orienting the boxes in the same direction as they came of the scale (facilitating both verification marking and sealing), and improvements on preparations for pallets (facilitating removal of completed work, and preparations for the next load). All of this, in a single two hour session.

A few key takeaways:

  • Don’t wait for a retrospective to inspect and adapt. Constantly be looking for ways to improve, and experiment (but make sure your team is aware!)
  • Achieving system flow is more important than achieving local optimization. Any improvements I make to my process are for naught if they negatively effect other parts of the flow.
  • Losing team members to “special projects” hurts the individual and the team. The individual loses connection, and the team may not have the skill or work ability to replace. The effects are far reaching, and a small gain at one point can cause a much greater loss elsewhere. If it’s good enough for one of us, it’s good enough for all of us; if it’s not good enough for all of us, it’s not good enough for any of us.
  • If the world was perfect, we’d all have exactly enough work to keep us busy without over loading. The world is not perfect. Flow is hampered when there is more work then can be done in a given period. Overloading a part of the process flow has far reaching effects before and after the single point. It is therefore better to do less than is possible, then to try to do more (when it can be set up that way!).
  • Above all, doing something for someone else is an uplifting experience. The rising tide raises all boats, so elevate someone else to elevate yourself. It feels good, and who knows what you might learn!

Our shift, by the way, was at that time the most productive shift of the event at the time. It was more than double of the previous shift my friend had done. We had no major issues, and everything went off pretty well. Past experiences can sometimes prep us for the future, but always remember that something may just come and blow your expectations away.

Once again, FMSC is a great organization, so if given the opportunity, I recommend supporting them as you see fit. Thanks to everyone that helped, and I hope that in some small way, both my efforts that night and my interpretations of them after the fact, helps you.