Back in 2012 I ran a small workshop at SyncNorwich on iteration planning. It wasn’t one of my best but went down well with the dozen or so participants I had.
During the workshop I asked participants to take a “textbook example” of a sprint planning agenda and adapt it to their own needs. I’ve uploaded the planning worksheet for anyone who fancies experimenting with this for themselves.
If you’re interested, here’s the presentation itself:
Happy new year!
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.
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.
It’s been a month since I last posted about the work I’ve been doing around career development. Things are moving well and trials of the process described in the first 2 posts in this series have been really successful and way more popular than I expected. Everyone I’ve spoken to about it has been really excited and we’re now doing an expanded second round of trials with another 20 staff before adjusting and rolling out as a tool to all our development teams.
This is just a quick post to highlight a few tweaks and important points for anyone wanting to try this themselves…
So far everyone that’s tried it has found it really useful. My 2 favorite quotes so far…
“I never would have thought of some of the areas to action without this process”
“I’m better able to prioritize actions because of the process”
This will almost certainly work best for people with quite a strong sense of self-awareness and self-improvement already (as does any development plan) and remember you can’t force this on someone.
There’s bound to be cases where this process doesn’t work but we’ve not found one yet. If you try this yourself, we’d love to hear how it’s worked for you and remember, after trying it out once or twice, it’s worth tailoring to your own needs further.
(I’d still aim for running one straight-through session first time around as the energy from doing it all in one shot is fantastic)
Inspired by a twitter conversation with Bob Marshall, Marc Johnson and Nicole Rauch.
What really are my needs when I’m looking to hire someone onto my team or organization?
This article is a great start on interviewing and the goals of doing so. (whether or not you agree or disagree with the content)
In particular, understanding :
I have to admit that’s a good summary of my needs – I’d add “Will they fit with the way we do things as a company?” as well.
What about the needs of the person applying?
Well there’s the whole safety, security Maslow’s hierarchy of needs type stuff for starters. There’s also Dan Pink’s work on Drive
“. Mastery, Autonomy, Purpose. Jurgen Appelo is doing some amazing stuff around this at the moment too but…
At the end of the day, this is a 2 way relationship. If neither of us will find our needs fulfilled, it’s just not going to work.
Incidentally we’ve found from talking to all of our teams recently that trust, respect, peer recognition, support and self-fulfillment are pretty key.
Chapter 1 of “Love ‘Em or Lose ‘Em
Before we even get to this point there’s a bunch of work to do though.
At the moment I see hiring as a funnel type of workflow with iterative filtering:
Note, this is just one example – I generally see the hiring process continuing through to being a successful, happy team member with a happy team.
I’m writing this post quite hastily but if we look at that flow, there’s a value stream in terms of effort and cycle time per candidate and also a funnel at which points candidates “drop out”. There’s a lot of effort, a lot of waiting and a lot of waste. I truly think there could be something better but I’ve not tackled the problem yet (and perhaps that’s part of my problem!)
Here’s the first challenge I face…
As a hiring manager, my time is at a premium. I’m usually trying to do at least one other job at the same time as hiring (usually running a project and team) and often working on other “hidden projects” such as improving the way parts of the organization work (including adjusting and learning from feedback on the hiring process itself and the types of candidates we’re getting through).
On top of that, it’s really hard to attract the “right” people – back to skills, motivation, team & company fit.
Our first port of call in most cases is a covering letter and CV. Sometimes we start with an introduction or conversation but eventually we usually go back to a CV.
We’ve hired most of the people we already know are good that want to work here (location and company-wise), that we can honestly afford and are available. (Being based within an hour’s easy commute of London means competition for good people is tough). So most remaining applications come from strangers.
If someone’s a stranger, how are they able to catch our attention (in a positive way) to make it clear to us they’re worth engaging with, spending our limited time getting to know and developing a positive relationship with? Particularly when there may be dozens (or in my last company, hundreds) of others competing for that same attention. This works both ways – how do I get your attention too?
For my current job, I developed an early relationship through reputation first but at the point we decided to formalize things, I was still happy to present my CV. I’m proud of what I’ve achieved and earlier conversations could have missed things that were relevant and valuable. In my case this was particularly true. I worked on CRM and order management systems early in my career and the conversations I’d been having so far weren’t around this area but it turned out this experience was really valuable to them. We wouldn’t have made that connection without my CV.
If someone approached us without a CV as a total stranger we’d have no idea what to expect it’s a gamble as to whether we’re dealing with someone we really want to know or not and realistically the little time I have for hiring isn’t an area I choose to gamble blind. That initial “Yes/Maybe/No” that I can get from reading a CV is a lot quicker that talking to every single person that applies to figure out what they can offer that’s relevant or valuable.
Similarly, job specs are like CVs – would you apply for a job with no spec? How do you know what’s expected of you and whether you’re a good match?
So, my needs – assuming you’re a stranger…
OR
I’m sure there’s more but this is plenty for now.
What are your needs when you look for a new job and how do I get your attention?
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?
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.)
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.
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.
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)
A cheeky re-post of my article published today at dev.red-gate.com
This is a tip that I originally picked up from Liz Keogh in one of her talks on BDD a couple of years ago…
“Can you give me an example of that?”
OK, so it’s not quite BDD but I’m currently working with the team of function heads at my current employer (a team of us leading communities of practice around each function of development) to explore and address concerns and issues around career progression for development team roles within our flat organizational structure.
We don’t have “Junior” or “Senior” type job titles so someone who’s great at their job can easily remain with the same job title for many years. But there’s still a desire from individuals to feel their careers are progressing. Rather than conceding to job titles we’re in the process of completing a study by interviewing every member of our development teams and asking a really direct set of questions. (we’ll publish more detail on the questions we’re asking over at dev.red-gate.com.) These were pretty daunting to start with but the candid responses and conversations we’ve been having have been amazing.
As a sneak preview so far, one aspect of our data is showing us that the majority of team members here don’t care about job titles – except in the ability to use them to define a sort of communication contract that allows us to set expectations about the kind of things we’re interested in and expect to be discussing.
As an example, we rely heavily on our User Experience team to do a lot of analysis and design work but this consists of multiple roles or specialized activities; Visual Design, Interaction Design, User Research, Functional Design, Service Design etc.
When talking to a UX person we frame our context in “User Experience” but that might not be precise enough to focus on the right value. Equally, most UX people I’ve worked with have natural specialisms within their field.
We expect all our staff to have some level of interdisciplinary skills – “T-Shaped” people. Some have a desire to become more “A-Shaped” (or even M-Shaped) by developing additional specialisms over time, some want to broaden their interdisciplinary skills whilst some want to extend their current specialism.
This is a really tough problem to solve so we’re looking at various paths around career development using named roles, collections of directionally aligned skills and personal development planning conversations (see my previous two posts).
In exploring our options, we kept coming onto discussions like “what about the person who has no idea what they want to do” and then diving into trying to develop a skills framework, map or tool that would support this problem. In reality this is an edge case and we’re probably trying to solve the whole problem without tackling issues that would work for the majority and then learning from these.
So I borrowed Liz’s BDD trick. We’ve already interviewed and gathered concrete qualitative data from nearly 80 staff but were still talking about cases in the abstract.
I asked:
“From the data we already have, can you give me a concrete example of someone that has this problem”.
After 3 failed attempts we realized that even in the cases where staff didn’t know what they wanted their next role to be, they still had a desire to progress and some idea of the direction to head. Rather than trying to develop a catch-all framework we realized that what we need to provide is simply an awareness of options and a means of exploration for their given context.
We’re still working on the solution but things we’ve found so far are:
Most people have a desire to feel they’re making progress. They want direction, differentiation, support, safety and opportunity.
Nobody we’ve spoken to yet wants a wholesale reset of their role (as an aside, I did once have a great developer who decided he wanted to be a medical doctor – he succeeded!). So in the examples we have so far, people are either looking to extend their current job into related roles, expand expertise in their current role or move into an adjacent job or role.
This allows us to frame conversations in terms of adjacencies, current job/role, desired job/role, role models, skills and specialisms.
There’s also another critical component to this – what I’ve chosen to call “Fit”. If there’s no space to fill or a chosen path isn’t a good fit for a team or person we need to be having those conversations too.
So my thinking model for this at the moment is to talk about direction in terms of:
Job -> Roles -> Fit -> Skills -> Specialisms
Rather than trying to fix everything at once, our next step is to seek early feedback, inspect and adapt. We’ll be looking for a few people across roles to trial the ideas we’re coming up with and help us identify concrete examples we don’t know about at the moment and work through those.
I’m expecting us to have some concrete results before the end of September but we’ll be putting things into motion in the next week or so.
I’ll keep you all posted on how things progress.
Following on from part 1 last week where I described the foundation concepts for a lean/agile development plan, here’s the detail…
So far I’ve done this twice with some of my team here and I’m in the process of introducing it across a couple of other teams and managers. As part of writing the details up, I’ve come up with some minor refinements and sequencing options that we didn’t think of at the time and added these in.
Before you start make sure you have a decent space to work in with no distractions and plenty of time. You’ll need about 2 hours but give yourself 2-3 so you have some slack. You don’t have to use it all and it’s surprising how good people feel when they think they’ve recovered some time back.
Grab a room, a pile of stickies and some markers. Did I mention you’ll need to use a lot of space? (We used 3 walls). In the cases I’ve run so far, I didn’t prepare anything in advance but it’s probably best to write up the headings beforehand – don’t show them until the participant is at the stage they’re needed though! (focus on 1 thing at a time – single piece flow!)
An important point before we start. Are we working with someone who wants to improve themselves in their current role, address some known (or unknown) issues or who wants some kind of progression – a promotion, a sideways move, expansion of skills, increased responsibility, or something else?
Take 5 minutes to discuss the possible scope and direction of the session. Think about the level of change, disruption and ambition behind the improvement and what is or is not achievable. How long have they been in their current state, what sort or timescales are we looking at for the plan etc.
We’re going to use planning horizons and swim lanes to develop a timeline.
Build a large grid using stickies for each heading with vertical planning horizon columns (I suggest 1, 3, 6, 12 months) and 4 “achievement” (“I Will”) swim lanes; “Done”, “Improved At”, “Tried” and “Learned”.
It should look something like this:
Aim for the grid to have space for roughly 1-3 stickies per horizon/swim lane cell. – We’re using visual management and physical constraints to minimize over-commitment and set WIP limits. I’ll refer to this as the “plan grid” for the remainder of this post as we return to it a few times.
Now spend a few minutes adding stickies to the plan grid for the things you know you’re going to be doing. (don’t worry if there’s not many to start with we’ll be coming back to this later).
Here’s an example recently completed from one of my UX specialists at the start of the process…
This covers the baseline set of directions and commitments before we start adding to it.
If the person you’re working with has a good grasp of upcoming work for themselves, the team and product plans, you might find this fills quite well already. In the case above we’ve spent a lot of time talking about interests and direction in the past. We also have some pretty clear ideas on where we want to go with the product and technology. Visualizing this as a roadmap with a series of planning horizons and the “Do, Improve, Try, Learn” swim lanes for actions gives some initial structured thinking and timing to work from. We’ll circle back to this at the end of the session after exploring other areas of personal development and skills.
In this particular case, you can see we’ve actually filled quite a lot of space already. This doesn’t leave much room for new things unless we over-commit or trade-out other activities and that’s precisely the point – we’ve just baselined our commitment and workload.
Now let’s explore things further. We’ll take multiple approaches to exploring options. Some of these may duplicate information – that’s perfect, it’ll help us spot common threads later.
We’ve developed a grid of over 20 actions with a single placeholder for each action (borrowing a 5S technique from Lean). The set of actions is my chosen selection and works well so far. You may want to add or remove some of these depending on your context but the thinking behind these is to get participants to explore their available options beyond what might naturally come to mind.
Our aim is to place a single post-it/action under each heading. Eventually we’ll have every space completed with something sensible.
We’ve deliberately not looked at any personal skills, strengths, weaknesses or needs yet. This is simply thinking about what types of actions a person could employ to develop themselves.
Sequencing Options: The first couple of times I used this with my team we completed the grid in its entirety at the beginning. In hindsight, I recommend splitting the effort here to partially complete the list of actions at the beginning and then return to it after each of the next steps.
If you’re working with someone who needs more support in developing an understanding of their needs first, you may choose to start this step toward the end of the session after exploring strengths and skills further.
If you choose to use any of this process, please do experiment with the format and post your experiences and improvements here!
When we first used this action grid, we wrote “over the next 12 months I will/would like…” It worked well in our situation but it’s important to emphasize the difference between achievable and aspirational actions, so…
Minor Refinement: Once the grid is completed, run through it together and mark which actions are achievable – “I Will” – and which are aspirational -“I Would Like”. (using red/blue sticky dots or similar).
This encourages you to discuss and think through what will be possible and what may be a stretch (or even unrealistic). When looking at transferring actions to the plan grid, you can decide how much of a stretch you want to make in any given period based on workload and other existing commitments. The “I Would Like” actions may also require some additional support to be achieved.
So we’ve got a structure for a plan, we know what commitments already exist and we have a set of potential actions. Let’s take a step back and deliberately reflect on strengths and improvement areas.
As I mentioned in part 1, it’s really important not to go overboard on perceived “weaknesses” so here we break a person’s perception of what they do and how they work into 3 areas:
In order to reduce waste we want to emphasize improving strengths and bringing any gaps to a necessary minimum level only. At this point we focus mostly on the person side of things. How do they work and what do they do? (Not “what does their current or desired role need?” )
As a person or individual, what’s their self-perception around their day to day actions, activities and behaviors. Ask them to think about and describe what areas they see as real strengths – what’s their specialism or superpower if any, what do they really enjoy (and how competent are they at it?), what things do they feel they suck at (and is that a problem or not?). What are the remaining things that they just get on and do? How well do they do those?
Here’s an example of the sort of things we’re after…
Note how this is general activities that tie-back to what a person is doing on a day to day basis in their current context, not just the usual skill inventory type list. It’s about the things we perceive – what we do and how we do it. (we’ll look at the skills next)
If you decided to develop the action grid from step 2 in small steps, now’s the time to re-check to see if there’s some actions that could be added as a result of the strengths or improvement needs here.
Allow enough time for the participant to run out of things to add – don’t be afraid of a bit of silence or thinking time – just sit back and let them run until the ideas dry up.
We’ve explored self-perception and started rolling on possible actions. Now we’re going to look more at role-based skills.
Depending on the scope and direction agreed in step 0, this may be covering either a current or desired role.
Have the developee list out what they think the skills they have/need for that role are, what additional industry or domain-related skills they have/need and what additional soft skills they have/need.
We want to steer participants into thinking of these skills themselves so if you think they’re missing anything, try to use coaching questions rather than direct addition of examples. Encourage thinking about their gaps or using examples. (E.g. “Assuming you’re about to kick off a new feature, what types of activities do you need to undertake? What skills do you need to engage the team?)
Once again, give this enough time to play out to a natural end.
A big thanks to Veronika Kotrba (@Simply_Coaching) and Ralph Miarka (@RalphMiarka) for the inspiration on this part – this is adapted from their work on solution-focused coaching.
Once you’ve got 3 lists of skills, have the participant rate themselves out of 10 at how good they think they are at each one of these skills. Get them to mark this consistently in one corner of each sticky. (They might guess what’s coming next but let this bit finish first).
Talk through what makes them say they’re at that level. Now get them to think about what their desired level for that skill would be – make sure they understand that “getting to 10” may not always be needed or even beneficial (remember their strengths and weaknesses). What would be right for them. Mark that in the opposite corner.
Now get them to mark the top 3 areas that they would particularly like to focus on.
For each of these focus skills, talk through what actions or activities they would need to do to get from their current state to move one point forward. E.g. If someone’s at a “4” today and eventually wants to get to a “7”, what would it take to get to “5”. Ask them to visualize what that result might look like and describe it to you.
Again if you’re partially completing the action grid as you go. Now’s the time to see if there’s some more actions to add or any existing ones that could be switched out or replaced.
We’ve now tackled skills, behaviors and improvement ideas from multiple directions and explored (hopefully) some areas in quite a bit of depth. Looking across all the details on the walls, are there any patterns, common threads or themes?
What do these highlight?
Name these, write them out and put them next to the plan grid from step 1
This comes back to my love of patterns and naming. By giving something a name and focus you can assemble more of a mental model around what that thing is. This makes it easier to understand what is or isn’t in scope for a theme.
As with the skills, I recommend limiting the number of threads / areas of focus to 3 or less.
When I’m trying to get stuff done I have a small mental buffer and 3 is about my upper limit (2 works better). Any more than that and my brain starts thrashing. The same works here – trying to fit too much in your head will make things harder later.
Now let’s get back to the action and plan grids.
First of all, make sure we’ve got a single item in every space on the action grid. You might need to get some creative thinking in to fill them all but it’s worth the effort. When that grid is filled it gives us an unsorted long-term backlog of ideas for our developee. When someone completes a particular action type you can decide whether to add a replacement or to continue clearing down the grid before adding anything new.
Don’t forget to mark which are directly achievable – “I Will” – and which are aspirational – “I Would Like”.
For the aspirational items, take some time to discuss and understand what support or commitment will be needed to make them achievable.
Now have the participant copy a small number of the actions from the action grid and decide where to place them in to the 1/3/6/12 month plan in the plan grid. (don’t move the originals – you’ll need them)
Next, have them look at those top areas identified for improvement (from the Self-Reflection and Skills Investigation activities) and identify any further specific actions for each (or a subset if there’s too many)
For each selected action, they need to decide when they intend to undertake it and place it in the corresponding location on the plan.
If there’s not enough space on the plan grid, remember that physical space constraint gives us a WIP limit! What do they need to trade out to stop themselves over-committing?
Here’s an updated example from step 1. Note we didn’t add much beyond the first 1-3 months this time around as we expect to come back to this again when that planning horizon has cleared. We also had some really powerful conversations around their overall development and direction.
Don’t underestimate the value of the conversations themselves, not just the artifacts! For the participant in particular, those conversations may have crystallized a whole bunch of questions about their personal direction and goals for the future.
Talk through the final plan grid, discuss timings and workload. Does the participant feel that the plan is achievable? Is there anything they might change? Are there any areas of risk or concern?
Take some time to talk through the actions grid (now a backlog). Are there any things there that might be time-sensitive or wholly unachievable or mis-aligned that they want to swap out?
Here’s where many development plans fall down.
Chances are you can’t leave all that stuff on the walls so capture all the content on decent (readable) photos and then harvest the stickies in their respective groups.
Ensure the participant gets both the original stickies and a copy of the photos. Ask the participant to type up the results of the session and to share back – agree when they’ll have this completed – ideally within the next 24 hours. (It’s amazing how much you learn from typing up post-it notes after any session!)
Ensure their actions grid is converted to a backlog and the plan grid is written up as a plan that can both be updated and modified easily. (one of my UX team wrote theirs up using Mural.ly – this is particularly neat as they were able to mimic the format we used in the room very closely)
In discussing ownership of development plans we’ve identified that simply handing over ownership is not enough. The developee will still need support, coaching and mentoring to progress successfully. Don’t let them fail alone.
Once the write-up is complete (depending on the participant you may need to chase them to ensure this happens). Follow up quite frequently to start with. I recommend at least once or twice in the first 2 weeks, and then again at the end of the first month planning horizon.
Minor refinement: It may also be useful to extend the planning horizon backwards by a month or more during your review cycle. You can encourage the developee to add other things they’ve achieved and “bank” these.
We know that people naturally do things that aren’t strictly on a plan. Make a point of marking those achievements. This lets us review what we’ve achieved on a rolling basis and gives us a trailing indicator of progress and capacity.
Depending on how things are progressing and the level of interaction or support needed, agree on a follow-up cycle and set dates for a regular one on one catch-up session to talk through progress, changes, adjustments or resets. At the 3 or 6 month point, schedule a more detailed review and repeat session.
That’s it! (so far).
Edit: We’ve been so successful in our initial trial with a few staff in my division that we’re expanding the trial across the company. We’ve also learned a few important tweaks and traps along the way. See where we are now in part 3.
Recently I’ve been working on a new approach to personal development plans using a few tricks from lean & agile thinking. Today I wanted to share the foundations of the approach.
It started with a lesson from the same coach who taught me that a leader sets the tone for their team.
As part of a leadership program I attended with one of my previous employers back in 2007 I completed an in-depth 360 degree appraisal to learn more about my behaviors and emotional intelligence.
The assessment required input from 20+ people who knew me.
Every attendee of the residential programme was given their 360 degree feedback in a 1-1 session and walked through the results in detail. In a couple of alarming cases, the disconnect between how a person saw themselves and how their teams saw them actually required individual counselling.
In my case, I found that everyone but my direct manager was very closely aligned with my self-perception. Given the high standards my manager held for all his team I was happy with this result – he measured the team’s comparative performance against his own exactingly-high standards, it’s why we were both successful but continued to strive for improvement.
The walk-through of the 360 showed each of us what was considered an “acceptable” competence level for each category measured and what was considered “exceptional”.
This is a pretty powerful way of thinking about things. We may all want to be exceptional but I’ll highlight the lesson many people miss with an example…
Usain Bolt may be currently the worlds greatest sprinter but that doesn’t mean he’s the world’s greatest javelin thrower or even marathon runner.
Chances are he’s pretty good at other things – as a world-class professional athlete he’ll have a broad baseline of skills but he knows his strengths, invests in those and doesn’t waste his effort and training on the areas he’s just “ok” at.
He’s part of an Olympic team. In order for his country to be successful he’s surrounded by a high-calibre team with a broad set of skills, specializations and expertise. His team mates will be signficantly better than him in some areas.
By all means address your shortcomings that are actually problematic but recognize which skills you only need to be “OK” at, which you don’t need at all and where you need to excel. If you need excellence across the board, chances are you need a team, not an individual.
Look around you and build a team that complements each others skills, gaps, shortcomings and mediocrity.
Save your precious time & effort (eliminate waste!) to focus on your strengths, find someone else to complement your weaknesses instead.
At my current employer we already seek 360 feedback (but not at quite the depth of the EI appraisal) as part of our monthly staff 1-1s where we discuss performance, status, career direction and well-being. We don’t have annual performance appraisals but we do encourage staff to have personal development plans if possible (note – we only encourage them, they’re not mandatory).
Recently I’ve wanted to improve our uptake of development plans for the team but I know they’re often really hard to work. Let’s consider some of the issues I’ve seen in weak personal development plans over the years:
Despite there being a need for the person being developed to “own” the plan, the manager is the one to identify and initiate the process and then draw out the plans and actions. This leaves little ownership, motivation or inspiration for the developee.
When a developee first starts on a development plan, they think they “should” improve and move forward (it’s what businesses expect of us) but are unsure on personal direction and their needs. They may be starting with a blank slate.
The concept of a “PDP” is often a remedial measure. Whilst this may be necessary, they focus on getting developees “above the line”. They lack a means to shine and excel.
Activities required to significantly level-up in an area may be disconnected from what’s required to simply deliver on a day-to-day basis. Balancing a day job with significant performance improvement is hard.
If a developee isn’t a team player, how do you draw that out and get them to the point where they don’t revert back when the plan is over? Are there alternatives?
Over-ambitious development plans may feel great when first drawn up but energy and motivation dwindles fast when things are difficult to achieve.
The approach I’m exploring aims to tackle these using lessons from lean, agile and my personal experience from the EI 360. Here’s what I’m trying out…
I work with the developee in a one on one workshop-style format. We take over a room for a couple of hours and using a structured, visual, kinesthetic, reflective sequence of steps we gradually fill the walls with thoughts, ideas and actions.
We’ve developed a list of over 20 concrete “activity types” for generating ideas that work well for developing people in novel ways. By borrowing a 5S tactic – Seiton from Lean we create a placeholder space for each action. We know we’re “done” when each activity type has its single placeholder space filled.
Here we aim to eliminate waste. Instead of looking at weaknesses, we explore 3 areas; “I think I’m good at…”, “I need to improve…”, “I’m happy as I am with…”.
Note the use of first person statements – this is about self reflection, not external direction.
In explaining this area we point out that items “I think I’m good at” are potential strengths that can be developed further. Items “I need to improve” should only be for weaknesses that actually need to be addressed within the context of their team, role and self development. Items “I’m happy as I am with” are areas that even if weak, do not need to be developed further.
In order to be successful, we need to ensure we have sustainable pace. We achieve this through setting a series of planning horizons and using visual management and physical constraints to define natural WIP limits.
I work collaboratively with the developee to draw out the list the skills they have or may be required for their development needs. We explicitly call out Role-specific skills, additional broader skills and soft skills as 3 categories. We then use simple measurement & rapid feedback to establish both baseline and desired levels for each area.
After pulling the threads together and building a plan with sustainable pace, we sanity-check the plan. Do we feel what’s there is achievable in the next sprint (for example). We agree the review and follow-up cycle and adjust as we go.
In part 2 you can read though the detailed mechanics of how I’ve been doing this with some of my team, including some minor improvements as a direct result of writing up the details. I’ll post an update on how this is all going in future.
Back in December I moved to a new team. After 18 months on DevOps and email marketing projects I’m back to managing commercial product development. After a week of getting up to speed on the product and project (it was already in flight when I joined) I started looking at the bug backlog in Jira.
One problem with bug backlog tools is that they allow you to create bug backlogs. I considered shutting them all down but knew we’d find value in being more considered in our approach.
For this project I was pairing with another project manager; Dom Smith (yes, pairing isn’t just for developers). The project was a major new release for one of our longstanding successful tools.
This is the second time I’ve pair-led a project and every time the overall outcome and workload is so much better. One day the rest of the industry will realised that having a single PM running multiple projects will always get a suboptimal outcome. In fact another critical project (fixed time, fixed quality, fixed schedule, fixed scope!) elsewhere in the building is also being pair-led right now and is proving to be a great success.
Dom was a technical author in a previous life and is therefore rather good at keeping track of everything a team does over the life of a project. Another team were interested in what we’d done so fortunately Dom managed to capture everything we did to get the oubliette under control. Today’s post is brought to you courtesy of his work.
At the start of our review we had ~1200 open issues, of which about 400 targeted for the “next version”. The backlog had reached a state where nobody wanted to look at it as it was “too big” to resolve.
Fortunately strategies for breaking down big problems is something I tend to specialise in.
If I’d said at the start we were going to spend 4 months doing this, I think we’d have struggled. Looking back, we spent about 50-60 hours of our time and about 100 hours from the development team to get things under control.
We started with just one hour’s “space” and simply said. “OK, what can we achieve in 10 minutes”. Fortunately bug backlogs have many “seams” to work through. We worked through the smallest easiest first and whenever things slowed down or value started to diminish, we’d move to a fresh seam and started digging again.
We started by setting up an hourly slot once a week to pair up and pull the things we were going to fix into the current version. In the process of this, we found many duplicates we could close. We also ensured that rough priorities (priorities would be clarified later) were set on everything we pulled through, and that they all had components (the functional or technical product area) set.
After a few weeks repeating step one, we started tackling the other end of the list: things that were out-of-date or really not going to get done.
Anything more than 3 years old was checked on a case-by-case basis with the starting assumption that it would be closed as ‘won’t fix’ unless we could argue a reason not to (primarily based on prevalence and customer impact). Pairing made these a sensible conversation rather than a hasty decision.
“Autobugs” – we have an automated bug reporting system so that when users hit an exception they can choose to report it directly into Jira with no additional effort.
Any autobug raised prior to the last major shipped release that was not seen in the latest live release. We were working on v8.0 so any bugs reported against v6.x with no reports in v7.x, were closed
Any autobug raised only by one our development team on an unreleased build over 6 months old were closed.
After cleaning up the “noise”, we added a weekly, 45-minute meeting with the whole development team to review all the new issues added in the last 7 days, set a clear and appropriate priority, ensured component information was present, and set an explicit release target. (Either “current” (v8.0), “Next Minor” or “Next Major”. This helped contain the quality of new bugs – we “stopped the bleeding“.
We adapted our weekly pairing slot, to tackle the issues assigned to people no longer on the team (the aim being to ensure that they ended up with no issues assigned to them). Many of these could be closed as No Longer Valid, but there were a few which should have been prioritized that they were being sat on.
Again during the weekly pairing, we started working on closing bugs targeted at “improbably releases”. We had placeholder releases called ‘Future – Possible’ and ‘Future – Unlikely’ which, by their very nature, aren’t likely to happen. Again, we ruthlessly reviewed each in turn. Many had already have been fixed, and just needed 5 minutes testing to verifying they were resolved.
We added a further hourly weekly session with our product manager prioritize any issues we’d found through this process that looked more important but needed a product management decision. Having set the impacted component on everything we weren’t closing we’d found clusters of problem-areas that had been previously hidden, that became candidate focus for our next minor release (due to ship imminently). We also checked any queries coming from the development team’s review of issues from the last 7 days, and the scope of work for the current release to determine ‘Must Fix’ vs ‘High’ vs ‘Would like to fix’.
In parallel to these activities, we worked with our Sales team to ensure CRM references were added to any feature requests in JIRA (both new requests and existing ones that were being asked for repeatedly). This helps our UX specialists and product managers with prioritizing these in the future and gives them direct customer links to follow up on actual needs and problems.
In the space of 4 months we closed over 50% of the backlog issues by not doing any development work – just investing in three weekly meetings. We fixed another 25% by setting clear priorities, targets and sensible grouping of issues.
We aren’t there yet though. Bugs are still coming in and there’s still two big ugly piles in “Next Minor” and “Next Major” that we have yet to tackle but we’ll continue to put a little effort in on a regular basis to keep improving our position. Better still, the last release we shipped has significantly less bugs and the one we’re about to ship has less again.
We’re digging our way out!
