AGILE APPROACHES Jiří Svoboda Projektový underground, čtvrtek

History and present situation  Formulation of Agile manifesto in Utah (USA), 2001  Initially focused on software development  Reasons:  Project failures  Changes always mean problems  Dissapointed and not motivated developers

Agile manifesto values  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan

The principles: Human factor orientated I  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.  Business people and developers must work together daily throughout the project.  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The principles: Human factor orientated II  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.  The best architectures, requirements, and designs emerge from self-organizing teams.

The principles: The rest  Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.  Working software is the primary measure of progress.  Continuous attention to technical excellence and good design enhances agility.  Simplicity - the art of maximizing the amount of work not done - is essential.

The benefits of going agile Strong product and business needs orientation Changes are welcome due to iterative approach Gaining experience is very fast Common sense Fast delivery Simplicity

Which projects are suitable for agile approach?  When it is necessary to deliver the product asap even with limited functionality  The project duration is weeks or months  The scope is unclear and requirements are changing over time  Projects in open and flexible company environment  Colocated teams up to 10 members

Success factors for using agile  Well structured team  Common vision  Ongoing team dynamic and social interactions monitoring  Cooperation support  Workplace without barrierrs  Rest zones  Information clarity and openness

Risky conditions for going agile  Very large systems with complex architecture  Long term projects with the delivery at the end  Rigid company culture  Workers resistance to change  Low management support  Large teams

Most common agile methodology VersionOne research (2011 )

Agile project management I  The shift of the project manager role to the role focused on team management based on:  leadership  motivation  couching  team development  working with team dynamics and social interactions  visions.

Agile project management II

Otázky k diskuzi I  V čem vlastně může agilní metodika pomoci a není to spíše jen novy módní buzzword?  Dokáží se principy agilního řízení aplikovat i na nevývojářské IT projekty (například Implementace ERP, infrastrukturní projekty atd.) a jaký to přináší užitek?  Jaké typy projektů jsou pro scrum ne/vhodné?

Extreme programming (XP)  Author: Kent Beck, 1999  Uses well known principles of software development but in extreme way  Team size: 2-10 members The most important is the orientation to source code and common sense!

XP Fundamentals  Values  Simplicity  Communication  Feedback  Courage  Project constraints  Quality  Time  Costs  Scope

XP Overview  Plus:  Short Iterations  Ongoing implementation and integration  Quick learning and knowledge sharing  Cons  High quality human resources needed  Too much of originality at the beginning  Limited project size  Limited team size

SCRUM Development Process  Klepnutím lze upravit styly předlohy textu.  Druhá úroveň  Třetí úroveň  Čtvrtá úroveň  Pátá úroveň Monthly sprints  Demo version Everyday Stand Up meetings Product backlog Sprint backlog

SCRUM Project roles  Product Owner  Responsible for Product backlog  Represents customer  SCRUM master  Similar role as Project manager  Ensure the right use of SCRUM principles  Team couching and leading  Possibility of certification  Team  Optimal size 7±2  The structure could be changed after the sprint  There is always concrete code owner

SCRUM Requirements specification  Product backlog  Ground and structures specification  Contains user stories (ID, priorities, estimates…)  The owner is Product Owner, he sets priorities  More teams can work with it  Is changing in time  Sprint backlog  List of deliverables for the current sprint  Priorities  Estimates

SCRUM Planning  Sprint planning meeting  sprint backlog + goal  Before start of each sprint  limit 4 (stage What) + 4 (stage How) hours Output: sprint backlog + sprint goal  Sprint review meeting  Control point of new developed functionality  Demo Presentation to stakeholders  limit 4 hours  Sprint retrospective  Sprint assessment  lessons learned

SCRUM - Estimations  Planning poker  Each team member estimates the needed effort for single tasks. If there is too big variance, the discussion starts.  Each team member hiddenly takes the card with points and after that all cards are turned up in one moment

SCRUM – Monitor and control  Daily scrum (standup) meeting  Regular time  Duration: 15 minutes  Everyday questions:  What I worked on in last 24h  What I will do next 24h  What are the blocking points  The finished tasks/stories are moved to done status  Sprint burndown  Work progress overview  Product burndown  The product progress overview

