AgileDC 2016 - Transform the Corporate Ecosystem for Enterprise Agility
•Transferir como PPTX, PDF•
2 gostaram•258 visualizações
You have made great progress at the team level with Agile, but your company still does not feel nimble and responsive. What is wrong, and what can you do about it? In this talk we show how executives and senior leaders can transform their organization/company to create a truly Agile Enterprise, by transforming corporate functions and enterprise shared services. The corporate ecosystem outside of teams must be transformed to achieve enterprise agility, but it is beyond the scope/authority of team members, managers, and consultants to make these necessary changes; these transformations can only be done by senior leaders and executives. From an executive's viewpoint we will describe the nature of the corporate ecosystem outside of teams and how - if properly transformed - enterprise services can be the missing link between team-level results and real company-wide agility.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a AgileDC 2016 - Transform the Corporate Ecosystem for Enterprise Agility
Semelhante a AgileDC 2016 - Transform the Corporate Ecosystem for Enterprise Agility (20)
Último
Último (20)
AgileDC 2016 - Transform the Corporate Ecosystem for Enterprise Agility
- 1. Transform the Corporate Ecosystem for Enterprise Agility AgileDC 2016 October 24, 2016
- 2. Scott Richardson • Background • 2 years at Fannie Mae, Chief Data Officer & Head of CorporateTechnology • 13 years at Capital One,VP of RetailTechnology for Consumer & Small Business Banks • Founder/owner of 2 technology consulting companies • Agile Credentials • Hands-on practitioner for 12 years • The usual certifications (CSM, SAFe SPC, etc.) • Agile sponsor/champion in multiple corporate orgs 2 Scott Richardson s12rich@gmail.com
- 3. 3 • Examine the corporate ecosystem outside of teams • Understand how senior leaders are uniquely positioned to drive agility throughout a company Scott Richardson s12rich@gmail.com Goals of this Session
- 4. 4 We will not talk about teams Scott Richardson s12rich@gmail.com Lead Developer Developer Developer Developer Tester Tester Analyst ScrumTeam Scrum Master Product Owner
- 5. 5 Rather, the ecosystem beyond… Scott Richardson s12rich@gmail.com
- 6. 6 … the fascinating universe of Corporate Shared Services Scott Richardson s12rich@gmail.com
- 7. 7 Some observations about Corp Services • Necessary to run any company • Goals not same as business units’ • Failure also to transform can inhibit corporate agility Scott Richardson s12rich@gmail.com
- 8. 8 Governance/Oversight Groups • There can be many – inventory them early as part of Culture assessment • Most do perform a valuable role of keeping the company out of trouble • Most have a document-heavy Inspect-and-Veto approach • Most inspect at end of value stream Audit Legal PMO/SDLC *QA/Test *Release Mgmt *Architecture Do: • Change from reactive controls to preventative • Shift to Advise- and-Escalate, up front • Educate and reinforce local accountability at every step • Publish meaningful metrics that help run a good business Scott Richardson s12rich@gmail.com
- 9. 9 Human Resources Do: • Reinforce target culture with HR actions Labor Strategy New Positions Performance Management Recruiting Training Scott Richardson s12rich@gmail.com • RefocusTraining • Hard Skills: T-shaped resources; cross-functional teams • Soft Skills: Assertiveness, independent thinking, leadership • Define a Human Capital Plan / Labor Strategy • Create formal positions for the new Agile organization • E.g., Scrum Master, Coach, Product Owner, DevOps, Release Train Engineer • Energize Recruiting • Team: Culture fit, team players, forward-leaning, continuous improvement • Management: Enabling teams, inspirational • Tune-up Performance Management • Individual vs.Team, 360° feedback, coaching on soft skills
- 10. 10 Procurement • Follow your Human Capital Plan • Fixed Price and MSP structures tend to inhibit Agile • E.g., Functional silos, non-aligned goals, different locations • Change MSP contracts to allow full-team sourcing, not functional sourcing • Ensure vendor SLAs are aligned with business/team goals • Solve for cross-functional team capability, not unit costs Facilities Do: • Reexamine MSAs • Enable team alignment • Need new style of work space: Open, sight lines, casual, vertical work surfaces, huddle rooms • Will be more collaborative, and noisier • Challenge: Keep up with demand for this new space Do: • Create open space • Act now! Scott Richardson s12rich@gmail.com
- 11. 11 Hosting/Infrastructure • As you scale, each team will need multiple non-Prod environments • Use automated environment provisioning to keep up with this demand • Invest in tech skills, standards, contractual arrangements, etc. • Pre-Prod environment support ultimately moves to the team; requires advanced DevOps capabilities Production Support • Downtime in non-Prod environments causes unproductive teams • Need Prod-like support of non-Prod regions to avoid costly delays • Teams own their code; less separation between L2/L3 and dev team • Build support requirements/docs into "Definition of Done" Do: • Standards, automation, cloud, containers Do: • Improve non- Prod SLAs • Shift some Prod support to team Scott Richardson s12rich@gmail.com
- 12. 12 Finance/Investment Management • Top-down budgeting based on corporate priorities • Fund theTeam not the Project(e.g., SAFe Portfolio view) • Use light bottoms-up business cases for local portfolio decisions • Measure business results against strategic metrics • Changing investment management is very difficult PMOs • Shift most PMO responsibilities to Product Owners and related roles • Shift PMOs to coordinating Portfolio Roadmaps, tracking KPIs • Eliminate the BCP (Big Complex Program): Value streams, Epics • Eliminate the Project: Bring work to the teams • Shift teams to new corporate priorities as needed (infrequently) Do: • Unit of investment is the team Do: • Lean out • Be more strategic Scott Richardson s12rich@gmail.com
- 13. KeyTakeaways Scott Richardson s12rich@gmail.com 13 • Corporate Shared Services often become sources of friction • Federate where possible, lean out • This is hard work and requires influence! • Only senior leaders have the authority to make these changes
- 14. Q & A Scott Richardson s12rich@gmail.com
- 15. ThankYou! Scott Richardson s12rich@gmail.com Scott Richardson s12rich@gmail.com
Notas do Editor
- Scott Richardson Email: s12rich@gmail.com LinkedIn: www.linkedin.com/in/scottrichardson/
- Quick distinction between (vertical) Lines of Business and (horizontal) Corporate Shared Services.
- Corporate Services are like The Force: “It surrounds us, penetrates us, and binds the galaxy together.“ If you can learn to use this Force then your powers of agility increase significantly. Failure to learn to use this Force relegates your company to the ranks of countless firms who never rise above mediocrity, who never achieve excellence. Why talk about this? Someone must deal with this to make the enterprise agile – as an executive it’s your job to fix these functions too
- There can be many of these groups (26…) Typically have a document-heavy Inspect-and-Veto approach Tend to apply generic standards and not consider local conditions Not good for the culture of the enterprise: Diminishes local accountability/responsibility Do: Shift to an Advise-and-Escalate function Ensure local leaders truly understand the risks that apply to their specific situation and that they manage the control environment appropriately Escalate to senior leaders/executives if risks not being managed Do: Change from reactive controls to preventative Move inspection cycles (if needed) to the beginning of the value stream, rather than inspecting it out at the end of a value stream “Someone else will make sure we don’t screw up” Risk Reviews at the Beginning: Teaches local leaders what they need, resulting in longer term greater accountability and success Risk Reviews at the End: Always slows down teams as it creates redo-cycles that could have been avoided. Audit: Move from documentation-centric audit to measuring meaningful metrics aligned to a Lean/Agile org; shift accountability from external oversight groups (Audit, Quality Office, etc.) to Delivery Leads. PMO generally should not be in an audit/quality function. Shift PMO to be portfolio coordination. SDLC: Any central group tends to apply generic standards and ignore local situations. Reinforce local accountability to manage the company’s risks. Stop doing this and measure concrete risks instead: Defects escaping team, architecture non-compliance, size of technical debt, Support Team satisfaction, etc. Testing Shared Service: Shift to CoE and modern/best practices, not providing bodies to teams If in an independent quality role, get out of this business. Shift responsibility to PO/Tech Lead Staffing is an in-team responsibility. Having a shared service introduces conflicting goals to the team and creates functional silos rather than cross-functional teams Architecture: EA (central) vs. Solution Architecture (local/federated) JIT architecture in smaller units (not big Target Architecture); proactively prescribe modern design patterns Shift to advise-and-guide with final quick checkpoint on what was previously agreed, not late-in-cycle first inspection Focus: Are we following the right patterns, InfoSec, not creating long-term technical debt, etc. DO: Guide/advise at the start rather than inspect at the end (preventative vs. reactive controls) Educate and reinforce local accountability at every step Escalate to senior levels swiftly if risks not being managed Be wary of “horizontal” functions as a general rule Publish meaningful metrics that help run a good business, rather than conduct documentation audits
- Most Important: Have a defined Human Capital Plan or Labor Strategy that outlines where you want to use Employee, contractor/consultant, MSP. Work proactively with HR to ensure their various processes support/emphasize what is needed in an Agile workforce vs. what was needed in the past. It is different. New positions and career paths, different emphasis in Perf Mgmt, Training, Recruiting POSITIONS (Create formal roles and career pathing for SM, Coach, PO, Product Mgmt) Create new roles/job families, AND LIMIT GROWTH OF NARROW JOB FAMILIES (PM, Analyst, Tester) Scrum Master: SM 1, SM2, SM Manager Scrum Master 1: Serve as the facilitator for the team, coaches and guides the team, removes roadblocks, and coordinates with other Agile teams. Scrum Master 2: Same as above but more Coaching SM Manager: Servers as senior SM responsible for managing other SMs, assess/build the quality of internal and external SM talent, run a SM Journeyman program, coaching Managers and leaders within the org on how to lead in an Agile environment, manage vendor relationships for Agile 3rd parties. Coach: Agile Coach, Enterprise Agile Coach Agile Coach: Onboard new teams and ensure Agile practices are adopted successfully by those inside/outside the team, mentor management to lead in an Agile environment, conduct agility health assessments periodically and drive long term team improvement in Agile Enterprise Agile Coach: Manage Agile Coaches, mentor executive leadership in leading in an Agile organization, coach business-technology partnership in Lean-Agile strategy execution Product Owner: Product Owner, Product Manager Product Owner: Responsible for the ROI of the product development/delivery effort. Creates the Product Vision and prioritizes the Product Backlog. Serves as proxy business intent leader where multiple stakeholders have a vested interest in Agile team scope and prioritization. Product Manager: VP level, P&L owner There is a debate about whether this should be a formal role/career path, or whether PO should be a secondary role of someone with a formal business job/position. If you don’t have a Day Job in Operations, product development, marketing, etc., then you’ll lose your business knowledge over time. (some think). Or, in more advanced organizations, the senior people are Product Managers and the juniors are POs, and there is no debate about this. PO position is how you gain broader business knowledge over time (move from tactical/delivery to strategic/product direction as you advance) DevOps: SDET (Software Development Engineer for Test), SDET Manager, DevOps Engineer, DevOp Manager, Technical Release Manager DevOps Engineer: Assess, design, develop enterprise continuous integration delivery framework enabling enterprise-wide adoption of Devops DevOps Manager (SAME AS Our TECH RELEASE MGR?): Manage a team of DevOps Engineers who work with Agile team members to ensure scalability, availability, continuous integration, automation, and deployments/releases to test and production environments. Technical Release Manager: (get from Kevin’s proposal) Release Train Engineer: Lead Agile Release Trains or other scaled agile program management approaches, ensure flow of scope across teams is well-coordinated, partner with Technical Release Manager to ensure business value is delivered in a timely basis PERFORMANCE MANAGEMENT Debate: Performance of Individuals vs. Performance of the Team. I’ve personally never experienced confusion about individual performance – you can easily see it. 360 Feedback is essential (team members, PO, SM, OOS stakeholders, Managers Use this opp’y to get more real-time, frequent feedback, rather than Annual Perf. Mgmt cycle. This mirrors Agile with short feedback cycles. Emphasize Coaching on soft skills more: than in the past. . TRAINING: Both a) hard skills – to get a more cross-functional workforce, and b) soft skills – to bring out more assertiveness and independent thinking RECRUITING: Culture fit becomes more important. Want people who can work in a scrum team, or managers who delegate readily. Need that energy level, forward-leaning, willing to try new things and not be afraid to experiment, continuous improvement mentality.
- Refining Procurement approach enables Agile The Fixed Price/Managed Service Provider structures inhibit Agile in several dimensions” Delivery Structure: Typically done in functional silos rather than cross-functional Management: Multiple vendors on one team are hard to manage cohesively and require more of our management Goals: How can you have a cross-functional team if individuals are incented differently? Location: Often the silos are in different locations If you’re going to have FFP/MSP, at least give the vendor an entire team (must have employee Product Owner however) Note: “Risk sharing” with a vendor is a fallacy Procurement: Have a defined Human Capital Plan or Labor strategy that outlines where you want to use Employee, contractor/consultant, MSP. Biggest shift: Solving for team throughput, not labor unit costs. This is counter to the goals of this ESS, but better for the firm. Spend more on skilled, cross-functional people, and you’ll need fewer of them and will have better teams Change MSPs to allow full-team sourcing, not functional sourcing Functional silo goals (e.g., Testing, Dev, PM) create conflict with Agile teams because some staff have different goals than the team/PO. Not good. Ensure SLAs are aligned with PO/PM goals SLAs to cover transformational goals too: Innovation, Lean, continuous improvement Be cautious with traditional thinking Fixed Price/Managed Service Provider structures inhibit Agile in several dimensions: Delivery Structure: Functional silos Management: Multiple vendors on one team Goals: Individuals within one team are incented differently Location: Often the silos are in different locations “Risk sharing” with a vendor is a fallacy Change MSP contracts to allow full-team sourcing, not functional sourcing Ensure SLAs are aligned with other goals such as Team objectives, Innovation, Lean, Continuous Improvement Biggest shift: Solving for team throughput, not labor unit costs FTEs may have higher unit costs, but are more cross-functional over time Procurement Themes: Solve for team capability, not unit costs Total ownership at team level, not functional silos Ensure agreements support PM/PO goals, innovation/Cont Impr goals Facilities/Corporate Real Estate Open space to promote quality, visibility/sharing, teamwork Cubeless, no walls, clear line of sight I-formation (caves and commons) Teams should have sightlines to each other (I prefer teams facing in, not out) Vertical surfaces: Walls to support task boards, mounting SmartBoards, etc. Also can get too noisy without moveable walls (Coalesce) Huddle rooms Few offices (VP+, if that) Do need some med/large conference rooms for Sprint Reviews, vendor meetings Continuous talking can get too loud for normal Team Spaces Need at least one Very Large conference rooms for SAFe Planning Events Wireless headsets create ability to walk away if it gets too noisy Facilities Themes: No cubes, fewer offices Need team space, huddle rooms Need vertical surfaces for work and noise reduction
- Hosting/Infrastructure: As you scale teams, each team will want multiple non-Prod environments. This will put pressure on Hosting/Infra teams. Automated environment provisioning is a necessity or you will slow down teams If you don’t have this yet, it takes some time to create this capability in the hosting organization (skills, contractual arrangements, standards, etc.) Need to get this started now Ultimately as the enterprise moves through the maturity curve, more infrastructure work for pre-Prod environments will move to the team level. This becomes feasibly with automation, cloud, containerization, and standards. Production Support: Each team typically requires multiple environments (minimum: Dev, local SIT/UAT) and shared environments (inter-team SIT, Pre-Prod). Although non-Prod, any downtime in these environments causes a team to be at a standstill, with ripple effects for other teams too (inter-Sprint dependencies). This drives the need for Prod-like support of these pre-Prod environments. The cost to the enterprise is just too high if teams are down even for a couple hours. This will increase your L1/L2 costs. Ultimately if infrastructure, design patterns, and DevOps are right, each team owns their own code from Dev through Production. There is less or no separation between L2/L3 and the development team. But until this maturity is reached, build full support requirements (e.g., documentation required by the L1/L2/L3 teams, handoff/shadowing, etc.) into the teams’ "Definition of Done" Themes: Automation, cloud, containerization, monitoring, standards Support non-Prod like Prod to avoid costly team down-time Team to own the full lifecycle; push Ops closer to teams as you mature
- Saved the best/hardest for last: Companies are very reluctant to change their budgeting/investment management processes because they are so politically sensitive (create winners and losers) Finance/Investment Management Investments should be driven by Strategy Execution Top-down based on strategic distribution of funding to business areas (its always ends this way regardless) Ideally align directly to strategic goals under stewardship of AEs (see above) Stop the madness of bottoms-up budget planning Instead, at the Senior Executive level agree to: a) the Corporate Strategy, and b) to a limited set of Corporate Investment Priorities/Themes Usually by major business function or division This is important because by doing this at TOH it encourages the leaders/divisions to be more collaborative with each other, and to anticipate where the strategic investments in one area require work to be done by another area. Then be sure to fund/invest in those ancillary areas so total outcomes are achieved without a budget or dependency crisis later in the year. Fund the Investment Theme/Corporate Priority: How much do we want to spend this year on this priority Yes it needs to be grounded in an expectation of certain outcomes Let the AE, PM/PO, and possibly team estimate what this will be Don’t engage in a massive business case/scheduling exercise that wastes the time of hundreds of people. Fund the Team, not the Project (e.g., SAFe Portfolio view) If can’t afford to go Agile at local level (e.g., by cutting PMs and Testers to fund SM/Coach), then move up a level in the org and solve more globally. Eventually you’ll find an area that has budget capacity once proper leaning out is performed. Failure to do this leaning out means you’ve lost the key tool for funding the transformation. This is hard to change: Companies hesitate to change budgeting/investment management processes because they are politically sensitive (create winners, losers) Themes: Strategy-driven investment of priorities/themes, not projects Fund the right nbr of teams to get capacity aligned with investment priorities PMOs If you have a central PMO, change focus to coordinating across Agile teams, visualizing the Portfolio/Roadmap view, tracking investments and business value realized (KPIs) Eliminate the BCP (Big Complex Program): Instead, decompose scope to Epics, Features. Never do big things again; decompose & reduce risk. Eliminate the Project. Instead: Fund fixed capacity teams aligned with business capabilities. Bring the work to the teams (Epics, Features) Better: Semi-annual checkins (quarterly is too frequent) to shift team alignment (not team existence) in edge cases (not the rule - keep teams stable) Measure results (KPIs) not projects completed Shift focus/staff from running projects to coordinating across Agile teams, visualizing the Portfolio/Roadmap view, tracking investments and business value realized Project Mgmt is an instrument of POs to coordinate across a large number of teams, not a practice unto itself. PMs should not be an ESS generally speaking; should report to POs If in a project oversight/quality/audit role, get out of this. Shift responsibility Themes: Shift staff from program/project execution to tracking the investments, coordinating across teams Measure business value achieved vs. investments Top-down, not bottoms-up