Lubo Drobny

Almost everybody in IT knows 'Answer to the Ultimate Question of Life, the Universe, and Everything', it is 42 - according to Douglas Adams book, but who knows the question? It is just joke from the book but anyway makes valid point. Good questions are important. From my coaching experience I can confirm it. People appreciate when I am asking good questions which help them to think different way or change perspective. They feel that in many cases it is more helpful than direct answers because they are able to figure out solution themselves. It is process of learning principles and getting fluency. It is obvious that non-directive approach needs time. It would be crazy to do it in critical or very stressed situations where direct answer do the job right.

Software engineers are very often pushed to implement solution which consumes less effort instead of the right one (clean and well designed). It is short term thinking: now we do it 'quick & dirty' and maybe later we will make proper way, which usually never happens. Common reasons for this decision are: time to market, nervous customers, release deadline, it is 'mess anyway' or manager's bonus for 'green' excel. The final result of all these quick hacks and dirty workarounds are accumulated in technical debt, which we would have to pay to make it right. Critical amount of technical debt is illuminated by classic symptoms: maintainability is very low factoring of code is awful (spaghetti) ownership of code does not exists unit tests are just fake or joke static code analysis is rather turned off CI is unstable and very slow (CD is only dream) adding new features is very time consuming  estimations are just guess from magic ball architect...

... after 6 month of development, 3 weeks of hardening, 1 week of migration & upgrade QA we finally have release candidate #8 which is suitable for customers ... fingers crossed ... candles lighted ... next weeks will be a real hell for product support This does not sound like something you would like to do again, or every month/sprint/week/day .... And it puts stress on customers and delivery teams, if something goes wrong it is a big issue ... I traveled to high school every day by public bus. It was usually very full, but if I was not able to get in, the next one went 3 hours later. Therefore I preferred to get it in any price - e.g. standing on one foot 45 minutes without chance to breath. When I am waiting on elevator and it is full, I do not mind, in few seconds there will be another one.  I believe that releasing as often as possible could 'un-drama' whole process. To achieve this, it is necessary to heavy invest into Continuous Integration & Delivery c...

What should QA guys do in Agile team first days of the sprint? This is an usual question. Assumption is as follows: all planned stories in previous sprint should by done-done. In others words: tested well and therefore QA have to wait few days till developers will finish some stories to test. Above assumption is completely wrong and there is a lot of work to do, these are just few suggestions: Prepare test environments for stories in current sprint Automate test cases just manually test last sprint Do grooming of stories for next sprint - challenge developers with non-happy paths Work on test strategy improvements to reflect last retrospectives Identify non-reversible changes and plan to be more rigor there

Everybody who was part of the SCRUM team could feel this tension between PO and SM. It is hard to avoid it due to essential role definition: PO tries to push into the team more and more features but SM tries to protect the team. Good balance is the key. Too strong PO can destroy SCRUM, team would just hunting features by sacrificing code quality and taking too much shortcuts. Too strong SM can destroy feature productivity because team would be trapped in over-engineering inferno, never-ending re-factoring and slow business value progress. Find the balance.

In 99%, the reason is very simple: Because, you are not doing Scrum,   but probably Kanban, Personal Kanban, Scrum-ban, Scrum-Fall or another aka Scrum-ish style. From my experience usually big corporations tend to implement SCRUM as micro-management tool with never-ending or empty meetings, without any ownership on team side. Usually with huge portion of non-addressable maintenance and legacy code. In this way team is just degraded to bunch of coders who must quickly hack unknown code and all decision are made outside of the team by management. This generates frustration and must fail, soon or later.

Product Owner as visionary & passionate product manager: defines the product road map & vision to deliver at first that 20% of product which repesents 80% of value communicates customer's needs and wishes watches competitors & business creates epics & stories is source of truth for domain knowledge manages budget provides priorities & orders backlog supports fun Scru m Master as natural & strong & servant team leader: moderates scrum meetings evangelizes Agile enforces continues improvement identifies/anticipates impediments & risks and coordinates action items to solve them shields the sprint protects the team from side distractions makes strong alignment between all stakeholders supports team-building empowers the team can accept/reject stories into/from the sprint masters scrum (not project/people) put fun back into computing Team as self-organized & cross-functional & pro-active group: execute the sprint...