Being vs Doing agile

857 views
537 views

Published on

Most of the times I have seen the teams spending immense amount of time in mastering the mechanics than the intent.
Key to successful agile adoption is to have the agile as a team culture than just doing it

Published in: Self Improvement, Technology
2 Comments
4 Likes
Statistics
Notes
  • User Journey: The experiences a person has when interacting with an Entity.
    Purpose: Visualise ideal path needed to achieve a specific goal of the User
    Focus on : What would be Ideal for the User as opposed to what the system can do (i.e) User Centric vs System

    http://www.scivisum.co.uk/images/User-Journey.png
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Using Comments as my Notes Space:
    WireFrame: A visual guide that represents the skeletal framework of a Entity.
    Purpose: Visualise Arrangements of elements to best accomplish a particular purpose
    Building Blocks: Intent, Content, Interface Elements & Navigational Flow. All of them connected Visually typically in a Layout.
    Focuses on : Functionality, Behavior, and Priority of Content. In a nutshell - 'What an entity does & Not what it looks like' Example of entity : Mobile App, WebSite, L1 Team etc

    Guidelines:
    1. Identify the Intent & Content
    2. Identify the Building Blocks (It could be Human or Non Human)
    3. Identify Interface Elements (First Call to Action)
    4. Identify the Navigational Flow
    5. Depict them as a Visual Guide
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
857
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
22
Comments
2
Likes
4
Embeds 0
No embeds

No notes for slide

Being vs Doing agile

  1. 1. 1 Being Agile – Mindset & Culture Raja Soundaramourty May 07, 2014
  2. 2. 2 Doing Agile ≠ Being Agile Agile Practices ≠ Agile Mindset
  3. 3. 3 Agile is Like Haircut – Copying Someone Rarely Works
  4. 4. 4 Agile Fragile Likes to Talk About Problems Likes to Solve Problems
  5. 5. 5 Agile Fragile Likes to Work in the Dark Likes to Work in a Team
  6. 6. 6 Agile Fragile “It Meets the Requirement” “I Hope This is Going to Help You”
  7. 7. 7 Agile Fragile Think Users are Dumb Respect for the Users
  8. 8. 8 To Release Benefit on a Schedule We’ll Need to Leverage Incremental and Iterative Thinking
  9. 9. 9 Iterative Builds a Rough Version, Validates it, then Slowly Builds-up Quality Incremental Builds Bit by Bit Move from Vague Idea. Making Course Corrections as You Go!Fully Formed Idea. Accurate Execution!
  10. 10. 10 Mix the Strategies Iterative and Incremental •  Iterate to Find and Improve Solutions •  Increment to Add Known Functionality
  11. 11. 11 Agile Methodologies Kanban* Xtreme Programming* Lean* Dynamic Systems Development Method Scrum* Feature Driven Development * Popular
  12. 12. 12 PracticesMethodologies Methodologies •  Scrum •  Lean •  Kanban •  Xtreme Programming Practices •  Test Driven Development (TDD) •  Continuous Delivery •  Pair Programming
  13. 13. 13 Product Development Maintain Work Environment Learn from Outside Sources Develop Team Commit to Agility Manage Risks Ensure Process Adherence Identify and remove impediments Ensure Internal Communication Provide Job Training Engage Stakeholders Everyone Environment Develop Product Strategy Manage Product Portfolio Understanding Needs of the Customer Product Strategy Define Product Roadmap Define Business Requirements Establish Product Vision Planning Define Product Backlog Solution Requirements Maintain Architecture Integration Testing Coordinate Work Achieve Customer Acceptance Understand Requirement Establish Development Environment Maintain Product Quality Manage Suppliers Design and Engineer Solutions Deploy Product Develop Product Coordinate Launch Support Implementation Plan Launch Launch Product Support Operations Perform Maintenance & Customizations Support Operations Operate & Support Product
  14. 14. 14 Development Sprints Independent Test Release Planning Plan Code DesignTest Team Release Planning Product Release Planning Team Backlog Levelling Delivery Integrate Platform Certification TestPackage Build IntegrateTest Shippable Release Potentially Shippable Product Product Planning Product Backlog Product Roadmap Product Planning Vision
  15. 15. 15 Visioning Wire-framing User Journeys Epic-writing Release Plan 1 2 3 4 5 10 10 10 10 10 Planned Velocity
  16. 16. 16 10 mins “Here’s what we have planned. Does it look reasonable?” Looks good to us. Let’s go! XD PO Dev QA BA LM PM
  17. 17. 17 How are we looking? LMPM
  18. 18. 18 10 mins PO PM LM Updates on Work Listening in for any questions on priorities or stories. Listening for any blockers I need to help resolve. Drives process and updates. Looks for improvements. Across Product On the outside of main circle. “What cross project impacts are there?” Dev QA XD BA
  19. 19. 19 10 mins PO LM QA XD Story “Here are the details of the story. Are we all on the same page?” BA
  20. 20. 20 10 mins Story “Here are the details of the story. Are we all on the same page?” BA XD QADev
  21. 21. 21 “This is what we produced during the iteration.” PO Walkthrough of live app. Stakeholders Provide feedback.
  22. 22. 22 1 hour XD DevQA BA LM PM What went well? What needs improvement? Questions? PO Action Items
  23. 23. 23 Four Types of Agile Teams to Avoid You’re  nuts.   I’m  King  of  the  world!   No,  You’re  not!   I’m  King  of  the  World!!   I’m  King  of     the  World   Are  you  crazy?   I’m  King  of  the  World!   I’m  King  of   the  World!!  No!  I’m  King  of   the  World!!  
  24. 24. 24 Team Communication User Accessibility Team Location Team Structure Delivery Frequency (Shippable) Measurement of Progress Ability to Change Direction Testing Planning Approach Process Philosophy 1 2 3 4 5 6 7 8 9 10 Minimal, written, knowledge is power Limited, off-site Highly distributed Departmental, top down, large teams Infrequent, 3+ months Phases, tasks, documents Low, prevented Manual, post-coding Up-front, detailed, activity-based Static, audited, my-way 1 2 3 4 5 6 7 8 9 10 Open, trusting, face-to-face Constant, on-site Co-located Cross-functional, self- organizing, small teams Frequent, 1-2 weeks Features/business value, working software High, embraced Integrated, automated, test-driven Just enough, adaptive, continuous Analyze/adapt/improve 1 2 3 4 5
  25. 25. 25 Thank you.

×