My thoughts about role of "Agile", in software engineering world.

Editor's Notes

• #2: Typical buzzwords of Agile No techie term included!!!
• #3: Innocent beginning Everyone agrees about its necessity
• #4: ... in time scheduled releases, milestones, roadmaps, sprint (fun fact: sprint is introduced to deliver continuously  outcome of idea is about a delivering periodically) due to customer’s expectation due to company’s offer technical aspect is supressed by tough schedule => this is a bad behavior, in Agile Software Development technical aspect is critical E.g: No tests needed => i won’t trust in my code No code styleguide created, maintained and explained => i won’t trust in other’s code codefreeze periods (in every sprint sometimes) => because we don’t trust in our code, we are afraid of it
• #5: Hands up: who yawns on meetings usually and frequently? Because they’re boring and we don’t have the feeling after them that we deliver something valuable No customer value thus no reason to have Arguments against meetings: Stand-ups needed because team members don’t communicate continuously Sprint Planning needed because team has a deadline called sprint Groomings needed because of 10-30-60 backlog (reality – possibility – fantasy) Retrospective needed because we are not agile yet (which state is conservated by circumstances anyway) Demo needed because customer is not involved into process (PO != customer)
• #6: inherited from pre-Agile era when PMs knew how long a task will take (WBS) Prag Dave Thomas: 2000hrs and half-way done storypoints: complexity – reccurency – risk (order of importance: 3-2-1 in reality, 1-2-3 in planning) no time estimated goal was to obfuscate time in estimations  reality: „1 storypoint = 1 day” Complexity = accidental complication + essential complication while planning: accidental complication = 0 in reality: accidental complication >>> essential complication E.g: 2 week-long sprint + grooming on 4th day story is big, must be splitted it takes time but you gave a contract to customer to deliver this and this and suddenly you’re loosing hours you can’t push shit back to customer => overtime Let’s estimate: neighbor village, pills from pharmacy, tomorrow (1500km, 2 tons, snowstorm) Let’s estimate: Tieing your own shoelaced (5sec) Writing complete guideline about how to tie shoelaces, for someone who has never done this before Options of outputs: need time-based estimation: BestCase-NominalCase-WorstCase (10% of success – 50% of success – 90% of success) #NoEstimate („i dont know”)
• #7: Project Manager: - no PM on Agile projects - controls time management and reporting - handles time forecasts - controls budget by getting approvals from organization + customer - sometimes he is SPOC to customer - should be a serving role Product Owner: - theoretically represents Customer but we need Customer himself - he is also difficult to get in contact with him - sometimes only PM is allowed to talk with him Scrum Master: - theoretically protects the process - transforms team methodology into Scrum - self-suicide job Example: - 1 Project Manager - 1 Scrum Master - 1 Project Delivery Lead - 1 Development Team => 1 Developer
• #8: Finance Department Before going to a relevant conference, this department must approve expense of travel and tickets  team-level decision and budget Corporate Architect Community: Before starting implementation, this department need to have an architecture to approve  in Agile Software Development, architecture evolves continuously IT Department Before choosing a technology, this department must approve team’s choice  generic guidelines or policies could not be applied on specific cases properly  team has all information necessary for making decision Project Management Community Before starting a project, this department must delegate a PM to make contract with customer and set up team  waterfall approach is followed usually by making fixed priced contracts based on theoretical understanding of future product  no need to split 1 big project into many smaller (manageable) ones with incremental improvements
• #9: delivering valuable products not cheaper neither in shorter time delivery of car (as we think it would happen): chassis, +engine, +seats, +gear, +body, +painting, +airconditioner delivery of car (as it would happen): scooter, bicycle, bicycle with small electric engine, motorcycle, squad, car acting as professionals trust in code (via TDD, continuous integration, static code analyzing) eliminating frictions between departments by giving responsibility to teams between customer and company by involving customer (not dedicated PO) into process between management and team by letting them working as professionals and focusing on delivering instead of forcing them to make financial (time-based) micro-contracts
• #10: My own buzzwords of Agile Software Development
• #11: I continuously fight against: estimations by arguing against their reliability deadlines because they are mostly based on assumptions and no relevancy after e.g. 2 weeks of development approvals (from other departments) because it’s a waste of time when I must explain and argue for something which is obvious timesheets because they’re about lack of trust If you face followings, you are not in agile organization: deadlines estimations approvals timesheets Scrum Master Product Owner (?)