A Story of DevOps

After 2 years of implementing the philosophies and practices of Agile and DevOps, I felt it was time to share my learning and experiences with the world.

Firstly, it’s important to note that DevOps is not the end game, what we aspire to do is add value and as a business the primary goal is to make money (The Goal, Goldratt). DevOps is a cultural mind-set underpinned by the philosophies and practices of Agile which is built on the philosophies of Scientific Management, Deming Cycle, Lean, Six Sigma, Scrum, ITIL, high performance teams and human psychology. Getting to 100’s of deployments a day is not the end game, creating a business environment that can respond and adapt to the changing market is.

From all the research conducted (and I’ll share some of my references later), I found some basic principles here;

1. Business performance is predicated by IT performance. IT Performance is predicated by Organisational Culture. Gartner says that every business is a software business and the last three State of DevOps reports (PuppetLabs) call out the relationship between Business, IT and culture.
2. People need three key things; Believe, Belong and Be Productive, Scrum (Sutherland) talks about being part of a transcendent purpose, we all need a common purpose or shared goal. We are communal beings and need to be in relationship with one another and generally people want to make a difference, to go home knowing they have added value.

With the philosophies, principles, manifestos and practice of DevOps, Agile and Lean Six Sigma, we have significantly improved the delivery of our back office systems which include SAP, SuccessFactors, ServiceNow, Salesforce, SharePoint, Cognos and our homemade applications. The impact across our business has been significant. Some of achievements include

1. Simplification of the operations of one of internal business groups which has led to increased profitability enabled through a consistent flow of changes in SAP, Salesforce, Cognos, SharePoint and homemade applications.
2. Consolidation of multiple systems, greater integration of business functions and processes and improved cost and efficiency of IT and Finance processes through the implementation and exploitation of ServiceNow
3. The modernisation and simplification of our company HR processes enabled through the implementation and exploitation of SuccessFactors

Gene Kim wrote the Phoenix Project which is a book about how our traditional delivery mechanism didn’t work and that a different approach was needed, learning from the manufacturing industry. Although the book is about DevOps, it does not really badge the use of DevOps, Agile, Lean, Six Sigma, etc. practices – instead it calls out the principles that apply to teams and processes, building on the Goal and the Theory of Constraint. It’s the application of what we see in the retail and automotive industries every day, only its applied to complex invisible work. I always wondered why the book was not written about video streaming, audio streaming, search or online shopping services – it was written about a supplier of car parts using sales ordering and procurement systems – an ERP eco-system. This is what hit home with me – I am sure Netflix, Google and Etsy are the Unicorns of DevOps but the book was written for me!

3 years ago we delivered about 50 to 100 changes per annum across about 80 business systems, all of which we managed using our standard structures and practices. Change was difficult and the transition from project to service was painful. I lived the opening chapters of the Phoenix Project on a regular basis. I remember saying to my wife on one of our Saturday morning lie-ins which generally involve coffee and a good book, “read this, it’s like my actual life” – she did not take me up on my offer but the story was compelling enough for me to want to change. From that moment on I was Bill.

I manage over 100 business systems but we categorised 8 of these as Products e.g. ServiceNow and we put Product Teams around them. These are teams that build and support the Product. As a result, we delivered over 2500 changes across the products whilst at the same time improving the service by 30% (with all service KPIs exceeding stretch targets in the last quarter), improving customer satisfaction and employee morale. Using the “you build it, you support it” (Amazon) mentality, change is no longer a big event but a normal everyday occurrence and the usual spikes of incidents are no longer there, in fact with each change we deploy, the incident volumes reduce! Teams are not only delivering new features but are cleaning up their code and config and removing technical debt with every release.

And guess what – we have done this with very limited automation. Most of our delivery is still manual (testing, release, deployment, etc.). We have automated our regression tests for ServiceNow but we are still far away from Test Driven Development and Behaviour Driven Development.

I think the benefits of DevOps are widely known and chasing the Unicorn is becoming a widespread hobby for the IT community. I do not profess to have found the unicorn, possibly the odd Horse or Rhino but no Unicorns. I like the fact that DevOps does not have a definition and I am not going to propose one – It’s about the philosophies and principles that underpin human behaviour that inspires me – it sets out the ground rules that help build a solid foundation that skyscrapers can be built from. We have only probably reached the 3rd floor of the skyscraper and now we need different equipment that was used for the foundations and the first 3 floors – our challenges have changed. I don’t even know how many floors there actually will be!

