Busy Times – Personal Development, Organizational Restructuring and Big Rocks

Share
Reading time ~2 minutes

I’ve been quiet on here for a few weeks as I’ve been head-down on some pretty major work at Red Gate and publishing what I and the team have been up to on their freshly launched dev.red-gate.com mini-site.

Here’s a roundup of the highlights:

“Slack” – Exploring how we approach “slack time”. Ensuring slack is available to the right people at the right time and trying to keep it guilt-free.

A Manifesto (of sorts) for personal development – what we expect from each other in developing ourselves and our careers. The outcome of 2 months of Genchi Genbutsu (go see at the source) – asking some really direction questions face to face (individually) with every single member of our development teams.

Top Tips for personal development – 12 Tips on personal development from Red Gate’s development team (plus another 12 linked from this one). These are the tips we use as part of our new personal development plans but are equally useful as prompts to simply “get out and do something”.

Skills Maps – An overview of the skills maps we’re developing at Red Gate for our development team roles (it turns out what we’re trying is pretty unique and developed a bit of a buzz.

Personal Development Plans – A distillation of the “Stop trying to fix your weaknesses” articles posted on here over the last couple of months. We’re still rolling these out but the trials from a dozen managers and staff so far have been resoundingly positive.

Fresh off the press yesterday; Organizational Restructuring – An Insider View – Putting Convergence & Divergence into practice. How Red Gate are performing a complete organizational restructuring to their teams without the usual cloak and dagger HR hell.

Finally, Johanna Hunt and I have paired up again on our “Cracking Big Rocks” cards and workshop. After much editing, re-editing and review we published the second edition of the card deck at the end of September and took them out for a first run at Agile Cambridge. The revised deck includes a few new patterns, rewording of many of the old ones, some basic instructions and some lovely artwork on a few of the cards from our good friend Paul Stapleton.

Enjoy the Friday reading.

 

 

 

Some Thoughts on Project “Closure”

Share
Reading time ~5 minutes

I’m currently working with the team of function heads at Red Gate developing a “skills map” for all our development roles. (I’m primarily covering Project Management).

Having “bought-in” skills inventories at previous companies and failed with months of time and effort wasted, we’ve taken our approach from the ground-up, knowing our role definitions are pretty unique to us and managed to get to “usable” for trials in less than 2 weeks! (We’ll be sharing what we did in the near future)

Having mapped out the set of skills and directions at a high level, we’re in the process of taking each skill and defining what the skill actually means to us, why it’s important, what does “good” look like and where to turn for more info or help. Each of us on the team is trying a couple out for starters and then planning to crowd-source the rest.

I’ve decided to start with “Project Closure” as a skill that’s not too simplistic, is really important to us and an area where through most of my career I’ve not often seen a “great job” done.

Before I progress, what I mean by Project Closure is everything required to get from an in-flight running happily along project to “done” – the ramping-down.  This is Not what PMI, PRINCE2, APM or most other standard PM definitions define as “Closure”.

This disconnect is why I decided to write this post. Most PM resources talk about closure being sign-off, completion of project documentation and lessons-learned meetings or retrospectives (and a few other process and stakeholder type things).

Having done a bit of hunting, it turns out there’s very little information available on “ramp-down”. It’s no surprise projects overrun with the lack of support and resources that exist around this area! “Traditional” project closure happens once everything’s already been delivered.

Forgive me if I’m being a bit ranty here but surely that’s after the horse has bolted, right?

What about all that effort of putting all those loose project tentacles back in the box first?

An Octopus in a treasure chest

How do we get from an “in-flight” project to “Done”.

My best analogy to this comes from the “String and Octopus Guide to Parenthood” that my first ever boss sent me a copy of over 15 years ago.

5. Dressing small children is not as easy as it seems: first buy an octopus and a string bag. Attempt to put the octopus into the string bag so that none of the arms hang out.

Time allowed for this – all morning.

Closing out projects well is hard and it takes  longer than you ever expect it to.

I’ve not finished writing up the full skill definition yet but I wanted to share where I am so far for anyone out there that wants at least a slight pointer in the right direction…

(Note, this is my definition based on the context I work in at the moment. It doesn’t conform to any certifiable standard so don’t scream if you answer your PMI exam questions on closure with stuff from this and get it wrong.)

A Short Definition

Project Closure (as a skill) is the ability to take a project from actively running to successful delivery and completion with a happy team, low defects, no panics, and in a timely fashion.

This is usually meeting a planned release date if there’s one set but for some teams can also mean getting to a point where we’re shipping production quality software with completed, working features on a frequent, regular basis and have the ability to move a team successfully off of a project stream (ready to work on another) and close it down in a satisfactory way for the team, customers, product management and the business if needed.

Why Is This Valuable?

Unless we ship valuable working software regularly we don’t keep customers happy and we find it harder to attract new customers. Working on products that don’t ship for long periods of time also has a pretty negative impact on morale for everyone involved – we love getting our stuff in the hands of customers and making them happy & successful!

We also risk building up large quantities of undelivered code or features (“inventory” waste in Lean terms), racking up undiscovered defects, increasing project risk and technical debt. The longer a project or feature is under active development, typically the longer it takes to shut down and ship.

Being able to ship and close down a project  is vital to our ability to balance investment across projects and products as it’s likely we’ll always have less teams than things we want to deliver and need to be flexible around team size, availability and commitments.

What Does “Mastery” Look Like Here?

Someone handling project closure really well will have a good handle on the state of development in relation to the remaining time left for a project to run and how long it’s been since we last shipped a successful release.

You’d probably expect them to be looking at what’s needed to close out the project from the point it’s about 2/3 complete. As an example – if you’re running a 3 month project, then most of the effort from the PM in the last month will be around closing things down.

They’ll be winding things down in a controlled manner with no surprises and no extreme rushes to the goal. Known bugs will be visible, regularly reviewed and going down, release testing will be planned, scheduled and resourced – chances are there will be a full-team release test towards the very end. Documentation will be all well under control, a UI freeze will be planned and completed. Features will be winding down or completed and bug fixing will be moving from high-risk breaking type bug fixes to showstoppers, visible, cosmetic or quality issues and small functional gaps for tying off.

They’ll have worked with our marketing team or product manager to ensure marketing is ready to go. Our sales and support teams will be being briefed on the new features, and we’ll have probably completed at least one bug hunt.

In the week or 2 before closure we’d expect to see a controlled code freeze and whilst the PM might be having to negotiate and plan what’s coming next they’ll still have a really tight rein on scope, be making decisions on any new incoming issues and setting clear priorities.

They’ll be encouraging the team to support each other across roles and swarming on areas that need a real push whilst ensuring that we don’t lose sight of the original project goals, customers’ needs and product quality.

 

That’s it – so far. If you have anything useful to add to this, please dive in and comment (mind the tentacles)

 

 

Dietary Manipulation (Part 3) – Coffee

Share
Reading time ~2 minutes

This line of articles just doesn’t seem to want to die!

Okay, so….

Today is day 3 of the filter coffee machine near where my team sits being broken despite repeated repair attempts.

There’s one on the floor below but that means carrying full cups of hot coffee all over the building – it seems most of us have been drinking alternatives most of the time for a few days.

We weren’t really aware of the effect this was having on us until we spotted it yesterday!

Sat in a team meeting. A usually energised team were so lethargic we actually called the session short, had lunch and took a walk to the pub to wake ourselves up!

If that’s the impact going cold-turkey on filter coffee had on a 30 minute team meeting, I’m dreading seeing what it did to team productivity this week.

However…

Anyone that’s given up smoking will know that by day 3, the worst seems to be over, as nicotine levels in the body drop further and withdrawal dies down.

Today had been my most productive day all week.

  • It might be that I’ve finally capitulated to instant caffeinated coffee rather than very good – but not very caffeinated – tea.
  • It might be that the half-life of coffee in my system has dropped below withdrawal symptom level.
  • It might just be that I’ve gotten over a momentum hurdle on some of my work.

Chatting to another of the team, their sentiment is the same so I don’t think it’s just me. Now we’ve recognised the risk, we’re making the effort to reach the other machine.

Regardless – it’s a little disturbing (but in hindsight quite obvious) how much the continuous supply of good filter coffee impacts the energy levels of a development team!

Advice to managers – good coffee is a necessity, not a perk.

Dietary Manipulation (Part 2) – Carbo-Caution

Share
Reading time ~2 minutes

My first article on dietary manipulation was intended to be the last. However as I learn, so I must adjust…

Some time ago I had the pleasure of guiding a team through a backlog prioritization session – taking items from a large unsized, unordered backlog down to a subset that we believed could be achieved in a short window of time (either in the next 6 weeks or to the end of the summer).

I had the benefit of free lunch in the staff canteen. At the time I wasn’t sure if the food selection was normal for the site or if it was just an end of the month special – either way, the food was very good. Although there were salads and yogurt, it was frighteningly easy to load up on a mountain of well-prepared comfort munchies.

The session I was running was scheduled for about 2-3PM.

Can you see this coming?…

Remember how I previously loaded a team up on carbs so my audience would hit their low-ebb during a difficult patch?

When I’m leading a workshop with an unfamiliar group I’m not very good with pauses & quiet periods so I tend to fill in the gaps (I already know it’s a weakness for coaching). Despite the mix of comfy armchairs and the post-lunch downturn, the team did a great job. They were very tolerant of my ad-libbing and ran the exercise in really good faith but even so it was really hard work for me.

The good news is we achieved our goal in just under an hour. A small, actionable, prioritized set of “must do” items for the team to dedicate some time to clearing before the end of the summer.

Next time, I’ll try loading up with fresh coffee and see what we can get done in 30 minutes and before everyone needs a bathroom break :)

