Shy? Try Exercising Your Asking Muscles

Share
Reading time ~4 minutes

Some Friday morning amateur social philosophy.

One of my current team is as shy as I am. We both agree that “we’d rather not deal with people”. It’s somewhat funny that even from the first day of my degree I had to work in teams and interact with external stakeholders. My ability to do so is my strength (but my dirty secret is that it’s also my biggest fear).

I’ve read and re-read loads of stuff on being an introvert, on being shy and assorted other musings for the “socially challenged”. I’m not socially awkward – I might be a bit of an over-sharer but once I’m up and running I can be the life and soul of the corner of the kitchen at a party, I enjoy sharing, I enjoy interacting with people but I’m like a dynamo – I need some winding up to reach that state.

I think my favorite term comes from Doc List who describes himself as an “Ambivert”. I think his observations closely define me as well.

Most people that I interact with in public or at work would never believe I’m shy. It’s one of the joys of the agile/conference scene – you know most people are just like you. They wear a mantle of bravery and a mask of confidence but after a week of conferences will happily spend the weekend recovering under the covers. Over the years those people become friends and the interactions become easier.

I gain short-term energy from talking to people but I’m exhausted afterwards. I find nothing more draining than leading planning sessions, demos and retrospectives but most people will never see it. In some camps that counts as introverted, in others extroverted – Let’s stick with ambivert.

Anyway. A challenge with being shy/introverted or even an ambivert is asking. Asking for help, information or even asking someone to do something you know is their responsibility or even pleasure to do for you.

As a project manager or leader this is a bit of a crazy situation. Every day I need to ask my team or external stakeholders for an assortment of things. The emotional effort needed to ask can vary from easy to terrifying and descends into experiences that are often addressed with Cognitive Behavior Therapy.

  • You believe it’s unreasonable to ask busy people for more of their time to meet needs you think are yours.
  • You feel (or have been told) you should ask someone for help or input.
  • You’re trying to make a difference, you know other people care but you don’t know how to approach the subject.
  • The list of doubts, “Shoulds” and “aughts” goes on.

From my experiences I’ve discovered the ability to ask is like any other mental muscle. If you use it regularly it gets better. If you don’t use it it wastes away. 

Unfortunately that shy moment freezes you up. It means you’re more inclined to not ask until it’s critical so you end up making life harder for yourself and the person you need to ask. All the while you’re procrastinating you’re expending mental cycles on stress and doing nothing.

But there’s more to it than that.

Each person you need to ask something of is a different muscle.

When I first started working as a PM in our DevOps group a few years ago I was new to the company, I had few existing working relationships and a number of key stakeholders I needed to learn to interact with.

How did I build up my asking muscles?

I reviewed my working relationships in the past to understand what I found easy and what was more difficult.  I found – even with my own team – that after about 3 useful interactions in a short period of time things became significantly easier so I decided to try an experiment.

There’s a neat idea in software development known as the “rule of three” – once you’ve needed to use the same thing 3 times then it’s probably time to make it generic and standardize it.

I bought a small (A3) sized whiteboard and placed it on my desk. On the board I drew a grid. Each horizontal lane represented a person I needed to learn to interact with. I wrote each name in the left-hand column. Each column after that was a placeholder where I’d mark an X every time I had an asking or collaborative interaction with that person. My goal was to get 3 X’s in each row over the space of about a month.

It worked – when there were only one or two X’s I’d figure out how I could build another interaction with that person that didn’t have to involve asking for anything significant.

One of those people came over to my desk and spotted my board – they asked what the “X’s” next to their name were. I explained and they immediately empathized. I wasn’t alone. That conversation counted as yet another X – It became easier to ask!

The tricky thing is once you’ve built those muscles up you need to kep them running.

If you neglect your asking skills for any time you need to rebuild them again (sometimes the second time is easier). If like me your projects and roles change a lot over the years you’ll probably find that by the time you’ve just got comfortable with everyone you need to ask that the world changes around you and you need to start again.

This is a good thing – it keeps us exercising our asking muscles.

Who do you want to ask something of today?

Go talk to them.

Have a great weekend

Simon

Seeing the Value in Task Estimates

Share
Reading time ~5 minutes

a list of task estimate sizes with beta curves overlaidYou might be aware of the ongoing discussions around the #noEstimates movement right now. I have the luxury here of rarely needing to use estimates as commitments to management but I usually (not always) still ask my teams to estimate their tasks.

My consistently positive experiences so far mean I’m unlikely to stop any time soon.

3 weeks ago I joined a new team. I decided I wanted to get back into the commercial side of the business for a while so I’ve joined our Sales Operations team. (Think DevOps but for sales admin, systems, reporting, targeting & metrics).

Fortunately for me the current manager of the team who took the role on a month or so earlier is amazing. She has so much sales domain knowledge, an instinct for what’s going on and deeply understands what’s needed by our customers (the sales teams).

I’d been working with her informally for a while getting her up to speed on agile project management so by the time I joined the team already had a basic whiteboard in place, were having effective daily standups and were tracking tasks.

The big problem with an ops team is balancing strategic and tactical work. Right now the work is all tactical, urgent items come in daily at the cost of important but less urgent work.

We’re also facing capacity issues with the team and much of the work is all flowing to a single domain expert who’s due to go on leave for a few months this Summer – again a common problem in ops teams.

I observed the movement of tasks on the team board for a week to understand how things were running, spot what was flowing well and what was blocked. As I observed I noted challenges being faced and possible improvements to make. By the end of the week I started implementing a series of near-daily changes – My approach was very similar to that taken in “a year of whiteboard evolution“.

Since the start of April we’ve made 17 “tweaks” to the way the team works and have a backlog of nearly 30 more.

Last week we started adding estimates to tasks.

I trained the team on task estimation – it took less than 10 minutes to explain after one of our standups. The technical details on how I teach this are in my post on story points. But there’s more than just the technical aspect. (In fact the technicalities are secondary to be honest)

Here’s the human side of task estimation…

  • Tasks are estimated in what I describe as “day fragments” – essentially an effort hours equivalent of story points. These are periods of time “small enough to fit in your head”.
  • The distribution scale for task estimates I recommend is always the same. 0.5, 1, 2, 4, 8, 16, 24 hours. (the last 3 are 1, 2 and 3 days) – It’s rare to see a task with a “24” on it. This offers the same kind of declining precision we see with Fibonacci-based story point estimates.
  • For the level of accuracy & precision we’re after I recommend spending less than 30 seconds to provide an estimate for any task. (Usually more like 5-10)
  • If you can’t provide an estimate then you’re missing a task somewhere on understanding what’s needed.
  • Any task of size 8 or more is probably more than one task.
  • Simply having an estimate on a task makes it easier to start work on – especially if the estimate is small (this is one of the tactics in the Cracking Big Rocks card deck)
  • By having an estimate, you have a better idea of when you’ll be done based on other commitments and activities, this means you can manage expectations better.
  • The estimates don’t need to be accurate but the more often you estimate, the better you get at it.
  • When a task is “done”, we re-check the estimate but we only change the number if the result is wildly off. E.g. if a 1 day task takes just an hour or vice versa. And we only do this to learn, understand and improve, not to worry or blame.

So why is this worth doing?

Within a day we were already seeing improvements to our flow of work and after a week we had results to show for it.

  • The majority of tasks fell into the 0.5 or 1 hour buckets – a sign of lots of reactive small items.
  • Tasks with estimates of 8 hours or more (1 day’s effort) were consistently “stuck”.
  • We spotted many small tasks jumping the queue ahead of larger more important items despite not being urgent. (Because they were easier to deliver and well-understood)
  • Vague tasks that had been hanging around for weeks were pulled off of the board and replaced with a series more concrete smaller actions. (I didn’t even have to do any prompting)
  • Tasks that still couldn’t be estimated spawned 0.5 or 1 hour tasks to figure out what needed to be done.
  • Large blocked items started moving again.
  • Team members were more confident in what could be achieved and when.
  • We can start capacity planning and gathering data for defining service level agreements and planning more strategic work.

I’m not saying you have to estimate tasks but I strongly believe in the benefits they provide internally to a team.

If you’re not doing so already, try a little simple education with your teams and then run an experiment for a while. You can always stop if it’s not working for you.

 

 

A quick update – Janne Sinivirta pointed out that “none of the benefits seem to be from estimates, rather about task breakdown and understanding the tasks.”

He’s got a good point. This is a key thing for me about task estimation. It highlights quickly what you do & don’t understand. The value is at least partially in estimating, not estimates. (Much like the act of planning vs following a plan). Although by adding the estimates to tasks on the wall we could quickly see patterns in flow of tasks that were less clear before and act sooner.

As we move from tactical to strategic work I expect we’ll still need those numbers to help inform how much of our time we need to spend on reactive work. (In most teams I’ve worked in it’s historically about 20% but it’s looking like much more than that here so far).

Martin Burns also highlighted that understanding and breaking down tasks is where much of the work lies. The equivalent of that in this team is in recognising what needs investigation and discussion with users and what doesn’t and adding tasks for those items.

1,000% improvement is a statistical outlier

Share
Reading time ~3 minutes

This cautionary tale came up a few times at Agile 2010 (yes I know this may be old news!) – including one of the keynote speeches.

“For a million dollars we’ll make you Agile.

