Countless books have talked about why organisations need to adopt an agile way of working; the promise of delivering value faster and ensuring that the customer ultimately gets what they want because they can change their mind and reprioritise requirements is an alluring prospect.
Unfortunately introducing an Agile way of working within an agency often results in unmet expectations and a feeling that Agile didn’t deliver everything that was promised.
Let us explore a typical “Agile Project” within an Agency.
Meet Chris (the sales person). Chris is really pleased that he has a lead from a new company and feels confident the agency can deliver the work required.
The project starts well — the client comes into the office and explains their requirements. Chris invites Joe (Technical Expert) into the room to assist with the sales process; Joe listens carefully to what the client says and articulates confidence that he understands exactly what the client is looking for.
In some agencies a project discovery phase may be sold to the client — this is usually a meeting or series of meetings which allow Joe and his friends to drill into what it is the client actually wants and ensure that they have a really good grasp of the requirements for the project.
At some stage during the sales process Chris will explain to the client how the project process works and the client is introduced to the concept of an Agile delivery. Invariably the conversation will go one of two ways:
Time and Materials
The agency explains to the client that they work in an Agile way and as a result the client can change their mind and re-prioritise requirements as the project progresses. For this reason the agency can’t give a fixed price and instead will estimate each of the requirements based upon the number of days required to complete the work.
The client is asked to place a work order for a fixed number of days to be used to deliver the highest priority requirements. If the client adds additional requirements they will be estimated and then prioritised accordingly. This might mean that lower priority requirements can’t be done because the client hasn’t purchased enough days — the client can either forego the requirement or purchase additional days to get the work done.
The client signs up to this approach confident that they are in control and that they effectively have a fixed price because they know that they won’t add or change any of the requirements during the project.
The agency explains to the client that they work in an agile way. The agency has a SCRUM team available to complete work and the team is able to deliver x points of value per sprint.
Each requirement will be estimated according to size and this will be converted into a numerical value using the Fibonacci sequence (a significant amount of the meeting is spent explaining this concept to the client). It is agreed that requirements will be prioritised by the client and will be grouped together into a sprints worth of value.
The client is asked to place an order for a set number of sprints worth of work. If the client adds additional requirements they will be prioritised outside of the current sprint. This protects the work currently being done by the agency and ensures that the entirety of the clients budget isn’t wasted by going down one particular route without checking in with the client.
The client signs up to this approach confident that they are in control and that the overall project budget is protected. The project is effectively fixed price because the client knows they won’t add any further requirements and there are milestones in place at the end of each sprint that can be used by the client to check progress.
Following this initial meeting the company will undoubtedly want to produce a proposal. In this document the company will replay what they have been told by the client to provide confidence that the requirements have been understood. The client will sign on the dotted line and the project will begin.
Typically the project starts well; delivery seems to be on track and the developers make all of the right noises during daily stand-ups (The Agency has started doing these because that’s what Agile organisations do — in reality it is an opportunity for the Project Manager, Jim, to demand an update which can be given to the client).
The client is given regular updates by Jim (who may or may not have been involved in the discovery phase) and they are pleased things seem to be on track and progressing according to plan. As the project progresses things start to go wrong:
Something was under estimated
A specific requirement was estimated as a small task that should only take a day to do — this isn’t actually a small task and takes 8 days to complete. At the end of the sprint the client isn’t happy that everything which was promised hasn’t been delivered within the agreed timescale.
Jim explains to the client that the feature took longer to do than expected and advises that the work will be prioritised in the next sprint. The client asks who is paying for the next sprint and states that they shouldn’t have to because the estimation is at fault and states that Chris promised that the company were really good at estimating — in the clients view as the agency was responsible for estimation it is the agencies mistake and as a result the work that was not completed should now be finished for free.
In return the client will graciously accept that the deadline has slipped but advises it is now critical that no other deadlines are missed or their project will be severely impacted.
In case you hadn’t noticed — the concept of Agile is now forgotten and we are effectively working fixed price waterfall.
Another project is experiencing problems
The clients project is underway and progressing well. Another project is experiencing some issues (perhaps it is the project referred to above where something was under estimated) the developers are asked by Jim to help get the other project over the line and immediately stop work on the clients project.
At the end of the sprint everyone is surprised that the clients project hasn’t made as much progress as was expected; Jim explains the problem to the client and the agency agrees to continue working on the project at no extra cost to get the work over the line. The client accepts that the deadline has slipped but advises it is now critical that no other deadlines are missed or their project will be severely impacted.
Once again we have slipped into a fixed price waterfall mindset.
The scenarios described above may be repeated several times. By the end of the project the client is generally ‘happy’ that they have a deliverable that broadly meets the requirements that was originally outlined. It is likely they have a sense that they have had to compromise on some features but they accept this as they have worked in an agile way and this was explained to them at the outset. The project has taken longer to deliver than anyone thought it would but the client is happy because they have only had to pay for the work that they committed to so their budget remains intact.
If any additional money has been spent it is for something brand new that definitely wasn’t mentioned in the initial project meeting. We know this because even though the client was “absolutely sure” that it was mentioned in the meeting the agency has spent several hours going through the proposal internally and grilling everyone who was at the meeting asking them to remember what happened in the room several months ago just in case the client had mentioned the new thing in passing.
After much negotiation the client reluctantly accepts that it was not part of the original requirements and agrees to pay for the bare minimum amount of extra work in order to make sure the new thing gets done.
Sound familiar? I have seen the project process above repeated within countless agencies. The harsh truth is that although everyone involved in the process firmly believes that they are working in an agile way the process described above can at best be described as “fr-agile”.
The agency has taken the bits of agile that sound good to the client and have sold a dream of being able to change requirements and deliver things quickly without also ensuring that the client is subscribed to the reality that they are also working in a world of estimation uncertainty. As a result the agency has inadvertently taken on the uncertainty risk because when things go wrong the agency gives ground in order to make sure the client is a happy customer.
Fixing Project Variables isn’t Agile.
The starting point for fixing the problem is to understand why the approach outlined isn’t agile. Let us consider a waterfall project — in projects of this type organisations try to fix the 3 project variables:
Agile methodologies recognise that in order to adapt to change all 3 of these variables cannot be fixed. In an agile approach typically budget and time will be fixed by virtue of the fact you have a set number of resources working for a given period of time, i.e. a sprint.
Agile methodologies recognise that in such circumstances it is not possible to fix scope because of the degree of uncertainty found within software development projects.
If we map this onto our typical “Agile Project” it becomes clear that the clients expectations were mis-set during the initial project meeting — estimating features in terms of days or story points allows the client to build a phycological bond between the money they are paying and the estimation that has been given — it is this phycological contract which is broken when a piece of work has been under-estimated and delivery therefore takes longer or when less work is delivered that was originally promised.
A better way ….
In order to move beyond fr-agile ways of working clients and agencies need to embrace the true essence of what it means to be Agile.
A good starting point is to review the Agile Manifesto. The first statement is that a truly agile organisation values
“Individual and Interactions over processes and tools.”
In my view the solution the agency agile problem requires agencies and clients to establish a close and trusting bond where both agency and client are incentivised to do the right thing and work together in order to meet the objectives of the engagement.
For an agile project to be successful the whole team need to work truly as one organisation. Both sharing in both the successes and failures of decisions that are taken.
Agencies must build a bond with a client where we move away from a traditional customer supplier relationship and move to a world where the everyone is aligned and incentivised to achieve the same goals and ambitions. This requires both parties to truly embrace moving beyond a fixed scope agreement and understanding at a deep and meaningful level what success really looks like.
The solution to the problems highlighted in this article are not easy or straightforward; but solving a problem begins by identifying that there is an underlying issue and agreeing that there is a problem which needs to be solved.
The premise of this article is that Agency Agile is broken; what are your views? Have you encountered an agency that faces the problems outlined in this article? Perhaps you have worked with an agency who has been able to move beyond the problem and create an environment where both client and agency successfully partner to create a shared outcome, shared risk and shared reward engagement?
Please reach out to me and share your experiences — @Steve Westgarth
A little thing happened today …. I say it is a little thing but to me and my colleagues at Boots it is actually quite a big thing.
In the grand scheme of things this might not seem like much — websites go live everyday with varying degrees of fanfare but this particular release is a big thing for us and has been the all encompassing focus of my team for the last 12 months.
When I joined Boots there was a big ambition. The organisation had a very complex brown field technology estate and was very aware of the need to modernise the digital capability and embrace a composable commerce solution built on a modern cloud microservices stack.
In the first days and weeks in my new role I considered that such a change would be relatively straight forward and a sensible first step; little did I know how difficult that journey would be and the problems we would encounter along the way.
For those of you who are interested here are some of the issues and challenges that we have overcome in the last 12 months:
The Concept of the Donut
This problem seems like it was encountered a lifetime ago, but its actually become fundamental to our approach. WCS is a huge monolithic application and everything is very tightly coupled. In considering how we might adopt Adobe AEM in a truly headless solution we were faced with a stark reality that there is a huge amount of functionality contained within the header and footer of our website:
Analytics / Tagging + a whole host of functionality (and tech debt) which makes the current site work today.
The desire to build out a headless front end required all of the functionality listed to be re-built in React. More than this though, it required all decisions related to these features to be known and agreed upon upfront.
Our strategy is to build a new composable commerce application using best of breed technology– we therefore needed to agree what technologies would be supporting each of these components and agree the target architecture of the site before the build could begin in anger. The analogy of knowing where you are going on holiday before you get on the plane never felt more real.
It quickly became clear that the timelines attached to this were going to be unacceptable and incredibly un-agile — we needed to break the problem down and deliver in an incremental way — the concept of Minimal Viable Product was discussed but in reality stakeholders (and our customers) didn’t want to loose functionality we already had on www.boots.com as part of our transformation journey.
Enter the concept of the donut. Our solution was to leave the header and footer of www.boots.com intact on WCS and read the existing HTML into our new microservices application. We then injected the new homepage content in between the header and footer — the homepage content effectively became the jam in our donut.
Taking this approach allowed us to kick the can down the road on a number of critical problems such as shared state, session management, integration of product data and a number of other issues. We focussed our attention firmly on what we believed would bring the highest customer value, a fresh responsive design built using a modern CMS and the ability to begin leveraging the power of the Adobe Marketing Cloud.
The solution isn’t perfect — the header and footer still contains a lot of technical debt and we haven’t been able to realise all of the site performance improvements that we want — but we have taken one very big step towards our end state! We also know that we will be able to incrementally address these issues over time and are confident in our approach.
This answers the key question that the eagle eyed amongst you will be asking:
“Why is the header on the old homepage and the new homepage the same?”
The simple answer – it is …. but not for long. We can now start to incrementally build out the header and footer components and also take those elements headless over the coming months.
Adopting the donut didn’t resolve all of our problems in fact it introduced a number of other issues that we have needed to overcome.
One of the key issues we encountered was the issue of style bleeding. This occurred because the WCS stylesheets hadn’t been written using BEM notation and therefore over-rode styles contained in the react application.
The solution was to create a template wrapper that performed a full CSS Reset on content held within it — this wrapper now encapsulates all of the AEM content making up the jam in our donut.
Shared Header / Footer
Although we took the decision not to build the new header and footer as part of the initial phase we did need to consider how our approach would scale as we continued to build out our headless front end.
To that end we explored the phased transition states that our header and footer would go through beyond the go live of our homepage.
The solution was to create a microservice to serve our header and footer to WCS and also any micro frontends that we might choose to create either now or in the future.
This service will be in our estate for a long time to come and provides the glue that will hold together our consistent user experience well into the future.
Routing — Content Served from WCS or AEM?
Today we have launched our new homepage, but over the coming weeks our business teams will be migrating all of our Department, Brand, Article and Category Pages onto Adobe Experience Manager which will bring our fresh new look to the whole of www.boots.com.
This means we have now entered a hybrid state with some content served from WCS and other content served from our microservices application. The problem? How do we make sure that new AEM content is served to the customer (as opposed to WCS content) when it is available?
Our solution was to create a service which is known affectionately as the decider of destiny. This service now forms part of our digital edge services and directs traffic based upon what content is published in AEM — effectively maintaining a routing table that determines if the business have published AEM content and serves it to the customer if it is available.
Editing and previewing content across the end to end customer journey was a critical requirement for our business teams. The issue we encountered was that as we move into our hybrid state we needed to enable the business to preview content across our microservices application and also the legacy WCS estate.
Our solution was to leverage the power of the Adobe Single Page App Editor and preview capability. Sitting here today this is a really obvious solution but 12 months ago when we embarked on this journey the SPA editor was still in beta and we really didn’t know if it would be able to handle all of our use cases.
It turns out our gamble paid off and the result provides an incredibly powerful way to scale our preview capability as we continue the development of our new customer experience.
Over the course of the last 12 months the team have resolved these issues and a whole host of other problems — turns out creating a headless front end does bring a lot of unexpected challenges particularly when facing into a brown field technology estate.
We still have a long way to go on our digital transformation as we gradually rebuild our website on a modern cloud technology stack. Each increment takes us a little closer to our target state which will enable us to leverage the true power of CI/CD and unlock agility and speed of delivery which will truly transform our ecommerce platforms across the Boots organisation.
Today is a big milestone, and a huge achievement! Today marks something that everyone on the team should be incredibly proud to have been a part of — I know I certainly am!
It is also heart warming to hear what our CIO Rich Corbridge thinks of today’s achievement.
“This change is one of so many big advances that happen to Boots over the next 3 to 4 months, an ambitious change that places the customer at the centre of every thing we can do for them on a digital platform.
Our customers love the Boots store, these changes begin to enable that same love to transition to the way we are reflected on line. Every part of Boots is involved in how we make this change, truly inspiring to see how the whole organisation understands and gets behind what so many others would describe as a technology change!”
I want to use this opportunity to thank everyone who has contributed towards this achievement from within my own team, our partner organisations (Including Adobe and IBM IX), other teams within Boots IT and the wider Boots business. What has collectively been achieved today is truly transformational, you all need to be congratulated on this success and on a job very well done!
To our customers, I really hope you like the new look and feel! Please take the time to reach out to us and let us know what you think, the team would love to hear your comments and we hope the new experience brings a little extra joy to your day.
As for me, I’m incredibly proud to work for Boots and to lead an incredibly talented engineering team of truly inspirational and very talented individuals. Thank you all for bringing your A game to work each and every day and giving me the opportunity to be part of a truly miraculous digital transformation journey.
Organisations are embracing agile delivery models at an unbelievable rate; a huge range of methodologies are being adopted in order to allow large corporations to make sense of doing things in a new and unfamiliar way.
All to often we see agile being interpreted as an “IT Thing”; as a result other parts of the organisation feel that they don’t need to adapt or change which introduces huge practical challenges in changing the culture.
Within my own organisation one of the biggest challenges we have faced is that stakeholders struggle with the concept of not being given a specific date when something will be delivered.
Stakeholders who are close to the delivery understand that we are prioritising feature developments according to business need. When a significant amount of money is being invested in a development which can’t go live until a critical mass of features are developed, it is often difficult to articulate a specific date on which that critical mass will be achieved.
The Burn-down Chart
The burn-down chart is one report which is commonly used to demonstrate and track team velocity. The burn-down chart is a great document for showing individual team progress, and for demonstrating how velocity improves over time. However, it does not help us visually present stakeholders with an indication of when work will be completed. To those who are not close to the work of the team the burn-down chart doesn’t give enough information because it only shows a snapshot of a single sprint which fails to show the whole picture.
The Burn-up Chart
One solution to the “When will it be delivered” problem that I have found effective is to create a Burn-Up Chart. The idea is simple:
- Estimate all stories in story points.
- Add up the total number of story points that need to be delivered in order to deliver the critical mass of work that people are interested in.
- Create a graph, the Y Axis should plot story points and the X axis should show sprint numbers (in our organisation stakeholders preferred the X — Axis to show dates).
- After each sprint plot the number of story points completed.
- Work out the average number of story points completed in each sprint and use this to forecast forward how many points will be completed during each future sprint.
The graph can now be presented to stakeholders and it clearly shows the estimated completion date based upon known velocity.
The burn-up chart can be used when you have a single team and also when you have multiple teams working on the same delivery. Just add all of the story points together and accurately plot the combined total achieved during each sprint.
I have also found that the burn-up chart is a great way to explain why a delivery date might change.
If scope changes part way through a delivery you can adjust the target line to reflect the point in time that the scope changed. This also gives an indication of how much extra work has been introduced.
Conversely it is straightforward to model what the delivery date might look like if scope were to be reduced.
If velocity significantly reduces during a sprint it becomes immediately obvious to stakeholders. This should then inform a transparent conversation about what caused velocity to decrease at that point in time. Expectations can be managed at the earliest opportunity which ensures there are no surprises when a committed date isn’t achieved.
The burn-up chart is one tool which can be used to help organisations understand how delivery is progressing. It is particularly useful in businesses who are new to agile or have difficulty in breaking down work into small increments which can be fully delivered in a single sprint.
Have you used any alternate strategies to answer the question “When will the work be delivered”? If you have any ideas please reach out to me on twitter @stevewestgarth
Someone asked me today why I put my pronouns in my e-mail signature and what it means.
As a cisgender man (a person whose gender is in alignment with the sex they were assigned at birth) there is little to no risk in sharing my pronouns. When you’ve never questioned what pronouns people use for you, or even thought about the idea of pronouns, sharing your pronouns is easy and costs you nothing. For a person who is transgender or nonbinary, sharing pronouns can be incredibly daunting and create huge barriers for the individual particularly in the workplace.
By sharing my pronouns in my e-mail signature I hope that it makes it easier for others who may be transgender or non binary to share their own pronouns
More information on why pronouns matter can be found at https://www.mypronouns.org/what-and-why.
If you don’t already actively share your own pronouns perhaps you might consider putting your pronouns into your e-mail signature – you never know who it might help.
Over Christmas I’ve been reading a fascinating book called The Chimp Paradox by Professor Steve Peters. The book introduces the concept that we all have two brains:
You (The Human) — this brain is responsible for intelligent, rationale and logical thought.
The Chimp — this brain is completely independent of you and not under your control. This brain thinks emotionally and is led by feelings and impressions.
The book argues that throughout life our two brains battle continuously in response to situations. The stronger Chimpbrain often wins, particularly in the moment as You, the human brain takes time to process information and to construct an intelligent and rationale response that considers all of the information available.
I am guilty (as I guess we all are) of not always thinking through the consequences of my actions and in particular not always considering how others might respond. Sometimes it is necessary to take an action which provokes an emotional response from another individual but strong emotional intelligence requires that we are cognizant when such a reaction is being provoked and what the outcome is likely to be.
I have been reflecting on my own approach both in my personal and work life. Sometimes I want to provoke a reaction. The question I have been asking myself is which brain has the response to the actions I take has come from and is it possible to tailor my approach in order to specifically target someone else’s human or chimp brain.
Experience tells me that sometimes in order to make someone sit up and take notice it is necessary to provoke an emotional response. The chimp paradox has reminded me that I need to have a game plan — when deliberately provoking an emotional response it is always helpful to consider how I will subsequently engage the respondents human brain; and how I will subsequently help the respondent to fight their inner chimp and logically rationalise my intention.
Learning from the Chimp Paradox in 2021 I am going to make an effort to get to know my inner chimp; both before and after I take action. I am going to carve time into my day to reflect on situations that have occurred and to evaluate which brain I engaged. I will also take time to consider which brain others around me are using and proactively consider how I can get to know the inner chimp of those around me.
My hope is that by taking time to understand how my inner chimp, and the inner chimp of those around me thinks, I can use this information to build my own emotional intelligence which in turn will help me to achieve my own goals and objectives.
My challenge to you in in 2021 is to take some time out and get to know the inner chimp of a friend or colleague. Taking this time might help you to tame your own inner chimp and focus more on positive human intentions and less on uncontrolled emotional responses that detract from your goals and objectives.
Above all when you are faced with an emotional reaction recognise that this is the response of an inner chimp and remember the words of Maxime Lagacé
“The most important thing is to look ahead. The past is your anchor.“
Now go find your inner chimp and ask your chimp if you can work together this year.
On a daily basis our organisation makes choices about what features can be released and what features are not yet ready to be put into the wild — sometimes this means that we allow functionality to go into production with known bugs and occasionally defects enter production without being noticed.
I strongly believe that we have a duty of care to our customers to make sure that our software is fit for purpose and to ensure that our software does not have any negative impact on our customers lives. Unfortunately sometimes the most innocuous bugs can have wide ranging unintended consequences that would surprise the most diligent development teams.
I am not ashamed to admit that I practice good sexual health by ensuring I have regular check-ups at my local sexual health clinic. After a check-up the clinic advises you that the results will take 4 days to process and they give you a number to call.
Going to the clinic is never a pleasant experience — but going to the clinic when you suspect that something may be wrong is a particularly unpleasant thing to do. Unfortunately that is the position I found myself in last year.
I’d be been tested and I was waiting for the results — as you can imagine it was a long wait but eventually 4 days had passed so I called up the number.
The automated voice asked me to enter my unique ID which I did and then pleasantly asked me to “Please wait while I look up your results”.
Now having used this service before the next step is normally that the automated voice informs you that your test is negative — on this occasion after nearly 60 seconds of silence the system said
“Please hold while I transfer you to an operator”
Now at this point my anxiety levels were going through the roof — I’d already spent four days fearing this test result and I’d absolutely convinced myself that I’d contracted something hideous — by the time the system told me to please hold I knew that there was something wrong — as a software developer I understood that you should never deliver bad news using an automated system — the reason I was now being transferred to an operator was so that I could be told the bad news by an actual human.
“You are now 12th in the queue and we will connect you as soon as possible”
So I waited — the system kept me in the queue for 35 minutes and I can honestly say it was one of the worst 35 minutes of my life.
Eventually — I am connected to Marie:
“Good morning, you’re speaking with Marie, please can I have your unique ID”
Now not withstanding the fact that I’d already entered my unique ID and I couldn’t understand why the system hadn’t been designed to automatically pass it to Marie — I gave it to her and a few seconds later she said
“Your results are negative”
At this point a wave of absolute relief spread through me — I was absolutely convinced this was going to be bad news and suddenly all of my fears were unfounded — this was good news, I was eurphoric — I spluttered back at her
“Why did the system put me through to you if the results were negative?”
and she replied
“It just does that sometimes”
Read that again …. “It just does that sometimes” — Now this makes me angry — I have many problems with this on many different levels.
First, this isn’t Marie’s fault, she’s working in a call centre — my problem with that statement is what it represents. This means that the failure is not a one off, it means that it has happened before and not only has it happened before its happened often enough that Marie, who is one of what I assume are hundreds of call centre operators working with this system, has been able to normalise it to such an extent that she can say “It just does that sometimes”.
That means it happens A LOT. Often enough for Marie to not think of it as an unusual circumstance. How many people are put through the agony of having to wait to be connected to an operator to be told that their results are negative?
Let’s explore what has gone wrong. Maybe the database lookup failed? Maybe there was a timeout error? As an end user I don’t care — what does matter to me is the emotional trauma that I went through prior to getting my results.
Now you can argue that I’m making a big deal out of this; does it actually matter? Or, is this just another 1st world problem?
From my perspective, I genuinely thought I had a hideous disease — and some of those diseases could be life threatening — so forgive me — but I think it is a big deal!
I can’t imagine for a second that the product owner set out to create such a poor experience for the end user. I don’t believe the developer intended the code he put into the wild to have such a negative unintended consequence and I’m sure the CEO of the organisation responsible for this experience would be devastated that his organisation was responsible for the emotional trauma that his system had caused.
Working in delivery for a large corporate organisation I am ashamed to say that I can see exactly how this experience has been allowed into production. It is all to easy to understand that this system had a date on which it had to go live — that date would likely have been attached to a business case which released funding and as a result I am quite sure that those delivering the system were under pressure to get it out of the door on a specific date in order to meet the business objectives.
The developer may have even noticed that the database query occasionally failed — perhaps it only happened one in every 1000 times and maybe the business took an active decision that fixing the issue was to costly at that moment in time.
The wider issue is that once code goes into the wild it is often in production for years, with little or no funding available to go back and remediate minor issues — once the system is live unless there is a big security problem or other regulatory issue it becomes very challenging for businesses to justify the money to do further work — and a database query which fails 0.1% of the time is unlikely to meet the threshold required for further investment.
Is that ok? Is it morally acceptable for me to have been put through this psychological trauma — does the money which was saved by not testing these edge cases justify the experience I had when I called to get my results?
Now you might say that this is an extreme example — that very few systems would have unintended consequences that would have such a direct impact on people’s lives — and that might be true — but all systems can have unseen consequences and those consequences by their very nature will affect users in unexpected and often undesirable ways.
I believe that within our industry there is no higher purpose than finding ways to surprise and delight our users. Yes, sometimes compromises are needed, and yes sometimes systems won’t be perfect — but as a community and as an industry we need to make sure that we do everything in our power to make sure that we don’t adversely affect the lives of our customers.
As Software Engineers our reputations are on the line — a bad experience here, and a poor experience there will lead customers to talk about those experiences and this will lead to negative press.
You never know, someone might just write a blog post and tell everyone how bad the experience is or maybe the experience will slip under the radar silent and unnoticed. The question we must ask ourselves:
“Is this morally acceptable?”
We often find ourselves morally challenged — There is a climate emergency; parts of the world are starving, it is still illegal to be gay in more than 70 countries. These are big problems and we must do our part to help improve our planet.
And yet as technology professionals we find ourselves in a unique position where we are able to directly affect and change the lives of thousands and in some cases millions of people.
In the grand scheme of things having to wait 35 minutes to get my test results might not seem like a big deal — but the software team that created this product had an opportunity to make a direct improvement to my life and to the lives of thousands of others calling up to receive their results — was it morally acceptable for this opportunity to missed?
Have you ever come across a system that had a negative impact on your life? If you work within a development team do you always consider the negative and often unseen impact an unresolved bug might have on your customers?
Please reach out to me on Twitter and share your own experiences and explore which bugs you consider to be morally acceptable.
I have often pondered what makes a Senior Developer “Senior” and what makes a Junior Developer “Junior”. Invariable such titles are bestowed upon software developers based upon where they are in their career and how many years of experience they have.
The idea that the number of years you have been doing a job is in my view quite an old fashioned idea. In some industries this may be valid; clearly I would prefer to be operated on by a heart surgeon with 15 years experience as opposed to a surgeon who is newly qualified – that said even in this context the newly qualified Dr may be versed in more modern techniques that the seasoned surgeon may not have knowledge.
I’m not suggesting that experience shouldn’t be considered but I would suggest that we are more interested in the skills that an individual has. Experience means that the individual has had longer to gain those skills but it in no way guarantees that the individual has used the time wisely.
With this in mind recently I’ve been giving some thought to how we should measure the performance of our developers and how to support them in building skills that benefit us as a company.
One of the tools that I have developed to help with this is a Developer Skills Matrix. The concept is really simple – across the top I list all of the skills that I want my developers to have and down the side I specify levels of knowledge (No Knowledge, Basic, Good, Great, Superstar).
When specifying the skills its important to drill down to a granular level of knowledge; being to broad brush doesn’t give you enough detail. In the example above you might be tempted to group all of the skills under the heading “React” – this would limit the benefit of the matrix as it is perfectly feasible for a developer to have no-knowledge of Redux and still be a great developer.
The idea is to create headings which cover areas that a developer might have knowledge or could be expected to have knowledge in order to effectively do their job.
In order to make best use of the ratings its important to provide clarity on what level of knowledge you would expect an individual to have in order to achieve the rating.
I use the following guidance but it can be adjusted to suit your own context.
You might have heard of the technology but you’ve never used it.
You have a working understanding and are able to make basic use of the concept or technology. You would usually ask a lot of questions and rely heavily on others to support you in any implementation work.
You are comfortable using the concept or technology as part of your everyday work but struggle with some of the advanced concepts. Sometimes its good to get help from someone who has more experience than you.
You are really comfortable with the concept / technology and feel you have a great working knowledge of most of the more advanced concepts. You can identify when people are incorrectly using the concept or technology and will offer support to assist them.
You know this concept / technology inside out and are a subject matter expert. You are able to support, help and teach others at all levels. If a stack overflow question were asked related to this area you would jump right in and answer confidently.
Once you’ve set up your matrix ask your Developers to complete it. I like to ask Engineers to justify their ratings in each area – this in turn leads to good 1:1 conversations and also helps normalise ratings across the development team.
Scoring the Matrix
When the matrix has been completed by the whole development team I like to score the matrix. No Knowledge = 0, Basic = 1, Good = 2, Great = 3, Superstar = 4.
When view across the whole of the development team this scoring allows you to identify areas of team weakness, where perhaps you have limited knowledge as a company in a particular area. This can then inform your recruitment strategy by identifying the areas you want to particular focus on when interviewing potential new joins.
The scoring can also be used to identify weaker team members or to help inform performance conversations. I would caution that this is not a silver bullet and should not be used as the only way to measure an individuals performance but it does open up some opportunities to recognise your staff and to inform clear and quantifiable objectives.
Ways to use the data
There are many ways to use the data to help your teams with continuous improvement such as:
Identify 3 skill areas where a developer has no knowledge. Set an objective that by the next performance review the developer will have basic knowledge in all 3 areas and ask the individual to provide evidence of their achievement.
The knowledge can be gained in a variety of ways such as independent research, an online course or pair programming. The method isn’t important but the commitment to improvement will benefit both the individual and your company. You know this concept / technology inside out and are a subject matter expert. You are able to support, help and teach others at all levels. If a stack overflow question were asked related to this area you would jump right in and answer confidently.
Company / Team OKRs
If you use Objective Key Results within your organisation then this data can be used as a quantifiable measure of performance improvement.
Objective: As an Engineering Team we will continually improve the skills required to build our products:
Key Result: The average score for every skill should improve each quarter.
The skills Matrix is not a silver bullet – it can be used as one tool to help with your overall performance management strategy.
When I first considered introducing this tool into my team I discussed with other Engineering Managers in my network and I heard horror stories of similar frameworks being abused – in one case engineers had nicknamed the tools “The redundancy framework”.
Like all tools its success is very much dependent upon its implementation – if implemented well as part of a wider performance strategy the framework can help identify areas of weakness within the team and help guide areas of focus for improvement over time.
Have you used a framework like this in your organisation? If you have I would be really keen to hear from you – please comment below or reach out to me on Twitter @stevewestgarth.
Agile is a term which has become synonymous with Software Development. For those of us who work in Engineering organisations the term conjures up ideas of Sprints, Burn-down, Iterative Delivery Cycles and Retrospectives.
The term itself has a very different meaning:
Recently within my organisation we have been embarking on an agile transformation journey. The Executive team continually refer to the need “to be agile”.
This direct instruction has, at least within IT, been interpreted as a direct instruction to adopt an Agile Software Development methodology and change our ways of working. Speaking as an advocate of agile development I fully support this initiative; I do wonder though if the meaning of the ask “to be agile” can be achieved if all we do is adopt a new methodology.
What is being asked?
As a large corporate we have historically been slow to respond to change. Layers of management approvals and the need to justify expenditure has led to a slow, bureaucratic and risk averse corporate machine.
The world around us is changing at a very different pace; companies like Monzo, Netflix, Facebook and Google are demonstrating that the need to respond to change is a key differentiator which is required to survive.
I don’t believe our Executive team really care about the successful adoption of a methodology, albeit that it may be a means to an end; what is being asked is that as an organisation we need to rewire our DNA so that we are able to respond to change with flawless execution and at pace.
Why is adopting a methodology “not” the answer?
For me adopting an agile methodology as a company allows different levels of middle management to feel a sense of comfort. We have taken a tried and tested system and have been able to weave it into our existing processes to achieve an objective set by the Executive.
According to the 2018 state of agility survey 96% of Agile Transformations fail to generate the capability to adapt to changing market conditions. In my view this clearly demonstrates that achieving the Executive objective “to be agile” cannot be met by simply adopting a methodology.
I am not suggesting that using an existing methodology is not helpful — learning from others is a key component of any successful agile organisation. A framework can bring structure to the organisation but in order for that framework to be successful the people within the business need to understand and buy into why adopting an agile framework is not enough.
A structural change
I recently read a book called Measure What Matters; the author discusses the organisational structure of Google. One of the points which I found most interesting was that a common feature of Google’s management is that managers have large numbers of direct reports. The rationale for this is to flatten the hierarchy which forces managers to delegate work into their teams and reduces the levels of approval required.
In order to be an agile organisation it is critical to remove bureaucratic process. Quite often within an organisation a decision to invest has already been made by the Executive; why is it therefore necessary for several levels of management to approve the release of the money?
The rationale for this approval chain would typically be linked to risk management; to ensure that the money is going to be well spent and that appropriate due diligence has been performed to verify that the spend is wise. In my view this is one example of where organisations fail to grasp what being agile really means.
One way that I think an organisation can signal that they really are serious about an agile transformation is to flatten the organisational hierarchy and restructure. By reducing the number of approval levels required for an investment decision it becomes much easier for teams to respond quickly to changing market demand and therefore achieve the true intention of the Executive; that is to respond and adapt to consumer demand.
Simplifying Governance and Process
Another key facet of a successful agile transformation is the need to simplify process. In my organisation we have well established processes that have been developed and implemented over many years. While the intention of these processes is well meaning the effect is often to slow the speed of change.
In addition we have also found that many of our processes are siloed into different teams and groups. As a result processes often conflict with one another or cause delays because there are interdependencies between teams.
In my view the solution to this is to break down the silos and develop cross functional teams which contain all of the skills and authority required to respond to change. This doesn’t mean creating one big team but instead focusing on making sure the smallest number of people possible can work together to achieve the stated aims and objectives end to end without the need to depend on other teams within the organisation.
I am not suggesting all processes should be thrown away; but it is important to challenge the need for a process and then when process is required is should be robustly tested to ensure that it is fit for purpose. Critically it should make life simpler for all concerned as opposed to introducing complexity.
We have found that quite often a process is introduced by one group of people which is either not understood by another group or requires information that it is difficult for the other group to obtain. This is an example of an ineffective process because it doesn’t make life simpler for all process consumers and therefore reduces agility.
In summary for organisations “to be agile” every part of the organisation needs to understand that the true ask is that collectively we need to adapt so that we can respond to change at pace. Methodologies can take us so far but if the bureaucratic machine isn’t ready to adapt then ultimately the transformation can never succeed.
Within your organisation have you undergone, or are you in the process of an agile transformation? Have you found that there is a mismatch in understanding between the definition of the word Agile and the adoption of an Agile methodology? Is your organisation one of the 96% who have experienced a failed transformation? If so please reach out to me on twitter and share your experience @stevewestgarth.