• Save
Building an Agile framework that fits your organisation
Upcoming SlideShare
Loading in...5
×
 

Building an Agile framework that fits your organisation

on

  • 572 views

Workshop delivered at Agile Australia 2012

Workshop delivered at Agile Australia 2012

Statistics

Views

Total Views
572
Views on SlideShare
569
Embed Views
3

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 3

http://www.linkedin.com 3

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
  • Introduce Rick and Kurt – backgrounds and experience – include internal IBM but emphasise CUSTOMER experience Quick overview of IBM’s credentials – yes we may be one of the largest organisations in the world but we too started small – small projetcs
  • Where did we come from? What was it like in early days Informal adoption since early 2000s, likely earlier Official adoption program started in 2006 Multi-faceted strategy Adoption of agile techniques Adoption of lean philosophies Increased reuse and asset management Leveraged existing IBM improvement group, Quality Software Engineering (QSE) Adoption of new collaboration and development products (including Jazz and Lotus products) Improvement of the governance process to reflect agile strategies Approach included Training and education at all levels in SWG, including practitioners, middle management, and senior management Mentoring/coaching at all levels, particularly on project teams This is a long-term, multiple-year strategy which is still underway Process improvement is continuous
  • Significant changes in project roles Traditional roles have mostly disappeared Agilists are generalizing specialists with a wider range of skills Significant culture change Focus on delivering visible value to stakeholders regularly Focus on high-value activities Agile teams are self organizing Disciplined agile teams are governed appropriately Quality focused Collaborative and evolutionary Agile adoption is a paradigm shift Multi-year, ongoing effort People and cultural issues are critical Insufficient support for the effort You must invest in training, mentoring, and coaching You must consider investing in new tooling
  • In the early days, agile development was applied to projects that were small in scope and relatively straightforward. Today, organizations want to apply agile development to a broader set of projects. Agile needs to adapt to increasing complexity. Agility@Scale is about explicitly addressing the complexities that disciplined agile delivery teams face in the real world. The agile scaling factors are: Geographical distribution. What happens when the team is distributed within a building or across continents? Team size. Mainstream agile processes work well for small teams (10-15), but but what if the team is fifty people? One hundred people? One thousand people? Compliance requirement. What if regulatory issues – such as Sarbanes Oxley, ISO 9000, or FDA CFR 21 – are applicable? Domain complexity. What if the problem domain is intricate ( such as bio-chemical process monitoring or air traffic control), or is changing quickly (such as financial derivatives trading or electronic security assurance). More complex domains require greater exploration and experimentation, including but not limited to prototyping, modeling, and simulation. Organization distribution. Sometimes a project team includes members from different divisions, different partner companies, or from external services firms. Technical complexity. Working with legacy systems, multiple platforms, or blending disparate technologies can add layers of technical complexity to a solution. Sometimes the nature of the problem is very complex in its own right. Organizational complexity. The existing organizational structure and culture may reflect traditional values, increasing the complexity of adopting and scaling agile strategies. Different subgroups within the organization may have different visions as to how they should work. Individually, the strategies can be quite effective, but as a whole they simply don’t work together effectively. Enterprise discipline. Organizations want to leverage common infrastructure platforms to lower cost, reduce time to market, and to improve consistency. They need effective enterprise architecture, enterprise business modeling, strategic reuse, and portfolio management disciplines. These disciplines must work in concert with, and better yet enhance, the disciplined agile delivery processes. Each scaling factor has a range of complexities associated with it. Each team faces a different combination of factors, and therefore needs a process, team structure, and tooling environment tailored to meet their unique situation.
  • No support for skills development Your organization needs to invest in coaching, training, and education Agile in name only You need to do more than read a book or attend a workshop to become agile Only focusing on construction Agile applies to the full delivery lifecycle Thinking that you’re special If you think that you can’t become more agile, you are very likely mistaken
  • To achieve systemic improvement within an IT organization, you need to address five primary issues: People. Solution delivery is a “team sport”, individuals and the way that they work together are the primary determinants of success on most projects. Principles. You need a consistent and coherent philosophical foundation which reflects your values as an organization to guide your decisions. Practices. Practices are contextual, describing how people work together to achieve a goal. Products. The tools and technologies which people use to perform their work. Process. The “glue” which pulls everything together. See https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/5pofit?lang=en_us
  • Agile roles are different than traditional roles, even though they may sound similar to what you are used to. Many organizations struggle to adopt agile effectively because they’re not willing to make the changes necessary to support these new roles. This is an example of the “Organizational Complexity” scaling factor. Agile principle # 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Building an Agile framework that fits your organisation Building an Agile framework that fits your organisation Presentation Transcript

  • ork ile fr amew ga n Ag ationBu ildin r :org anis sreyenurs ip p s o te akt hfo t htWor s rt Sola rte r Ku and Rick Weave 2 May 201 th ay 29 Tuesd
  • Building a smarter planet Agenda  Welcome and introductions  Activity  Learning from IBM’s transformation to agility@scale  Anti-patterns and scaling factors to look for  Addressing the 5 Ps of IT Driving Business  Activity Differentiation  Insights to help you build your framework  Action Plan  Your guide to building an Agile framework that fits your organisation  Feedback © 2009 IBM Corporation 2
  • Building a smarter planet Learning objectives and expected takeaways  Understanding of the critical anti-patterns and scaling factors that inhibit scaling Agile within organisations large and small  Strategies and tactics to overcome challenges faced Driving Business  Action plan to build a flexible Agile framework that fits yourDifferentiation organisation © 2009 IBM Corporation 3 View slide
  • Building a smarter planet © 2009 IBM Corporation 4 View slide
  • Building a smarter planet Our Journey to Agile… © 2009 IBM Corporation 5
  • Building a smarter planet Was a bit daunting at first… © 2009 IBM Corporation 6
  • Building a smarter planet But through Teamwork… © 2009 IBM Corporation 7
  • Building a smarter planet No Fear of Heights © 2009 IBM Corporation 8
  • Building a smarter planet And a Clear Focus on Destination © 2009 IBM Corporation 9
  • Building a smarter planet We found our way to Success! © 2009 IBM Corporation 10
  • Building a smarter planet …and We Proved that Elephants CAN dance! © 2009 IBM Corporation 11
  • Building a smarter planet Measuring Improvements… 2006 2011 Metric Measurement Measurement On Time Delivery 47% 95% Defect Backlog 9+ Months 3.5 months Enhancements Triaged 3% 100% Enhancements into Release 1% 21% Customer Sat Index 88% 96% Beta Defects Fixed Before 3% 94% GA % of Agile Projects 5% 78% © 2009 IBM Corporation 12
  • Building a smarter planet Some of the Challenges IBM faced… Complexity Challenges Team Challenges  More granular service functionality  Geographically dispersed teams in composite business applications  Large number of projects and  Effective cross-organizational assets (coming from all different visibility and synchronization, sources) sharing becomes an imperative Process Challenges Tools Challenges  Blind adherence to process insensitive  Lack of standards impacts ability to collaborate, automate and report to potential business trade-offs across teams and assumptions  Need for agility at scale  Frequent asset updates and changing interdependencies © 2009 IBM Corporation 13
  • Building a smarter planetKey Principles We Learned (Inspired by LEAN) Eliminate Waste Build Quality In Defer Commitment Deliver Fast • Value Stream Maps • Foundation Disciplines Keep options open Queuing theory • Complete Solution • Continuous Validation Focus on Learning Respect People Optimize the Whole Product & process • Teams • Systems thinking • Partners • Set-based design © 2009 IBM Corporation 14
  • Building a smarter planetAgile Scaling Factors Team size Compliance requirement Under 10 1000’s of Critical, Low risk developers developers audited Geographical Domain Complexity distribution Straight Intricate, Co-located Global -forward emerging agility@ Enterprise discipline scale Organisation distribution Project Enterprise (outsourcing, partnerships) focus focus Collaborative Contractual Organisational complexity Technical complexity Flexible Rigid Heterogeneous, Homogenous legacy © 2009 IBM Corporation 15
  • Building a smarter planet Common anti-patterns No support for skills development Have you invested in coaching, training and education Agile in name only Agile adoption is a paradigm shift Only focusing on construction Have you applied agile practices to the full delivery cycle? Thinking that you’re special Do you think you can’t become more agile? Interesting © 2009 IBM Corporation 16
  • Building a smarter planet Scaling Agile - Our point of view  Each organisation is different and faces a unique set of challenges  A one size fits all approach to adopting Agile practices may not be appropriate  Do what is practical for your team  The ability to understand and prioritise business objectives and track your success in achieving them is key to success  Your Agile transformation is an ongoing journey that needs constant review and refinement © 2009 IBM Corporation 17
  • Building a smarter planet © 2009 IBM Corporation 18
  • Building a smarter planet Reviewing your organisation Scaling Factors Anti-Patterns  Our team size is growing/is already large  We have no support for skills development  Our team is distributed geographically  We are Agile in name only  Enterprise focus is needed, we used to get by on focusing on projects  We are only focusing on construction  Our organisational structure is complex  We think we have achieved all  We have complex compliance there is to achieve with Agile requirements practices  Our technical environment is complex  Our partnering relationships are complex  Our problem domains are complex © 2009 IBM Corporation 19
  • Building a smarter planet © 2009 IBM Corporation 20
  • Building a smarter planetOrganisational Adoption: Address the “5Ps” of IT1. People2. Principles/Philosophies3. Practices/Patterns4. Products5. Process © 2009 IBM Corporation 21
  • Building a smarter planet © 2009 IBM Corporation 22
  • Building a smarter planetAgile changes your relationship with the business Your business and development processes must reflect one another – Plans must be high-level with the details coming just in time (JIT) – Schedules and estimates must be given in ranges – Traditional business approaches will eliminate most benefits of agile The new relationship with the customer: – They must be actively involved with development all the way through the lifecycle – The greater visibility and control that they now have implies the need for greater accountability on their part – They often don’t understand the implications of what they ask for, you need to educate them © 2009 IBM Corporation 23
  • Building a smarter planetAgile changes your relationship with the business Common problem: Customers don’t want to be actively involved with development, not realising that they increase project risk – The customer must be involved with development projects on a daily basis – The customer must provide information and make decisions in a timely manner Suggested strategy: – Help your customers to understand what is expected of them and why – Customer decision makers need to be coached too – Be selective about the projects you apply agile strategies to. If the customer isn’t willing to step up then the project isn’t a good choice for agile © 2009 IBM Corporation 24
  • Building a smarter planet Pulling it all together with planning & governance  Treat agile adoption like an agile project – Have a release plan – Have iterations where you deliver something regularly – Demo your results, both successes and failures – Reflect on what you’ve learned and steer the project accordingly © 2009 IBM Corporation 25
  • Building a smarter planetOur Strategy for Agile TransformationWaves of Change Today Future Wave 1 Wave 2 Wave 3 Vision Change Change Change Initiative / Initiative Initiative Project Introduces 1 or more development Agree Scope Train, Pilot, Harvest, Roll out wider Final Roll Business capabilities Business Case Package, Test scale out As Usual High Level Plan Define Results Development Projects [Best Practices for Transformation]  Adopt process & tools incrementally in projects  Support project teams with just-in-time training & mentoring to accelerate learning/adoption  Demonstrate quick-wins from projects.  Develop internal SMEs/Mentors who deliver mentoring to project team via CoE/Tools Group © 2009 IBM Corporation 26
  • Building a smarter planet Five Best Practices for Driving Change Outside-in Development Design Processes Componentization Communities and and Reuse Community Source Measurements and Reporting 27 © 2009 IBM Corporation
  • Building a smarter planet Our Approach for Agile Governance = Managing Uncertainty and Managing Variance  Scope is not a requirements document, it is a continuous negotiation Plans/Resource estimates Scope Product features/quality  A plan is not a prescription, it is an evolving, moving target Uncertainty in Stakeholder Satisfaction Space Initial State Initial Plan Actual path and precision of Scope/Plan © 2009 IBM Corporation 28
  • Kick off29 Initial release planning Indentify assets for reuse / sourcing (incl. documentation) Warm-up 2-6 weeks Building a smarter planet High level architecture Requirement confirmation release sprint planning Develop and stabilize Sprint1 2-4 weeks Demo plan sprint planning Sign-off Retrospective Project Timeline Template Develop and stabilize Sprint 2 2-4 weeks Demo sprint planning Sign-off On going Retrospective … Develop and stabilize 2-4 weeks stabilize Demo Finalise release testing Sign-off Retrospective Hand -over assets (incl. documentation) Technical implementation 2-4 weeks Roll -out organisational Implementation implementation Sign-off © 2009 IBM Corporation
  • Building a smarter planetBut What Should We Measure?An Example Set of Candidate Agile Metrics..lots ofpossibilities! Executive Dashboard Project Health Customer Quality Development Quality Strategic Health  Defect Backlog  Transactional Survey  Defect Backlog  Sales Plays  Defect Density  PMR / Call Rates  Test Escapes  Partner Enablement  Defect Repair Latency  Critical Situations  Functional Test Trends  Critical Situations  Support Enablement  Build Health  Cost of Support  System Test Trends  Technical Enablement  Project Velocity  Installability  S-Curve Progress  Sales Enablement  Staffing Actuals  Enhancement SLA  Automation Percentage  Localization  Process Timeliness  Useability  MCIF Index  Milestone Status  Consumability  Customer Testcases  Competition  Severity Analysis  Perceived Performance  Integrated into Story  Security Vulnerabilities  Scalability  Consumability Scorecard  Green Threads  Static Code Analysis  Integrations with other  LCM  Requirements Met products  Defect Latency  Pipeline / Multiplier  IPD Timeliness  User Experience / Doc  Quality Plan Commitments  Test Coverage  Revenue Time to Resolution Evolutionary Architecture Vulnerability Assessment Practices Test Driven Development Whole Team Concurrent Testing Requirements Management Team Change Management © 2009 IBM Corporation 30
  • Building a smarter planet Measures Help Answer Key Questions Business-Related IT-Related Agile-Related Measures Measures Measures Appropriate level Projects deliver of management Agile practice faster than today and analysis adoption activities Are we meeting Projects deliver Are we seeing Efficient change Are we agile? Agile role with lower overall business cost than today the benefit request process adoption objectives? created Systems where we Efficient Agile work requirements or updated in the projects have the expected? definition and product adoption agreed quality signoff The development Fewer breakages organisation is a when solution Agile task learning elements are adoption organisation integrated Employee Less “solution Agile process satisfaction hardening” needed adoption © 2009 IBM Corporation 31
  • Building a smarter planet Key Project Performance Metrics: Agile View (all reported by common reporting period) Delivery Rate vs. Plan Scope Change Rate Burndown/Velocity (Add, Modify, Remove) t 140 h 120% t 160 g h i 120 100% g i 140 e e W 100 W 120 y 80% y b b 100 s 80 s e e r r 60% u 80 u t 60 t a a e 40% e 60 F F 40 e t e t a 40 g a 20% g 20 e r 20 e r g g g g 0 0% A 0 A 1 2 3 4 6 5 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13 Reporting Period Reporting Period Velocity: Plan – – – Optimistic – – – Best Guess – – % Pessimistic – – – Planned Features Delivered Features – of Plan To-Date Baseline Features Added / Modified Features Removed Features Actual Burndown (Features Remaining) Delivered in Period Delivery / Labor Cost Performance Integration Test Quality 350% 140% (High Severity Defects) 300% 120% 250% 100% 200% 80% 150% 60% 100% 40% 50% 20% 0% 0% 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 5 4 6 7 8 9 10 11 12 13 Reporting Period Reporting Period % Defects Open Defect / Test Run Ratio % of Plan To-Date % of Plan Spend Rate Cost EAC % Projection % Test Cases Run In Period Feature / Test Run Ratio This is a sample view. Metrics can take different forms. The intent is ensure that the charts address core management concerns and associated questions. © 2009 IBM Corporation 32
  • Building a smarter planet Agile Performance Metrics: Core Answers (all reported by common reporting period) Delivery Rate vs. Plan Scope Change Rate Burndown/Velocity (Add, Modify, Remove) t 140 h 120% Are scope changes t 160 g 120 h i e Are we on schedule? 100% g i 140 e overwhelming our W 100 If not, how far behind? W 120 y b 80% y ability to deliver? b 100 s s 80 e r When will we complete? 60% e r u 60 u 80 t t a a e 40% e F 60 F 40 e t 40 e t a a 20 20% g g e 20 r e r g g g g 0 0% A 0 A 1 2 3 4 6 57 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13 Reporting Period Reporting Period Velocity: Plan – – – Optimistic – – – Best Guess – – % of Plan To-Date – Planned Features Delivered Features – Pessimistic – – Baseline Features Added / Modified Features Removed Features Actual Burndown (Features Remaining) Delivered in Period Delivery / Labor Cost Performance Integration Test Quality 350% 140% (High Severity Defects) 300% Are our estimates good? 120% Do we have enough test coverage and 250% Do we have enough staff ? 100% execution? 200% What will it take to complete? 80% Is the quality of our deliveries good 150% 60% enough? 100% 40% 50% 20% 0% 0% 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 5 4 6 7 8 9 10 11 12 13 Reporting Period Reporting Period % Defects Open Defect / Test Run Ratio % of Plan To-Date % of Plan Spend Rate Cost EAC % Projection % Test Cases Run In Period Feature / Test Run Ratio Here are the key management questions answered by each chart. An inability to answer any of these questions serves as a source of fundamental risk. © 2009 IBM Corporation 33
  • Building a smarter planet © 2009 IBM Corporation 34
  • Building a smarter planet © 2009 IBM Corporation 36
  • Building a smarter planet © 2009 IBM Corporation 37
  • Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 38
  • Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 39
  • Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 40
  • Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 41
  • Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 42
  • Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 43
  • Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 44
  • Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 45
  • Building a smarter planet Addressing the anti patterns © 2009 IBM Corporation 46
  • Building a smarter planet Addressing the anti patterns © 2009 IBM Corporation 47
  • Building a smarter planet Addressing the anti patterns © 2009 IBM Corporation 48
  • Building a smarter planet Addressing the anti patterns © 2009 IBM Corporation 49
  • Building a smarter planet The roles have changed, so must you Traditional roles:  Agile roles: –Analyst –Stakeholder/Customer –Architect –Team Lead/Scrum Master –Database Administrator –Designer –Product Owner –Developer –Agile Team Member –Product Manager –Architecture Owner –Project Manager –Quality Assurance (QA) –Tester © 2009 IBM Corporation 50
  • Building a smarter planet Agile Coaches Good agile coaches – Have deep experience in agile – Have good interpersonal skills – Are respected by their teams based on merit, not on positional status – Are actively involved with the team(s) that they are mentoring, but don’t dominate them – Create an environment where people collaborate and learn together Role and responsibilities of an agile coach – Provide advice to the team – Provide opportunities for people to learn, even through mistakes – Pair with the people they are coaching to provide detailed mentoring – Help teams to solve problems – Negotiate conflicts within the team – Promote self organization and self discipline within the team – Help the team to understand and meet their improvement goals “Growing” your coaches – 1 experienced coach can coach two teams (10 people each) on one project at a time. While doing so, they can also develop one agile coach with each team. – Senior coaches can develop coaches in about 3 months, but typically it takes 6 months to develop new coaches © 2009 IBM Corporation 51
  • Building a smarter planet Agile Champions Good agile champions – Understand the fundamentals of agile – Understand how to apply agile at scale – Understand enterprise-level implications of agile – Are respected by agile teams based on their merit, not positional status – Create an environment where agile teams are given the resources to succeed Role and responsibilities of agile champions – Support the agile coaches – Work closely with the business to help them understand and shift to agile – Work closely with IT senior management to help them understand and adopt agile – Communicate to the organization the current status of the agile adoption, successes, … – Help promote communication between the agile coaches and teams – Promote and defend agile approach in their LoB – Use collected results to show value © 2009 IBM Corporation 52