Hopefully no one is out there to get this noise, but if you are, my apologies. Trying a new synchronization trick, and I don’t know if it will post to the stream or as a draft.
[sometime later]
Ok, pro-tip. You CAN send a post from Bear to WordPress on iOS, and that’s pretty slick. However, if you do so, it will post straight to the stream, for good or ill.
I’m experimenting with this because I’m debating using a microblog for my note booking purposes. Not a published one – just one I can reference to “flip back” through past thoughts. WordPress is almost certainly the wrong tool for the job – I’d be more likely to use a static site generator that can handle markdown files – and there are lots of ways to set that up, but they’re all 75-90% solutions with a little bit of extra work to make it go, and that’s the problem. If I want a notebook alternative, then it needs to be comparably reliable to just picking up paper.
I’ll figure it out. There absolutely are tools for this, I just don’t know them well enough yet.
There is something akin to Maslow’s Hierarchy of needs as it applies to success, and the foundation is something like “I still have a job”, with the next step up being “On track for raise/promotion” and it’s a few more steps up the pyramid before we get to “customer success”.
The thing is, Agile and its adherents can help a team through those subsequent steps, but the first two layers of the pyramid come from their leadership structure, usually in the form of their immediate management. If that leadership cannot create enough safety to get past the foundation, we are never going to get to the peak.
I attended AgileDC this week. I hadn’t planned on it, but at the last minute we got as nudge at work that our new GrandBoss was encouraging people to attend, so I shuffled my scheduled and went in. I’m very glad that I did. It’s a one day event, filled with 45 minute talks and well thought out breaks. I love the 45 minute format – it means fewer deep dives, but it also demands that speakers cut the fat from their decks and really focus in on the key of their point. As an aside, it also means that time-filler workshop activities must be kept to a minimum out of sheer necessity, and I am always up for that.
I had a number of takeaways from the event, but my favorite (and the one I’m itching to use) is a method of handling estimation which was rooted in my misunderstanding a speaker explain the bucket method.
For the unfamiliar (as I was) the method is a simple relative sizing tool that’s good with larger groups. Set up an empty table with a number of columns (these are the ‘buckets’) labeled according to your sizing schema – let’s go with fibonacci for simplicity. Grab the first ticket and simply put it at the middle, say, at 5.
Then, grab the next task, and rather than get into a long discussion of the “right size”, you simply ask “is this bigger, smaller, or about the same size as the last on? If it’s bigger, put it to the right, if it’s smaller, put it to the left. If it’s the same size, put it underneath.
Over time, you’ll fill in multiple columns, but the decision making process will be roughly the same – if the new task goes between two tasks, slide them apart and put it in there. At the end, you have a sorted, pointed list without anyone needing to have an argument about what a 5 “really means”
So, this is great, and I would love to try it, but the secret sauce was the part I misunderstood. For whatever reason, I missed the part where you label the buckets beforehand, so as I understood it, you just built the stack and then assigned the numbers based on how they shook out (so the leftmost is now 1).
I love this. It’s the estimation equivalent of building sidewalks to follow the grass worn by pedestrian traffic.
It has some risks – too few columns might result in inconsistent sizing (which can throw off velocity calculations) and too many might break the estimation schema (which is not automatically bad, but is probably a sign that your team is being a bit too granular).
So with that in mind, I think what I intend to try is somewhere between the original and my lack of understanding. I’ll keep the same 7 buckets (because I like 7 a lot of brain things) but I won’t label them the first time, and I’ll start in the middle.
This way, as a team, we will *find* what a 5 (or whatever) is for us. After a few rounds (or maybe even just one, if it goes well) if we have some agreement on an anchor point, then we can just start there and proceed.
Now, I haven’t tried this yet, though I may have an opportunity to soon. It’s exactly the sort of experiment I’m very excited to try.
I’ve been drawing variations on this diagram a lot lately.
These are what I think are the core components of an effective team1. These aren’t revolutionary ideas, but they’re the ones I’ve really zeroed on from a lot of really good sources, including Marquet’s Turn the Ship Around!(which probably informed this most strongly) and Dignan’s Brave New Work, and this is how I like to summarize them.
Like all such models, it’s not perfect – there’s a bit of unpacking necessary to turn it into a story, but I like the process. In short, these are the things that a team needs to know what needs to be done (Clarity), have the skills and resources necessary to do the thing (Capability) and it able and willing to take the necessary action (Autonomy)2.
Clarity
Clarity means the group can see the problem and see a path to resolution. This means that they understand the domain, have visibility into the situation, and have enough insight to be able to understand how a solution might work and test that hypothesis. Clarity need not be perfect (tip: it never will be) and it covers a number of critical things like understanding value, measuring the right things and the ability to learn.
In the absence of clarity you can have an incredibly capable team that goes nowhere or, worse, goes off a cliff at very high speed. If the team is good enough, they may still stumble onto success (broken clocks and all that), but that’s a bad thing to rely on.
Autonomy
This is probably the hairiest of the three, because it comes with all sorts of scary ideas like responsibility and independence, but it’s also the simplest to test for – if the team can see the problem (or opportunity) clearly and see how to fix (or take advantage of) it, are they able to do so? Most critically, can they decideto do so?
Usually, they don’t. There are permissions to pursue, processes to go through and a general lack of trust. This mistrust is usually framed as benign – it’s protecting the team from making mistakes or wasting resources. And it’s reasonable enough on its own – it the team has autonomy but lacks clarity, then they’re just a wrecking ball on the lookout for a load bearing wall.
However, without autonomy, even the best teams are hobbled. All that capability and clarity goes to waste as they sit around waiting for permission.
Capability
The biggest and most obvious part of capability is skill, but it’s not justskill. It also means having the resources, access, will and knowledge to do the work. There is a certain amount of flexibility demanded by this in complex situation – the necessary capabilities are not always predictable, but excess capabilities can bring in extra costs. As such, one element of capability is, paradoxically, restraint. The team does not just bring the right actions, they bring it in the right amount.
The absence of capability has the most obvious drawbacks – the work can’t get done. That might seem to make this the most critical of the three points, but it turns out that the opposite is true, for reasons we’ll get into in a second.
The Imperfect Triangle
This trio of keys is easy to spot when you find it, but most real world teams need to operate with a flawed version of these things to get through the day.
If a team has none of these, they’re going to be entirely reliant on proxies (see below) to get the work done. That’s a worst case scenario, and if that’s what’s going on, it’s almost certainly not the only problem.
If the team has only one, that can be worse in some ways. Clarity without autonomy or capability is a recipe for frustration. Autonomy without clarity or capability makes more problems than it solves. Capability without clarity or autonomy is just wasted potential. All three of those scenarios are grating on the soul.
A team that hits two of the keys might be better off. If they have clarity and capability, they might still get a lot done if the authority they follow is reasonably sharp. That is, they will be able to kick ass in the manner they’re instructed to. If they have capability and authority, then they can at least proceed with good intentions and general best practices in hopes that if they try enough things they will eventually solve the problem3. If a team has clarity and autonomy, but lacks capability, then they can learn, and since they know what they need to learn and are motivated to do so, they should have that third key in short order (which is why this is the easiest gap to overcome).
More likely, though, the team is getting by with a proxyfor one or more of the keys – some other attribute which offers enough similar benefits for functionality, but with some other tradeoff that’s usually for the worst.
The grand-daddy of proxies is instruction– it can technically cover for any gap. Instructions can tell you what you can do, what you should do, and how you should do it. The problem, of course, is that instructions are never as complicated as life, so whichever key is replaced with instructions has now become the limiting factor on the others. This is not necessarily disastrous – instructions canbe good, timely and useful. It’s just a lot of work to keep them that way.
One common proxy for clarity is certainty, a pernicious attribute which often presents itself as clarity but actually overlaps very little. Dogma and enthusiasm can provide the kind of direction that clarity provides, but without the guarantee that the direction is the right one. Unfortunately, because certainty also lacks clarity’s ability to judge itself, the inevitable failures are almost certain to be attributed to someone else.
Capability is a little bit harder to proxy for, but if you need to fake it, then a bit of flim flamgoes a long way. Look busy, produce good looking metrics and just never deliver. If your environment is dysfunctional enough, you can surf on this patter for ages.
Autonomy has a couple proxies, but my two favorites are panicand subversion. Panic is what happens in an emergency, and it’s now all hands are on deck, all rules are set aside and all eyes are on getting the job done. For some, this is their only taste of autonomy, and they will actively find ways to turn problems into emergencies in order to be able to “do something”.
Subversion takes the other route of recognizing that the lack of rules is a problem, and then just working around the problem. Backchannel deals, shadow networks and secret work get the actual work done while maintaining nominal command and control. This is admirable work, but if people on your team need to resort to this, that’s a real problem.
Scaling and Use
Ok, so it’s a triangle. Now what?
Technically, you can use this model to plan – look ahead and see what you’re doing to provide and encourage all three keys – but I admit I find more use in it as a diagnostic tool. If things go wrong, it can be handy to look at things in these terms and ask if one(or more) of the keys is missing or damaged, and if so if there is any way to fix that. It won’t always point to a solution, but it’s a good starting point.
Beyond that, once you get used to the pattern, you can scale it up or down. For groups, the model scales up even as responsibility diffuses and communication becomes challenging. The need for the trio is there, and the patterns of failure are similar, if larger. You can also scale down – these attributes apply to individuals, or even single tasks4. Generally speaking, if something needs to get done and it’s not getting done, check for these three things as a quick smoke test of how solid the infrastructure is.
This doesn’t JUST apply to teams, but unpacking that is a bit involved. A larger group may have these attributes, but it introduces more questions about how to distribute them. An army may have all three attributes, but they’re not evenly distributed the general may have autonomy, the spies may have clarity and the soldiers may have capability, but extra steps are required to keep those things connected. For my purposes, a team is something where all of these attributes are held by everyone on the team, even if they might be a bit lopsided on an individual basis. ↩
If I want a TED talk, I really need to give this a C name, to make this all punchy. ↩
This one is really common, even in teams that usually have all three keys, because sometimes the keys are situational or partial. An operations team dealing with an outage may not have clarity on how to resolve the problem, for example. What they do have is clarity on the best ways to identifythe problems, and if those fail, then they have the smarts and the persistence to keep at it. ↩
Is it actionable (Autonomy), doable (Capability) and useful(Clarity)? ↩
I think it’s necessary for a company to have a shared understanding of how they use Slack (and similar tools). If such an understanding exists, it’s incredibly powerful, but without shared understanding then the rules can change from moment to moment based on HIPPO and momentary frustrations. In this environment, collaboration and brainstorming can end up being treated as bad things because they’re not compliant with someone important’s vision.
Now, if you’re going all in on slack, this is pretty easy. There’s not much question of what to take to email or the like – the tool you’ll use is slack, and you make it work. This is great, if you can pull it off, but for a lot of people that is a bridge too far. So how do you get everyone on the same page when every communication requires the decision (and friction of) “Is this the right context?”
This is a bad situation, so the best we can do is try to make this decision simple. If you could boil it down to a few rules (“Finance discussions must be in email”) that works, but it scales poorly. What it really calls for is a shared metaphor.
The one I’ve been using lately is this: Treat your Slack as your company’s RAM.
For non-nerds, RAM is the memory on your computer or device where things happen. When a program runs, all the information necessary is kept in RAM. When I say it’s memory, I mean it’s memory the same way your hard drive is, but the components used to make RAM are faster than the ones in your drive because it’s constantly changing it’s contents as needed.
So RAM is essential to your computer functioning, but there are things it’s not for. Specifically, it is not a reliable place to keep any information, since its current contents could be swept away at any moment. For this, your computer has storage (like your hard drive) to keep things without losing them
Slack can serve the same role in your organization. It should be the place where things happen. What kind of things? Well, what do you do? Whatever it is, I bet it requires people needing to talk, think, plan and be creative. Slack is a great place for that stuff to happen, and your organization should encourage it.
But, like RAM, it is not necessarily where you want to keep things. Yes, Slack has pretty robust search functionality, so you might be able to recover things, but for a Slack of any size or age, search leaves too many possibilities for things to be lost. So it’s necessary you also identify your company’s memory. It’s probably Confluence, or a Wiki, or Sharepoint or something else. It might be more than one thing, in which case you have a different problem. Whatever the case, you should have a place where important things end up.
Now, you could just copy and paste into memory (‘dumping the RAM’) but with a little bit of mindfulness it’s reasonably easy to capture the outputs of discussions rather than the discussions themselves. This requires a little bit of extra work, but it’s a fantastic habit for an organization to develop for two reasons. First, by making it everyone’s responsibility, it gives a bit more ownership to decisions. Second, if the discussions as important enough to save, it’s important enough to take the time to get everyone on the same page, and communicate that agreement in a useful way.
It may take a little bit of time to get people used to this, but once they see that their outputs are treated as important (and that no outputs means it didn’t happen) then they can see how it benefits them, at which point you’ll be surprised how invested people are in the final result.
My son, an elementary schooler, participated in his school’s public speaking contest. Initial participation is mandatory for all students, but then a top 10 is selected for another round, and from that there’s a top 3 (and 3 alternates) who compete to win. Normal enough.
Now, the thing is that my son is a super bright, amazing dude with a palette so high that he could probably store acorns in there. We’re addressing it over time, but it’s meant all manner of speech issues, which were exacerbated because he picked up the habit of speaking fast from both his parents. So, last year, we tried to get him out of the contest on the grounds that it would just be embarrassing for him, but the principal (who is amazing) gave us a look and said that the kids who are going to have the roughest time are the ones who benefit from it most. So he did it, and that was the end of it.
Sort of.
This year, he actually put some work into it, and came back from the first round with the proud announcement that he had made the top ten. We were blown away. We did all the right parenting things, emphasizing that this was the result of his hard work and so on, and treated this as an absolute victory lap.
Then he made the top 3.
Now, I say this like it was an accident, but in reality he was busting hump practicing and improving. We were delighted and supportive, but this was coming from him.
So today was the finals, and he won for his grade.
We were floored and delighted. This has been very nearly a made-for-tv-movie kind of thing, and it has so fantastically driven home the lesson that HE can do these things. I really hope it sticks.
And in the realm of lessons, there’s an amusing sidebar. There’s another kid in the class who is very socially capable, able to do funny voices and so on. He also made the top 10, but ended up as an alternate because – frankly – he goofed around rather than work. My son was surprised and remarked to my wife at how good and funny this kid was, and she looked back at him and said “You’re right. Imagine how he could have done if he’d worked at it.” You could see the understanding hit the kid like a hammer.
So, given that one of our biggest goals is to not produce the kind of bright slacker that both of his parents are, this felt like a big win for everyone today. I have no idea if he wants to follow it up, but if the kid wants to make a podcast, I am all over it.
For an array of reasons, I’ve decided to become familiar with SAFe (the Scalable Agile Framework) and it’s proving an interesting education. The underlying model is not bad, and in fact it has one or two practices I wish I had known about earlier. My favorite? If you have multiple teams working on stuff, collect sprints into “increments” – buckets of 5 sprints – and have high level planning around that. Fun extra caveat – you only plan on 4 working sprints. The 5th sprint is nominally for creativity and exploration, and I love that idea, but the fact that it could also be used for hardening or deployment is a nice bit of flexibility.
Cynically, yes, it’s just a different wrapper around quarterly planning, but I admit I like the idea of models rolling up which is sort of the point of things like SAFe and Scrum@Scale.
Downside? I could not tell you why, but the diagrams I’ve run into as I learn SAFe are consistently horrible. I don’t think it’s necessary intrinsic to the framework, but the keystone image you see when you first go to find out about SAFe looks like this:
And I think that sort of establishes a tone of erring on the side of comprehensiveness over clarity. That’s not necessarily a bad thing, but it was definitely at odds with my expectation of something in the lean & agile space. That might just be on me, though.
I had reason to go through a LOT of archived video from old company meetings. Several years worth. It was kind of fun, if only to see how things used to be (especially haircuts) and how things had changed, but it was also a real grind. When we recorded these meetings, the thinking was that it would be a permanent record of what had been discussed – something we could look back on and learn something from.
In practice, I’m pretty sure I was the first person to see some of these videos ever. Not because the material was not valuable, but because no one is going to go back and watch hours of videos for possible insight when there’s actual work to be done.
Obviously, this is an argument for good record-keeping around meetings. Have an agenda, capture the key points and decisions, make sure that’s available. That sort of document is much more skimmable, so it might at least see some use.
Unfortunately, that doesn’t always happen. Sometimes for good reasons, sometimes for bad, we often will have meetings that don’t have any documentation, and the prospect of going back and creating documentation seems daunting and wasteful. I sympathize with this. I really and truly do. But there’s another option:
Just capture three bullet points.
Not even long ones. One post it note or index card should give you enough space. It’s not hard, it takes no particular time, and it’s easy to archive or communicate.
Now, I get why there may be some resistance to this – your meetings are complicated! They’re nuanced! Any attempt to summarize them in this fashion will lose all the critical information that you spent all that time putting into the slide deck! I completely understand.
BUT.
If the content of your meetings really matters that much, then you probably are having no problem keeping them documented. No one would willingly surrender such treasures.
But if they’re not being documented, then an incomplete document is better than nothing. It can capture key decisions, or just be a pointer to other information which is documented but maybe hard to skim (like video recordings).
If you’re still uncomfortable with this idea, do me a favor and think of a meeting you had last week. Any meeting. What can you remember about it? There’s a non-zero chance the answer is “nothing”, so try to pick one that you recall. What do you remember about it?
Unless you cheated and checked your notes, I will bet that your recollection lines up pretty well with a few bullet points. You remember why the meeting happened, what was decided, and anything urgent that came. up. Anything more detailed than that maybe lives in your task list or your personal notes, and those things are being dealt with appropriately.
And that’s as it should be. The goal of the meeting is to unpack things in the moment, but then allow everyone to proceed. If something is important, it will generate its own work. The meeting itself needs only a few bullets to pin itself up in your brain.
Still skeptical? Give it a try for a week. It’s not a lot of work, and can be done in a notebook, a text file or anything else. At the end of the week, take 30 seconds to look over the bullets and see if you think anything is missing. Maybe it will be an unnecessary exercise. But if you are used to getting to the end of the week and wondering how you lost so much of your time to meetings, it just might help you get a better sense of your own reality.
And if you use that information to start demanding better meetings? Well, that’s just a bonus.
Fitbit experiment is looking like a failure. My steps have not been great, but I’ve been sick, so I’m not actually thrown off by that. The problem is that the Fitbit is INCREDIBLY GENEROUS in in interpreting steps. I woke up this morning to discover I had 820 steps already, and it similarly adds hundreds every time I take a drive.
So, back to just the watch. Annoying, but workable.
I am about to start rocking a smart device on each wrist. It’s going to look goofy, but I am driven by necessity. See, this past weekend I went to a convention and got in about 30,000 steps over the course of the weekend. Back when I was tracking my steps this would have been a pretty normal weekend, but I’ve been off that habit long enough that I am embarrassingly sore this morning. Enough so to make me want to get back in the habit.
The problem is that I stopped when I switched to the Apple Watch. It’s a great device, and I love mine, but it is crap as a pedometer. Not because it can’t track steps (it can, very well) but because that information is not privileged in the interface. Either I have to drill down into the health app to see my steps, or I have to use a third party app (pedometer++) which is great, but which can’t display in realtime because of the watch’s limitation.
Intellectually, this shouldn’t be a big deal. It’s just a few more seconds and a few more clicks to check my steps – how in the world can that have a drastic impact on behavior?
My suspicion is that it’s all about keeping the information at top of mind. When my steps are presented to me, I stay mindful of them (and the associated behaviors) with no effort on my part. When I have to find them, that introduces enough friction that it’s easy to forget to check, and by extension to then forget the behavior.
That’s the theory. An alternate theory may be that I have just been slacking, and I can’t rule that out. But I have enough experience to know that if I try to solve this problem with good intentions and brute force willpower, then I’ll have a few good days before it all collapses for perfectly legitimate reasons. I need to build a ramp, and in this case, this ramp is going to mean wearing two watches.
There is something akin to Maslow’s Hierarchy of needs as it applies to success, and the foundation is something like “I still have a job”, with the next step up being “On track for raise/promotion” and it’s a few more steps up the pyramid before we get to “customer success”.
Frustration
Remove Clarity => Wrecking Ball
Remove Capability => Learners” class=”wp-image-126″/>
I think it’s necessary for a company to have a shared understanding of how they use Slack (and similar tools). If such an understanding exists, it’s incredibly powerful, but without shared understanding then the rules can change from moment to moment based on HIPPO and momentary frustrations. In this environment, collaboration and brainstorming can end up being treated as bad things because they’re not compliant with someone important’s vision.
I had reason to go through a LOT of archived video from old company meetings. Several years worth. It was kind of fun, if only to see how things used to be (especially haircuts) and how things had changed, but it was also a real grind. When we recorded these meetings, the thinking was that it would be a permanent record of what had been discussed – something we could look back on and learn something from.
I am about to start rocking a smart device on each wrist. It’s going to look goofy, but I am driven by necessity. See, this past weekend I went to a convention and got in about 30,000 steps over the course of the weekend. Back when I was tracking my steps this would have been a pretty normal weekend, but I’ve been off that habit long enough that I am embarrassingly sore this morning. Enough so to make me want to get back in the habit.
Never Not Learning 