IT Project Management - life on the front line

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 in the first

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