Tag Agile

The Essence Of A Digital Culture Part 1

wakeuptodigital Leave a comment

 

Photo by rawpixel.com on Pexels.com
Photo by Makenzie Kublin on Pexels.com

We were incredibly lucky to host a Buildathon earlier this year in our Digital Transformation Centre.  One of our visitors (a global senior exec in the company) described our Centre as walking into a ‘Digital Disneyland’.

I took this as a great compliment !

We have been working over the last few years to really understand what it  means to have a digital culture and I think we’re very close to having nailed it.

It hasn’t been easy to get where we are today, especially when we have been part of a much bigger corporate machine, but there are a few key things that have made it possible.  I’ll explore a couple of ideas and principles we used to build amsuccessful Essence of  a Digital Culture…

Think Small, But Be Big …

Despite being part of one of the biggest IT companies in the globe, we started to think and behave as though we were a start up.  We were very insular, looking within the team to really figure out what we were trying to be. Even though we are part of a mega corporation, in today’s Digital IT market our competitors are more than likely to be a small software house than one of our traditional rivals as we started to think and behave like a start up.

This approach helped us go for some of the work that in the past our sales organisation would have turned their noses up to.  We didn’t mind going for a small 6 week project as we knew that when our clients saw what we could do they would want some more.  We needed to build our reputation as a digital company as our traditional market was in large scale infrastructure programmes and mega deals. One of our first projects started as 2 people looking at some blockers and now we have grown to 4 scrum teams for that client and have been delivering on new and exciting opportunities for them ever since.  They now consider us their partner in developing their digital road map and have absolute confidence in what we can do to support the transformation of their business.

Listen To The Teams

Although we had been operating under Agile and Dev Ops for a few years, we really started to crack the Digital Culture when we started to listen to our teams.

We held a deep dive focus group session and basically asked a number of our more vocal and opinionated team “what can I do for them to make them more effective in their role, happier at work and feel engaged within the team?”

There were the obvious salary, bonus responses, but we also obtained a wealth of valuable information from those sessions covering everything from training, tooling, creating an inspiring environment, innovation, technical and business partners, social and community, leadership and communications.

I took the output, categorised it into work streams with various actions in each work stream backlog relating to the feedback in the teams and created a programme called ‘Making The Digital Transformation Centre Real’.

Each action was given a RAG rating and reported on at each of the bi-monthly Centre Uber Scrum (large team cascades).  All of our successes, progresses and blockers were made visible to all of the team and they could see, very clearly that we were listening to them.

We had some quick and cost free wins …

  • set up a Kudos board
  • set up an ideas board
  • contact our teams preferred technology /tooling companies for free software and training – thus creating real technology partners verses the corporate strategic partners we didn’t have any contact with
  • develop and publish a comms plan and have regular ‘uber scrum’ meetings
  • give the team freedom to use best in class and often free software and tooling
  • run knowledge sharing lunch time sessions developed by our own in house experts
  • create a practical mentoring environment
  • engage with subject matter experts in our local ecosystem to support our lack of niche expertise
  • engage within the local community to support STEM activities in local schools, get involved in charity events, develop a relationship with all of the local colleges and universities in the area

We also made some small investments to allow innovation ideas that came from the team to be developed.  We spent around £500 on some Raspberry Pi’s, RFID readers and some virtual reality headsets.  The teams turned this into some amazing innovative projects which have either supported activities in the Centre or our clients.

We had transformed from a very unclear future into an environment where ideas were encouraged and supported and best of all, the team had some amazing ideas!

After 6 months of doing this we held a pulse survey of engagement indicators and found that over 85% of our team were either ‘happy or very happy at work’.

At this point it felt like we had found the team’s Mojo and we didn’t want to lose it, so our engagement activities turned into Project Mojo.

F720AE11-A3B1-499B-A0D5-A30C26E6854F

We are still running Project Mojo, issuing 6 monthly surveys, having Uber Scrums and running Mojo Workshops to keep the momentum going.

There are other aspects to our digital culture which I’ll go into more detail in subsequent blogs including collaboration, guilds, training amongst others.

We are still learning and continuing to get better every day.  Sometimes it’s amazing, sometimes it’s another learning opportunity.  I don’t know if it’s quite on the level of the Magic of Disney, but there is definitely a buzz, excitement and enthusiasm that I’ve never felt before in the air.

There are other aspects to our digital culture which I’ll go into more detail in subsequent blogs, including collaboration, guilds, mentoring, training amongst others and also, how we are looking to take what we have achieved and scale that out across the wider organisations.

 

 

Everyone Needs Their Own Lightbulb Moment

wakeuptodigital Leave a comment

I’ve lost count the number of times I’ve been asked by sceptical clients and colleagues about using Agile and Dev Ops methods in software delivery.  This is usually followed by …

“We can’t use that because …”

“That won’t work for us because …”

“Our teams don’t want to change because …”

“Agile doesn’t really work”

… I think you can see a pattern.

In response, I usually find it is best to recount my team’s story of how we were very sceptical of change and happy with our waterfall status quo before we started using Agile and Dev Ops methods, but making the change and giving it a go was when the real fun started.  If you’re sitting comfortably, here goes with our story …

Like most IT Professionals over a certain age with a background of complex legacy public sector traditional waterfall projects that lasted more than 6 months, usually resulting in going over budget whilst running into impossibly tight testing windows where the requirements would change (usually late in the project) and defects were expensive to fix alongside a mounting technical debt, we thought we knew how to do things right.  The project managers blamed everyone, the business analysts blamed the client, the designers and architects blamed the business analysts, the developers blamed the testers.  Just writing that down now makes me embarrassed to admit our arrogance.

In our minds there was nothing that we didn’t know about IT delivery.  With vast experience amongst us all (we once counted the IT experience in our team of 40+ people to be just over 1000 combined years!)  we all thought we knew what we were doing.

Then we were asked to deliver the impossible.  Everyone agreed we needed to do things differently and re-write our well-thumbed rule book.  So we made a plan with timelines and milestones and phases … in other words the same as before.  Then someone suggested that we try Agile.  Terms like scrum, sprint, standup, backlog, Kanban were thrown around and we all sighed, looked around at each other smugly, but agreed to give it a try – under our breathe we secretly thought it would never work.  We reluctantly agreed that as we were going to fail doing this in our legacy way, we might as well try Agile.

We trained scrum masters, set up white boards, agreed with our client who would be our product owners, trained our engineers in some Dev Ops tooling, introduced some automation and then it happened … OUR LIGHTBULB MOMENT.  We managed to achieve the impossible!

Collaboration with the client was seamless and they even integrated themselves into our scrum teams.  Our staff were learning new techniques and ways of working that broke down the barriers between ‘them and us’.  We removed the blame culture between the separate teams as our scrum teams were made up of designers, analysts, developers and testers – we were all in the same (scrum) team now.  All parties were working together with common goals, learning our lessons every sprint and taking ownership of our own areas of delivery whilst at the same time supporting our team wherever we could.  We recognised when we failed, but we failed fast and we failed together – so we fixed it without the need to produce and approve reams of paperwork to get changes agreed (working software over documentation for the Agile Manifesto purists).  We had the client product owner within our scrum teams and we were making decisions when they needed to be made.  Priorities actually made sense for once.

This was a few years ago now and we are still learning each and every day.  We now talk about how “it’s all common sense really and it’s just what we do”.  We have learned to be pragmatic with Agile.  We do what works for each and every project.  Sometimes we lean towards more purist Agile and other times we take what we need from a number of different schools of thought and adapt to fit the work.  The constant feedback loop is crucial to our success so we can learn and improve at every iteration.

We have happy staff – who have amazing relevant digital skills, who receive ongoing mentoring, training and development in Digital, Agile and Dev Ops.  Our team are now highly multi-skilled.

We have happy clients – who feel part of the process and don’t feel like we are trying to sell them something, but are trying to help them fix their business problems through amazing IT.

This has resulted in a very healthy pipeline of work as our reputation has grown and we are leading the way in how to effectively delivery digital solutions as well as a highly engaged workforce who actually enjoy coming to work.

The advice we usually give to our sceptical friends is …

  • Start small, maybe with one project – don’t try to boil the ocean.
  • Identify a problem and create a one problem statement, so you really understand what you are trying to solve and fix.
  • Use Agile techniques appropriate for your delivery – be pragmatic.
  • Up-skill and Multi-skill your teams, so they can work effectively.  Give them the autonomy to decide the best in class software and tools to use (unless the client has constraints we can’t move) – give your scrum team members a voice.
  • Make the scrum team own their delivery and equip the scrum master to be able to take away the blockers and have leadership who can support the scrum masters and team members.
  • Have a good product owner – we define this in it’s basic form as someone who knows stuff and can make a decision.
  • Have open, honest and transparent collaboration.  The quicker you acknowledge the problem, the quicker it can be resolved.
  • Create an environment of no blame.  If (when) there are failures and mistakes – learn from them and making them a learning opportunity, rather than turn them into an inquest over a failure.
  • Willingly and openly give and receive feedback – listen to your teams – who knows better than those who are doing the work?  I can’t emphasise enough – LISTEN TO YOUR TEAMS !!!!

This isn’t an exhaustive list, we have found it works for us and it might bring you a lightbulb moment too.

man and woman doing high five

Photo by rawpixel.com on Pexels.com