Deploying a data centric approach to enterprise agility
0 likes173 views
The document discusses deploying a data-centric approach to enhance enterprise agility, emphasizing the importance of measurements, benchmarking, and continuous improvement in agile transformations. It outlines Intel's security products and their engagement in comparative agility as a tool for assessing and improving team performance across various agility dimensions. Additionally, it highlights the necessity of understanding qualitative aspects alongside quantitative metrics to address broader organizational challenges effectively.
Deploying a data centric approach to enterprise agility
- 1. Deploying a Data- Centric Approach to Enterprise Agility Agile 2016, Atlanta Jorgen Hesselberg & Rajan Seriampalayam Intel
- 2. Outline ▪ Introduction ▪ Measurements and their implications ▪ Comparative Agility Overview ▪ Workshop Exercise ▪ Debrief ▪ Q&A
- 3. Intel ▪ Intel is a company that powers the cloud and the billions of smart, connected computing devices that connect to it. From processors, chipsets, memory, SSD, boards & kits to networking, telecom, software, firmware, security and other solutions.
- 4. Intel Security Products • Intel Security provides security products and solutions for consumers, small businesses, enterprises and governments. Security protection on PC to your connected devices and in the cloud. • Enterprise Products • Data Protection & Encryption • Database Security • Endpoint Protection • Network Security • SIEM • Security Management • Web Security McAfee Labs is one of the world’s leading sources for threat research, threat intelligence, and cybersecurity thought leadership.
- 6. Why consider a data-driven approach? ▪ Bench-marking – Are we doing as well as we think we are? ▪ Empirical – Helps us validate whether or not we’re making progress ▪ Informs Strategy – Helps inform our Agile EnterpriseTransformation approach at the team, program and organizational levels ▪ Essential part of continuous improvement – Business agility is not about “becoming agile”, it’s about continuing to be “more agile” over time
- 7. A Comprehensive View of Business Agility ▪ Building the RightThing – Examples: ▪ Customer Satisfaction ▪ NPS ▪ Building theThing Right – Examples: ▪ Quality metrics ▪ Employee engagement ▪ Building at the Right Speed – Examples: ▪ Optimizing for Flow ▪ Time-to-Market, CycleTime
- 8. Measurements Need to be Holistic ▪ Here is a sample set of measures that help us get a rounded perspective of performance and how we’re delivering a great customer experience. – MeanTime Between Build Failures – Story Completions by Sprint (Planned vs actual) – Test automation % and Code coverage – SQALE rating (SonarCube) – Net Promoter Score (NPS) – Comparative Agility
- 9. But data only tells part of the story… Why?
- 10. Understanding the “why” behind the metrics… Method Purpose Observations via Coaching Understand how teams perform in the context of their current environment; identify areas of improvement and share strengths with others in the organization Individual Interviews Structured 1-on-1 interviews with everyone from executives to team members in an open and honest environment; uncover underlying issues not easily observed in coaching Open Space Sessions Theme-based Open Space Sessions with targeted groups; helps identify broader insights Continuous organizational improvement requires deeper interactions in addition to meaningful subjective and objective measures at all levels of the organization
- 11. What is Comparative Agility? ComparativeAgility.com is an independent, third-party instrument and the industry’s most comprehensive Agile assessment tool. Comparative Agility provides companies with a view of how they compare against the industry in the following 8 dimensions of agility: Dimension Description Technical Practices Behaviors and actions that support sound industry-standard engineering practices typically associated with the principles of XP Knowledge-Creating The degree to which teams are embracing the concept of continuous improvement – effectively learning from their experience, evaluating existing processes and always improving their efficiency, effectiveness and flexibility. Planning Focuses on fundamental principles such as prioritization, Product Owner involvement and establishing predictable delivery of value. Outcomes Captures the extent to which team members perceive Agile is providing value relative to the way they used to do their work. Requirements Addresses core Agile and Lean concepts such as just-in-time (JIT) planning, emergent design and focus on customer value. Organizations that perform well in this dimension typically do not spend excessive amounts of time on activities such as documentation, meetings and extensive design sessions and instead focus on “just enough” documentation and design in order to quickly deliver value while being prepared to pivot when necessary. Culture Covers areas such as work/life balance, the perceived degree of stress in the workplace, whether work is performed at a sustainable pace and to what degree the organizational structures have an effect on work Quality Evaluates the degree to which teams have Quality ingrained into the way they do their work. Clearly defined customer acceptance criteria, an end-to-end testing strategy, automation and a commitment to only delivering fully tested code are all best practices that typically lead to higher software quality, fewer defects in production and less rework. Teamwork Addresses the manner in which teams are composed, how they work together as a unit and identifies their patterns of communication.
- 12. An Example – With Real Data ▪ What can we infer? – They have made major improvements in a few areas (Outcomes, Teamwork, Requirements) – Some areas had a slight slip (Planning, Knowledge Creation) ▪ What did we do? – Went beyond the data to better understand what the results were showing us – Examined broader patterns with other teams; shared results at all levels – Collaborated with owners to identify concrete improvement actions (‘kaizens’) at all levels -0.1 0 0.1 0.2 0.3 0.4 0.5 0.6 Teamwork Requirements Planning Technical Practices Quality Culture Knowledge Creation Outcomes OneTeam's Data fromTwo Separate Points in Time Nov-15 May-14 PP O P P P O PP PP
- 13. Example Chart –Comparative Agility -0.3 -0.2 -0.1 0 0.1 0.2 0.3 0.4 0.5 0.6 Most code is written using unit test-driven development. Code is written using pair-programming. Team members pair program at appropriate times. Refactoring is performed whenever needed. Technical debt (i.e., accumulated undone or poorly done work) is made visible to both technical team members and… The entire system is built automatically at least once per day. Automated unit and acceptance tests are run as part of each automated build. Within our team, anyone can change anyone else's code. The team can change any code in the system, even code written by other teams. Technical Practices
- 14. A Practical Example Business Unit Product Group Team Based on patterns observed we met with the Business Unit leaders to highlight challenges and improvements Each BU owner in turn clicked one level down and took ownership of improving an area at a product group level Each team then started focusing on that product group level improvements and at least one other team level improvement
- 15. What has Intel done with Comparative Agility? ▪ In the last 2.5 years of its use we have had over 150 teams take the survey. ▪ Nearly 1400 team members, scrum masters and product owners have participated ▪ We get to know our performance against rest of the world and against ourselves from the prior year(s) ▪ Great insight into organizational patterns and team progress towards improving their own agile practice ▪ We can understand how each business unit or a solution or a product is doing. – Improvements focused on specific BU or solution related challenges
- 17. Exercise ▪ Goal: – Devise an organizational/project improvement strategy for their agile journey ▪ What’s available to you? (your inputs) – A set of data points, both objective and subjective, to help gauge current situation – Select project team members for interviews (for additional insight about the project) ▪ Time - 10-15 mins to review/understand the problem (‘What’) - Analyze the data, interview team members, form an hypothesis - 10 minutes to discuss what the impact of the problem is (‘SoWhat’) - Understand the impact of the current situation - 15 minutes to present your solution for the problem (‘NowWhat’) - Devise strategies to address the problem; think short-term AND long-term approaches
- 18. What were your learnings? (Debrief)
- 19. Conclusions ▪ Data is important but is only part of the equation when it comes to understanding what we can do to help as coaches ▪ There are multiple solutions to a problem ▪ Sometimes problems at the team level are indicative of larger organizational impediments ▪ Leveraging data as a means for having deeper interactions with the team and programs is critical to identifying the root cause
- 20. Q&A