• Save
Agile Rendezvous
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Agile Rendezvous

on

  • 1,394 views

A brief Agile primer of values, principles & practices of thinking Agile before following & being Agile.

A brief Agile primer of values, principles & practices of thinking Agile before following & being Agile.

Statistics

Views

Total Views
1,394
Views on SlideShare
1,388
Embed Views
6

Actions

Likes
2
Downloads
0
Comments
0

2 Embeds 6

http://www.linkedin.com 5
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • When a programmer says, "I don't want to estimate my tasks," he generally isn't talking about technique. He already estimates, but doesn't want to reveal what he really thinks for fear of providing a fixed point of judgment that will be used against him later. Better triple that estimate! Refusing to communicate estimates reveals something much deeper about how he sees the social forces in development. Perhaps he doesn't want to be accountable because he has been blamed unfairly in the past. In this case, the programmer values protection over communication.
  • When I hear a programmer brush off a defect, I hear a failure of values, not technique. The defect itself might be a failure of technique, but the reluctance to learn from the defect shows that the programmer doesn't actually value learning and self-improvement as much as something else. This is not in the best interest of the program, the organization, or the programmer. Bringing values together with practices means that the programmer can perform a practice, in this case root-cause analysis, at effective times and for good reasons.
  • COMPANY CONFIDENTIAL
  • COMPANY CONFIDENTIAL
  • COMPANY CONFIDENTIAL
  • COMPANY CONFIDENTIAL
  • COMPANY CONFIDENTIAL
  • COMPANY CONFIDENTIAL
  • COMPANY CONFIDENTIAL
  • COMPANY CONFIDENTIAL
  • COMPANY CONFIDENTIAL
  • COMPANY CONFIDENTIAL
  • COMPANY CONFIDENTIAL
  • It is important to note that agile planning is multi-tiered to regulate the level of detail in accordance with the HOP. Vision – sail off into the sunset Roadmap – get out into the ocean; open waters Release – get through the straight Sprint – avoid that island Daily - go between the two buoys COMPANY CONFIDENTIAL
  • COMPANY CONFIDENTIAL
  • Refer Hofstede’s dimensions for distributed work
  • Novice rigid adherence to taught rules or plans no exercise of "discretionary judgment“ or context Advanced Beginner limited "situational perception” – has context but needs rigid guidelines all aspects of work treated separately with equal importance Competent "coping with crowdedness" (multiple activities, accumulation of information) some perception of actions in relation to goals – questions reasoning behind the tasks and can see consequences deliberate planning, formulates routines Proficient holistic view of situation prioritizes importance of aspects perceives deviations from the normal pattern employs maxims for guidance, with meanings that adapt to the situation at hand Expert transcends reliance on rules, guidelines, and maxims intuitive grasp of situations based on deep, tacit understanding has "vision of what is possible“ uses "analytical approaches" in new situations or in case of problems

