Agile and Lean meets IT

Was making presentation about how we were transforming IT into service type instead of control type.


  1. Imagine you have to earn money. Perfectly shifts away your thinking away from “cost efficiency”.
  2. Avoid broad terms. Too much room for interpretation.
  3. Control scope. Be explicit about what you can do. Say “no” to things you can’t.
  4. Monitoring and Transparency. Best way to control things.
  5. De-centralize certain activities. Build for scale.
  6. Grow you process. Evolution vs adoption
  7. Know value flow. Local efficiency is not what you need

Priority #1

How often do you ask your main stakeholders about first priority features?

Should we analyse feature A first or feature B first? Should we start working on A, B or C?

Do you think that prioritization would remain the same with following options (assuming that we know potential users and revenue)?

  • Option 1
    • A – 1 month; B – 1 month; C – 1 month.
    • Teams involved: A – 1 team; B – 1 team; C – 1 team.
  • Option 2
    • A – 1 month; B – 1 month; C – 1 month.
    • Teams involved: A – 3 teams; B – 4 teams; C – 2 teams.
  • Option 3
    • A – 3 months; B – 2 months; C – 4 months.
    • Teams involved: A – 3 teams; B – 5 teams; C – 2 teams.

What additional information apart intuition do you use in decision making? Do you use spikes to improve decision making?

The “science” in the science of …

Often notice that people tend to be “black and white” when talking about practices in any field, let it be management, design, development or whatever… e.g. go completely scientific and measure everything and be very structured or become completely ad-hoc and reactive.


Of course it’s an option to work in a binary way, but in my opinion it is not necessarily the best way to go while facing complex problem. You must have various “tools” in your toolbox and be creative in applying them depending on a situation or context.

As a confirmation for myself I’ve stumbled upon an article  recently which covers exactly the same topic –

So, can design be a science? Sometimes yes, sometimes no. Can it be empirically based, evidence driven? Yes. Will it have to reply on intuition and the creativity of individual designers? Sometimes, yes.

Answers and Questions

Giving answers and suggestions is very tempting especially when you join a team temporarily as there is obvious time constraint and normally you are there for a reason. Answers can be easily misunderstood because of established behavior, knowledge and etc. answer

I prefer questions first and typically focus on a couple of areas:

  1. How do you make decisions?
  2. What are your dependencies?
  3. How do you deliver?
  4. What ?

Why these questions?

Question #1 leads to a conversation who decides what to do (business, technical), how critical situations are solved if any, what information or KPIs decisions are based on.

Question #2 leads to understanding roadblocks: technical, organizational, business, knowledge

Question #3 gives an understanding of current team’s process, how the plan, how/if collect feedback, how they deploy, ensure quality and etc.

Question #4 leads to a conversation about end users and what services/products/components are delivered to them.