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.
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.
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”.
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)
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 accommodatingall the time.
Must try to remember… No mid-afternoon team workshops. Oh and …must… …stick… …to…. salad & smoothies.
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 simplyfail 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)
In my first article on “breaking the seal” I described how this pattern applies to managing WIP on teams. There’s also a work/social concept that fits the same name with a different pattern…
Name: “Breaking the Seal”, “The Lid is Off” etc.
Analogy: When you open a new pack of good coffee there’s that great smell that comes out – suddenly everyone wants a brew.
Concept: Socially, many people are unwilling to speak up in a crowd or be the exception either in positive or negative situations. Fortunately for experienced agile teams, the social norm of staying silent has often become disrupted but you’ll need to break it back open once in a while and as a coach you’ll need to find ways to introduce it.
Being the first to speak up triggers team inertia; suddenly others’ voices will also be found.
How many times have you sat in a meeting where someone uses a term or concept you have no idea what they mean but you don’t speak up? How many other people in the room also have no clue but stay silent? This might be inertia, it might be fear or just an unwillingness to appear stupid. Particularly with technical teams where your career goal may be “technical guru” – being seen as wrong or not clued up may be a sign of weakness. Having a “wise fool” on the team breaks the seal on this but needs some caution applied.
In some organizational cultures it may not be socially acceptable to question more senior staff. This really gets to me. In fact, I’ll write another post dedicated to this.
Occasionally speaking up might be risky, particularly if there’s obvious management issues. (Nobody likes to speak about the elephant in the room when the elephant is in the room) In these cases arrange with a few like-thinking peers to take it in turns to be the one to raise issues so it’s not always you. This will also ensure that you’re not speaking alone with others relying on you to take the risks up every time.
On the more positive side, the “red cards” tool relies on this same concept for group self-facilitation. Where once it becomes socially acceptable to halt a problem or challenge others the team’s self-organizing capability steps up another notch.
Practice this in your own teams – challenge yourself and your peers to ask a dumb question or plug a rat-hole at least once a week.
One of the best facilitation tools I own. How to get a group out of a rat-hole & back on track without personal confrontation and minimal effort.
Name: The Red Card
Concept: When a group is in discussion on a particular topic they can often disappear down “rat holes” or off onto tangents. Every member of an agile team is empowered to “red card” a conversation that they feel is going off track. The group as a whole typically rapidly decide whether the red card is warranted or not.
Usage: I ensure that plenty of of small (playing card sized) red cards are available in the team rooms. To introduce them to a team that haven’t used them before, I will usually take a large session such as release planning and introduce the concept of red cards as part of the facilitation tools and ground rules at the start of a session. What I tell the teams is:
“Whilst I’m facilitating, I tend to get drawn into the conversations and need hauling out, especially if I start ranting. Therefore the red cards are required primarily to shut me up – although feel free to use them on each other too!”
Once a member of the team first uses a red card, that’s it – the lid is off. Expect use of cards to take off rapidly. (see “breaking the seal – part 2“).
Background: Chances are this has been used before me elsewhere in the world, but this is a tool I introduced to my teams after returning from Agile 2009. During one of the evening sessions there was a panel discussion. Questions were submitted in advance and each panelist had 2 minutes to discuss. After the whole panel had their say, the audience were given an opportunity to vote. On every seat was a large red and green paddle. If we wanted the discussion to continue we voted green. If we wanted to stop and move on, we voted red.
When I got back to Cambridge I introduced it during some training I was running. I “borrowed” my eldest daughter’s red & green art straws. There were a few “hot spots” on the course where 1 or 2 attendees would lose track. We had a great team who immediately raised a red straw. They enjoyed calling each other out so much that we had red straw warfare at one point!
After using the same in a couple more sessions it became clear the green straws weren’t needed. The red ones were getting tatty so I raided the stationary cupboard for some red card instead, cut this into pieces about the right size to hold up visibly and planted a few in the team rooms. These are now the social norm for facilitators on many teams worldwide but probably not well-known outside the company I’m at right now.
Impact: Of all the tools I’ve used over the last 2 years this one seems to have had one of the greatest impacts on teams and the most viral spread within the organization I work with. Even the management team now red card each other and they don’t even have the cards in the room. Like all good verbal anchors, everyone now knows what “red card” means during discussions. Better still – even on difficult teams I’ve not yet seen anyone use red cards in a socially unacceptable way.
Try red cards out on your next big retrospective – you might want a stooge to break the seal first of all and chances are you’ll need to set yourself up as the first target but once the team have been through this once, facilitating meetings will become more of a team sport than a job for you.
Inspired by this post I just read from Seth Godin. As an average joe, hob-nobbing with CEOs isn’t so likely for most of us but the interpersonal interaction certainly is worth making time for. However…
If you’re paying to learn and thinking of attending Agile 2011 (or any other really big conference) take a team!
For the last couple of years I’ve attended the big US Agile Alliance conferences. I love going although I miss my family; I really enjoy the social interaction, spending time with (on the surface) a bunch of smart, similar-minded people sharing a week of learning, collaboration and fun. There are of course undercurrents (see this old post from Jean Tabaka) but I still find attending these conferences a rewarding experience.
For anyone that’s not been, the Agile 20xx conferences are huge and seem to be getting bigger every year. The number of parallel tracks – all with great presenters means you really have to make a plan.
Each year I’ve attended, I’ve had the luxury of going out as part of a team. My advice to future attendees is the same – take a team and collaborate on what you want to see.
My goal each year is to walk away with at least 3 key pieces of new thinking that would add value to my teams. The travel and conference fee for just 3 ideas might be excessive but as I said, I also go to learn, collaborate and have fun.
If even 1 of the ideas I bring back is sticky enough to be introduced successfully to a group of nearly a thousand engineers worldwide then I think that’s worthwhile!
So which sessions do you attend?
Personally I tend to steer away from the “rock star” sessions. Most of what they’re presenting is covered in their current or forthcoming books (and I read a lot of those already) so I don’t get much from them. Other members of my team don’t read so much and so will go along to some of these. Get the team to strike a balance but make sure the motivation is to learn and share, not just to meet “famous people“.
The stuff out there from people without book deals is rarer so I make the most of those sessions but less-experienced or well-known presenters may mean a higher risk of a not-so-good session. Also keep an eye out for the open space sessions and lightning talks. You’ll find a lot of up-and-coming talent and thinking out there but again, your mileage may vary.
I also tend to look for things that are relevant to my current context, and future direction, not just my current role. A big part of my interest is in viewing things from other people’s and roles perspectives – for example I’ve never formally had the job title of “tester” but “Agile Testing” is one of the best books I’ve read that really “gets” cross-role pairing and test strategies – relevant to developers and managers, not just testers!
Others may prefer to spend the entire week in “UX” or “Testing” tracks but generally I strongly discourage spending the entire week in a single track in your own domain – you just don’t learn enough of the other interesting gems. Maybe it’s just me but agile isn’t just about your own specialist area, it’s about the whole team and organization.
Having presented at Agile Cambridge last year; I and my team have submitted a couple of proposals for Agile 2011 as we’re hoping we can start to give something back. There’s a lot of presentations out there so our chances are slim however despite the number that don’t make it, there are hundreds of great ones that do.
When planning your sessions, take a team and go for a knowledge portfolio – balance risk & reward to get maximum return on your investment. You won’t regret it.