Introduction to Agile Values & Principles
•
2 likes•536 views
1. Cynefin framework 2. Waterfall software development 3. Agile software development (including Agile history) 4. Activity: agile vs waterfall 5. Agile tools (lean)
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Introduction to Agile Values & Principles
Similar to Introduction to Agile Values & Principles (20)
More from Andreea Visanoiu
Recently uploaded
Recently uploaded (20)
Introduction to Agile Values & Principles
- 1. AGILE VALUES & PRINCIPLES
- 2. Who am I? Andreea Visanoiu • Scrum Master, Agile Coach • Originally from Romania • Lives in Kuala Lumpur • Works for Mindvalley • Former Product Manager / Product Owner • Working with Agile for 7 years • CSM, CSPO, Certified LeSS Practitioner • Co-founder of Girls Who Code Romania
- 4. • Good leadership is not a one-size- fits-all proposition => we need a new perspective based on complexity science => Cynefin framework • The framework sorts the issues facing leaders into five contexts defined by the nature of the relationship between cause and effect • It’s a decision / analytical framework • You should manage in the Complex and Complicated spaces and only move a small amount to Simple, as it is highly vulnerable to rapid and accelerated change Complexity theory - Cynefin framework Source: https://hbr.org/2007/11/a-leaders-framework-for-decision-making
- 5. Complexity theory - Cynefin framework COMPLICATEDCOMPLEX CHAOTIC SIMPLE Disorder • Cause and effect are only coherent in retrospect • Probe - Sense - Respond C E • Cause and effect are separated over time and space • Sense - Analyse - Respond C - - - - > E • No cause - effect relationship perceivable • Act - Sense - Respond C # E • Cause - effect relations repeatable, perceivable & predictable • Sense - Categorise - Respond C = E UNORDERED ORDERED Examples: • Simple: heavily process-oriented situations - loan payment; complacency, falling in chaos • Complicated: call the experts; you know something is wrong with you car, but you need an expert to solve it; the expert might overlook non-experts thus miss opportunities • Complex: battlefield commanders, politicians in emergency they gather a team together (different domains, backgrounds, etc.) desperately hoping some will come up with an answer; “Huston, we got a problem” • Chaotic: September 11; the “legend” issue Scrum&Leanarehere EMERGENT PRACTICE GOOD PRACTICE BEST PRACTICENOVEL PRACTICE
- 6. Cynefin framework and software development Examples: • Simple: just do it • Complicated: web shop; solution not evident • Complex: empirical process (Scrum, Lean) • Chaotic: outage in a hosting environment; “Triage” - solve the most urgent problem and go down towards less urgent (stabilise situation first) Source: https://blog.agilistic.nl/on-complexity-why-your-software-project-needs-scrum/
- 7. WATERFALL
- 8. Waterfall ModelConception User requirements Deployment Analysis Design Development Testing Idea is generated, business case created, requirements are built, analysed, and written down in a specification document which is the basis for ALL future development. System analysis Technical design requirements Coding - building the app QA, all testing Release complete application as per agreed requirements Client
- 9. Waterfall pros and cons Advantages Disadvantages Suitable for simple systems (simple apps, that solve one problem) Creates big issues for complex to complicated systems and completely fails in chaos Adapts to shifting teams: as the scope is not changed from the beginning of the project and work is done entirely based on documentation (in theory) The application is built based on specification that can be obsolete or not reflect the client’s needs anymore Forces a structured organisation Ignores client feedback (mid to end project). Changes required by client after the design phase are costly and time-consuming Allows early design changes => lack of adaptability across all stages of development life cycle (e.g. testing coming up with essential issues that affects the entire system design can lead to complete project fail) Suited for milestone-focused development Not adaptable or flexible to continuously changing customer needs Delayed testing period; testing is a fundamental and always-present process throughout development.
- 10. AGILE
- 11. The birth of Agile movement • 1930s: W. Edwards Deming used the Plan-Do-Study-Act (PDSA, created by physician and statistician Walter Steward of Bell Labs) as a consultant for Toyota • 1948-1975: The Toyota Production System was born => lean thinking (Taichi Ohno, Eiji Toyoda) • 1950s: Iterative and incremental development methods - contributed to successful creation of X-15 hypersonic jet • 1986: The New New Product Development Game, by Hirotaka Takeuchi & Ikujiro Nonaka: “rugby approach” at Fuji Xerox, Honda, and Cannon • 1993: Jeff Sutherland (Scrum father) started to apply agile principles in software development and called it Scrum (see “rugby approach”); 1995 it was made public • 2001: 17 developers - “organisational anarchists” - created the Agile movement after an intense few days at Snowbird, Utah; the Agile Manifesto was born • 2000s on: lean and kanban software development systems emerged (formal)
- 12. An Agile approach to software development
- 13. Conception User requirements Deployment Analysis Design Development Testing An Agile approach to software development Client feedback
- 15. You don’t “do” agile, you ARE agile CUSTOMER • Highest priority: satisfy the customer through early and continuous delivery of valuable software • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. • Constant customer feedback through the development lifecycle • Work directly with customers and business people (no intermediaries) • Continuous learning & adaptation: the teams reflect on how they become more effective, tunes and adjust behaviour accordingly PEOPLE • Build projects around motivated individuals. Give them the environment and support they need and trust them to do the work • Working software is the primary measure of progress • Sustainable development - maintain a constant pace indefinitely (work - life balance) • Cross-functional teams • The best architectures, requirements, and designs emerge from self-organising teams • Face-to-face conversation as much as possible • Continuous learning & adaptation: the teams reflect on how they become more effective, tunes and adjust behaviour accordingly PROCESS & TOOLS • Embraced continuous change, in all development cycle • Short iterations (maximum 30 days) • Deliver frequently • Continuous attention to technical excellence and good design enhances agility • Maximize the work not done - simplicity is essential (just in time and just enough) • Continuous learning & adaptation: the teams reflect on how they become more effective, tunes and adjust behaviour accordingly Source: http://agilemanifesto.org/principles
- 16. Agile pros and cons PROs (all of the above and…) CONs Creates value from the get go Lack of understanding agility (it needs training and management support to be successful) Fast response to change Requires cultural change - it’s not only about adopting a framework => Accepts and integrates uncertainty Becoming truly agile is timely (1-3 years) Greater flexibility in releasing features Interpreting the manifesto ad literam can create issues (people blame Agile for their own bad behaviour) Promotes caring about employees and creating a highly motivating environment Integrate diverse skills-set into teams (cross-functional teams) Less up-front work Lack of predictability. Waterfall creates a (false) sense of security with steady deadlines and estimation, in Agile environments these are continuously changing, constantly considering feedback). Constant integration of customer feedback, among the entire development cycle Challenges at scale
- 17. Why short iterations? • 2-4 weeks sprints • Why: • Rapid response to changes • Continuous client feedback - as early as starting up • Easier tracking of progress and planning (with real data) • Detect problems (from architecture, design, process, etc.) as early as possible • Shorter iterations = smaller items to be built => easier reprioritisation • Easiest approach to go “iterationless” :) • Releasable increment / MVP / MMF
- 18. What is an MVP?
- 19. Building MVPs (or MMFs)
- 20. Building MVPs (or MMFs) Breakdown of client needs: • The client needs to go from A-B (let’s say 50 km) • In under one hour, Every day, back and forth • She also needs deposit space in case she does any shopping • She needs extra space for friends in case he wants to take someone or bring someone along. Client needs: to go from A-B (let’s say 50 km), in under one hour, every day, back and fort; she also needs deposit space in case she does any shopping and space for friends in case he wants to take someone or bring someone along.
- 21. PLAY TIME
- 22. Waterfall vs Agile Software Development
- 23. Traditional vs Agile - game Rules • Each egg must have at least two different colors • Two separate people must complete each coloring activity • Each egg should be minimum 90% filled with color • White space doesn’t count as colour • Cutting must be around oval edges of the egg • Eggs with major distractions in cutting will be disqualified Method 1: Plan driven approach with waterfall team structure 3 min 6 min 3 min Plan Execution Learning Method 2: Multiple iterations with cross-functional team 1 min 2 min 1 min Plan Execution Retro 1 min 2 min 1 min Plan Execution Retro 1 min 2 min 1 min Plan Execution Retro
- 24. AGILE TOOLS
- 27. Go and see is a management technique A technique with four dimensions: 1. Develop judgement by testing hypotheses: figure out if you’re right or you have misconception 2. Build consensus by getting people to agree on the problem before debating a solution; most conflicts involve people arguing on the solution when they don’t agree on what the problem really is (=> one-person solutions, people resist implementation) 3. Achieve goals at the desired speed by checking regularly where people are in the implementation and helping them if they run into impediments 4. Empower people by involving them. “Take it to the team”.
- 28. Kaizen - continuous improvement • The heart of agile • Help the team figure out what’s their best performance and why • Try to beat that • The “standard” m.o. is the best the team can give at any time; now try to beat it • Continuous improvement - the basis for creating “learning organisations”
- 29. 5 THE WHY WHY WHY WHY WHY’S The vehicle will not start. (the problem) 1. Why? – The battery is dead. 2. Why? – The alternator is not functioning. 3. Why? – The alternator belt has broken. 4. Why? – The alternator belt was well beyond its useful service life and not replaced. 5. Why? – The vehicle was not maintained according to the recommended service schedule. => the fifth why, a root cause NOTE: you should continue asking “why” until you reach the root cause of the problem. Only then you jump into finding a solution.
- 30. Closing • Expectations check • Q&A