To Be or Not To Be - Digital

 I had to step away from my role for a period of time and as such did more reading than I have in a while and realised that businesses are going through the hardest changes and decisions that they have seen in a long time. Most businesses have realised they need to change, in fact in a recent survey by BCG[1] it was shown that 89% of Managers globally are involved in digital transformation. The challenge we face is transformations are often compared with any other business decision we take, linear, a or b, left or right. A true transformation is just that, ceasing to be what you were before to become something new. Think about the Caterpillar who becomes a butterfly, this is what business leaders should have in mind when they are seeking to transform, at the end of the initial transformation (because once you start to evolve, your team should continue to keep looking at how that journey can continue), you should be able to see the marked differences from how you operated before to what you are doing now.

Lets stay with that Caterpillar analogy, if a business decided to glue wings on the caterpillar, change its colour, it would not be a transformation, it would still do what it did before, it might look interesting, but actually we would have just made things harder by bringing new complexity to an organism that was built to do what it does (crawl and eat). Many businesses are stuck in this pattern, looking at new technologies, bringing in exciting consultants, however the way of working and the processes and roles and responsibilities all remain exactly the same. Whether there is a new app or website, without these broader changes those businesses – like it or not – will remain a caterpillar. A caterpillar who spends a significant amount of money and whose Board, Senior leaders start asking why are they not becoming a Butterfly.

This brings me to my question – “To be or not to be digital”. Many people will say that being digital is having digital channels to engage with your customers, or having an app to support your employees, these in all honesty are the cosmetics. Imagine a butterfly racing a caterpillar to get to the next branch above, now the caterpillar can eat more but how long will it take to get there and is it worth eating when it does? When we look at Digital native businesses – i.e. those who were born digital, the way they work, they way they create and continue to evolve, just think about some of the apps you use. How many of those are the same as they were a year ago, or even 3 months ago?

Being Digital requires the thinking within an organisation to change, a rewiring if you will, its really hard, but hard things done well is what will effect real change going forward for an organisation. If the organisation can go digital, then the technology can follow. Its amazing in fact there are so many technology options that if a business can transform itself it will realise that it can test ideas, and then decide what works or doesn’t as they continually evolve with low risk and high reward through a fail fast and continually learn approach.

The caterpillar puts in a lot of energy to first builds its cocoon then expends so much energy through its transformation that it loses nearly half of its weight in the process. The same is for businesses, when you are truly transforming you need to ensure it has everyone’s focus and commitment to make the change, if one part of a cocoon wasn’t ready then perhaps the transformation might not look complete or could be eaten by predators crawling in.

Ok I know enough about the caterpillar, but it is a great example for us to consider as we all seek to “Be Digital”. Use it as a measure of how much is actually changing within your organisation, are people taking on new roles, are teams working in different ways? Are outcomes being realised incrementally faster? It isn’t easy, but big changes should never be easy, choosing to be digital brings with it, risks, challenges, emotions, learnings and a commitment that many won’t have experienced before. Hence when you are thinking about embarking on your transformation, think about what it will look like on the other side for your people, your customers and yourself. How bold will your transformation be, because at the end of your journey only you can decide whether you will choose to be or not to be digital – as likewise for any transformation that remains the ultimate question.

[1] BCG Global Survey on Digital Transformation  engagement - https://www.bcg.com/press/3july2020-digital-transformation-survey

How to stay agile while working remotely

 Like most teams across Singapore, M1’s staff members made the shift to working from home during the circuit breaker period. Whilst it was a significant adjustment for all of us, it has been an exercise that has proven the importance of digital tools, cloud technologies and creative collaboration while social distancing.

To support our teams in continuing to work towards our goals, we’ve encouraged them to use a variety of technologies, including online collaborative tools that help staff members stay nimble through cross-team ideation and problem-solving while working remotely, and have provided educational workshops on remote working methods and techniques, such as SCRUM, which encourages teams to “sprint” while working on different aspects of a project together and ensure achievements are seen in weeks rather than numerous months.

In addition, all our teams working from home were equipped with hardware that included the software suite available at the office. Though a critical piece of technology for everyone, few software suites are a perfect fit for every employee and situation – especially when working remotely as a complete organisation for the first time. To bridge the new gaps our teams were experiencing in working from home, they worked together to tackle how best to fill gaps and communicate with each other. Through this, they have found innovative and fun solutions and share them with the wider team.