Here’s a list of previous clients whom we helped achieve a 1,000% performance improvement. Lead times halved, profits doubled and everyone was AWESOME!.

Here’s some REAL DATA …”

A graph going "up and to the right"

Axis titles shamelessly acquired from a recent company presentation

What you’ve not been told is that those testimonies are statistical outliers!

These are the top 1-5% of companies that have successfully undergone a major transformation. (or the bar was set very low to start with) There are thousands of companies out there that don’t reach these lofty heights.

The journey is longer and harder than the marketing will ever tell you but that’s fine as long as you know what you’re investing in and why.

Your organization is unique. There are many factors about your organization that will make significant improvements hard to achieve and most of them will not be technical. The forces of resistance will be many and will be a mix of institutionalized and personal.

Let’s replay this with a more realistic conversation…

A consultant visits your site, and does a “free” one-day Agile Assessment of your teams.

“OK Boss. Right now you suck at developing software. Give us a million dollars, a year of your time and a willingness to drop productivity for a while and we can make you suck a bit less.”

Furthermore, they won’t actually be able to tell you just how much less you can suck and by when.

Why not?

Back to all those forces of resistance – how many of those can you really prod, assess and quantify in a day or even a week?

Every company, organization and site differs.

The investment may still be worthwhile but it’s time to manage expectations better. Those assessments should highlight where unexpected limitations lie. Maybe they could offer alternative higher priority areas to tackle (rather than up-selling scope).

If product development and software engineering was like cutting coke cans, there really would be a “one true right way” of producing software products.

Moreover. There wouldn’t be a thousand consultancies promising you the moon on a stick, there wouldn’t be conferences on improving the state of the art and there wouldn’t be hundreds of books full of great ideas on how to do/be agile or perform software engineering a little bit better.

In fact chances are there wouldn’t be a competitive software industry.

Or would there?

• Maybe there really is a one true way and the entire software, consulting, authoring and conference industry is in on the joke.

• Maybe all those leading lights on their skiing trip a decade ago came up with one of the world’s greatest “Long Cons”

• Oh and they invited 3M to the party and agreed to promote stickies in the 21st century in exchange for a marketing budget.

Probably not…

There are no “best practices”. Stop looking for them, stop asking consultants and Scrum Masters to implement them.

There are only “best known practices for your current state, knowledge and context”.

When your state, knowledge and context change, it’s time to look at what’s next and more importantly – what’s beyond your current focus – what have you missed or not considered yet?

What did you discard previously because there were constraints or issues preventing them working? (I learned a great term for this from Chris Matts &/or Dan North – I can’t remember which – “Idea Wombling” – seeking out great ideas that were previously discarded)

You may reach a point where your organizational immune system (politics and process) blocks progress.

Sometimes you’ll need outside help to see what’s “better” or learn new ways of working. That outside help can often be more effective at delivering hard truths than you can yourself. It’s worth investing in “straight-talk” from strangers sometimes.

Figure out what is holding larger improvements back (and where) and determine who you could pair with either externally or in a different part of the organization to make a real difference!

We Create The Politics Ourselves

Share
Reading time ~5 minutes

Back in June 2013 I was asked to facilitate a discussion exploring one of Red Gate’s company values – No Politics. This was the second in a series of open sessions that the company had initiated to preserve and highlight what they have valued for many years and to get to the bottom of what these values mean, their relevance and impact on individuals and teams around the business. The expanded wording for our “No Politics” value is:

No gossiping, no intrigue, no pussy-footing around problems and no telling people what you think they want to hear whilst privately disagreeing. We will be transparent in our dealings.

Many of our staff – myself included – were starting to feel that we were no longer being true to this value.

After an hour’s discussion between about 40 of us including concrete examples of where many of us felt we’d seen or been involved in “politics” we established:

Politics are created when “your needs” conflict in some way with “my needs” and where both “you” and “I” fail to openly communicate.

Taking this further – all the examples of politics we’d seen boiled down to a combination of failures in communication of motive and intent and failure to share conflicting needs. Ironically, we’re usually all trying to achieve the same ultimate goal.

Our encouraged altruistic culture tended to exacerbate the situation further and cause us to wade in when we felt a decision had insufficiently involved those impacted – even when the person taking exception felt the decision was right. (You should have seen the angst when a rapid decision was taken “on high” to move to Github for all product development)

Our values and culture have encouraged this “challenge everything” behaviour for years!

Being on the receiving end of a change or decision we don’t fully understand, agree with or have had no involvement in makes us feel bad, we internalize and build that frustration up and start sharing it in passing conversations, at coffee and in corridors – because we’re entitled to share our opinions. But we’re all pretty gentle and fluffy here. We’re a software company, many of us are shy and conflict-averse. This means we share our worries in private and let them radiate out. (This also means any vocal or forceful minority have much stronger voices)

