Skip to main content

Posts

Showing posts from 2018

Stop Demonising Process

All too often people appeal to being "Agile" as a way to avoid following or having process. It could be because the term "Agile" implies flexibility or even because the Agile Manifesto itself says explicitly that "Individuals and interactions over processes and tools". Here, the manifesto doesn't say that being "Agile" doesn't mean you don't have process, it simply says you favour individuals over process. The demonisation of process could also be a knee jerk reaction of when teams had process imposed on them.


How rock climbing, cooking, and weight lifting help us relate to software delivery.

Incremental, iterative, sprints. Whatever word you may use, the whole point is, as the agile manifesto says to Deliver working software frequently. The key here is working not necessarily perfectUsing the words just mentioned or even the word agile can cause some confusion. One of the most common aspects of confusion for people not wanting to deliver incrementally and pushing a large amount of changes into a future release is Aren't we agile, let's be flexible. Of course, this perception of flexibility ends up hurting the team in the future because many changes are pushed through one big release. What this means is if something goes wrong we're simply guessing which change caused the bug.


Here are a few analogies I've been working with to help people understand the importance of frequent delivery.

Scaling Agile with GRC (Governance, Risk, and Compliance)

In the 21st Century, software is at the forefront of our lives. Our insurance, money, communication is all done via software. As such, the importance of GRC is becoming ever more apparent as more and more sensitive information is being stored and viewed by a range of people. We as software practitioners have the responsibility to ensure we store data securely, encrypt communication, output data in a legal and compliant format, and make everything accessible to the general public. At the same time we want to be able to make changes to our platforms as quickly as possible to interact with market conditions.


GRC has always been something of an awkward conversation when it comes to agile delivery. There's no questioning the value of end-to-end delivery that includes the delivery of GRC related activities such as: security, accessibility, and financial reporting. GRC should be a function of delivery, not an afterthought. At the same time, the value in having independent auditing in are…

Book Review: Leading by Alex Ferguson

Alex Ferguson was Manchester United FC's manager for 27 years. During this time he managed the club to multiple titles while leading some of the most hard working, talented, and high performant players on the planet. I thought I'd give this book a shot to see what I can get out of it in my everyday life. Whether you like Alex (Or Manchester United FC) or not. It is clear that Alex was successful in his tenure at United and Aberdeen.What aspects of Alex's experience will I take into my software delivery life? And what aspects I won't?


Commerce, coffee, and value

According to Wikipedia, commerce is the exchange of goods and services that existed as part of the human story since prehistoric times. Before currency we used to barter, then we began to use currency backed by resources like gold, and now we use fiat money (currency backed by the issuing government).

As humans we've learnt that this is the way we exchange value. When I go to a particular coffee shop on a Saturday it's because I judge that the value in the coffee given to me is better than the shop next door. I may even be willing to pay a little extra depending on the value provided. In this case, the value is the extent to which my taste buds are excited from the coffee.

Tips to Automate Yourself Out of a Job

Providing tools, processes, and platforms that automate everything, including yourself out of a job should be the goal of everyone in IT. It's something people rant about on Twitter, speak about on YouTube, and attempt to inspire on LinkedIn. Everyone seems to be telling us we should automate our jobs, not many are telling us how. Today I have a few practical things you can do to actualise this goal.


Book Review: How We Got to Now by Steve Johnson

How We Got to Now is a book that I can't really put into any individual genre. It isn't a novel, isn't a collection of small stories, isn't purely educational, and isn't historical. It is a combination of all of these genres and that's what makes this book unique and enjoyable.

The book How We Got to Now describes, as suggested by its subtitle, "Six Innovations That Made the Modern World". In the introduction Steven Johnson describes evolution and the way one change can trigger a change throughout the course of all of evolution. He also explains various other casualty phenomena to create an overarching point of linkage throughout the whole book. The most notable of these examples is the butterfly effect.




Build and Release Pipeline for Your Own Custom VSTS Tasks

Anyone can create their own custom VSTS tasks and put them on the VSTS marketplace. There are tons of these custom tasks and they can be published publicly into the marketplace or privately into your own instance of VSTS. This blog post will demonstrate how to setup a build and release pipeline for these custom tasks (using custom VSTS tasks!).


There are many reasons to create your own tasks on an instance of VSTS. You could be part of a DevOps capability that wants to share common platforms, standardisation, or integrations. Generally though the reasoning is to avoid common steps that are duplicated across different build and release pipelines.

Using SBAR in code reviews

After the end of a messy sprint everyone was excited and scared to attend the sprint retro. The topic we were dreading the most came up - pull requests. It had been a sprint where few pull requests went through smoothly and everyone was picking up issues with every pull request. Stylistic things came up, whole features needed to be redeveloped, people were clearly annoyed, and you could sense the tension in the room.

Then, a suggestion by our non-technical product owner (who was a nurse and who had never been a product owner before) Why don't you use something like the SBAR technique?

Transformation, reorganisation, and continuous improvement

It seems that almost everywhere I look, a big corporate is going through a 'transformation' or 'reorganisation'. Clearly someone within these organisation is making the decision that this is required because of problems occurring with existing software delivery practices.  That is, they want something improved.

Throughout 2016, I lost more than 20kgs of weight. I did this very slowly through dieting and returning back to my previous exercising habits. I've maintained this weight throughout 2017 and now. How I did I do this? Well, I took out the obvious cheap calories out first: sugary drinks and junk food. When the weight started slowing I then took out desert. When the weight started slowing again, I reduced my carb intake. When it started slowing again I cut out carbs. When it started slowing again, I began to count calories. I now have kept the weight off, feel reat, and habitually live a healthy lifestyle. I am also able to indulge every now and then. NB: I'…

Book Review of 'TED TALKS' and what I learnt

For those of us wanting to improve our public speaking, have been speaking for a while, or just starting out. This is a great book which was lent to me by my colleague Paul. Below is my review which covers 'how I read it', 'what were the main points', and 'what was missing'.


'Hierarchy' the dirty word

Modern human resource departments dread the word "hierarchy", companies happily boast of their "flat structure" in job advertisements, and national leaders are disparaged as being out of touch. However, when is a bit of hierarchy actually good? When is it worth it?

My personal issue isn't with hierarchy. It's with excess, unneeded hierarchy. Hierarchy can be good as it means the higher up the individual goes, the more responsibility they have. Problems arise in organisations where individuals in higher levels of a hierarchy do not have much responsibility and thus do not do much work.


Make your code review requests count

The value in PRs (or code reviews in general) is more than just ensuring good code is pushed into the main-line branch. There's more to a PR in my opinion. This includes

•Learning from others
•Sharing learning, understanding, and the architecture of your system

3, 2, 1 - REVEAL POINTS. The true value of poker sizing

Many of us are in teams with a good habit of sizing work items, and in many cases this is a good habit. However, do we truly understand the importance of this behaviour? Why do we do it? Is it even necessary, and where is the real value of all this?

My top 3 development tools

Every developer has a set of development tools which they use on a regular basis. Below is a list of my top three tools, why I use them, and how they benefit me. In the list below I haven't included code editors, IDEs, or extensions to IDEs. Please note: this may disappoint many of you who are expecting something "advanced" or "funky".

Git breaking? Get off the UI

Git is perhaps the best VCS I've used in my life. However, some of the things I always hear when people are trying to learn Git, or have used it for a while but never in larger teams are:
"something stuffed up my Git"
"my Git is broken"

In my experience, Git is probably the most predictable, deterministic tool I've ever used (thankfully, considering it does version your code!).

I Don't Know

Many people who come from command and control working environments have a very limited circle of safety. This maybe because their suggestions have been discarded rudely, being treated poorly, or always fearing for their job. They do not suggest improvements and are often too scared to ask for help.