Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (13)
Ähnlich wie Rethinking the agile enterprise
Ähnlich wie Rethinking the agile enterprise (20)
Rethinking the agile enterprise
- 4. Scaled Agile Framework™ Big Picture
- 5. 5
- 6. 6
- 7. What prevents us from being agile at scale? 8
- 8. leading causes of paralysis • Focus on business alignment over IT efficiency 9
- 10. Leading causes of paralysis • Focus on business alignment over IT efficiency • Tech debt 11
- 12. Leading causes of paralysis • Focus on business alignment over IT efficiency • Tech debt • Centralization 13
- 14. Leading causes of paralysis • Focus on business alignment over IT efficiency • Tech debt • Centralization • Budgeting 15
- 16. 18 Don’t just do something, STAND THERE!!!
- 19. Values & principles Values: •trust •independence •pride of ownership •feedback Principles: •decentralization •design to throw away •fail fast / fail cheap •plurality •devolve accounting to value centers 22
- 20. Practice: products over projects 23 Customer focused Competitive marketplace Cost / customization balance Customer support
- 21. Practice: Vc funding model 24 http://www.quicksprout.com/2009/01/21/how-to-raise-venture-capital/
- 22. Practice: business process precedes automation 25 Business process experimentation with out of band integration Lightweight integration Full integration
- 23. Practice: experiments precede large capex spend 26
- 24. Practice: full lifecycle ownership 28 Funding approval Development Operations Upgrades and retirement
- 25. Practice: all shared code is publicly hosted 29 Open source curation Optional adoption Runtime integration No domain logic
- 26. Practice: replaceability as a first class “ility” 32 Limit depreciable lifetime Eschew centralized solutions Careful package selection and implementation Communication > Implementation
- 27. 34 The Douglas Adams rules TV spam grunge REST Snapcha t twerking me me @ 15 me @ 35
- 28. Inherent context 35 Ids => URLs State => State Machine N/A => Referer headers
- 29. Practice: dissolve shared services 36 Analysis App QA Security DBA Release Ops 1 week 4 weeks 1 week 2 weeks 1 week 2 weeks 2 days 1 week 1 day 2 weeks 3 days 12 weeks Customer
- 30. Practice: dissolve information technology 37 Align automation with business units Centralized IT decisions made by top management Cost / benefit analysis on business, not IT
- 31. Manifesto for enterprise agility I have imagined better ways of running enterprises by sitting and thinking inside my ivory tower. Through this work I have come to value: Economies of flow over economies of scale Devolved accountability over standards Systems thinking over analytical thinking Replaceability over reusability That is, while there is value in the items on the right, I value the items on the left more Brandon Byars 38
- 32. THANK YOU Brandon Byars email: bbyars@thoughtworks.com twitter: @BrandonByars
Hinweis der Redaktion
- Agile being extended both in scale and in scope
- Not invented here syndrome Focus on “doing agile” instead of “being agile” Fundamentally all these methodologies have one thing in common – I didn’t create them
- There is clearly a demand for scaling agility
- 0% IT spend b/c the % is the average of all companies surveyed, and most live in the bottom left IT can never move at the speed of business Hypothesis: alignment => Overcustomization; need to allow flexibility in business workflow Excess features = biggest waste
- The lines will still meet eventually
- Focus on activities as units of production; unit cost over flow Focus on utilization, shared services, centralized qa, standard frameworks and toolsets Not enough focus on flow, and we dip into diseconomies of scale before realizing it in most organizations
- Budgets are the principal weapon of command and control mindsets, used as a control mechanism We always measure against the budget and have to explain variances 1st Law of cybernetics: The more complex the environment, and the tighter the targets, the more flexibility the control system must have "only variety can absorb variety" - only way out is to game the system
- One of the main reasons enterprise software is so terrible is because of the captive audience
- Budgeting forces compliance to the estimated plan. VC funding forces you to prove that your product is worth continued investment. Unreleased code is a liability!!!!! – Toyota treated inventory as liability instead of asset Force proving value early to continue funding t (forcing factor towards CD) Have as much of the costs with the team as possible (support, infra, etc)
- Inditex (Zara) Concept to cash in 3 weeks (9+ months for Gap) Uses no commercially available enterprise software; all internally developed .5% IT spend / revenue, compared to 2% average Excess automation paralyzes a company’s ability to adapt – it makes changing the complex process that was automated very expensive Reduced feature set = reduced complexity; viciously resist temptation to cater to various stores (1 solution for all unless tax laws force the issue) – also forces small focused solutions instead of big “enterprise” solutions Perhaps have this under business IT alignment = IT is part of business Eschews economies of scale and and works well below capacity to ensure its ability to fill orders twice a week
- JC Penney, ron johnson, removed promotions, sale prices, smaller shops with a genius bar like concept, new logo, replaced top execs Publix / Petco
- Netflix curates their OSS platform stuff used internally Domain logic sharing – beware of bounded contexts; copy paste instead Shared code leads down garden path of requiring same tech stack, etc – increases inter-team coupling and ossification Stefan Tilkov – sharing code can save a little up-front time, but almost always costs in the long run Johannes Brodwell: - Modern development frameworks take away 80% of the job. Then they make the remaining work ten times as hard. if you're forcing people to use shared tech, why do you have to force them? why don't they want to use it? from: http://architects.dzone.com/articles/humble-architects, written by Johannes Brodwall Reuse creates coupling. If system X and system Y reuse some functionality and system X needs that functionality to be modified, this will affect system Y. At the very least, the team working on system X must decide to make a private fork of the reused functionality, which means that it’s no longer really reused. At worst, system Y will get a bug because of a change in the reused functionality. When you reuse across systems, what you reuse should either be stable (say: the Java SE platform, or something so stable that you definitely didn’t make it yourself) or strategic. By strategic reuse, I mean services that integrate information and not just duplicate functionality.
- Since capital asset benefits span multiple reporting periods, it’s appropriate to similarly distribute costs Abstract business capabilities, not packages
- Inherent context, esp. with the URL containing both the id and the system of record, gives you less coupling between systems and increases replaceability
- Major sources of waste: handoffs, queue time Now no frameworks teams or operation teams, let’s go further Instead of shared services http://calchaspss.wordpress.com/ presents lots of evidence on the flaw of shared services across industries Hire experts and rotate between teams Can contract outside the firm during capacity constraints
- IT is itself a shared service based on economies of scale, and IT is the command and control manager’s dream Inditex (Zara): No separate IT department Concept to cash in 3 weeks (9+ months for Gap) Uses no commercially available enterprise software; all internally developed .5% IT spend / revenue, compared to 2% average Excess automation paralyzes a company’s ability to adapt – it makes changing the complex process that was automated very expensive Reduced feature set = reduced complexity; viciously resist temptation to cater to various stores (1 solution for all unless tax laws force the issue) – also forces small focused solutions instead of big “enterprise” solutions Eschews economies of scale and and works well below capacity to ensure its ability to fill orders twice a week