For example, our Digital Apps & Platforms  team, led by Nicole Cheah, has adopted a hybrid approach to enable her team’s mode of communication, track work progress and drive remote collaboration by using a blend of enterprise suite of software and social apps.

Still, teams are experiencing some challenges while working remotely. “I’ve received feedback that people felt as if they were trapped in a borderless time and space realm where they were unable to logout from work,” Nicole said. “The lack of division of ‘on work’ and ‘off work’ status because people were at home ultimately prolonged their working hours.”

To help her team balance their time more evenly and work sustainably, Nicole has encouraged everyone to work the usual office hours – which includes taking a lunch hour and respecting everyone’s time by not scheduling meetings outside of work hours as much as possible.

Beyond the challenge of balancing work and life when always at home, Nicole’s team also misses the social aspects of the office. “I do miss face-to-face interaction and informal conversations,” Lau Seng Keat, a team member from the Digital Applications and Portals team said. “I feel like in-person communication really helps to uplift the team spirit.”

To recreate the feeling of in-person interaction while social distancing and working remotely, Nicole and her team check-in with each other every morning to chat about work. They also have a dedicated channel for sharing non-work thoughts, articles, and memes, get together virtually on Fridays to wind-down the week, and have held birthday celebrations online.

This is just one example we can share and overall, Nicole and her team feel as if they are working well together and have been able to remain productive while working remotely over the circuit breaker period. “Our team is passionate about digitalization,” Nicole said. “We are adopting a growth mindset, and we believe in being the digital change agent to inspire our M1 teams to develop, grow and win as one team.”

We know there are still aspects we need to improve and therefore we won't be viewing these achievements as completed but merely providing insight for our next steps. Our new objective is that when we are able to all work in the office again many of the collaboration and productivity tools will continue to be used so that we realise a “win-win” outcome of personal interaction with some exciting new digital capabilities to support our team members and realise achievements on a more regular basis for the foreseable future. Our new approach to collaboration and transparency on productivity might have started from being “stuck” at home, however it will be one of the positive new capabilities for our team when we are back collaborating together as physical instead of only virtual teams.

How Fragile is Agile?

I have been reading a lot of articles lately about whether Agile actually works, or whether it’s simply a dream for businesses looking to accelerate business outcomes. Ultimately, the growing view seems to be that Agile doesn’t work – that it is a hype that consulting firms are thriving on, and we’re actually better off going to traditional delivery methods that provide predictability, consistency and the ability to hold someone accountable to get things done.

This debate stems from a need to find the ‘magic answer’ – the silver bullet to take all of our worries away, especially when we are looking to transform. We like Waterfall because we can allocate responsibility to someone else, whereas Agile requires us to get more involved through evolving design, constant prioritisation, showcase presentation, and ultimately owning the outcome (scary stuff). Waterfall means I can document everything I want and then point to someone else to deliver the outcomes. Any delays, errors or increased costs are totally on them, right? (ahem). However, with Waterfall delivery we tend to forget the wonderful concept of change request, where it tends to have a growing number of change requests over time, and then finishes with a resignation of taking what can be delivered with the remaining budget. Now, some might say that if you plan things right you don’t need change requests, but in today’s era of constant change, avoiding it is challenging, to say the least. Historically, in a market where market change was measured in years and for the most part manual (or at best, half yearly) the scale of change was manageable, today however, we are faced with two types of businesses: those that were born digital and those that aspire to become digital. In this dynamic, the extent and scale of change is huge and the challenges this brings to Waterfall delivery means we constantly ask for changes to our delivery plans to evolve with the market.

On the other hand, Agile provides a degree of unpredictability and tends to shift directions based on the priorities set by the business and, more specifically, the product owner themselves. The timing of when a specific capability is completed can be a little vague, as the definition of ‘done’ comes down to when the product owner is actually happy with the capability, and whether they feel it’s fit for purpose. While there can be a desire to go fast with Agile, the concept of minimum viable is always in the eyes of the product owner and thus velocity is determined by the business. For those looking to test in-market quickly, you could achieve a faster launch, but with the knowledge that there might be errors or adjustments to make ongoing. For others who like a capability to be holistic and low risk, it can mean numerous sprints are necessary before it is deemed “done” and as such ready to share with colleagues and / or customers.