From a personal perspective, as leader of this initiative, in 20 years in IT in a large blue-chip corporate environment, I have never felt so vulnerable and isolated at times but I also have never felt so proud and connected. Making the change in an organisation with over century’s worth of heritage as well as the amalgamation of different cultures from different organisations acquired under a federated business model has been extremely difficult. Together with walking down a new path with uncertain outcomes, limited organisational understanding and no plan was not easy. This was further compounded by that fact that the new practices expose all the issues in the way we worked. At first I thought they created the issues and it took a while for me to realise the issues were always there. In a factory, the constraints and issues are more visible, in IT much of what we do is invisible. When you make the invisible, visible, you have to deal with what you see.

So, how did we build the foundations and the first 3 floors? Key to the success so far are:

• Executive Sponsorship
• Time
• Product Teams
• Training and Education
• Visible Workflow
• Definition of Done and Acceptance Criteria
• Visible Workload
• Practices and Ceremonies
• Improving the Flow
• Customer Engagement
• Estimation and Velocity
• Engineering Excellence
• Automation

Executive Sponsorship

We had sponsorship at senior levels of the organisation, even before we really knew what we were doing. Gaining understanding that this is a cultural transformation and that, as per the Goal and the Phoenix Project, we had to work this out the path we needed to take ourselves. This was not something we could ‘buy’ or ‘copy’ – this had to be our own journey. We had one sponsor in particular who could read and absorb faster than I could and he championed the movement from the top. This would not have happened without this level of belief and trust.

Time

As part of our initial thinking, we developed a business plan which included the structure and approach we would take. This involved educating ourselves, working with the right coaches and the tools we needed to monitor and measure. When challenged with what we needed to achieve this, my response was education and time. We are 2 years in and there is still a long way to go – when we visited one of the Gartner hosted DevOps workshops in 2015, one of Lego’s chief architects stated that it took them 3 years to achieve the results they were seeing at the time. 3 years feels like the right amount of time before one can expect a mature transition to have occurred.

Product Teams

We set up teams around our Products. New roles were created like Product Owner, Product Technical Lead, Product Delivery Lead, Product Engineer, Product Analyst and Product Administrator. A key differentiation from standard Agile roles, is that these role not only build the product but support the product. So the Product Owner not only owns the requirements but is the owner of the service and the associated service performance. The Product Delivery Lead is not only scrum-ready but can navigate ITIL, Kanban and Waterfall effectively.

Wherever possible, we co-located these teams and provided them with access to wall-space, Agile tooling and piles of post-its.

Training and Education

We invested time in ourselves and in our teams. I have provided references to the books and articles read and we engaged with Emergn and DevOpsGuys who provided education based on Value, Flow and Quality (VFQ) and at elbow support in our day to day operations – coaching us to think differently.
We took our teams through this and we engaged with our customers throughout this education.
As part of our journey, we also established a DevOps Academy and we ran multiple cohorts of education and we sat alongside teams around the country and internationally to help others get started on the journey. They say that the best way to learn is to teach – this definitely helped us to consolidate our learning.

Visualising the Work

So, we had executive sponsorship, time, training, established new teams and we started receiving coaching – but what was going to be different?
We took one of the teams and we found some wall space. We created some columns; backlog, sprint backlog, define, execute, release and done. We then filled out post-its to capture all the work the team were currently doing and we put these in the right columns. We then decided we needed a definition of done and wrote this up on the board and we needed a way of tracking progress of all the work so we marked each post-it with an ID, priority, owner, description and expected due date.

The result was magnificent. We could now see all the work, which state it was in and what the priority of each item was. However, there was a lot on the board. This is where all the questions started; what is work? what constitutes a post-it on the board? who decides the priority? what if something urgent comes in? etc. We did not have all the answers, but we created an observations board and we wrote down the things we did not know. The key thing was that we could see all the work – the invisible had become visible.

However, we had no idea if what was on the board was really valuable. So, we commandeered some more wall space and posted our team vision, goals, objectives and categorised the delivery outcomes into the changes we needed to make and packaged these up into releases. The work on the Kanban board now needed to be related to one of the releases – we now had a reference point for all the work.

Practices and Ceremonies

We had learnt about the ceremonies of Scrum and we decided to adopt these the very next day. So, our stand ups started and we scheduled in Sprint Reviews, Sprint Planning Sessions, Retrospectives and Backlog Grooming sessions. We decided that our Sprints should be 2 weeks which was enough time to get an appropriate level of work done.

We tailored our stand-ups – we stuck to the 15 mins but we started from the right lane on the board and worked backwards until the 15mins were up – this forced us to finish the work that was started and we got this work to ‘done’. Our key question, if we could not move a piece of work was ‘is there anything blocking progress?’ – If there was then we would find a way to unblock the work. It also got us away from the ‘what we did yesterday/today’ conversation and focussed us on what really matters.

We also initiated Sprint Reviews, Sprint Planning Sessions, Retrospectives and Backlog Grooming session. We took these pretty much as the Scrum defines them with each team modifying slightly to fit their rhythms. e.g. Some teams do 4 week sprints and some do 2 weeks. Some teams have multiple squads, some only have one.

The key challenge was people understanding the value of taking a day out every couple of weeks or so. It soon became apparent that people had a lot to talk about and lot to understand. There is a lot of stuff not said when working and if you are part of a team, regular refreshers on what the goals are (long term and short term), where we are against the goals and how we are performing against the measures help the team focus on what’s important and help them understand the context for the work. Every team need alignment and empowerment. Without these together you have a dictatorship or chaos.

Improving the Flow

A big list with some meetings is great for visibility, prioritisation and unblocking issues but it does not really help with improving flow. You need more than a Kanban board. We started to apply Work In Progress (WIP) limits to our Kanban states and we visualised the movement of work using a cumulative flow diagram. This is key – if not, critical. By introducing WIP limits you start to see where the blockages are.
We found that if your lanes become full, you cannot bring new work into that lane, so you need to move its state – that’s where Swarming comes in where the team work together to get the work shifted. There may be many reasons why work does not move – maybe it’s too big, maybe we are waiting for people outside the team, maybe someone sent an email… and is waiting for a response. Breaking the work down, bringing people into the sprint and picking up the phones were some simple ways of moving work from one state to the next.

We also created cumulative flow diagrams which essentially was a graph of how pieces of work were moving each day. Initially we have flat lines and spikes which demonstrated a lack of flow but as we broke the work down and challenged the constraints the lines become smoother with a gradual increase. We could also tell whether we had the right velocity based on the rate at which new work was coming in versus the rate at which work was getting done and which lane resulted in the greatest bottlenecks.

As we progressed from a more Kanban-style of work to a more Scrum-style, we are now using sprint and release burn down charts to help us identify where our constraints are. However, in some teams, although we have moved to Scrum, we have modified our practices to also include WIP limits to help improve the flow of work.

One of the big challenges for us was how to factor in capacity for unplanned work. We recognised that there are 4 types of work (as per the Phoenix Project); Business Projects, Internal Projects, Change and Unplanned Work. Locking a sprint down for Projects and Change was relatively straight forward – however, Unplanned Work was more of a challenge. So, we used a technique called yesterday’s weather – what happened last sprint, what happen in the same sprint last year, etc. and we assigned capacity for the unplanned work. We also put in the mantra “Service is King, Change is Queen” – We have to serve the service first – if incidents come in, SLAs must be met, requests must be fulfilled before Change is delivered. What this did was drive a focus on better service and also made us think about the technical debt we were carrying – we started including stories / changes in our backlogs that were focussed on technical debt removal. Less technical debt resulted in less unplanned work which resulted in more capacity to deliver change.

This all comes from understanding the flow of all the work and working together to optimise the whole system not just part.

Customer Engagement

