Considering The Scrum Guide

It is perhaps unsurprising when you consider the widespread adoption of the framework by development teams around the world that there seems to be almost as many variations of practices as there are teams working under the auspices of Scrum. Over the years since Scrum burst onto the development scene as a new way of organising to deliver complex work, a host of techniques, customs, and habits have found their way into how teams implement Scrum in the real world. Anyone who has worked with different teams in different organisations can tell you how these customs can vary and of the delight that can come with introducing to a team a practice that you saw work somewhere else.

However, amidst the myriad of associated practices something about Scrum has gotten lost. The core truths of Scrum, the underpinning theory that gives rise to core values that are to be exemplified by the team as they engage in the limited set of well-defined events that mark the cadence for delivering increments of value, don’t play as big a part in the day-to-day as the habits that have formed on top of the framework. It appears that a lot of teams have forgotten, or perhaps didn’t know in the first place, that Scrum is a defined framework and not a collection of habits that are supported by tools like Jira.

The Scrum Guide is the foundational document that outlines what exactly Scrum is, the values behind the framework, the people involved, and the events that need to take place in order for Scrum to be effective. Even as the primary source of definition for Scrum, the Guide is a lightweight document at only fourteen pages long, which is reflective of the philosophy that informs the approach; but the brevity of the document isn’t the only surprise.

The Guide is firm on what is and what isn’t Scrum, stating that the framework outlined in the guide is immutable and that any practice that does not completely implement everything described in the guide isn’t really Scrum at all. What’s interesting here is that a lot of the practices that you may see implemented as “Scrum” in the real world aren’t mentioned in the guide, though there is an acknowledgement of how these things come to be, facilitated by something of a loophole that allows for various techniques to extend Scrum without needing to be vetted or described anywhere in the core framework.

Where this takes a bit of a turn is when you look at how certain practices, for example having the Scrum Master or Product Owner never work on backlog items, contradict how the framework should operate as stipulated in the Guide, suggesting that teams that don’t ground their practices in the framework and refer back to the Guide to verify the techniques they are utilising may in fact be introducing problems rather than solving them.

The Scrum Guide is a surprising read and worth reviewing on a routine basis to help ensure that the practices being followed by a development team aren’t straying too far from the whole point of the framework: the central aim of generating value through adaptive solutions to complex problems.


Psychological Safety Webinar

Earlier today I was fortunate to be able to participate in a webinar for Laois and Offaly Education and Training Board on the subject of psychological safety in teams, which is a topic I care deeply about as it’s so essential for cross-functional agile teams to be able to operate well, but beyond that, ensuring psychological safety at work is in my mind simply the right thing to do!

Check out the video and slides below.

Lessons Learned in 2020

A lot has already been written about the year 2020 and I’m confident that an awful lot more will be written about the impact on society this particular year has had. As the events of the year unfolded and various aspects of life were forced to adapt to the different challenges that were thrown up, it seemed like more and more material for academic papers, theses, policy documents, training materials, and even half decent fiction was being presented on an almost daily basis. From the technology leadership perspective I think 2020 showed that there’s work to be done around how to adapt Agile processes to remote work, but while interesting this isn’t the only area where there’s something to be learned, so in the best traditions of the internet here’s a list of things I consider among the lessons 2020 taught.


Easily the single biggest take away from 2020 is in the field of communications. Over time many of us have developed a strong preference for written communication methods like email and texts to get our messages across to the point where phones are no longer deployed on desks by default and tools like Teams or Slack have become established as the comms tool of choice. However, a bias for a particular type of media doesn’t make it the best way to communicate and during difficult times like those experienced this past year when tensions ran a little higher than usual and nerves were a little more frayed the miscommunication issues known to be associated with written messages became more frequent.

