Doing the ‘Do’
I was having an interesting chat yesterday, and as a consultant who gets to visit lots of companies and implement a lot of stuff, I wanted to talk through the key areas I’m often involved in. What I do, how I do it, and in effect the manifesto I follow when implementing my passion around Enterprise Agility. I’m not talking about overviewing it and waxing lyrical from a theoretical level, I’m talking about actual practical application of a broad set of sAFE and LEAN principles.
Agile
For me, the four key Agile ceremonies of Sprint Planning, Daily Standups, Iteration Review’s and Retro’s are something I want to get weaponized and into daily behavior as quickly as possible if they aren’t already. Even if the organisation isn’t compatible yet with Scrum its important for me to set a pattern of working to coral people into repetitive behavior as that, is fundamentally culture change. Running a stand up properly is my thing, and from that, I can start to gel product managers, the developers, testers and the PM’s all together over a unified backlog. That helps me shape out the project and start to think about de-risking it.
I usually get favour from developers at this stage because I’m bringing the Product Managers backlog to the table early and getting the developers involved upfront, it minimizes surprises later down the line –  we all get to pour over the features going into the sprints, that makes the sprints manageable because I’ve already sat down with the product owner previously and managed expectation. I don’t want to see people working late nights or busting their chops because a sprint hasn’t been well planned.
So I schedule in a daily 15 minute (no more) meeting, always where there’s a screen available throw up a Google timer, it really helps keep people focused and to time. Especially for those who love waffle!
At the end of each sprint, we’ll break out a whiteboard and do some Kanban with some post it notes. I prefer physical post it notes to something like Trello, because by presenting issues as physical things on little bits of paper, it gives them life by making them tactile and it’s easier to attribute ownership.
Retro’s are usually weekly or bi-weekly for me, to match whatever sprint pattern we’ve decided to run, and I bring in cake, chocolates, and ensure it’s really informal. Usually a Friday, I like to see the Dev teams include working demo’s, and bring in feedback loops into this stage too ready for next weeks planning. I’m surprised how many companies don’t give the floor to Developers often so they can demo what they’ve done.
That brings me neatly onto…
Project De-risking
For me, there’s a triple of core ways to de-risk a technology project – either scope (aka complexity) or timescales or streamlining the delivery & reducing bottlenecks. First thing I want to do is sit down with a key stakeholder or Product Manager (if we’re building a piece of software for example) and look at a feature and functionality list. I want to check to ensure this was born from satisfactory detailed technical and functionals specification documents. Granted it gets a bit more complicated when there’s 3rd party vendors involved, or code is being shipped between different teams in different locations or there’s time based dependencies. Then I start looking at really what features are necessary for a release and why. Why do we need to ship X feature on this date? Can we change the deadline? Why is the deadline what it is? Is this a false deadline?
These are tough questions and often involve a lot of push back because the Product Owner is usually under pressure to deliver everything as quickly as possible. However, I often go back to the business sponsor and challenge them also, to ensure what’s being delivered is appropriate for the size of team, actually achievable, sensible and baked in reality. I’m comfortable with myself now to absolutely go back to a MD and tell them no if I genuinely think what they are asking for isn’t possible in the timescales they are demanding.
So that tidily brings me onto
DevOps and CI/CD
Now I’m not suggesting I meddle heavily in a core crack team of coders work, but I do empathize what it’s like having sat with a coding squad, late through a weekend because a client or stakeholder have made unrealistic demands and that trickles down into a coding team – things are rushed, mistakes are made, and you start to not see beyond the tree’s. I’ve sat there buying pizza for teams doing nothing but providing support & making the tea just because in my part, I was responsible for them being in that situation in the first place!  So I’m always encouraging teams to stand back and check their pipeline. I’ll help however I can.
They may be organizationally constrained to a certain toolchain which may not be efficient, or maybe CI isn’t really possible through technology limitation or team configuration. I want to get into that sweet sweet DevOps position of a really efficient CI/CD pipeline.
I’ll listen and learn the coding teams workflow understanding where efficiencies can be gained. Is time being spent waiting on testers to do their testing through lack of automation? Are the right tools being used, in particular I’m always keen to see what Agile tool is used (if any) as part of the development phase. I’m a big fan of AgileCraft from Atlassian as it ties into a load of stuff, but I also hate seeing teams struggle with legacy TFS so migrating at least onto Azure DevOps if it’s not in place already can be a quick win.
Sidenote: The above sounds obvious, but I’m never surprised any more at regardless of an organisations size, how development teams are often coding in silo’s, sending that code by email and compiling infrequently and that compiling often done by whoever has the latest version. This is no joke. I’m not suggesting developers aren’t already using all these great tools at home, of course they are, they’re awesome developers – but the amount of times I’ve seen organisational constraints lead to broken dev teams frustrates me massively.
Being Happy
I’m about people, I never used to be. In fact I used to be terrible so it always surprises people who have worked with me in the past on how focused I am on peoples happiness now. I have learnt that a happy team protected from organisational politics and the bullshit which comes with it will produce better work. I’ve learnt that as a Delivery Manager/Scrum master type person, passing down the pressure never works, and failing to get to grips with problems you know are on the horizon and letting your delivery team soak that up leads to failure.
I have the learnt to push back hard. If I know what’s being asked is impossible, I wont send a dev team to the firing squad. Getting everyone together up front works and if I’m parachuted in to find Dev and Testing haven’t been involved up front, then I change that – even if it means delaying the project because ultimately, this is de-risking the final deliverable and you only get one opportunity to do this once so I never miss the opportunity.
In Summary
I don’t always get it right, but I’m getting pretty solid at being consistent and have started see dramatic results in my projects implementing the above. Want to discuss? Contact me on Twitter @mariodc
Image References