This has been a challenging journey as we were clearly learning how to think and behave different. In some aspects we tried to do this separate to the customer engagement. What we found worked best is where we go on the journey together with the customer – in partnership. Now, this is where challenges with tradition waterfall contracts, expectations and project phases, etc. take their toll. I probably need to write a separate article on this. Essentially though, it’s really hard to do Water-Scrum-Fall and I have the sleepless nights, grey hairs and scars to prove it. Agile needs to be all in and it’s not just about Software Development – it’s about business agility.

Product Owners need to be seen as a business partner, an advisor and collaborator – the customer needs to be embedded in the team and take just as much responsibility for delivery – all the people doing the work should be in the team, irrespective of the organisation they sit in – and this requires trust and an understanding that we are going on the journey together.

Working with the customer, we now need to prioritise the requirements, we need to batch them up into releases that deliver value incrementally (which in itself is a massive challenge on our ways of thinking) and we need clear prioritisation. We then need to agree and deliver the minimum viable product and allow time for enhancements and exploitation. We also need a healthy backlog of requirements with an understanding that we are simply not going to get more resources to get more work done – sometimes we may need to burst capacity to do more work but not at the end of a project and not to the detriment of the performance of the whole team.

Estimation and Velocity

A lot has been written about estimation and I am not sure we have really cracked this yet. Research shows that we struggle to measure in hours but we are much better at relative estimation. In our organisation, like many, we work in time and cost – our business cases and product and project funding structure requires a view of the cost of a piece of work – this normally is calculated by time multiplied by rate card. All our systems are geared to recovering based on hours available, hours consumed and utilisation – like most organisations. So, at some point we have to convert our estimates to hours and we have to track and bill against the hours consumed. The business case is then defined by the cost of doing the project versus the benefit realised.

Therefore, if inherently the research says that estimating in time does not work but our business operates on time as time is money – then how do we harmonise the ability to estimate using alternative means alongside understanding the time and cost equation?

Firstly, now that we have Product Teams that stay together and work together, we understand the capacity of the team in hours and we have a much better idea of productivity – e.g. the team has 5 people, who typically work 8 hours a day but we find that the actual productive time in a day is 6 hours – that gives us 150 hours of productive time in a week – 300 in a two week sprint. Secondly, we also have experience as a team of estimating together. Inevitably the estimates improve as more work is conducted – which means that as a team, our estimates based on time and cost will get better. Thirdly, we know the cost of a sprint as we have a fixed team – therefore, we can work out how many sprints and therefore what the cost is of the overall project. We can also, based on history, work out what contingency is needed by estimating how many sprints may be needed if things go wrong.

However, this still does not work as effectively as it should and so, over the last year, we have introduced relative sizing and story points into the team – This starts with defining a reference point – a story (or feature) that is the least complex thing to do – this becomes our reference point for 1 story point. The teams may also create a number of other reference points at 3, 8, 13 and 55 story points. We also use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, etc.) as the more complex the work, the harder it is to accurately estimate. Using this method, we soon can determine how many story points a team can deliver in a sprint – this becomes our velocity, story points/sprint. Now, when we estimate a new piece of work, using tools like planning poker where collective estimation is done across the team, we can size the piece of work at story, epic and theme level. So, let’s say we have a piece of work that takes 1000 estimated story points and we have a sprint velocity of 100 story points per sprint, we know that the work may take 10 sprints to complete – if the cost of a sprint is £20k – we can estimate that the work will cost £200k.

One of the principles is that we are trying to break work down and during the course of the sprints, we are delivering value to the customer and responding to feedback – we are also using tools such as bur down charts to understand if we are progressing as per estimates and we are actively addressing constraints and blockages. This progress also helps with the estimation as we are able to receive constant feedback on how the work is progressing and adjust / course correct as appropriate.

Needless to say, we delivered a significant proportion of the 2500 changes in 2017 as per our estimates.
Engineering Excellence

People think Agile means no documentation or no processes – in actual fact, there is a lot more discipline needed. Just as in the manufacturing and retail industries, we have to the thing about the disciplines, structures and processes that are needed to create and deliver a product using invisible inventory. Collins in his book Good to Great talks about Disciplined People, Disciplined Thought and Disciplined Action. Bezos transformed Amazon from a loss-making business to the what it is today after speaking to Collins.

