I don't often write blog posts that claim to be life-changing, but this post really is an exception.  Let me start with a story about the "Wiley Old Fox"...well Dr Fox actually.

So about 6 years ago I heard an incredible talk from a very eloquent and charming keynote speaker by the name....yes you guessed it.....Dr Fox.  He presented at the MIcrosoft Ignite conference in Australia and he was very exceptionally entertaining.  Through his elegant story-telling, he put me onto the idea that we should not check our emails first thing in the morning.  Why....because it's makes us unproductive and is a counterpoint to everything agile.  I can see the skeptical look in your eyes...so let me explain further.

Tip of the Week:

Reduce the time you spend checking your email....

So we all spend probably too much time checking out email.  It's often mis-used and it can lead to hours and hours of reading and responding, that often does not lead to huge productivity gains.  I set about putting together some rules, to help fix this up.  These rules have stuck with me ever since. 

I first implemented these rules around 4 years ago when I was working as a Senior Principal Cloud Architect with  DXC Technology.  It was a very challenging senior position, reporting to the global CTO of an offering called MyWorkStyle.  Ali Shadman was his name and he was a fantastic person to work with.....lots of fun!

I had some simple rules for email engagement.  My role was to lead an architecture and engineering team to deploy a private cloud in Australia.  Iniitally problems were aired to me via email and it all became unmanageable, and hugely stressful.  So, to avoid a burn-out situation for myself, and also to ensure that we could meet the 13 month timelines to deploy 12 brand new offerings, alll fully automated with a team of around 25-30 people.... I set about putting some new rules in place for my team and my key stakeholders:

1)  Is it a complex issue and/or is it highly urgent.  If YES - call my mobile.  If I don't answer text me with a summary of the problem.

2)  Is it a YES / NO answer to a simple question.  If YES - use email.

3)  Else, consider using Instant Messaging, i.e. Skype for Business, or Microsoft Teams (which didn't exist 6 years ago).

This was after taking Dr Fox's advice and doing the following at the beginning of each day:

1)  Read your weekly, monthly and yearly outcomes that you wish to achieve.  If you haven't already, you should have these in an Outcomes Kanban.
2)  Write down all the work that needs to be done for that day in a Task Kanban.  If necessary schedule meetings for the next few days.
3)  Then.....check your emails.

If you're not sure what a Kanban is....check out this awesome article below from the Scaled Agile Framework, known as SAFe.  As an instructor I ran the Leading SAFe courses for ALC Training:

:
You'll  find that when you think about outcomes first, and then think about your daily work, you will focus on what is important.  Which should hopefuilly be the outcomes.  This will then put your mind into a state where you're not being driven by emails.

Now....it's quite possible there will be some urgent items in the email that require attention.  Maybe your sponsor needs someething done urgently today or there is a pressing urgent technical issue that requires some attention.  Simple...add 1 task to call your sponsor, and another task to call the person who is raisinig the technical issue.  That's it.  You don't have to spend hours bouncing emails back and forth, trying to solve just those two problems.

What about the rest of your email......well if you're working with your stakeholders effectively, you will have influenced them to follow the first set of rules. Influencing people in a positive way, is probably another blog post....or two.

It took me a few months, but eventually my emails were down to maybe 5 or 6 a day, that were simply YES/NO questions.  All email that I was cc'd in, went into folder.  I also encouraged people not to CC me in stuff, as it wasn't ever going to help.  

Some people think, but that may be useful one day....well if an issue comes up....there are better ways of resolving....than to point to your past emails and said "I told you so".  That doesn't build positive relationships and doesn't help with solution deployment, so why do it.

Feel free to continue the conversation on:

Twitter: https://twitter.com/musiccomposer1

LinkedIn: https://www.linkedin.com/in/paulcolmer/

Instagram: https://www.instagram.com/paulcolmer/?hl=en

Have an awesome day beautiful people.  😎❤
​

I've been running some DevOps, Agile and Cloud Computing courses the past 2 weeks.  A common question that I'm asked...is what exactly is Agile and what does it mean to be Agile.

Simply put...Agile is a mindset...where you're able to take a problem....divide it up into very small pieces...and execute as efficiently as possible using lean flow techniques....agile principles....feedback loops....whilst allowing yourself to experiment, fail and learn to produce a significantly better outcome.

Lean flow is all about eradicating waste....things like shorten waiting times....don't pass defects or problems downstream to the next person....relying less on email and more on face to face communications....as well as experimenting with smaller targeted meetings of 30 minutes or less.

Value stream mapping is a very effective tool for understanding the flow of work between teams.....as illustrated by my fantastics students below:

Finally feedback loops....by asking your client how you can improve...asking your stakeholders their key concerns....automating your tasks....especially tests....and ensuring all your work is visible...especially with a large geographically dispersed team.  Using physical and digital Kanbans are great methods for reminding the team what needs to be done...and also helps to celebrate the wins...especially the small ones.

Students in my cloud security (CCSP) class are using the Kanban technique to derive work that covers some of the top cloud security threats:

What does Agile mean to you?

Many CIO, CTO and business leaders are all working through their cloud strategies.  Most large companies in Australia have adopted a hybrid cloud approach, using both private and public cloud services.  In this blog, I'm wanted to outline  10 critical steps on how you can create a cloud adoption roadmap and then align this roadmap to your current execution path.