I am not going to say that Agile is faster or cheaper – in fact, it can be more ambiguous, frustrating, and lack accountability, which ultimately means there’s no one to point the finger at in pushing toward an outcome. However, this is also why I believe Agile is our future.

Agile represents the cultural change a business needs to go through. We need to be comfortable with a degree of ambiguity and we need to share ownership of the outcome. One aspect that Agile does outperform Waterfall on is the ability to learn faster – and if a business is willing to learn through quick tests and recognises that early failures ensure a program is on the right track overall, then Agile can be a great vehicle to achieve business outcomes. My concern is that Agile has been branded in the tech market as a vehicle to move faster, which means the expectations are wrong from the get-go. Agile will help you learn faster and pivot as the needs of the business evolve or the market drives change, which can create a sense of speed, however it is simply an ingredient in the recipe for broader business agility.

The challenge we keep facing is that our world is not the stable working environment it was before. The predictability of having a three-year outlook that could merely be followed through with minimal disruption is rapidly diminishing, with software that felt more like hardware because it was very much standalone and constant. Today, change doesn’t happen in a two or three-year cycle; it’s happening in months and, if you are really unlucky, in weeks. This is why Waterfall is struggling, as the changes we need to make means we would need to constantly raise change requests and our costs keep going up.

This doesn’t mean I have suddenly prescribed to Agile as being the answer to everything, but it’s about knowing what has the right outcome for your business. If you are doing a migration to the cloud of premise-based applications with fixed scope and deliverables, then Waterfall is likely a better path. On the other hand if you’re developing capability that you know will continue to evolve, then Agile can actually help drive a better outcome.

So, to answer the question in the headline of this article, Agile can appear fragile because it means accepting that we are all accountable for its success. When we struggle to accept ambiguity, the need to change the way we work, or accept joint accountability in partnership of realising outcomes, we make the process fragile.

All of this is simply leading to one key reason - We are the reason why Agile is fragile. We don’t like change, we don’t like being responsible for things which in a traditional IT world was always the ownership of others. In fact, I remember my first project with Agile ways of working, I was constantly asking the delivery partner if this is going to work. My big realisation was when one of the team leads from the delivery partner turned to me and asked me back, “I don’t know, you tell me.” After my heart skipped a couple of beats, I realised this was the difference, and what I didn’t like was that there wasn’t the same clarity that I felt I had before. On the other hand, following our initial delivery, I realised it was that constant ability to keep improving, evolving our tools and external facing systems that was giving us the ability to continue to evolve.

I look at Agile as being a reminder that the business needs to take accountability for the delivery of projects. The time of simply pushing the problem to someone else is over. The introduction of Agile has added another tool to our bag to support our business in become increasingly digital. In doing this, we can enable the business to be less fragile and more adaptable, innovative, disruptive, and, well, agile.

When failure takes too long

In a digital world, new ways of working are becoming increasingly common. One of these is Agile, which broadly refers to how we deliver solutions in an iterative and incremental manner, through collaboration between self-organising, cross-functional teams.

This can seem very exciting – an opportunity for rapid development, co-creation and evolving requirements, as the business adapts to learning's and change.

With Agile fast becoming mainstream, this may not be new for those of us already on-board. Nonetheless, where businesses tend to struggle with the introduction of this new way of working is the cultural change that it needs to represent as well.

Now, when I talk about culture here, I’m referring to our fear of failure. In a society that celebrates success, it’s human nature for us to not want to fail.  Failure suggests we didn’t plan, didn’t consider the options and ultimately let down our colleagues, managers, customers or even family.

Consider for a moment the last time you failed, what did that feel like? How much were you willing to share that failure with others? Announce it to the world?

Some brave souls would have stood up straight away and said, “Well got that one wrong, let’s have another go!” Now, think about the idea of failing on a regular basis. No – I don’t mean every day, but how you may have to keep changing directions while working on a project, as you become more knowledgeable on the pertinent challenges, to meet a projects objectives. How long would it take before your manager or even other senior leaders start to question what you’re doing, and wonder whether you’re the right person to be leading the project?

I’ve had some spectacular failures in my career as we sought to try new ways of working, introducing new capabilities or launching new offerings into the market place. However, I’ve also been fortunate enough to have some amazing support from my managers as I sought to pivot, recover or simply stop what we were trying to do and take a different approach (You know who you are and thank you for your belief!).

The biggest thing I have learned from these failures is simply to find my courage and highlight the risk or failure early, however uncomfortable this is, and no matter what the consequence might be. Unfortunately, not everyone has been as fortunate as I have in having some amazing managers – who understand that in the pursuit of some exciting goals, sometimes we get it completely right and other times spectacularly wrong!

It’s not uncommon that when a risk emerges within the business, an early view may be to classify it as “Amber” or even “Green” on the wishful basis that it will probably sort itself out before it becomes an issue. Unfortunately, it’s equally likely that with the passage of time, that initiative may not recover and in fact results in the risk becoming compounded due to collateral impacts.

These compounded risks can reach the point that they start to jeopardise the entire project. Given people’s natural tendency to want to show a project is performing well in its early stage, flagging this as an issue can make many folks nervous. Then one of two things will happen: either they will call out the bigger risk and wait for the bombshell of a response, with everything put on hold while a post-mortem takes place; or break down the main risk into smaller components, with the goal to resolve them individually and show that it is being managed.

I’m sure many managers who read this will say that they’re always supportive of their teams – and that all the team needs to do is raise the concern for the manager to help them solve it.

Now put yourself in your team’s shoe: when you wanted to be successful and prove that you could solve things on your own, how willing were you to call out issues on a regular basis without being seen as incapable of delivering on the outcomes?

At this point, I can anticipate the question many will be asking: what in the world does this have to do with Agile ways of working? Simply put, failure is a core aspect of Agile. In fact, you will meet many Agile coaches who say that the Agile methodology cannot be truly successful without failure.

Agile methodologies can let you achieve outcomes faster, by breaking deliverables down to their smallest component or feature you’re looking to develop. The Agile way of working requires teams to be empowered to define what they should prioritise to build first, to realise new and exciting outcomes without being encumbered by a fear of failure.

Two words leap off the page for me now – empower and failure.  Both are important and intrinsically linked to each other. What level of decision making would you be prepared to cede to someone in your team, who is leading a development project? How often would you insist on them checking in with you?

Insisting that failure is necessary for Agile to work doesn’t mean we simply sit back and watch teams continuously fail. Sometimes, intervention or a change of team member is required. Even as we empower our teams, it’s equally important that they know the standards expected of them –  whether it’s the performance of individuals or the overall team.

In setting the expectations and standards while providing the right coaching, we enable the teams to grow in the direction the business needs. I like to refer to these as the guardrails – giving people the reassurance and sense of security they need in the early days of Agile, that early failure is acceptable in the development of new capabilities. As those teams mature, these guardrails become less necessary as the team knows what is expected, and more importantly start to set their own expectations of the business as well.

To be clear though, giving greater flexibility and autonomy to teams doesn’t mean development paths look more like a bowl of spaghetti, with new capabilities created all over the place. Development teams still work to a roadmap and continue to have a prioritised view of what the sequence should be in the development of features. This lets them achieve an end goal, whether it is a new offer to market, a new system deployment or even customer deployments.

In a nutshell, Agile can be an exciting path for businesses to embark on, but it is merely a set of instructions for business leaders to follow. Simply following the said instructions doesn’t always translate to the desired business changes or accelerated outcome. For this way of working to thrive, it is imperative for business leaders to change their culture by providing the bandwidth for teams to learn, iterate and grow, without the fear of failure.

We need to recognise that without taking on the responsibility ourselves in driving this change in business culture, we will be left with teams that have been asked to embrace a new way of working that will ultimately lead to failure. This comes about when teams try to manage every risk scenario themselves, avoid the “bad news” conversation and try to be all things to all stakeholders. The result?  A workplace fixated on risk avoidance, which eventually leads to demotivated teams, increased cost of change and missed objectives – all because failure took too long.