Agile Rendezvous Presentation Transcript

  • 1. Agile Rendezvous
  • 2. Speaker Profile
    • Focus on helping build an organization culture to "be agile" rather than "follow Agile".
    • Achieve business agility delivered through agile software products and services
    • Achieve software agility delivered by agile teams
    • Achieve team agility supported by an agile organization / enterprise agility
    • Agility Services
    • Software Craftsmanship
    • Midas Touch - Agility in software maintenance
    • Agile Enterprise Architecture solutions
    • Agility Nurseries (Agile ODC)
    • Organization Metamorphosis
    • Agility Assessment Radars and Roadmap
      • Team Agility Assessment
      • Value Stream Mapping
      • Shared Vision and Team Chartering
    • Team Agility Coaching, Executive Coaching
      • Scrum Coaching
      • XP Engineering Practices Coaching
      • Lean Software Development Coaching
  • 3. Don't bring me solutions, show me the problem first ! (Can we name the problem we are trying to solve by Agile?)
    • Business Risks – The Problem
    • Slow rate of development response to business change
    • Slower concept (initial customer request) to cash (delivery of business value) throughput .
    • Delivered systems falling short of customer needs and/or expectations.
    • Quality compromised for timely delivery of released software.
    • Failing to deliver projects as per cost and schedule commitments.
    • Strained, arms-length relationships between business and software development. (“us” and “them”)
    Where all think alike, no one thinks very much -- Walter Lippman
    • Being Agile - The Solution?
    • Is Agile a Silver Bullet - A One-stop solution - a plug-in formula to solve the problem?
    • Is the solution to follow A gile or is it to be a gile?
    • Being agile is designing a process to fit people rather than fitting people to the process.
    • Developing agile working habits requires change at three levels -
      • Culture
      • Top-down
      • Bottom-up
  • 4. Agility and Software Development Values bring purpose to Practices ; Practices are evidence of Values and bring accountability to Values . Principles are context specific guidelines that link Practices to Values . Conflicts in Practices can be analyzed and resolved by mapping to the underlying Values and Principles . Being agile in software development is to design and deploy software development practices that inculcate the true values and principles mentioned in the Agile Manifesto and the Software Craftsmanship Manifesto.
  • 5. Values , Practices and Principles : Relationship Interpreting Value rather than Practice I won’t reveal the estimate as I would be held accountable and blamed unfairly like in the past. I value Protection over Communication I don’t want to estimate.
  • 6. Values , Practices and Principles : Relationship Failure of Value rather than Practice I am reluctant to learn from the defect. I did not try to find root cause for the defect. I value Laziness over Learning and Self Improvement Oops, a defect. Ignore it. I will fix it when tester reports it.
  • 7. Agile Manifesto The skill of writing is to create a context in which other people can think. Edwin Schlossberg Manifesto
  • 8. Agile - One Page Definition Being agile in software development is to design and deploy software development Practices that inculcate the true Values and Principles mentioned in The Agile Software Development Manifesto & The Software Craftsmanship Manifesto.
  • 9. Required Mindset Change
    • Embracing agility as part of their software development lifecycle is the key enabler of the ability to respond to the constantly changing market and business needs.
    • Factors to consider when comparing traditional mindset with agilist mindset :
    • Leverage business core competencies by “timing” the deployment of software products and services right based on the ability to release on a more faster time-to-market basis
    • Focus on getting an accurate alignment of software functionality to user needs by calibrating user expectations based on a continuous feedback cycle
    • Create value in the form of increasing revenue, reducing cost, and gaining competitive advantage based on an incremental and iterative software development technique
    • Ability to respond to change needed in an ever changing market
    • Continuous attention to technical excellence in software release quality
  • 10. Change is constant - Reducing Cost of Change INDIA
  • 11. V-Model to I-Model (Changing a “waterfall” verification and validation testing mindset to test-driven defect prevention mindset) INDIA Acceptance Test Driven Development (Executable Requirements) Automated Integration Testing (Interface Driven High Level Design) Unit Test Driven Design (Low Level Design) Unit Test Driven Development (Implementation)
  • 12. Planning Terminology INDIA
    • Lets understand the terms and their relationship -
    • Planning
    • Estimation
    • Target
    • Control
    • Commitment
  • 13. Estimation & Planning INDIA
    • Estimation
    • unbiased, analytical process
    • goal – accuracy
    • Planning
    • biased, goal-seeking process
    • goal – seek a particular result
    Estimate is the foundation of a plan, plans don't have to be the same as the estimates. Estimation Planning depends on Plan Estimate
  • 14. Estimate, Target, and Commitment INDIA
    • Estimate is a prediction about how long or how much cost
    • Target is a statement of a desirable business objective.
    • Commitment is a promise to deliver defined functionality at a specific level of quality by a certain date.
    • It is dangerous to expect the estimate to come out with any particular answer. We deliberately (and appropriately) bias our plans to achieve targets.
    Estimation Planning depends on Plan Estimate not to seek a particular target goal seeking Biased towards achieving Target Commitment
  • 15. INDIA Planning Basics Estimation Planning depends on goal seeking not to seek a particular target Plan Scope Budget / Resources Schedule [Risk] [Depth] Control Biased towards achieving Estimate Target Commitment + –
  • 16. INDIA Cone of Uncertainty
  • 17. INDIA Fallacy of the Iron Triangle Scope (Features) Cost Schedule Quality ?
  • 18. INDIA Elastic Triangle Scope (Features) Cost Schedule Quality Scope (Features) Cost Schedule Quality
  • 19. INDIA Planning is a continuous activity (Progressive Elaborative Planning) Planning supports and embraces change Just-in-time planning Feature based NOT Activity based What is Different?
  • 20. INDIA The Horizon of Predictability
    • The further from the present, the less certain we can be about anything
    • In agile planning, the level of detail increases as (product and project) knowledge grows.
    • This is a realistic and efficient view of the horizon of predictability.
  • 21. 5 Levels of Planning INDIA Daily Sprint Release Roadmap Vision
  • 22. 5 Levels of Planning INDIA Daily Sprint Release Product Vision Team Product Owner, Team Product Owner, Stakeholders, Team Product Owner Executive Mgmt. Product Management Why? What? When? How?
  • 23. Agility Solutions For Offshore Challenges
        • Transition
        • Operational Integration
        • Quality and Standards Control
        • Communication
        • Management and Governance
    Results In Lack of
      • Trust
      • Coordination
      • Feedback
      • Visibility
      • Motivation
      • Productivity
    Solved Using Agile Techniques
        • Short cycles
        • Incremental delivery of working software
        • JIT requirements elaboration
        • Daily, direct customer involvement
        • Lightweight design modeling
        • Continuous Integration
        • Continuous Testing
        • Continuous Deployment
        • Real time technical and management dashboards
  • 24. Lean Values, Principles and Practices
  • 25. Development Practices Lightweight Agile Model Driven Development (AMDD), Test Driven + Behavior Driven Development (TDD + BDD), Continuous Integration (CI)
  • 26. Agile Testing
  • 27. Enterprise Architecture Agility
    • Application architecture – Application components structured to represent the business needs with consideration to all of the internal and external interfaces required.
    • Infrastructure architecture – Designing underlying infrastructure components that accommodate the business needs with consideration to the relationships and connectivity to both internal and external services. 
    • Information or data architecture – Organizing data both logically and physically to meet the transactional and reporting needs of the business taking into consideration interfaces to both internal and external data providers and subscribers.
    • Applying an enterprise architecture strategy to the business of IT will enable internal IT organizations to:
    • Prioritize projects,
    • Manage internal and external resources,
    • Align services to business needs,
    Enterprise Architecture (EA) View
    • Assess and manage risk,
    • Minimize business disruption,
    • Manage and report on service levels.
  • 28. Value - Individuals and Interactions Build projects around motivated individuals . Give them the environment and support they need, and trust them to get the job done. The best architectures, requirements, and designs emerge from self-organizing teams . At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (Retrospective)
  • 29. Extrinsic and Intrinsic Motivation
    • My Survival Cycle Persona - Others define My identity
      • I am fearful and reactive .
      • I react to and avoid obstacles.
      • By doing this, I reinforce my old strategies for coping , conspiring , adapting , and assimilating when difficulties arise. (All fear-based responses)
      • My purpose is not fulfilled and I feel disappointed .
      • As a life-long habit, this approach is limiting , lacks purpose and meaning .
    • My Creative Cycle Persona - I define My identity
      • I am excited about possibilities to connect with my strengths , talents , and gifts .
      • I look at obstacles as opportunities to observe , reflect , experiment and learn .
      • My experiments align to my actions with purpose and potential .
      • When I achieve the desired result, I feel fulfilled and celebrate my successes.
      • But, it is very difficult for me to be in Creative Cycle all the time.
      • I tend to fall back to my Survival Cycle.
      • Tune the mind and conscience to be in the Creative Cycle (Intrinsic Motivation).
  • 30. Natural vs. Coercive Self-Organizing
    • Examples of naturally self-organizing systems
    • homeostasis (the self-maintaining nature of systems from the cell to the whole organism)
    • pattern formation and morphogenesis, or how the living organism develops and grows.
    • the coordination of human movement
    • the creation of structures by social animals, such as social insects (bees, ants, termites), and many mammals
    • flocking behavior (such as the formation of flocks by birds, schools of fish, etc.)
    • the origin of life itself from self-organizing chemical systems
    • Its in the genes !!!
    • How can we apply this principle into a practice to self-organize in agile context?
    • Self-organization in teams can be taught …….
  • 31. Self-organization Practices
    • Apprenticeship over Classroom Training
    • ( Tacit Knowledge ) ( Explicit Knowledge )
    • Collaboration over Document Handoff - ( for Knowledge Management )
    • Argumentation over Passive Acceptance - ( for Logical conclusions )
    • Constructive Conflict Mining over Artificial Harmony
    • Aggregating Team Intelligence over Intelligence of Individuals
    • Psychological distance solvent over Geographical distance solvent
  • 32.
    • Traditional Conduit Co-ordination
    Geographical Distance Solvent Customer Development Team Onsite Coordinator Offshore Manager / Lead
    • Peer-To-Peer Co-ordination
    Customer Development Team Onsite Facilitator Offshore Facilitator
  • 33. Psychological Distance Solvent Traditional Team Hierarchy (Crowns) to Cross-Functional Roles (Caps) Project Manager Tech Architect Test Architect Tech Lead Data Architect Designer Developer Business Analyst Test Lead Test Analyst Automation Tester
      • Crowns
      • Creates and widens gap
      • Restricts knowledge sharing
      • Builds up power distance
      • Steep learning curve for increase in maturity
      • Caps
      • Can be swapped depending on situations
      • Increase sense of collective ownership
      • Rotation of responsibilities
      • Open culture within the team
  • 34. Problem - Team Dysfunction Model - Patrick Lencioni
  • 35. Solution - Team Leadership Model
    • Team Leadership is a condition of a team
      • reduction of uncertainty ( Constructive Conflict Mining )
      • comes from clear messages ( Argumentation before Commitment )
      • leads to focused actions that cannot easily be misinterpreted ( Aggregating Team Intelligence for Collective Accountability )
      • developing channels for continuous feedback ( Collaboration against Blame games )
      • uniform effort balance - sustainable pace
      • having a very high fun factor
  • 36.
    • Followers
      • Initial guidance needed to come up to speed
      • Show progress after some hand holding
      • Need to be mentored to grow into volunteers
    • Volunteers
      • Self inspired
      • Take technology and process initiatives
      • Come up with ideas that build the team
      • Implement innovative concepts
      • Lift the team
    • Mentor
      • Servant Leader
      • authority used to serve the needs of others
      • genuine compassion for his people
      • knows the problems of the community as a whole
      • finds the solution to the problem
      • has the skill to carry out the solution
      • develop the next generation of leaders
    Shu-Ha-Ri Pattern In Team Members
  • 37.
    • Leaders do
      • Encourage the hearts of “followers”
        • Help build confidence and expectations of followers
        • Equip them and be their mentor.
        • Grow “followers” into “volunteers”.
      • Value and recognize “volunteers” as VIPs
        • Affirm / Affirm / Affirm your volunteers
        • Challenge volunteers to stretch and grow
        • Grow “volunteers” into mentors.
    “ The great leader is first experienced as a servant to others. ” - Robert Greenleaf, Servant Leadership Leader Apprenticeship
  • 38. “ Software Craftsmanship is all about putting responsibility and pride back into the software development process. ” “ The best processes in the world will not save a project from failure if the people involved do not have the necessary skills to execute the process; conversely, really good developers can make any process work” “ A Software Craftsman is a continuous learner. When he doesn’t work, he spends his time studying, to find new methods and tools can refine him as a Software Craftsman” - Pete McBreen, Software Craftsmanship: The New Imperative Developer to Craftsperson What is Software Craftsmanship?
    • Software Craftsmanship is about
      • Taking responsibility
      • Taking pride in work
      • “ Signing” your work
      • Being a continuous learner
      • Practicing deliberately
      • Writing code
      • Having the right attitude
      • Contributing to the community
  • 39. Developer to Craftsperson through Apprenticeship How should I become an expert in software craftsmanship?
    • Read and understand the concepts in the book on Apprenticeship Patterns
    • - David Hoover, Adewale Oshineye
    • Find a mentor
    • Study, Train and Practice
      • Performing Code Katas
      • Performing Coding Dojos
      • Performing Acceptance-Test based
      • Learning TDD
      • Learning programming paradigms –
      • functional, dynamic, statically typed languages
      • Refactoring – keep your code healthy
      • Learning design patterns, tools and frameworks
      • Learning emergent design, evolutionary design
  • 40. Developer to Craftsperson How will I know the learning levels in software craftsmanship?
    • Dreyfus Model of Skills Acquisition
    • Novice - Needs to be told exactly what to do. No context to work from.
    • Advanced Beginner - Has more context, but needs rigid guidelines
    • Competent - Questions reasoning behind the tasks and can see consequences
    • Proficient - Still relies on rules, but can separate what’s important
    • Expert - Works mainly on intuition, except when problems occur
  • 41. Finding Your Own Identity is about Meta morp hosis (Shu – Ha – Ri) From Developer (Crawling Caterpillar) to Craftsman Leader (Soaring Butterfly) Collaboration Argumentation Conflict Mining Team Intelligence Psychological Distance Solvent Apprenticeship Creative Cycle Continuous Learner Deliberate Practice Right Attitude Community Contributor Follower  Volunteer  Mentor Pride (“Signing” Your Work) Responsibility To Follow Agile  To Be agile Novice Advanced Beginner Competent Proficient Expert
  • 42.
    • Team Agility Baseline (Assessment Framework)
        • Purpose
    • The purpose of the Agility Baseline is not to “grade” the team, but to provide an action plan for improving their Agile process and practices. By baselining the team at the beginning of a process improvement cycle and at significant points thereafter, team maturity can be tracked and made visible.
    • The Agility Baseline would:
    • Provide a thorough evaluation of Agile team practice and process against current best practices and common guidelines.
    • Provide process improvement based on outcome that identifies which practice or process changes would have the most impact on productivity.
    • Provide a detailed action plan for the next steps in process improvement for that team.
        • Participants
    • Project Manager & Scrum Master, who perform strategic and tactical planning and tracking for the team.
    • Product Owner & Lead Analyst, who define and prioritize the team’s goals, requirements, and acceptance criteria
    • Lead Developer & Lead Tester, who led the efforts to build and validate the team’s product.
    • In addition to these active participants, the members of the team are passively engaged through observation and interaction with the Agile Coach exploring best practices.
    • Some outside observers of the team’s process, who may include: subject matter experts, line managers, discipline experts, or other governance body members.
    • Deliverables
    • Agile Coach shall deliver the following:
    • Retrospective meetings at the end of each agile development sprint that include Agile Coach, Scrum Master, Product Owner, Management Leadership and Agile Transformation Leader.
    • Performance reports at the end of each agile development sprint that includes a quantitative assessment of the development team’s performance against its commitments.
    • Written recommendations at the end of four months for improving the performance of RRF development teams which could include changes in the development teams and/or perpetual coaching (internal / external).
    • Weekly Timesheets, Expense Reports, Service Activity Reports, and other Project Management Documentation as required.
    • Applicable Project Documentation and/or Reports
    Team Agility Baseline and Deliverables
  • 43. Proposed Approach for Agility Transformation Duration / Objective Activity Month 0 (Initial Assessment for Agility)
    • Based on agility axis parameters (requirements, planning, design, development, testing, governance, collaboration), prepare an assessment of the existing teams
    • Prepare initial Agile Transformation backlog and prioritize the same (Based on initial assessment)
    • Facilitate preparing a list of teams for agility coaching
    Month I (Focus on Agile Fundamentals Training, Agile Transformation Planning, and Defining a collaboration infrastructure)
    • Deliver Agile / Lean / Scrum / XP Fundamentals concepts training
    • Conduct Agile Leadership Workshop, focused on developing a concrete Agile Transformation Vision and set of supporting metrics to measure desired business results (Business Agility, Lean Roadmap and Agile Enterprise Architecture)
    • Detail Agile Transformation Roadmap prepared in Month 0 and prioritize Agile Transformation Backlog factoring in Agile Leadership Workshop result (Based on existing processes and lean / agile values / principles to be introduced)
    • Facilitate definition / refinement of distributed team’s infrastructure for agile development (e.g., common usage of SVN, Wiki, and Bug Tracking).
    Month II (Focus on Sprint cadence, Product Backlog Grooming, Estimating and Planning, Writing Acceptance Criteria, Definition of Done)
    • Conduct Iteration 0 (focused on solidifying initial Product Backlog Grooming) (Requirements Management – Use Cases, User Stories, Acceptance Criteria, Definition of Done)
    • Validate setup of distributed team’s infrastructure for agile development (e.g., common usage of SVN, Wiki, and Bug Tracking)
    • Conduct Iteration 1 (Focus on Team Agility practices)
    • Perform initial Software Agility Practices Team maturity assessment, and review results with team(s)
    • Perform Agile Transformation Backlog grooming, based upon the results of the initial Software Agility Practices Team maturity assessment
    • Create project pages in shared wiki, identify key documentation and provide guidance on the granularity of information radiators required
    Month III.. Month (N-1) (Focus on introducing advanced Agile Engineering Practices such as ATDD, pair programming and CI)
    • Conduct Iterations 2 & 3
    • Perform Software Agility Practices Team maturity assessment, and review results with team(s)
    • Perform Agile Transformation Backlog grooming, based upon the results of the initial Software Agility Practices Team maturity assessment
    Last Month of engagement (Focus on solidifying practices, refine Agile Transformation Backlog to support ongoing Continuous Improvement)
    • Conduct Agile Transformation Leadership Retrospective
    • Perform final Software Agility Practices Team maturity assessment, and review results with the team .
    • Deliver final engagement report
  • 44. Thank You www.stixis.com