IT Project Management - life on the front line

OK, I know how most of the Agile community feels about Project Managers: Process over People Meetings Documentation Urrgh... But however you name the role (Agile Delivery, Scrum Master, Project Manager) and whoever does it  - someone needs to help the team to: Plan Track Deliver Communicate Being a group of incredibly talented engineers does not give a team the right to ignore 3.5 of these. All too often, engineers want to dive in to designing and building great software, but see planning as a hassle, tracking as a waste of time (or an abuse of their rights), communication as an alien concept and delivery (the fun bit) as something that will be done when it's done. It may be popular to talk about being a 'self-organising team' and railing against any form of 'order' being imposed.  But why is that order being imposed?  Maybe it's to deal with the chaos that your s-o-t has failed to deal with so far. As organisations scale and the senior leadership gets further a...

Would you push your project team until they snap?  Of course not, you believe in sustainable pace. Would you expect them to consistently sacrifice family time to achieve unviable targets?  Of course you wouldn't, you'd rather they delivered consistently over time while maintaining their work-life balance. Would you have them work when they're ill?  No, you're not a monster. I could go on, but hopefully you get the point. Unless you're an appalling relict of an aggressive 1980s management style, you protect your team.  You realise they're humans with individual lives and needs outside work. But do you apply the same standards to yourself as project manager? There's a tendency in our roles to pick up any slack ourselves, to look after the team and the project as a priority.  After all, who gets hauled over the coals if things fall behind?  Whose career could be stalled (or ended in case of a contractor) by one catastrophic deployment? The longer hours and cal...

The world has become very full of new dogmas.  The old dogmas have perhaps decayed, but new dogmas have arisen and, on the whole, I think that a dogma is harmful in proportion to it's novelty. New dogmas are much worse than old ones. -- Bertrand Russell

Ready for what? Ready to be picked up by the delivery team and added to a Timebox/Sprint backlog. NOT: Defined to the nth degree of detail so that no further discussion is required. Definition of Ready: Like the DoD, the DoR is defined by the team and should be updated whenever it seems appropriate e.g if there's a big change in the team or the work; or the team simply sees the need for a change. Being agreed and enforced by the team means that it should, hopefully, mean an end to the common moaning in retrospectives that 'the story was crap'. As the team gets used to only selecting 'ready' stories it focuses grooming/refinement sessions to ensure that the top priorities are in the best possible state. The business/product owner will also very quickly understand the need for good prioritisation and quality stories. This is driven home the first time a team refuses to take a priority story into an iteration. While there are a number of ways to start, ma...

Done? To call a story 'Done-Done' we should refer to two things: the acceptance criteria for each story the team’s Definition of Done The DoD is defined by the team and should be updated whenever it seems appropriate e.g if there's a big change in the team or the work; or the team simply sees the need for a change. If you have project based teams, it's something to agree before timebox 1 kicks off. If you're more product based and continuously working through an ever growing backlog, slot it into a timebox kick-off, a retro (if that's where it was discussed) or just grab 10 minutes after the daily stand-up. An Example: Here's a basic example created by a team I was working with: ---------------------------------------------------------- A. Dev done ---- Code review done ---- Unit Tests written and passing ---- Integration tests written and passing B. Test complete ---- Manual Testing complete – Acceptance Met ---- Automation Tests written and ...

Who doesn't enjoy the warm glow of validation that comes from having others strongly agree with their opinions? It's a great feeling; it's encouraging,  and a gentle massage to our self-confidence. Without this experience, all but the most arrogant of us would soon be wracked with self-doubt, so it's certainly not a bad thing. But... everything in moderation! At time-of-writing I'm in the position of having a team who are incredibly comfortable in voicing their opinion.  Whether they're just brutal or a little further along the spectrum than the average developer I can't be certain, but I do know I can rely on hearing their opinions. Not a great environment if you're sensitive, but it does force me to challenge my views, thoughts, and actions on a regular basis.  And on the assumption that I'm not always correct, which my wife assures me is the case, that's a great thing! Why? Because living inside your comfort zone 24/7 can only re...

It's a standard Saturday morning and I'm sitting working on my phone at the kids' dojo while they practice sparring drills.  Their coach is giving them some feedback and I'm returning to feedback in this post. When I wrote the last blog on Continuous (self) improvement I was thinking about it in the abstract and although I had many real-life examples in mind, I was then confronted with an opportunity to share an instance almost immediately after it occurred. I write this the morning after a team social occasion (aka leaving drinks) and although I don't drink (medical reasons - don't judge me...) my colleagues certainly do.  These events can be fertile ground for picking up people's feelings and frustrations at work. Sometimes a shared rant is a bonding exercise Sometimes it's an opportunity to let a teammate feel listened to. And sometimes it's a chance to learn how people feel about you or your performance. Over the years it...

“Everyone thinks of changing the world, but no one thinks of changing himself.” - Leo Tolstoy Introduction: Most people talk a great game about continuous improvement.  And as a group, most of us truly agree with and see the benefits of, the concept as applied to our projects and teams. Sprint Retrospectives, Post Implementation Reviews, 5S, DMAIC, PDSA (not the dog people) and so on. But... Do you practice it personally ?  I don't mean training courses, formal development plans and all the other bureaucracy that people step through stoically every year in a bid to get a pay rise.  I'm referring to the small (but meaningful) improvements we can make every day. Or to work in an Agile principle: "At regular intervals, the team (of one in this case) reflects on how  to become more effective, then tunes and adjusts  its behavior accordingly." Step 1: Feedback (aka input to the CI process): Of course, all improvements need to be identified i...

