Category Archives: DevOps

Express yourself

I am still committed to the idea of the workplace as somewhere for creative expression.

Not artistic or musical or anything like that, and perhaps intensely corporate, but where individuals are afforded the opportunity to express and develop their ideas. And through this comes true personal development.

Over the years I have seen that whenever members of  team are given the freedom and autonomy to develop solutions to problems, the end results are of a higher quality.

And any time I hear a (micro) manager say that you can’t have everyone going off doing their own thing all the time, I know that that is someone who seeks control and actively tries to inhibit realisation of potential.


Using process to support the team

One of the early joys of my new job is the use of Jira to manage the change control process.

This matters because Jira is quite unobtrusive and fits in naturally with the development process.

Compare this against a previous employer with as bloated a process as could possibly be imagined (there was a category for a P3 emergency) and where low-impact had to wait at least 2 days and with the expectation that teams change how they go about their work to support the process: the process is more important than getting stuff done.

And the managers wonder why the teams hated it.


Let yourself be impressed

Quite often when we’re with junior or less-experienced members of a team, we’ll ask them to carry out an apparently simple task and because we consider it trivial or inconsequential we don’t feel it necessary to say ‘well done’ or ‘thank you’.

But bear in mind that the junior team member doesn’t think of the task as of no consequence and will consider that completion as an achievement and appreciation and recognition indicates that they are making a genuinely valuable contribution to the team effort.

Any junior team member will want to impress so any opportunity that arises where they notice or say something novel must be embraced, no matter how trivial it may appear to be because it helps reinforce the collaborative nature of team work and will mean everyone continues to look for ways to move forward and improve on what they are doing.

Explicit exclusions

When deciding what tasks need to added to the delivery of a particular iteration of whatever is being worked on it’s often easy to overlook what won’t be included and it becomes tempting to add that nice simple little feature.

But this is scope-creep and it needs to be avoided at all costs. The best way to avoid this risk is to have a list of items that are definitely not going to be included. They might be for inclusion in the next iteration but any time that there’s the temptation to include that feature there’s a reminder (and preferably with annotations) to explain why it is not to be worked on right now.

This will help to maintain focus on the most important project goals and ensuring that we’re sticking to the design. document, deliver principle.

Design. Document. Deliver.

There is only one way to have a fully maintainable and supportable system: document what has been designed and implement what has been documented.

Anything other than should be considered as having its long-term supportability and maintainability compromised.

Now, it is sometimes inevitable and necessary that systems be put in place that have not been properly documented before build time. That’s okay, but what is required in these circumstances is acknowledgement and agreement up front that ideal practice is not being followed and  compromised system is the result.

I worked on a high-profile (and high-stress) project where comments from the managers were often like: ‘don’t worry, junior admin that’s working way beyond experience and expectations will have documented all the components’. That upsets me. Not only are the (supposedly) experienced managers absolving their own responsibility they are heaping pressure where it least deserves to be.

By agreeing up front that the expectation is for a system that cannot (and will not) be fully documented we are making an effort to reduce the stress on the implementer who already has the unpleasant task of trying to create complex applications on the fly (and inevitably feeling that they’re making the best of a bad job) by saying that there’s a shared responsibility when it comes to the later questioning of why nothing matches up.

Sweating the small stuff

In a previous role, in preparation for a major datacenter migration project, I figured that there were a ton of really small mini- or micro-projects that we needed to get sorted before we’d be in a position to undertake the big stuff: migration of filestore from Netware to Windows, internal app upgrades, non-disruptive re-platforming, the kind of things that were often talked about in the office for half an hour and then lost to the ether, or, jobs that were important to a particular team member, that would have been started but lose momentum when the bigger stuff takes over.

Realising that these small-scale projects are a genuine way for the team to deliver incremental improvements, rewarding in their own right, I figured that why they usually stopped or lost was because they were no actual targets, that the individual knew what was required and didn’t need to write any of it down.

Also, knowing that techies are lousy are keeping track of their ideas, I asked the powers that be for some low-key project management assistance, not a formal project, but keeping tabs on the wee items that need to be done, most of which wouldn’t appear on the radar of a proper project.

Because the PM wasn’t really interested in tracking it ‘properly’ (because it was a proper project, had no budgetary implications, no vendor managements, or contracts to negotiate) he put as little time and effort into as possible, just checking up on the progress the devs and infrastructure were making on their areas. And it was just two or three people, agreeing on a set of tasks to be done whenever they got done.

But after a while, I noticed that all he was doing was getting agreement on: what needed to be done, who was going to do it and when it should be done by; he was an independent (and uninterested arbiter).

All the tasks were simple and achievable, but having an agreed list where each part needed to be ticked off at regular brief meetings was key. I already appreciated the need for actively tracking tasks (I tried using a now-defunct tool called todoyu) but trying to get the team to manage their own work like this just doesn’t work; that external guide was the key.

And it delivered. Not everything, of course, but enough to make a difference; the stuff that didn’t get done that way turned out to be much more complex and needed to be a project in its own right, but this becomes obvious.

To me, there are two real benefits of an approach like this,

  • stuff gets done,
  • there is a record of stuff getting done

When a team is working toward a strategic objective there are many small items that get in the way or get forgotten about in the flood of important matters, but in the end it all counts.