Lubo Drobny

Build smart automation automate everything and everywhere implement clever monitoring  in case of a failure automatically fall back into the previous working state Enable continues development give all developers easy and simple way how to do continues development without compromises build support for step-by-step deployment and A/B testing deliver production-like environment runnable on developer's workstation  Rule the cloud deeply understand cloud technology code scalable infrastructure for actual and future needs enforce optimal security model Be step ahead always think one step in future about necessary improvements constantly identify bottlenecks and limits of current production system with possible solutions  apply agile and lean principles 

Andon Board : The facility for workers to signal problems to supervisors for immediate remedy, stopping the production process if necessary. Workstations along the production line can activate a warning on an illuminated central display board, which constantly displays productivity levels. =>  SCRUM/Kanban board + CI/CD automation Asa-ichi Meeting : A meeting held every morning in Toyota plants to discuss quality deviations and eliminate their causes. An essential part of the practice of kaizen. => Daily stand up Genchi Genbutsu: Going to the source to find the facts to make correct decisions, build consensus and achieve goals. => Retrospective (Root Cause Analysis) + face2face communication Heijunka: Leveling the production schedule in both volume and variety. A precondition for just-in-time and elimination of mura, muri and muda. => Velocity + self-organization + sustainable development Jidoka : Making problems visible so that they can be immediately ad

"... if I knew this a year ago I would did it better" This is a typical reaction when you learn something new and you are automatically applying it on stuff you did in past. The crucial question is: Should I go back and make it better or just let it go like it is? In software engineering it is question about refactoring. Honestly I prefer to do refactoring because I believe that " make things better " is a role of engineering in general. But on the other hand I am also lazy, older guys are telling me: " do not touch it if it works " and I really need to see a value of such a work. Therefore I have to somehow measure and visualize source code. This could be done by static code analyze, test coverage and performance tools. From the results I can Learn if my Refactor really made things Measurable better or not. 

boring stand-ups typical reason: every team member is solving very different issue, no intersections or direct collaboration; basically "I do not care" about 1 status sentence of my colleagues because there is no connection to my current work + strong individualism possible solution: moving towards to the feature team, e.g. instead of doing 1 feature by 1 developer 6 weeks, try to split work and do it in parallel by 3+ developers with feature lead in 2 weeks or even faster if possible (could be challenging at the beginning but helps to build no siloed knowledge) + build the team too long stand-ups typical reason: too much details + bike-shading and direct follow ups on stand-up with whole team + manager's hijacking possible solution: park every discussion longer than 1 minute after the stand-up and follow up only with committed people (pigs & chickens); 'kill' any bike-shading; have manager's talk after the stand-up non realistic estimations t

It is quite annoying to me when argument during discussion is like this:  it must be XY because the book says it. It is kind of: Bible is saying XY so we have to follow = end of discussion.  I am not very happy in such a case because we probably do not understand principles and just trying to blindly imitate something without deep knowledge of the matter. I prefer to admit it or show personal standpoint.

It is absolutely normal to invest time & money into cleaning service, so working desks, floors or toilets are clean and tidy. Working in messy environment is not easy and productive. Find a pen on table covered by tons of papers, gadgets and books can take few minutes instead of 1 second when it is just there. This makes sense for everybody. But when we talking about cleaning & tidying = refactoring of source code it is not so obvious and some managers suddenly needs SWOT analyses, meetings and arguments to understand why we should invest into it. The reason is very simple: what is business value of refactoring? Product management do not see any new feature (it was working before) but only risk of regressions. Also they have feeling that we did tons of shortcuts & dirty hacks till now so one more cannot hurts. Let's ask another way: what is business value of cleaning of working desk? Mainly: better, faster & comfortable work. Is is not directly linked with bu