We create the politics ourselves

Since discussing and recognising this fact I started making a concerted effort to tackle issues head-on again and had a deeply humbling moment when a colleague pulled the “grown up” card on me for my own bad behaviour.

It’s amazing how the weight comes off when you realise that everyone is trying to do the right thing within their own context and needs and often have simply not recognised where this butts up against our own. (And that you have failed to empathize with them!)  Gently calling out those disconnects and addressing them has defused even some of the thorniest conflicts I’ve faced.

Oddly, I hadn’t recognised a link until a serendipitous moment yesterday but my friend Clarke talked me through some aspects of this same challenge a few years ago. He’s since written up his thoughts in detail here.

I also see this same expression and sharing of uncommunicated needs as a cornerstone of non-violent communication.

If you’re still reading, as some background here’s the wording of the full set of values as included in the “Book of Red Gate”  (an earlier 2010 Edition is also available) – we’re reviewing whether these are still the right set and the right words even now but they do capture a lot about working here.

  • You will be reasonable with us. We will be reasonable with you

We’re all trying to treat each other as we would like to be treated in the same circumstances. Sometimes the circumstances are difficult, but we will all still be reasonable.

  • Attempt to do the best work of your life

We’d like you to achieve your own greatness and to be all that you can be. We’ll try hard to allow that to happen and we’d like you to try hard too.

  • Motivation isn’t about carrots and sticks

Constant oversight and the threat of punishment are incompatible with great, fulfilling work. We believe in creating appropriate constraints and then giving people the freedom to excel.

  • Our best work is done in teams 

We work in groups and towards a common goal. The company is more important than the team, and the team is more important than the individual.

  • Don’t be an asshole

No matter how smart you are, or how good you are at narrowly defined tasks, there is no room for you here if you’re an asshole.

  • Get the right stuff done

We admire people who get stuff done.  While there’s a place for planning, thinking and process it is better to try – and try well – and fail than not to try at all.

  • Visible mistakes are a sign that we are a healthy organization

What we do is very difficult, the current situation is hard to understand and the future is uncertain. Mistakes are an inevitable consequence of attempting to get the right stuff done. Unless we can make mistakes visible both individually and collectively we will be doomed to mediocrity.

  • No politics

No gossiping, no intrigue, no pussy-footing around problems and no telling people what you think they want to hear whilst privately disagreeing. We will be transparent in our dealings.

  • Do the right things for our customers

We believe that if we do what is right for our customers then we will thrive.

  • Profits are only a way of keeping score, not the game itself

Focusing purely on the numbers is a sure way to kill Red Gate’s culture. We believe that if we focus on the game – building awesome products that people want to buy, and then persuading them to buy them – the success will follow.

  • We will succeed if we build wonderful, useful products

Shipping something amazing is better than creating something average and to budget and on time. We cannot market, sell, manage or account our way to success.

  • We base our decisions on the available evidence

Not on people’s opinions, the volume of their voices or who they are. When the evidence changes, we are prepared to change our minds. We will thank, and never shoot, the messenger.

  • We count contribution, not hours

What you achieve is more important than how long it takes.

A Year of Whiteboard Evolution

Share
Reading time ~2 minutes

Back in December last year I started supporting Red Gate’s .NET Developer Tools Division. As of this month, we’ve restructured the company and from next week, the old division will be no more (although the team are still in place in their new home).

When I joined the team things were going OK but they had the potential to be so much more so I paired up with Dom their project manager and we set to work.

The ANTS Performance Profiler 8.0 project was well under way already and the team had a basic Scrum-like process in place (without retrospectives), a simple whiteboard and a wall for sharing the “big picture”.

I spent the first week on the team simply getting to know everyone, how things worked and observing the board, the standups and the team activities.

We learned some time ago here at Red Gate that when you ask a team to talk you through their whiteboard, they tell the story of their overall process and how it works. Our whiteboards capture a huge amount about what we do and how we do it.

I attempted to document and capture at least some key parts of the journey we’ve have over the year in which we released over a dozen large product updates across our whole suite of tools. This post is picture heavy with quite limited narrative but I hope you’ll enjoy the process voyeurism :) If there’s any specifics you have questions about, please ask and I’ll expand.

Next time, I think I’ll get a fixed camera and take daily photos!

The end result? Multiple releases of all 5 of our .NET tools including a startup and quality overhaul for our 2 most popular products, support for a bunch of new database platforms, full VS2013 support (before VS2013 was publicly released), Windows 8 and 8.1 compatibility and a huge boost for the morale of the team.  See for yourself if you’re interested!

Of course this is just one aspect of what I’ve been up to. You might notice the time between photos over the summer grew a little. See my last post for more insights into what happens at Red Gate Towers.