What makes a Good Agile Team Erik Barnes
What makes a Good Agile Team Erik Barnes erik. barnes@kcc. com
Introduction Kimberly-Clark PMO – Agile COE Using and coaching Agile teams for 4 years We currently have 60+ Agile teams and growing
Agile Teams Agile Workstreams vs Agile Project Agile (Workstreams) Agile Project Never ends Has a Beginning and an End Team size based on investment strategy Team size based on Scope/Money and Timeline Cadence/Ceremonies The Same Used to manage all team workload Used to manage project workload Release Planning (less defined) Release Planning (more defined)
Based on my experience Leadership ◦ Could not deal with not having a comprehensive Plan for the year, including estimates and dates. ◦ Sometimes it’s their leadership ◦ Support to Fail Lack of Trust ◦ Product Owner ◦ Wrong Product Owner (Do they have the right accountability) Multiple Product Owner w/o a single voice Shallow backlog Lack of expertise
What makes a Good Agile Team
Excel Agile Assessment tool Team fit (Self organizing, problem solving, empowered and open minded attitude) Single Owner that is accessible and has the decision rights to the vision Is the team centered around a single product Is there a continuous flow of work or enhancements (i. e strong backlog) Can the team deliver capabilities/ROI incrementally High understanding of tech/solution (Inc Dependencies, sequencing, standards, decomposition) Continuous development, test and integration approach is possible Team Composition and Balance (Cross functional skills, balanced across SA, BA and Dev) Leadership and Senior Stakeholders supports continuous/adaptive planning Team is co-located or can effectively use tools to simulate co-location Resource commitment/utilization is consistent Detailed requirements or Feature priorities may change over time Excel Template
Ideal Agile Team Members Product Owner Product Backlog of new capabilities The Team 1 – Security Update 2 Develops – New EDI form new Product 3 Capabilities –Owner Pricing Config 4 - XXXX The Person a Vision 5 with - XXXX Self Organizing Centered around and can Product (Business Process new or Capability) Prioritize Features Examples: Order to Cash, HR, Warehouse Mgmt, ATR Scrum. Master to Facilitate the Agile Framework
What do you think makes an Ideal Agile Team
Share our Results
2014 ITS State of Agile Survey Results By: Christian Dominguez & Erik Barnes
Respondent Demographics • Months and Years of Practicing Agile Techniques 25% 24% (1 -2 Years) (4 -6 months) 12% (1 -3 months) 32% (7 -12 months) 7% (2+ Years)
Respondent Demographics Roles played by the Respondents Team Member Scrum. Master Roles Team Leader of an Agile Team Other Product Owner Proxy PDCA Kanban Leader Product Owner Never been on an Agile Team 0% 10% 20% 30% 40% 50% 60% 70% Respondents were able to select multiple options • The majority of the respondents were from either the Team, Scrum. Master or Team Leader of an Agile team.
Productivity Improvements Productivity Improvement Percent of People Believe 40% 37% 35% 32% 30% 25% 20% 15% 10% 2% 5% 0% 0% 0 -10% 11%-24% 25%-50% 51%-100% Percent Improvement 100+% Worse • 90% of the respondents believe there was a greater than 10% improvement in productivity, with 71% believing there was a significant (greater than 25%) improvement
Business Alignment Improvements Alignment between IT and Business Priorities Percent of People Believe 35% 29% 30% 25% 20% 22% 17% 15% 10% 5% 0% 0% 0 -10% 11%-24% 25%-50% 51%-100% Percent Improvement 100+% Worse • Over 88% of the respondents believe there is a greater than 10% improvement in Alignment between IT and Business Priorities and Objectives • 22% believe there is over 100% increase in alignment
Team Morale Improvements Team Morale Percent of People Believe 40% 34% 35% 30% 24% 25% 20% 15% 15% 10% 2% 5% 0% 0 -10% 11%-24% 25%-50% 51%-100% Percent Improvement 100+% Worse • 90% of the respondents believe there were improvements in team morale, with 73% believing there was a significant improvement
Managing Changing Priorities Ability to Manage Changing Priorities Percent of People Believe 35% 32% 30% 24% 25% 20% 15% 17% 15% 12% 10% 5% 0% 0% 0 -10% 11%-24% 25%-50% 51%-100% Percent Improvement 100+% Worse • 83% of the respondents believe there were improvements to the speed at which changes were implemented
Visibility of Blockers Percent of People Believe Visibility to Blockers and Items to be Escalated 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% 44% 20% 7% 5% 0% 0 -10% 11%-24% 25%-50% 51%-100% Percent Improvement 100+% Worse • 93% of the respondents believe there were improvements in Visibility to Blockers with 88% of those surveyed believing there was a significant improvement
Time to Market or Completion 83% of the respondents believe there were improvements to the speed at which changes were implemented Time to Market/Completion 40% 34% Percent of People Believe 35% 29% 30% 25% 20% 17% 15% 10% 5% 0% 0% 100+% Worse 0% 0 -10% 11%-24% 25%-50% 51%-100% Percent Improvement
Simplicity in Completing Deliverables Simplicity of Completing Deliverables Percent of People Believe 35% 29% 30% 27% 25% 20% 17% 15% 10% 5% 0% 0% 0 -10% 11%-24% 25%-50% 51%-100% Percent Improvement 100+% Worse • 83% of the respondents believe there were improvements in the simplicity of completing deliverables with 66% believing there was a significant improvement.
Risk and Quality Improvements Risk Reduction Percent Improvement 7% 10% 5% 0% se or W +% 10 0 00 % -1 % 51 -5 0% 0% 25 % se or W +% 10 0 00 % -1 % 51 -5 0% 25 % 11 % 10 0 - -2 4% 0% 15% -2 4% 5% 24% 20% 11 % 15% 24% 20% % 22% 24% 25% 10 24% 30% 0 - 34% Percent of People Believe 40% 35% 30% 25% 20% 15% 10% 5% 0% % Percent of People Believe Software Quality Percent Improvement • Although Risk reduction and Software Quality had improvements, it was not as significant of an improvement as the other areas
Agile Techniques Agile Methods Used Sprint Planning Daily Standups Retrospectives Sprint Review Visual Workboard Burndown Single Focus on Task Release Planning Single Product Owner Shared Estimating PDCA Co-Location Continuous Deployment Kanban Automated Testing Average 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% Respondents were able to select multiple options • Sprint Planning, Daily Standups, Retrospectives and Sprint Reviews are widely used techniques by Agile teams • Areas to focus in on are; Burndown, Release Planning, and Single Product Owner
Barriers to Further Adopt Agile Techniques Dedicated resources Culture None Complexity Waterfall Framework General Resistance Scale Customer Collaboration Management Support Availability of Agile Experience Perceived time Budget Avg 0% 5% 10% 15% 20% 25% 30% 35% Respondents were able to select multiple options • • There is a strong belief that a lack of dedicated resources for the work is a significant barrier to further adopting Agile techniques. The same goes for the ability to change organizational culture. The good news is that Management Support or Availability to Agile Experience is not a significant barrier to adopting Agile techniques
Thanks
- Slides: 23