Epilogue: – I’ve just started working with this team full-time. The food is that good and the team are that accommodating all the time.

Must try to remember… No mid-afternoon team workshops. Oh and …must… …stick… …to….  salad & smoothies.

Well – sometimes.

Black Holes & Revelations

Share
Reading time ~3 minutes

Have you ever had to deal with a black hole on your team?

“As predicted by general relativity, the presence of a large mass deforms spacetime in such a way that the paths taken by particles bend towards the mass. At the event horizon of a black hole, this deformation becomes so strong that there are no paths that lead away from the black hole” – Wikipedia

I’m not a physicist so here’s a simplified view that I can fit in my smaller brain:

Black holes are like huge “gravity traps” sucking in all energy from the surrounding area. Energy and mass are drawn toward the event horizon, sucked in and lost forever. The more they take in, the larger or denser they get.

Here’s some cool stuff I learned from Karl Schoemer a few years ago.

A team undergoing change can be coarsely divided into 3 behaviors: Design, Default and Defiant/Detractor.

• The “Design” population are your role models; your supporters & change agents – but be aware, some may have short attention spans or become zealots. This is up to 20% of your population.
• Those following the “Default” behavior will sit on the fence; “What.. …ever”, “it doesn’t apply to me”, “I’ll carry on as I am thank you” are all common “default” responses. Typically this is 70% of your population!
• “Defiant/Detractor” behavior exhibits extreme symptoms including shouting, arguments, tantrums, sabotage, threatening to leave and pulling everyone else down with them. Less extreme responses include focusing on the minutiae, public cynicism and endless debate without action. In many cases, whilst this may seem prevalent, often this is actually as little as 10% of your population!