SCRUM - Velocity

SCRUM - Demo  Meeting for showing the results to Product Owner (PO)  PO can see the product and can request changes in Product Backlog for next sprints  Anybody can join the meeting.

SCRUM - Overview  Advantages  Quick product delivery  Quick reaction to changes  High team performance  The universal framework  Effective team work support  Cons  Not for big projects?  Smaller teams (…or SCRUM of SCRUMs)  High demands on human resources  Overhead for tiny projects

Extrémní projektové řízení I. (Doug DeCarlo) 27 Tři základní myšlenky:  To, co je neznámé a nepředvídatelné se musí řídit jinak než známé a předvídatelné,  Mise projektu je podporována motivací a důvěrou klíčových účastníků projektu,  Nejde jen o metodologii, jde o ucelený přístup, který je:  holistický – je založen na integraci určitých hodnot, technik a postupů, které musí být integrální součástí celkového přístupu zúčastněných,  humanistický – úspěch projektu a kvalita života se nedá oddělit, demoralizovaný tým přináší špatné výsledky,  zaměřený na lidi – důraz na dynamiku, komunikaci, interakce mezi účastníky projektu,  zaměřený na byznys – projekt především dodává přínos byznysu,  zaměřený na realitu – snažit se přimět realitu, aby se vešla do projektového plánu, nemá smysl, je nutné pracovat s konstantními změnami a nepředvídatelností.

Extrémní projektové řízení II. 28 Charakteristika extrémních projektů:  jsou nepředvídatelné, míra chaosu a nejistoty je velmi vysoká,  vyžadují rychlost a inovaci – produkt musí být dodán velmi rychle, cíl projektu se může v průběhu měnit, tak jak se změnili vnější podmínky,  plánování „just in time“ – plán se musí rychle měnit s tím, jak se mění okolnosti a musí být měněn odzdola – přímo projektovým týmem. Projekt je samostatný ekosystém ovlivňovaný:  externím prostředím – např. změny v technologiích, legislativě, dodavatelích, preferencích zákazníků,  interním prostředím – kvalita myšlení, emocí a interakcí obklopující projekt, očekávání a celkový přístup k projektu,  projektovým manažerem, který musí šířit pozitivní přístup k projektu u všech účastníků a řídí vztahy - vyjednávání, politické a sociální schopnosti,  technickým projektovým manažerem, který dodává samotný produkt.

Diskuze II  Jak efektivne a prakticky aplikovat agilni metodiku, abych spise tym neotravil - jak "priohnout" k praktickemu vyuziti (manazerska novota nemusi byt to nejlepsi pro tym)?  Jak zafixovat budget v agilni metodice, kdyz se vsechno rychle meni, ale penize byvaji odsouhlaseny fixni a rovnez tak terminy pro dodavku?  Jak stanovuji cile projektu, rozpocet apod., když toto se vlastne rozkryva az v jednotlivých iteracích…?  Jaký je vztah "agilního řízení" ke stylům řízení, které známe z ekonomické teorie?  U jinak standardniho waterfall projektu je cast dodavky vedena agilne. Waterfall i agilne vedene aktivity probihaji v urcitem obdobi paralelne a mohou se vzajemne ovlivnovat. Jak co nejlepe tyto aktivity sladit, resp. jak by mela byt nastavena komunikace/interakce mezi TPM, PO, SM …?

Diskuze III  Jaké jsou rozpory agilních metodik s metodikami P2 a PMI?  Nepřináší s sebou agilní způsob řízení více neutilizovaných hodin? (denní meetingy, retrospektiva,..)?  Jak postupovat, pokud bych na projektu chtěl scrum využít?  Pro jake typy projektu vnímají kolegove agilni rizeni jako optimální. Zejména s ohledem na rizeni scope, budgetu a casovani.  Existují nějaké specializované řídící nebo i programátorské nástroje, které agilní řízení (programování) podporují?  Stav používání agilních metodik v ČR?  Do jaké míry lze kombinovat tradiční a agilní techniky?  Pro jaké oblasti projektového řízení se hodí nejvíce agilní technika?  Jak se vyrovnat s dokumentací při použití metodiky SCRUM?

Děkuji za pozornost 31  Kontakt: