IT Project Management - life on the front line

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 call

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