Now let’s return to the Black Hole. In space, black holes are invisible – only their effects can be seen. In change management, we simply fail to recognize and identify them.

Human black holes must be understood and handled with extreme caution.

For those inexperienced with black holes, your instinct will be to try and defuse them. You must spot when you are feeding a metaphorical black hole, rewarding negative behavior by pouring your finite energy and resources in. Feeding black holes provides them additional credibility in front of their peers – their gravity trap grows ever-larger.

Lean values time… Eliminate waste! – Where are you wasting your energy?
If you removed the energy feeding a black hole would it eventually burn out?
In human change, detractors usually either get with the program or leave.

If you’ve read some of my prior articles you’ll know that whilst I appreciate good people; if your behavior and attitude isn’t up to scratch, all the technical prowess in the world is unlikely to make me want you on my team.

Some black holes may be an almost permanent rift in space. Work to minimize their impact and sphere of influence rather than offering more fuel. Consider using them as your “professional cynic” – your sounding board for the detractor response – but be aware this is a lot like playing dodgeball with a burning coal. It’s usually safer to move them away from the powder magazine instead.

Where could your wasted energy be better spent?
Simple! Use it to shift the center of gravity on your team away from the black hole.
Partner with your “design” members as a team and swing your population of defaulters toward your chosen direction. Some may be pulled toward or into the black hole but work on the overall gravity shift to bring the team around.

If you don’t have sufficient design weight to adjust the center of gravity right now, go digging for more – one person at a time if needed. At some point you will be able to tip the balance.

(Oh – a nod to Muse for inspiring the title of this post)