My far more technical compadre and fellow Agile Yorkshire attendee 'Agile Bert' (aka John) has joined the blogging world. Will he become a prolific blogger? Will he become a (thought) leader amongst men? Why is he called Bert? That last one actually has an answer: here

Hands up if you've ever heard someone say: "We don't have a fear-and-blame culture." And keep them up if the reaction of the 'doers' was to roll their eyes and mutter something sarcastic. It's a nice phrase to trot out at a senior leadership conference or to write in your 'best employer of 2020' application, but if you have to say it, it's probably not true. And repeating the mantra won't make it any more true. In fact, people might respect you more if you were honest and admitted that there is blame and where the boundaries lie.  At least in that scenario, the individual knows where they stand. Instead, we often have the jarring dissonance of hearing our leaders say one thing and seeing them act entirely differently. As a leader (especially a senior leader): When you stand at the front of a room and tell the assembly that there is no fear-and-blame, look at their faces.   If they mostly appear too scared to dis...

The reason I titled this post with a question mark is that I believe empowerment to be a very misused term. Here's the Cambridge dictionary definition: Of course, you know this already. Yet for some, "to empower" has become synonymous with "to abrogate responsibility" Or in other words, passing the buck to your team: 'boss we need help dealing with team x' 'you're empowered to deal with that' This is just crappy leadership. Of course , you have to empower people so you're not a blocker. Of course , you have to give people additional responsibility to help them develop beyond their current role. But when you 'empower ' someone, you retain the accountability overall.  It's not a get-out-of-jail-free card to blame them if things don't go as planned or to turn around months later and say 'well you can't complain.  I empowered you to do it and you failed' No.  If you're my bos...

I received a very earnest email from a senior IT director that implored us (the unwashed masses) to provide feedback on how 'empowered' we felt. 'Great' I thought.  I chance to voice an opinion, vent some frustration and maybe, MAYBE, even help to change things for the better (no, I'm neither delusional nor stupid - I didn't believe that last one for a second). I had a quick glance round the office to make sure my boss wasn't around - he'd have spotted the dip in productivity with a blindfold on at a thousand yards. I clicked the link (after the usual concerns that it was a test of how easily we might be caught out by phishing scams) AND ... NOTHING Because as I flexed my fingers over the keyboard I couldn't think of any examples where a lack of empowerment had hamstrung me. So I refreshed myself on the concept: Without any empowerment we would, essentially, be subject to a prescriptive and highly inflexible regime.  Trotting o...

I was sent these videos earlier on the way Spotify operates. It looks a lot closer to Agile utopia than many companies. Well worth a watch: Part 1 Part 2 If this doesn't make you want to be more Agile at work then I despair! Maybe we'll never get to this level but we can keep trying. The bad news?  Most workplaces I've experienced have been a huge distance from this experience. The good news? I wasn't sent these video links by one of my cutting edge start-up contacts, but by a Head-of Delivery in a major European Insurance company.  The desire is there and it's moving up through the hierarchy. The slow realisation that the way in which they create, buy and deploy tech is paramount is dawning. Let's focus on doing it the right way and learn from the hard lessons of other industries. Mining and textiles were thrown away in the UK in the pursuit of being cheap (at the cost of quality - and jobs). The British Automotive Industry fell apart i...

If I asked what qualifies someone to lead an IT Project you might immediately think of literal qualifications; a degree, a PRINCE2 practitioner certificate, DSDM certification. You might think of the practical skills needed to achieve Project Management tasks; the ability to plan, management of RAID/CARDI items, stakeholder communication. All of these things are vital to managing a project, but as we're often reminded: Management ≠ Leadership And projects need leaders.   Why?  Because people need leaders.  Humans are pack orientated creatures and we are most comfortable within a structure that supports and guides us.  Within a project the same is true.  The 'doers' usually thrive within a supporting structure that takes care of their (professional) needs and protects them from attack.  Without Developers and Testers the rest of the project team is just a lot of expensive * flesh. In a mature and capable project team there is a certain joy to be ...

If you're an Agile practitioner of any sort you will understand what I mean by Armchair Generals (if not, it may be an idea to check if you are one..). Apropos of nothing an email arrives that questions the management of your project in terms of whether it is properly 'Agile'. Feedback is, of course, a great tool.  But it must always be understood within the context of the person providing it. So when the email lands questioning the type of contingency you've built into your project or the depth of analysis performed on your requirements set, ask yourself: 1. Has the questioner spotted something you and the team have missed? It happens.  That's why independent reviews can be helpful. 2. Has the questioner misunderstood something about your project?  If so, maybe your communications weren't quite clear enough or they've missed something - it happens, we're all busy. If the questioner has understood the topic correctly and is simply disagreeing ...

A phrase Project Managers hear a lot, and one that occasionally proves to be at least partly true. As it's most often spoken rather than written, it is hard to know whether the speaker means 'agile' or 'Agile'.  I find that asking the question ('big A' Agile or 'small a' agile?) can reveal a lot about that person's knowledge of the 'Agile' world.  If you find yourself asking the people around you this question and you receive blank faces or confused responses you can be fairly certain you haven't landed in a particularly Agile organisation, rather you're somewhere that has rolled out a buzzword in the hope of improving speed of delivery. Organisations tend to fall into one of the following categories: - Comfortably Waterfall - Fine . This organisation knows how it wants to work and perhaps has reasons why they prefer to keep projects waterfall. - Waterfall but concerned they need to get on the Agile bandwagon - Confused ....