Written communications just don’t work for everyone as some people don’t write clearly and some don’t comprehend willingly, which triggered a need to adapt how to communicate in order to accommodate these differences in style. While this became more obvious this year as all those hallway conversations that normally happen in the office just didn’t take place and were instead replaced by emails, the fact is that there is a broader lesson to be learned about the tools we use to collaborate with others as well as how we respond when faced with an email that seems unfair or overly critical. Taking a beat before responding or doing away with the CYA email in favour of a clarifying phone call is something that should be taken from 2020 and re-established as normal practice.

Risk Management

Wired published a great article in June 2020 about pandemic insurance and how no one wanted to buy any in 2019 ( and it speaks to the obvious about how risk is really managed in businesses around the world. Organisations need to get better at risk management. Right now “risk” is too often considered like a gamble that doesn’t pay off and therefore isn’t worthy of attention. Conversations about bus factor issues in teams all the way up to business continuity in the face of global pandemics or more localised and very real risks like fire never seem to resonate the way they should until it’s too late.

2020 made a distant risk into a crushing reality which cost people their jobs as businesses were forced to close and markets became inaccessible. In IT, a lot of firms discovered the consequences of under investment when they tried to get their workforces to operate remotely and in the panic of trying to get teams working the conversations about laptops and cloud as risk mitigators were forgotten. Suddenly, the only issue with getting a laptop was finding somebody to sell you one, whereas at the start of the year the justification arguments still raged as did budget fights around moving on-prem applications to the cloud. In hindsight these fights seem silly but it’s a pity that they ever happened at all.


The value of culture in an organisation is well documented but what interests me about culture when considering 2020 is how culture manifests in the real world in terms of traditions and cultural norms expressed by a team or firm as a whole. Established traditions are a valuable way to build and reinforce culture but where tradition is helpful at a practical level is as an aid in times of crisis.

Traditions remind us of who we are and help to ground us when times get tough. Teams that are encouraged to connect to their culture (like the very strong culture around software development) and create traditions of their own are able to guide themselves through new, high pressure situations with greater ease as they can base their actions on the standards of behaviour and insights of the community of which they are a part, and of which they are reminded whenever they do something “traditional” like a daily stand-up or distribution of a new set of stickers for laptops.


The concept of agility, as in adaptability in the face of uncertainty, was strongly tested in 2020. Companies struggle with agility, not just adopting the Agile values and principles used to guide development, but in being responsive to the opportunities and challenges that come along regardless of the scale of those events. Companies strategise and lay plans and place value in adhering to those plans without enough concern for the value to be delivered as a result of those plans. This results in long backlogs that teams are tied to delivering without regard for the potential need to pivot away from the backlog at short notice.

A stronger sense of agility suggests that teams should shorten the timelines of their deliverables in accordance with Agile practices, ensuring that stories are atomic and that it is possible to drop everything and pivot to something completely different by the end of the current sprint. Beyond that specific Agile action, there is a need to build capacity into teams to allow for a disruptive event to be capitalised on.

Away from development, 2020 showed that there is a benefit for organisations to think on shorter time frames, to iterate on most activities, to report frequently so that issues can be identified early and actioned quickly.


In times of disruption, whatever the cause, reassurance can be found in the regular routines of life. Real disruption triggers ad hoc responses and these responses too quickly become normal – how many times this past year did you hear the phrase “the new normal” to describe pretty much anything that was happening? Accepting ad hoc structures as normal isn’t the most productive approach nor does it make for happy teams, as trying to work in uncertain times using uncertain methods only creates stress.

It may seem contradictory but agility thrives when there are structures in place that promote responsiveness, as long as those structures build capacity and recognise the activities that are really going on in the organisation. Regularly scheduled cadences of work that facilitate as much BAU as possible are absolutely essential as are techniques to identify what constitutes “Business As Usual” in a world where change is a constant. A good example of this that was validated by the events of 2020 is that meetings specific to a narrowly defined topic should be minimised where possible and more flexible structures be implemented in their place that can handle when things change.


It’s a truism that we learn more from hard times than from good, but it’s also too often true that we never learn. Anyone who’s worked a project in the real world knows that the “lessons learned” part of the process is frequently skipped due to time constraints, which is such a shame. 2020 was a year where a lot of people had too much time on their hands, stuck at home with nowhere to go, but even after having all that time we should still take a little more for a retrospective on what happened, how we handled the situations presented, and what we can do better as a result of having learned a little from the experience.

My Role

As someone who has spent their career working with systems I have come to love a good framework. Taking a systematic approach to how things should operate enables me to conceptualize the tasks at hand and to identify gaps and weak spots so that they can be managed successfully. Identifying the component parts of my new role as Director of Software Innovation with ACETECH and weaving them together into a framework of sorts has helped me in these early stages to approach some difficult topics with confidence as well as quickly establishing where I can add value.

Having spent some time deep diving on where things are going well and where there are definite needs for improvements with my new employer, I have worked out that there are four major focus areas of the role:

  • Product Management
  • Team Leadership
  • IT Management
  • General Management

As I worked out how to group my work into focus areas and these four headings emerged, I realised that only the people focused area was about leadership in the truest sense whereas the other three seem more accurately defined as management areas. This is reflective of how I have assessed the job ahead of me and how I feel that so much of my focus needs to be on delivery and addressing certain key challenges with processes and approaches, as opposed to needing to “manage” the team I am working with. To put it more succinctly, the processes need management capability whereas the people deserve leadership.

Product Management

The main thrust of the role is about delivering software products. ACETECH produces IoT devices that are installed into vehicles to aid in the management of the vehicle, the operation of the vehicle and more, on into areas like real-time tracking of high-value assets. In order to unlock the value of these devices, customers are given access to a suite of software tools delivered in a SaaS model, that enables them to view, manipulate, and derive even more value from the data that is captured from the devices on their vehicles.

All software benefits from strong product management, and there is a definite opportunity here to implement some new approaches to product management that I am sure will help to improve the pace of delivery while also better addressing the needs of our customers.

Team Leadership

While there is significant focus on the Product Management aspects of the job, for me the most important aspect of the job is managing the development teams, meaning directly managing the team based in Tullamore but also working with remote teams around the world, both in-house and outsourced.

Managing a team is an absolute joy, either regardless of the challenges or maybe because of them. Walking into a situation where a team has been without direct technical management for a little while was especially interesting as it had highlighted the value a manager can bring to a team in terms of offering guidance on activities for a given period, providing structure in terms of how things need to be done, delivering feedback and developmental advice, but most essentially acting as a buffer between often conflicting needs of the business who had gotten used to approaching engineers directly and demanding action on a variety of things.

The nature of managing the outsourced teams is different in that their performance management is more clear cut from my perspective but I still want them to operate in a certain way, to utilize the same tools as everyone else, and to align their processes as closely as possible when it comes to areas like Agile. The distance and time zone differences are challenges but not insurmountable especially when taken properly into consideration – simple tricks like including the timezones of the outsourced teams on my Outlook calendar are gentle reminders that other people are experiencing their day at a different point to us when scheduling meetings or calls.

IT Management

Every company is in someway a technology company due to the reliance on Information Technology that all businesses have. In order to be able to unlock the value of that technology there is an ever present need for someone to be thinking about how the internal network is managed, how the hardware and software we need is purchased and supported in the long run, and how the whole operation can be kept secure.

In a practical sense, for smaller organisations there’s little chance of having a dedicated Systems Administrator, despite the need for that type of focus, and ours is no different with Sys Admin falling to members of the Software Engineering team. I’m not opposed to this in principle as that team are the ones best placed to look after the running of a network but also because it’s good practice for those who are tasked with looking after a cloud estate to understand the fundamentals of networks and the types of issues you will encounter when users are unleashed and where better to learn that in a realistic but also relatively safe manner than a company LAN?

General Management

As a member of the leadership team, I have a duty to contribute to the broader running and direction of the company as a whole, beyond my areas of direct responsibility as part of a holistic management structure. That being said, there is a significant opportunity for me to address the impact of software and data products on the strategic development of the company, by looking at how software can drive sales and help push the company into new markets.

More broadly though, this part of my role is for me all about delivering at a higher level, about making a mark on how the company will grow into the future, about setting the tone in terms of culture particularly around diversity and inclusion, and about guiding us to greater success through initiatives like strategic partnerships with other technology organisations but especially with local educational institutions, and not just for recruitment purposes but also to contribute to, and of course benefit from, original research.


There is always more to a role than can ever be accurately captured in a job spec and it is this element of possibility that often brings the most rewards from work; in the spaces between the lines of a job description lies the chance to do something wonderful, though it is something of a skill to be able to spot those opportunities. To that end I have found that, in the early days of starting in my new position at least, it has been beneficial to classify the major areas where I can make an impact and thus put some level of structure around where I need to focus my attentions and where I can develop the technology offerings of ACETECH.

Prepare to Fail

There’s always a lot going on in work and it can be easy to sacrifice essential, foundational activities in order to progress the “real work”, but doing so eventually takes a heavy toll. Just like spending enough time contemplating what’s being done and why and if that’s the right thing to be doing, there is a need to be prepared and thus avoid going into every situation trying desperately to figure out what’s going on and determine your position on the fly, a position that you may regret taking and finding you later need to defend out of not wanting to loose face.

Some activities demand preparation, it only takes one attempt at winging a presentation to convince most people of the value of being prepared, whereas it is too often the norm, for example, for people to arrive in meetings late and utterly unprepared, which is just a waste of everyone’s time. Again, this type of problem is all about time management. How many back to back meetings or events fill the calendar? How much time is set aside for preparation, if any? And how would you feel if a colleague blew-off a meeting you considered important in order to prepare for some other meeting or event?

Personally, I’ve seen too many organizations where terrible meeting etiquette prevails, from an over reliance on using meetings to actually do work, to the lack of defined purpose or an agenda, and so on, with a particularly nasty vice being the continuous overloading of calendars with recurring events and double, triple, and more bookings, and in those organizations a common underlying issue (no doubt one of many) is the lack of consideration for colleagues. Being busy can wrap us in a sense of urgency that can manifest as a feeling of self importance that in turn erodes the consideration we would normally have for those around us.

One way to help restore that consideration might be to build enough sacred time into our schedules to ensure we are prepared for the events that keep the wheels turning in our respective organizations, and in that small way show some professional consideration to those around us and start to limit the urgency that’s pressing us to be so unprepared in the first place.


I flip-flop on the subject of whether to use a paper notebook or to use a laptop for everything including note taking in meetings and capturing stray thoughts. My indecision comes from appreciating both sides of the argument for either tool with laptops claiming the higher ground in terms of efficiency but loosing out to things like noise levels, having the opened screen imposing a barrier between you and other people, the issues around battery life, and the distractions that come with the installed apps all clamoring for your attention, usually when you need to be more focused.

Recently I’ve noticed a previously hidden benefit of using a paper notebook as a tool to monitor commitment levels, particularly when you’re prone to over-commitment in a busy organisation.

Once upon a time it was normal for students to take notes in lectures to later write-up into proper materials that could be used for study. This concept is where my paper notebook come back into play as it is certainly beneficial to spend some time digesting notes, transcribing them even, as an exercise in thoughtfulness around work.

However, when time is limited, do you have enough for this type of seemingly unnecessary activity? Arguably, if not, can you be sure you’re spending enough time thinking about what you’re doing at all, or are you simply running from meeting to meeting, lurching from issue to issue, and hoping that you’re doing the right thing in the heat of the moment?

Taking time out to be mindful of your work is a proactive thing to do, as counter intuitive as that may seem, and thinking about something is getting ahead of the issue. If there aren’t enough hours in the day to dedicate some time to this, then perhaps it’s time to assess if you’re over committed, need to delegate more, or in some other way need to address your workload; this is the action I’m taking away from the current use of a notebook and pen!

5 Considerations for Brilliant Diary Management

My diary today is blank. Of course, the fact that I’ve nothing scheduled to do doesn’t mean that I’ve nothing to do.  In the life of a consultant an empty day in the diary can be a Godsend allowing for the all important admin to be done, leading to a day filled with expense claim submission, outstanding paperwork being filed, laptops getting some much needed systems administration attention, personal projects being followed up on (like the in-house test servers I manage), and clients who haven’t been in touch for a while getting a courtesy call to ensure that everything is OK with them. These days are much needed and welcome. But not too often.

businessman playingAn IT Consultant with “nothing in the diary for today”

It can be easy as a consultant, who lives and dies by the contents of the diary, to look at their full calendar for the next few weeks and despair at how busy they’re going to be, overwhelmed by the volume of work coming their way and longing for empty days like today. I like to take a different, more entrepreneurial view of the diary and try not to think of it as merely a calendar of upcoming activities but rather as my order book, as a promise of future work, and that puts the whole thing into a more favourable light.

Regardless of how you look at your busy schedule, the fact is that managing the diaries of multiple people can be a complex task and should be handled with some care as mismanaging it can lead to disaster. With this in mind, here are some of my considerations for managing the diaries and therefore the time of consultants. Continue reading “5 Considerations for Brilliant Diary Management”

Supernanny = Super Consultant

I was at the doctor’s office the other day as I’d fallen foul of the Man-Flu and needed serious help. While I was in the waiting room a mother came in with her two young children, a boy about 3 or 4 years old and a little girl of about 18 months. It was pretty obvious, even to the untrained eye, that there was a significant problem of sibling rivalry growing between the two kids, with the boy especially in need of that careful balance of attention and discipline. He was climbing over furniture, pulling things from his mothers bag, and picking up his sister in unsafe ways, all in all being the kind of child you don’t want sitting behind you on a long flight!

I mentioned what I’d saw when I got home as I wasn’t impressed with the mother’s lacklustre attempts to deal with her son and I was surprised at the response I received: “Supernanny has ruined a lot of parents out there”

Supernanny, with her naughty spots and rules about never raising a hand to child, has made a lot of parents believe they’re child psychologists, so they go around trying to reason with three year olds in the same way that they’d try to talk to a thirty year old and then simply give up in frustration when they inevitably get nowhere. In reality, I don’t think Supernanny herself is actually to blame for this as I think what has happened is that parents have misinterpreted the message the TV show was trying to convey.

Supernanny Jo Frost… looking for her paycheque

Continue reading “Supernanny = Super Consultant”

Leadership in IT Projects

I’m a big fan of Starship Troopers. Before you run away screaming please note that I mean I’m a big fan of the 1959 book by Robert A. Heinlein and only a regular level fan of the 1997 Paul Verhoeven movie. Heinlein wrote science fiction about the nature of government and the role of the people in society. In a later novel he stipulated the things that a human should be able to do and one part of the quote always interested me, to paraphrase Heinlein: a person should be able to “…take orders, give orders, cooperate, and act alone” when necessary. Sound advice, especially the giving and taking orders part, and doubly so when it comes to project management.

Leadership, Starship Troopers style! Would you like to know more?

Continue reading “Leadership in IT Projects”

The Nature of IT Projects

Project Management, on the scale that business managers are really considering when they talk about it, is radically different from IT Support as the nature of the projects under consideration moves to a different level.

Ask a senior manager in an Irish SME about project management as it relates to IT and they are unlikely to think about server upgrades or even moving from one version of an email system to another. What this term is more likely to conjure up is images of a suit-wearing professional organising large-scale projects; for the SME this would mean projects like Finance, ERP, and CRM system implementations.

Project Manager: A suit-wearing professional who organises large projects, drinks coffee, updates Facebook

Continue reading “The Nature of IT Projects”