Skip to main content

Anti-Lean Quotes


Set of quotes which usually highlights Anti-Lean behavior

Create waste instead of Eliminate waste

'Developer who is not working at least on 4 projects is not properly utilized' - less is definitely more and only done-done work counts by end of the day, limited work in progress is helping to focus on right priorities
'In case of any network issues please create a ticket on the help desk system at our partner's web-page' - creating catch 22 situations by design is craziness, such a process does not make any sense
'Yes, this is what our customers really need but could we add also this small feature, just in the case?' - extra feature creates an extra complexity, it is better to stay focused on real value and make it great for the users

'I know that you are working on the top priority but I am sure that you can do also this small task till noon' - probably there will be nothing really done by noon, task switching is more expensive than it looks like
'I cannot continue till back-end guys finish that API I need' - in this case feature oriented team should be better that typical functional teams to avoid the waitings like this

'Development is over and next week we will do handover to the ops team' - if they have to operate the solution they should be involved sooner

'We will fix this bug later' - ouch, known bugs shall not pass!
Disable learning instead of Amplify learning
'You have to make it perfect at the first attempt, you are an expert' - James Bond is just a movie not a real person, also experts need experiments and learning
'I know it the best and I do not care about your opinion' - appropriate feedback could help also this James Bond
'It is not possible to do it in small steps, it is all or nothing' - identification of meaningful increments is not always easy, but needs to be done anyway; it is development not big-bang magic
'We should kill all stand-ups and grooming meetings, people should work instead' - work on what? communication and alignment is the key
'We have exactly this one possibility' - spend little bit much more time and find more options could bring new light into solution
Big up-front planning instead of Decide as late as possible
'Only when back-end is fully finished and deployed we can start with front-end implementation' - some mocking could help to apply more concurrent development
'In order to prepare budget for a next year I will need detailed overview how much virtual machines we will need, how much RAM, CPU and disk they will occupy' - oracle ball is needed for such a report, probably this decision could be delayed when we have better understanding
Jeopardize delivery instead of Deliver as fast as possible
'Even I know that there is no customer who wants this but I am sure that this will be a game changer' - do not forget that customers should pull features into production, make some prototype to test your idea at first 

'We cannot deliver faster then once a year' - in most cases we can, but we have to change the way we are working 

'XY is the best one, call him now and let him fix it!' - protect your 'best ones' that they could be focused only on really top priority work and delegate rest

Create pushovers instead of Empower the team
'We have to plan it in details up-front and then let monkeys execute precisely our plan' - old way of management does not do the job anymore, best solution emerge from the real team work 

'They do not have a clue about our goal therefore we have to take care about each detail' - avoid micro management and coach teams to be self-organized and self-determined 

'I can hire hundreds like you in India in a second' - motivate and encourage people is not easy job but this is not very helpful

'Just do what I said' - if people are treated as push-overs they hardy become innovative and self-organized heroes

'I do not have budget for a such expensive training' - not all learning is about spending money, it is also possible to invest some time into internal groups of expertise


Disrupt integrity instead of Build-in integrity
'It is not a bug it is feature'
Focus on my desk instead of See the whole
'I am responsible only for architecture of communication layer and I do not care how it is connected with rest of the system' -  see the big picture is very helpful to optimize and invest an effort into the right place


Comments

Popular posts from this blog

Senior or Junior

Usually companies call young employees Juniors and more experienced Seniors. Sometimes you need to just sit and wait and it will come. Sooner or later. From my point of view it is not enough. I met a lot of old employees they call themselves Seniors but they behave like Juniors. So I defined my point of view on Seniority: professional simple understand what I am doing and understand reason why I am doing it can coach others this is very basic; who can coach others is just fine but who can coach others to became a new coaches is super not genius but have deep knowledge on some specialized parts geniality is overestimated, we do not need "magical guru", to be expert is good enough; if you are "one to go" when there is problem, it is OK big picture overview it is not probably possible to understand a whole system in details but it is necessary to have at least overview know what I know and know what I do not know to see myself in correct light is very

Software Engineer

Recently my company expanded the Software Engineer positions in my team. This leads me to thinking about the skills which are necessary for these positions. So I prepared a list of qualities which I think are important for a good Software Engineer. Abstract concept modelling This is essential and there is no room for discussion on this because this is what we do. Love to code It does not matter if you are 15 or 50 or if you write code 10% or 90% of your time, code writing is crucial. Team player The surgeon style teams (one genius with helpers) are obsolete, I prefer real team players who are able to work towards a common goal and share responsibilities. Communicative Silent geeks siting in the corner with a notebook on their knees are not cool any more, we need to talk to each other, we need to be able explain technical stuff to non technical managers, we need to be able to choose the right phrase at the right time. Take responsibility There is no quali

Scrum rollout

Would you like to start with Scrum in your team? These are few hints from my experience how to make this process smooth, iterative & incremental: get commitment from the management & team define reason: why would you like to do Scrum? what problems it should solve for you? start with simple Kanban in one team: it is easier, you just need to manage 3 lists: backlog (todo), work in progress and done  focus on right priorities of backlog - person who defines the priorities will be 'product owner' setup quick way how to track work in progress and indicate 'impediments' -> daily stand-up; max 15 minutes meeting every day - moderator of the meeting will be 'scrum master', he will be also responsible for solving the 'impediments' focus on dependencies between the tasks to avoid 'impediments' start to put 'discoveries' into the backlog to pre-analyze tasks; discoveries should be done by architect or analyst what is the busi

Agile is not a religion

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.