Employees don’t need titles, we need clear-cut duties, responsibilities and boundaries

you can create fancy titles all you want but it will just lead to stress and unproductive time spent thinking “wtf does this title mean?”
this is a people WASTE in terms of LEAN, see (unclear reponsibilities)
in contrast if we give people answers to the ff: we will be more productive instead of letting the person discover all of these by chance, like maybe within a few years.

  • what is my high-level goal (unless you are the CEO, your superior should set this with you) ?
  • who do i report to?
  • what group do i belong?
  • what tools/resources are at my disposal ?
  • who reports to me ?
  • up to what part of the system is under my control (or who else shares control over portions of it) ?

People like working for things they are passionate about, things where they know how they could be of help.
We need more of those instead of the “anti-stress” features such as a fancy pantry or free snacks.
we can elimininate that stress before it even begins.

What is DevOps? (what is this buzzword really?)

What DevOps is not

it is not a team or role

It is not about having an internal third party setup where you ask a “DevOps” team for systems administration stuff because your project team does not know how.

What are signs that DevOps is not implemented?

you “handover” a lot of tasks (it’s much more evident if you actually use the word “handover” during task transactions, and NO changing the term to a synonym still won’t hide the fact that you are not practicing DevOps

What DevOps is

it is a discipline, a mindset, a way of working.
It is a paradigm you can use to view how you define workflows/roles/responsibilities within your software development teams

DevOps is about equipping your self-organizing project team with the skills and tools to fulfill their role of delivering value to the customer from product conceptualization, development, deployment, and continuously ensuring that the customer is getting the value all the time.

What about tooling?

Of course there is a baseline of skills/tooling that is required for a team to be able to work the “DevOps” way.
The team needs to have

  • mastery on Cloud Service Providers (AWS, GCP, Azure)
  • mastery on Linux Operating Systems
  • mastery on the Application Tech Stack e.g. php+mysql+nginx, javascript+react+node, react+python+flask
  • mastery on automation tools e.g. Automation using scripts like bash or python, Configuration Management tools like Ansible, Cloud Resource Provisioning tool like Terraform or Cloudformation
  • mastery on Automated Testing, understanding and implementation of linters,unit tests tools, UI test tools, Performance monitoring tools for the application tech stack.
  • mastery on Systems Design like Microservices, Autoscaling and Loadbalancing etc.

These skills/tools need not to be on a single person (and it should not).
Having these masteries singled-out to a single person is a sure fire way to achieve a very low BUS FACTOR

What can I do to achieve DevOps within my project team?

  • either find people who has the right DevOps mindset or find open-minded people within your team to study the discipline.
    • be sure to avoid dogmatic people at this phase, some people pretend they know it but act otherwise.
    • this role could be the DevOps evangelist within the team, much like the role of a Scrum Master in a team following the Scrum Framework of Agile Methodology
    • the DevOps Evangelist shall then train the other members of the project team to grow their Server Administration skills.
  • find people with high mastery on tools/skills listed above or grow multiple people within your team.

The right Mindset is crucial before you slap on the technical skills,

Here’s what a sample Self Organizing Development Team could look like

  • Developer (90% programming, 10% systems administration)
  • Developer (50% programming, 50% systems administration)
  • Developer (30% programming, 70% systems administration)
  • Product Designer(s)
  • UI|UX Designer(s)
  • Quality Assurance (Automated)
  • Quality Assurance (Manual, for Exploratory testing)

Notice that there is no “DevOps” role, just a bunch of programmers who know their shit up to production.
Programmers like these won’t be the types that tell you “But It works on my machine!” or “It aint my problem” or just get blocked whenever they see an error in production.
They have higher skills since they know how the application behaves in production and thus, are able to create better applications.

Other References

DevOps as defined by atlassian

This very popular DevOps skillset roadmap from github (kamranahmedse/developer-roadmap)

DevOps as explained by an Openshift Evangelist

Four types of Office waste according to LEAN management

LEAN – https://en.wikipedia.org/wiki/Lean_manufacturing
Get your Introduction about L.E.A.N in under 17 minutes

8 wastes of LEAN (T.I.M. W.O.O.D.S)

Transport – Moving people, products & information
Inventory – Storing parts, pieces, documentation ahead of requirements
Motion – Bending, turning, reaching, lifting
Waiting – For parts, information, instructions, equipment
Over production – Making more than is IMMEDIATELY required
Over processing – Tighter tolerances or higher grade materials than are necessary
Defects – Rework, scrap, incorrect documentation
Skills – Under utilizing capabilities, delegating tasks with inadequate training

Four Types of Office Waste: 1- Information Waste

Defects redundant i/o iof data
Defects incompatible info systems
Defects manual rechecking of data in info systems
Inventory unused data
Motion reentering data
Motion converting data format
Defects unavailable data
Defects unclear/missing data
Defects data discrepancies

Four Types of Office Waste: 2- Process Waste

Defects defect
Defects scrap
Defects rework
Defects workarounds
Motion inspecting,checking,double-checking
Motion approvals*
Motion variable flow in process
Inventory too much inventory
Motion incompatible work
Over productionoverproduction
Waiting waiting
Over processing overprocessing

Four Types of Office Waste: 3- Physical Environment Waste

Transport travelling to another location for a meeting
Motion organizig a disheveled conference room before a meeting
Transport going to your divisions office supply person for a replacement pen

Four Types of Office Waste: 4- People Waste

Skills unclear roles/responsibilities/authority/accountatbility
Skills lack of training
Motion work/task interruptions
Motion multitasking
Skills underutilization of talent
Transport hierarchy and structure
Skills recruitment errors
Skills lack of strategic focus
Motion handoffs

What happened to Agile Software Development?

Many Developers and Project Teams are still in the process of learning agile software development.
I think the best place to learn it is from one of the founders himself.

In this talk by Robert Martin (Uncle Bob) you will learn how the industry was prior to Agile and why Industry needed Agile.

In this other presentation, you will learn what happened to Agile in ways that the founders never intended.


watch this guy talk about scrum/agility and reconfirm your understanding about it.

Core Agile Principles

If you haven’t seen the Agile Manifesto yet, here you go.

*screenshot from http://agilemanifesto.org/

You also need to see the 12 agile principles. Practices like Scrum/Kanban/XP are just implementations of these principles. You do not need to follow every prescription of these practices as long as your custom workflows abide with the agile principles.
see: principles vs practices

“Agile” is more of a mindset than a tool set.  It is a framework for establishing a positive organizational culture.

If you are based in the philippines and wants to jumpstart or learn more or share about your journey to learn Agile software development, you may join  Agile Philippines! They meetup every last wednesday of the month.

The Efficiency Paradox

Flow Efficiency vs Resource Efficiency

[et_pb_section fb_built=”1″ _builder_version=”3.22″][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”3.27.4″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”]

Toyota, Lean Management

During this lecture I will talk about something that I think is extremely interesting: What is efficiency? It is a term that everyone uses, but very few understand. I would argue that 98% of all organizations have an incorrect understanding of what “true” efficiency really is. We tend to over focus on individual and functional performance. We think that efficient “islands” is a good thing. The more we deliver the better! The problem is that research shows the exact opposite! The more we try to squeeze out from the different islands within our organization, the more inefficient the organization will be! So what is the conclusion? Being “busy” is BAD! We call this the efficiency paradox! During this lecture I will describe why this phenomena occurs and how we have to redefine our view on efficiency in order to deliver true customer satisfaction!

This talk was given at a TEDx event using the TED conference format but independently organized by a local community. Learn more at

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.4.1″][et_pb_row _builder_version=”4.4.1″][et_pb_column _builder_version=”4.4.1″ type=”4_4″][et_pb_text _builder_version=”4.4.1″ hover_enabled=”0″]

To Understand LEAN better, I recommend these books because they were the ones who helped me understand it.

[/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row _builder_version=”4.4.1″ column_structure=”1_4,1_4,1_4,1_4″][et_pb_column _builder_version=”4.4.1″ type=”1_4″][et_pb_text _builder_version=”4.4.1″ hover_enabled=”0″][/et_pb_text][/et_pb_column][et_pb_column _builder_version=”4.4.1″ type=”1_4″][et_pb_text _builder_version=”4.4.1″ hover_enabled=”0″][/et_pb_text][/et_pb_column][et_pb_column _builder_version=”4.4.1″ type=”1_4″][/et_pb_column][et_pb_column _builder_version=”4.4.1″ type=”1_4″][/et_pb_column][/et_pb_row][/et_pb_section]