Lubo Drobny

... 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

openness : enables progress trust : enforces internal motivation continues learning & improvement : give satisfaction autonomy : builds responsibility team spirit : allows scaling alignment : creates peace enabling : makes it faster focus : helps to deliver in time fun : makes it easy Release as fast as possible! Do not wait! Fail fast & learn! Experiment! Mistakes are allowed! No politics! No hiding! No denial of the truth! Tell the whole truth, do not serve it step-by step! Manage your manager! Automate! Escalate asap! Use awesome tools! Build skills! Make waves! No fear! No blaming! Do this loop: think, plan, correct plan! Eat own dog food!

CODE is clean self-documenting communicates the programmer's intentions well designed/structured  ERRORS are handled consistent and transparent way LOGS are appropriate on appropriate level CODE ANALYZER reports no new issues reports satisfactory coverage CODE REVIEW is done CI is green = code is committed to appropriate branches + builds are OK + all unit tests are passing + all integration tests are passing CD is green = build are integrated & deployed OK at staging environments + all regression tests are passing QA initial tests are OK do not report any defects test automation is planned if makes sense PO accepted the story

When is user story ready for a sprint? I think that team should prepare in advance these points: Title - short summary of the story  PO: business requirements (schematic, not novel, priority order) = what & why & when to do? UI: wire-frames or sketches of new UI/UX and flows = how to do it on UI? Dev: architecture & design impact (dependencies, cfg, DB changes, migration, new libs ...) + suggested technical solution = how to solve it on backed and code it? what is impacted? could solution generate technical debt? are we aware of taking some technical short-cuts? CI & devOps impact (Jenkins, VMs, Sonar, Vagrant, Ansible ...) do we need change on CI/CD or envs? QA: acceptance criteria (could be part of DoD) + environments definition to validate PO: clear and understandable DoD (bullets) - fixed for a sprint duration Estimation in story points Links to discoveries (wiki page) or related stories or bugs Fix versions: branches where to commit or merge  Sub-ta

Implementation of Agile (SCRUM) in company requires setup of few meetings to achieve benefits of this methodology. It could be very different across various companies and this is my perspective after 7 years experience with Agile. Daily stand-up goal: build team awareness about the progress of each story in the sprint, detect impediments and identify potential actions to remove them; reassess priorities to be sure that we are on right road with focus on ticket flow who: team moderator: SM length: 15 minutes, every day - it must be the heart-beat of the team, everybody should contribute and understands that this makes sense - the same time and place every day, - quick as possible: 'pam-pam-pam' - sprint board (backlog and story we talking about) must be visible for everybody - only one attendee talk in one time; SM should kill side talks - team members should pick tickets voluntary (self organization) - SM is discussing stories from top priority to lower ones and

How many devops do you need to change light-bulb? - None. It is one shot manual job, they do not want to do it. How many java developers do you need to change light-bulb? - 100. One is doing a job, rest are just dependencies. How many consultants do you need to change light-bulb? - Well, It depends ... IQ is not lower by aging - it is just slower.