Over the last couple of years we have focussed on removing technical debt by cleaning up code and configuration, upgrading our platforms and simplifying workflows, permissions, etc. This then results in a more supportable solution that is easier to change. Over the last 2 years, we have seen a 30% reduction in incoming incidents and we have increased the rate of change three-fold. Going into 2018, early signs show that the upgrade work we did on some of our platforms in 2017 have resulted in further reductions in incoming incidents – less unplanned work has resulted in greater value delivery.

This is an important point actually, in the traditional models of plan, build and operate silos, there is no real incentive to improve – if you support an application and the incidents reduce, you may feel that your role is at threat. If you are a developer and you finish the code earlier, you may be released from a project early and have nothing to do or get put on the bench and if your code is bad, it doesn’t matter, someone else will pick it up in support. In DevOps, Product-Centred thinking results in engineers wanted to remove incidents so that can do more work on projects and to finish projects early and to a high standard so they can work on enhancement and innovations – suddenly, by staying with the product, you become proud of your work, the customer experience and the value delivered.

In addition to this, we have been working hard on our engineering architectures and methods – spending time thinking about the architecture in terms of what will deliver value, performance, high customer experience in a supportable, secure and easy to change way is what Product-centred thinking is all about. It’s not just about delivering a solution that meets a customer requirement – Product Teams have a lot more to think about and the engineering that sits behind running a Product demands more thought.

We also look at our methodology – how are pipelines built, how are requirement captured, what does good look like, what does ‘done’ mean, how are we going to design and build, how do we test and verify and how do we get the value safely to where it is consumed. We also think about how we monitor and manage the product including patching, upgrades and the application roadmap. We have taken Product Engineering Plans and Service Management Plans and combined these into a Product Engineering Plan. Then we apply our standards and structures in our workflow management tools, be that a Kanban Board, Jira or ServiceNow. We have then spent time looking at our coding standards, regression test packs, deployment processes and have tuned these, removing constraints where we can, simplifying through engineering and focussing efforts on where the value is.

As you can appreciate, in an Enterprise, there are lots of interfaces with other IT services (networks, hosting, end user compute, other applications) which means running a Product needs to be delivered in context of the wider estate – we have a lot more to do to improve our architecture and engineering practices but we have made some positive steps and are seeing the benefit through service improvement and increased high quality change.

Automation and Orchestration

With the little I have read on the Theory of Constraints, we have been monitoring a number of key performance measures which include Priority 1, 2 , 3 incident SLAs, availability, incident and request volumes and turnaround, customer satisfaction, budget performance, throughput of change, cycle time, lead time, story point velocity, team size and composition and morale. We also monitor progress against projects and alignment of all the work to the share product vision and objects. This is captured and shared internally and with customers using an A3 Balanced Scorecard (something I borrowed from reading the Toyota Way) – this gives a great perspective on the health of the service and allows us to focus on the areas that need attention. More importantly, it give the team visibility of their targets and gives them pride in delivering to their agreed goals.

This provides us with a lot of actionable data and we can now see where the constraints are. We can also see the direct impact of improvements that have been made. What we have found is that before we get to automation, there are we needed to improve the architecture, remove the technical debt and improve our working practices and engineering methods – cultural change with the right practices and a focus on engineering excellence can significantly improve the performance of team and quality of a product.
However, we now know that over the 2500 change delivered, we can build and unit test a new feature on average in 10 days (which incidentally is the duration of our sprints) – however, on average changes take 60 days to deliver a new feature from when we include the work into a sprint to when it is delivered into Production – it takes about 20 days to define what we need to build and 30 days to release the value to production, on average. The changes delivered last year vary from large releases that replaced legacy systems to small enhancements – however, we can tell that agreeing what we need to build takes time, as does regression test, integration tests, user acceptance testing and the governance checks before production deployment is conducted.

We have experimented with one of our teams and have automated the regression test pack and have seen some really positive results – we are about to expand this across a number of other teams. For most of our Products deployments are already automated so test and deployment can be automated and save days from the lead time. We have also started to work closer with customers and perform user acceptance testing together but we need to start thinking about test driven development so that we can build the end-to-end build, test, deploy process. We will need to build our governance processes into the automation so that we can deploy to production from our development environments without human interaction, safely and securely – I would like to think that we can take the 30 days release time and reduce this substantially whilst improving the quality of the product released.

Watch this space in 2018.

Retrospection:

At the beginning of 2018, we had a retrospective with the Product Teams and with all the data visible, we came up with a number of themes for improvement for 2018. These include;

• Customer Engagement
• Agile and DevOps Contracts
• Technical Development
• Automation and Orchestration
• Engineering Excellence

Customer Engagement;

We still have an internal customer/supplier engagement model. We have some good experience of working collaboratively with customers, building credibility and trust but we have more work to do here – part of this is about bringing the extended team together and focussing on delivering the value quickly and safely through working through requirements together, testing together and managing the change to the business together.

We also want to want to take this further by understanding our customers outcomes and processes better and the performance indicators they use – we can then look at the constraints and handoffs in their environment and automate these using our Products – There are examples where multiple people run business processes over multiple days which could be achieved our Products with less effort, better customer experience and much faster. By the end of 2018, I would love to have more of these stories to share.

Agile and DevOps Contracts

Our contracting is still based on the tradition requirements-solution-time-cost basis with largely Time and Materials based contracts against a set list of deliverables underpinned by a business case.
I don’t have the answer to this yet but there must be another way to contract for Agile Projects where the focus in the delivery of value based on a collaboration between us and the customer. I feel like we should agree the Themes and Epics of what we are going to achieve, and set out a high level plan based which results in the need to work together over a number of Sprints but on the basis that we accept change based on learning during the engagement and we will deliver the highest priority features first – We may not deliver all the features initially anticipated. This requires a culture change between us and the customer and a stronger relationship between our customer and their customer – this is where Agile is not just a software engineering thing, it’s organisational-wide thing. We have to take the principles of Agile and apply them to the whole organisation.

I have a number of examples of what I would call DevOps contracts where our customers pay a total cost of ownership of the whole product; infrastructure, licences, support and enhancement – this results in a team with all the roles and capacity to run and exploit the Product through life. The principles of engagement above still apply and there needs to be that continued level of trust that we will build and support the Product as efficiently as possible. This type of contract really helps the cultural aspects of Engineering Excellence as detailed previously.

Engineering Excellence

With Software/Platform as a Service products, there is a need for continuous learning – I am keen to continue developing our teams so that we have technical excellence in our teams. In the traditional model, I was frustrated as our customers knew more about our products than IT did. I firmly believe that IT needs to influence business performance and we should be trusted advisors to our customers. We should also be able technically support and change our Products – in the past, we have paid high prices for external help which we should be able to do ourselves. One of the biggest challenges with projects is that all the valuable experience that is built during a project is lost when it transitions to support – With a DevOps model, this does not happen as the knowledge and experience is retained and re-used.

Peter Drucker talks about the productivity of the knowledge worker being a key concern in the 21st century and as a result I believe in developing people who have the knowledge and experience and protecting their thought processes and time so they can deliver value in the right environment.

Automation and Orchestration

As mentioned before, we are keen to progress with automation this year and we have plans in place to focus on testing but we will be looking to integrate this with build and deployment processes this year.

Closing Thoughts and Wider Implications

I am really proud of what has been achieved by the teams. 3 years ago, we did 50 to 100 changes per annum – we now do over 200 per month and we have made change normal – in fact, we are still not doing enough – this is a testament to the change across our customer base as they have seen the value of incremental change through Product Teams dedicated on delivering value.

We are now doing more whilst improving our services demonstrated through customer and user satisfaction, significantly better service level performance and reduce unplanned and costs for service.

However, DevOps is not the goal. Agile is not the goal – we have optimised the delivery of IT Products but this is not the ‘whole system’ – Goldratt says optimising anything other than the constraint is a waste – the goal of a business is to make money and just making IT better, although a significant contributor, does not lead to better business performance. I can deliver great services and provide faster high-quality change, if the things I am delivering are wrong in the first place, what use is it? – we need to consider the whole system and make sure that we are changing our systems to deliver business value. This is the challenge I have over the next couple of years.

Any insight or contribution from the community would be most welcome.

References;

This is a subset of the research conducted which I pulled collected in video-form as part of the DevOps academy we launched last year. I would recommend the books mentioned below.

It is important to note that although sharing is really important, copying something that works for someone else is not necessarily the right thing to do – your organisation, your environment, your people are different to mine – take the philosophies, principles and practices – learn and adapt. This was the biggest challenge at the start of the Phoenix Project – the organisations ability to adapt to the external market.

Create a learning environment provide the generative culture environment to enable your people to be the best they can be.

The importance of a learning organisation
Fast Learning: https://www.youtube.com/watch?v=zatL4uFRpC0

Learning Organisations 10mins: https://hbr.org/2008/03/is-yours-a-learning-organization

5 mins. https://www.youtube.com/watch?v=izkXtw1tDeg

70:20:10: https://www.youtube.com/watch?v=t6WX11iqmg0

Learning Styles: https://www.youtube.com/watch?v=bYyVWBJn59g

Learn something new fast: https://www.youtube.com/watch?v=EtJy69cEOtQ

Scientific Management – 1911
What is it 8 mins: https://www.youtube.com/watch?v=dsnMjVBYNE8

Ford 7mins: https://www.youtube.com/watch?v=8PdmNbqtDdI

Six Sigma 3 mins: https://www.youtube.com/watch?v=SAfCxubyipk

Six Sigma 4 mins: https://www.youtube.com/watch?v=wSZOsimeB5Q

Lean Engineering 90 secs: https://www.youtube.com/watch?v=wfsRAZUnonI

Deming in 60 secs: https://www.youtube.com/watch?v=e4gOPeHSRo8

Systems thinking 7 mins: https://www.youtube.com/watch?v=lhbLNBqhQkc
Toyota way 3 mins: https://www.youtube.com/watch?v=42C2JL-SZ64

Thinking Globally: https://www.youtube.com/watch?v=jU2iWZEYbKA

Book: The Goal: https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp/0566086654

Seven Habits 7 mins: https://www.youtube.com/watch?v=ktlTxC4QG8g

Tuckman model 5 mins: https://www.youtube.com/watch?v=OhSI6oBQmQA

Tuckman in practice: https://www.youtube.com/watch?v=1QvGUjJrRLQ

The effective executive 7 mins: https://www.youtube.com/watch?v=UVYg6qQ2YK4

Transactional Analysis 10mins: https://www.youtube.com/watch?v=nKNyFSLJy6o

Our roles as Entrepreneurs, Vision, Steer, Accelerate
3 mins: https://www.youtube.com/watch?v=9bPgNEDdX3E

10 mins: https://www.youtube.com/watch?v=Sk9X8JscUh8

19 mins: https://www.youtube.com/watch?v=inS0b_rrehc

Book: https://www.amazon.co.uk/Lean-Startup-Innovation-Successful-Businesses/dp/0670921602

Engineering Culture

Part 1: 13mins: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

Part 2: 13 mins: https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/

Book: Google: https://www.amazon.co.uk/How-Google-Works-Eric-Schmidt/dp/1444792490/ref=sr_1_1?s=books&ie=UTF8&qid=1463829711&sr=1-1&keywords=how+google+works

5 Whys:

3 Mins: https://www.youtube.com/watch?v=JmrAkHafwHI

ITIL

ITIL in 100 secs: https://www.youtube.com/watch?v=s4VH0A687lg

Simple explanation 4 mins: https://www.youtube.com/watch?v=vBguassbAzo

ITIL Lifecycle 11 mins: https://www.youtube.com/watch?v=M9sMPBmw9Yw

ITIL Foundations 1 hour: https://www.youtube.com/watch?v=kOwVBm0wv9o
About: https://www.axelos.com/best-practice-solutions/itil

ITIL Certifications: https://www.axelos.com/qualifications/itil-qualifications

ITSM Career Path (login required) : https://www.axelos.com/enhance-your-skills-with-axelos/career-paths/itsm-careers-path
Incident: https://www.youtube.com/watch?v=8cctLnKdEfo

The Stars 3 mins: https://www.youtube.com/watch?v=2oL3LdrCBa0

Finlay Fox 5 mins: https://www.youtube.com/watch?v=0jLpjwEdaU4&index=3&list=PLrAaLLVVONAxWYEuCq60OsYEnOMo1FAqM

DevOps:

About: 5 mins: https://www.youtube.com/watch?v=wwTR2urq89c

7 Mins Intro: https://www.youtube.com/watch?v=_I94-tJlovg

Book: Phoenix Project: https://www.amazon.co.uk/Phoenix-Project-DevOpsHelping-Business/dp/0988262509/ref=sr_1_1?s=books&ie=UTF8&qid=1463829776&sr=1-1&keywords=phoenix+project

evOps, ITIL, Processes and Architects: K16 – https://youtu.be/4yVp8RNOB6s

DevOps – https://www.youtube.com/watch?v=CSrKwP1QrjE

Real thing? http://www.theregister.co.uk/2016/07/07/is_devops_a_proper_thing/
Understanding: https://www.youtube.com/watch?v=HpZBnc07q9o&list=PL-u6s3rs05hUuEe4bLahtULFGQZXruAoq 6.12

DevOps with Kim 24.35 https://www.youtube.com/watch?v=877OCQA_xzE

Scrum:

7 Mins: https://www.youtube.com/watch?v=9TycLR0TqFA

10 mins: https://www.youtube.com/watch?v=XU0llRltyFM

Book: https://www.amazon.co.uk/Scrum-Doing-Twice-Work-Half/dp/038534645X

Scrum Guide: http://www.scrumguides.org/scrum-guide.html

Scrum Book review: https://hennyportman.wordpress.com/2015/03/08/book-review-scrum-the-art-of-doing-twice-the-work-in-half-the-time/

Scrum Takeaways: http://topquestionsandanswers.com/home/2016/3/12/gok3merymr6oz7qub2iv41b8o6mmn7
Neuroscience: https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=video&cd=1&cad=rja&uact=8&ved=0ahUKEwiTqvechNXNAhWnI8AKHdpEAJUQtwIIJTAA&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dx6PSTHuvNQ8&usg=AFQjCNGspcEU5nr7fB0gafpnsxUzlAyxMg&sig2=EgUlE2Psj1Lxu0QKkfcGGQ&bvm=bv.126130881,d.ZGg

Neuroscience: http://www.methodsandtools.com/archive/agilefacilitation.php

Scrum Brain: https://www.infoq.com/articles/brain-scrum-maza
https://www.infoq.com/articles/neuroscience-agile-leadership

Checklist:

Structure of Scrum 5 mins: https://www.youtube.com/watch?v=O7cA1q0XwhE&list=PLD5EMbfkdP1Q-RYbyoj6S7MUpXXCVpmjz

Kanban:
4 mins: https://www.youtube.com/watch?v=R8dYLbJiTUE
Kanban: Book: https://www.amazon.co.uk/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402/ref=sr_1_1?s=books&ie=UTF8&qid=1463829651&sr=1-1&keywords=kanban

Roles:

Product Ownership: 10mins: https://www.youtube.com/watch?v=502ILHjX9EE
Product Owner: https://www.youtube.com/watch?v=3eljozEWpf8

Scrum Master: https://www.youtube.com/watch?v=QbPkcfzi2HI

Ceremonies:

Daily Stand Up: http://scrumtrainingseries.com/DailyScrumMeeting/DailyScrumMeeting.htmRetrospectives 2mins: https://www.youtube.com/watch?v=-hnD43Gs_ys

Retrospectives: 3 mins: https://www.youtube.com/watch?v=BDlyS8nh6GI

Retrospectives Book: https://www.amazon.co.uk/Agile-Retrospectives-Making-Pragmatic-Programmers/dp/0977616649

Happiness Ratings 2 mins: https://www.youtube.com/watch?v=mBrWcqWECUU

Sprint Review 3 mins: https://www.youtube.com/watch?v=2Jhf7PcYrzY

Measurement

Burn down Chart explained 3mins: https://www.youtube.com/watch?v=rUJsqEHRcJA

Burn down Chart understood 4mins: https://www.youtube.com/watch?v=HV76WzqpSI0&index=7&list=PLD5EMbfkdP1Q-RYbyoj6S7MUpXXCVpmjz

Cumulative Flow Diagram: http://kanbantool.com/kanban-analytics-and-metrics