​
A cloud adoption roadmap is a really important tool, as it serves to visualise and communicate your plans to all key stakeholders in your organisation.  The important part of the roadmap is to ensure you have a clear 1 page visual outlining the key milestones / decisions points, backed up by clear definitions behind the roadmap of what each component on the roadmap means.  My suggestion is to use a modelling tool to create your roadmap and my top pick is the Abacus tool from Avolution.

Before we delve any deeper into our cloud adoption roadmap, let's be clear on some basic terminology, to ensure we're all on the same page:

Software as a Service (SaaS)
These are services that end-users consume.  Examples include: Social Media Tools, Salesforce, Office 365 and Xero.  The apps that you download to your mobile phone are predominantly SaaS.

Platform as a Service (PaaS)
These are services that developers consume to create SaaS products.  Examples include: Development Tools, Testing Tools and Datastores.  Apps that you download to your PC or laptop at home to allow you to write code, test code and setup datastores in the cloud are all examples of PaaS.
​
Infrastructure as a Service (IaaS)
These are services that operations teams will build, test and commission to support developers, who consume PaaS and end-users, who consume SaaS on the PaaS, or SaaS via a 3rd party.  IaaS can be virtual machines, networking or basic storage.
If you're interested in digging deeper in cloud definitions, there is a simple whitepaper that the National Institute for Standards and Technology have produced.  It covers everything in 3 pages:
nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf

I've also created a simple reference model below:

DevOps
This is cultural change centred around ensuring that the developers (working on PaaS) are collaborating and communicating effectively with the operations teams (working on IaaS).  This is important to create secure, reliable and engaging SaaS apps.

Great video on DevOps from the DevOps Institute:
devopsinstitute.com/certifications/devops-foundation/

Hybrid Cloud
All organisations I have worked with in Australia, that have more than 100 employees will have a combination of private and public clouds in their environment.  This is the definition of hybrid cloud.  Probably 99% will have an on-premise (or 3rd party hosted) private cloud for Active Directory and using public cloud for Office 365  with Azure Active Directory.  The 1% is a single instance of G Suite I have come across. 

Great video on hybrid cloud here:
www.youtube.com/watch?v=_n5Le8aePB4

Now that we have defined these terms, we can take a look at our Cloud Adoption Roadmap and our 10 steps:

1. Perform a current state architecture analysis to understand how each department / business area is already adopting SaaS apps in your organisation.
2. Understand the needs each department / business currently has and develop a feature-centric SaaS cloud adoption roadmap to cover the next 12 months.
3. Communicate and seek feedback with the key stakeholders regularly, to guide your cloud adoption roadmap, particularly as the business investigates and pilots new SaaS apps and develops new business capabilities.
4. Define a clear strategy at the CTO / CIO level as to whether you are going to adopt PaaS and/or IaaS services, or simply remain with SaaS-only services.
5. Ensure your IaaS / PaaS strategy includes key business drivers and evidence of business need.
6. Feed in your IaaS and PaaS strategy into the cloud adoption roadmap and socialise with key stakeholders.
7. Based on business situational awareness and factors that are important to the key stakeholders, embark on a short IaaS / PaaS cloud service provider shortlist selection.
8. Once the IaaS / PaaS shortlist is down to say 2-3 candidates run a proof of concept for each cloud service provider to determine the value, test your hypothesis on how you may transform your legacy IT and seek input from key stakeholders.
9. Extend the IaaS / PaaS proof of concept to a pilot with a single cloud service provider, to further strengthen the more complex hyposthesis you've made with your current legacy IT investments.
10. Extend your cloud adoption roadmap to include how you will transition your current private cloud and/or legacy IT investments to IaaS, PaaS and SaaS services, being cognisant that this may be a 2-5 year journey.

I recommend using the Lean UX method for testing out your hypothesis when validating your cloud adoption plan.  This can be found in the Scaled Agile Framework:
www.scaledagileframework.com/lean-ux/

If you're interested in learning more, I offer a range of Cloud, DevOps and Scaled Agile courses at ALC Training:

Cloud Courses (Foundation to Advanced)
www.alctraining.com.au/courses/cloud-computing/

DevOps (Foundation to Advanced)
www.alctraining.com.au/courses/devops/

Scaled Agile
www.alctraining.com.my/safe-scaled-agile-spc/
www.alctraining.com.au/course/leading-safe/

Scaled Agile Framework, or SAFe for short, is a large interactive knowledge-based of best practices, case studies, courses and toolkits.  The patterns and resources are proven, backed up by numberous case studies.  It is specifically designed to work for very small businesses, right through to multi-billion dollar corporate giants.  How does it do that? 

Well there are a number of components that allow the method to scale.  This includes a list of the key principles, outlined above, but also used the concept of Agile Release Trains.  These are teams of teams, containing all your resources, including suppliers and partners, that are co-ordinated through program increment (PI) planning.  These planning sessions ensure all the trains are moving in the same direction and that all the work is decomposed into features and stories.  This results in working code shortly after the first sprint.

The framework itself comes in four flavours:

1. Essential SAFe
2. Portfolio SAFe
3. Large Solution SAFe
4. Full Safe

The order and selection of the above configurations is highly dependent on the organisation's vision, committment and maturity to adopting Agile.  Below are all the frameworks for comparison.

Still not convinced.....well there are a wealth of case studies on the SAFe site:

www.scaledagileframework.com/case-studies/

Below is are a few of my favourites:

Want to know more about how to use SAFe?  Please check out my Leading SAFe 2 Day Course.  Please let myself or ALC Training know when and where we can run this course for your organisation: