Transforming Enterprise Teams to DevOps Workflows
•Download as PPTX, PDF•
8 likes•2,414 views
Talk for IPExpo Manchester, May 19, 2016. As large organizations become more interested in DevOps and the velocity it can offer, introducing new ways of working to teams with longtime habits and familiar workflows can be challenging. Shifting goals, new tools, and new skills create a stressful environment for technologists still trying to keep applications and services running. New tools should make work easier, not worse! This talk will cover some of the common pitfalls large organizations face when radically changing work as well as tips for technologists and managers for surviving the implementation of large changes.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Transforming Enterprise Teams to DevOps Workflows
Similar to Transforming Enterprise Teams to DevOps Workflows (20)
More from Mandi Walls
More from Mandi Walls (20)
Recently uploaded
Recently uploaded (20)
Transforming Enterprise Teams to DevOps Workflows
- 1. Transforming Enterprise Teams to DevOps Workflows Journeying with Culture and Tools Mandi Walls Technical Community Manager, EMEA IP Expo Manchester
- 2. whoami • Mandi Walls • @lnxchk • Working at Chef since November 2011
- 3. Who DevOps? • Small companies • Big companies • Government agencies • Not-for-profits
- 4. Anyone who recognizes the future of Technology + Business is alignment and working together https://www.flickr.com/photos/sfgirlbybay/3360299725/
- 5. Why? Why DevOps? Why Now? • Technology is everywhere • People become deeply attached to and dependent on it • Cloud platforms and IaaS / SaaS have reduced the cost to bring new online properties to market • Lower upfront investment in hardware and software • More resources to invest in the applications or products themselves
- 6. This has created an environment hostile to slow- moving existing organizations https://www.flickr.com/photos/barbeezgarten/22416012213/
- 7. What’s Special About Enterprise DevOps • Silos • Compliance and regulatory constraints • History • Size • Previous investments
- 8. Risk Aversion • What’s old to fast moving companies is the future for risk averse companies • Driven to find “Best Practices” • Want everything to be “right” the first time
- 9. All while the whole industry is evolving around them https://www.flickr.com/photos/39032463@N07/10001334855/
- 10. The Dreaded Silo • Functional silos happen for a reason • Complex work leads to specialization • Specialization without regard to organizational goals • Goals and priorities in conflict • The functional fanatic • Looks at everything through the same lens of their function
- 11. Why Worry About Workflows? • Tools inform culture informs tools • Good workflows promote good behavior, and bad workflows encourage bad behavior • Bureaucratic teams choose bureaucratic tools • Open teams choose more open tools
- 12. Old Workflows • Manual • Slow • Often requiring multiple approvals • Division: of labor, of expertise, of power
- 13. What’s Bad About Old Workflows • Slow • Reward the wrong behaviors (culture) if the goal is to be fast and flexible • Promote functional fanaticism and bad habits • Escalations, short cuts for some
- 14. Why Better Workflows are Necessary • Teamwork vs antagonism – DevOps! • Common goals and shared rewards • Equalize the treatment of projects that follow the workflow
- 15. Where Do New Workflows Get Started • Adoption of public cloud for Dev • Avoid working with old processes created for legacy on- premise systems • Should it take 6 weeks to procure a virtual host?
- 16. Bad Workflows Mean Work Doesn’t Get Done https://www.flickr.com/photos/rmc1952/19611845573/in/album-72157636873610105/
- 17. Why Does This Matter in the Enterprise • Everything has a longer life cycle: Projects, Budgets, Systems, Careers • Coordination across more and larger teams • Internal politics • Organizational culture
- 18. Affects of Organizational Culture • Workflows reflect culture • Do teams work together? • Do teams trust each other? • Are goals clear and shared? • Is responsibility shared? • Are rewards shared?
- 19. Does Everyone Know How They Impact the Bottom Line? https://www.flickr.com/photos/16054928@N07/9633080921/
- 20. Helping Individual Contributors • Being helpful before being obstructionist - Maybe/why vs No • Follow and give feedback • Try before deny • Be honest about how the work being done and how it impacts goals and bottom line • Balance between fun and necessary
- 21. Helping the Technical Manager • Job is to listen and remove obstacles • Articulate goals, and not just once a year during goal planning • Prioritization of people, resources, and budget in a clear way • Advocate for the team
- 22. The Role of Executives • Be clear on goals and objectives • Be ready to prioritize and make decisions • Resolve conflicts and budget disputes
- 23. TRUST • Trust required among all groups – Practitioners, Managers, Executives • Enabling all teams to experiment and innovate in their areas High trust, high-communication environments give everyone the information they need to do their jobs and make good decisions
- 24. Why We Think About Workflow • Several years helping teams through modernization projects • Seeing the impact of lack of clear goals • Articulating the benefit of the new process
- 25. Breaking Bad Habits • Risk averse organizations want the “Best Practices” • Want the workflow to be 100% right the first time • Low tolerance for experimentation
- 26. Challenges at all Levels • Technical folks may have to go back to basics • Learning to do a bit of programming, command line work, more typing • Management has to set clear goals • Stick to them and provide support
- 28. Audit Trail • Infrastructure as Code provides better auditing • Proof of when changes were made and by which team • A traditionally difficult task becomes part of the default workflow
- 29. Flexibility • Apply the same workflows to internal and external resources • Make use of tools with APIs for integration
- 30. Reliability • DevOps workflows and tools aid in producing the same outputs repeatedly • Reuse the same procedures in Dev / QA / Production to reduce errors
- 31. Single Path for All Changes • Allows for the incorporation of requirements from not just Dev and Ops • Centralized location for anything that needs to go to production Integrate your applications with all requirements from Security, Compliance, Networking and lower risk of bad pushes to Production
- 33. It Can Be Done • It does take investment: time, people, resources • Clear goals are essential to helping teams understand why change is necessary • Prioritizing the future
- 34. Photos • https://www.flickr.com/photos/sfgirlbybay/3360299725/ • https://www.flickr.com/photos/barbeezgarten/22416012213/ • https://www.flickr.com/photos/mediman30/5624525299/ • https://www.flickr.com/photos/39032463@N07/10001334855/ • https://www.flickr.com/photos/rmc1952/19611845573/in/album- 72157636873610105/ • https://www.flickr.com/photos/16054928@N07/9633080921/ • https://www.flickr.com/photos/rmc1952/14853887069/
Editor's Notes
- “The way we’ve always done it” is very powerful when measured in decades vs months or years
- Clear goals and obvious impact help workers stay effective. When goals aren’t clear, or aren’t articulated in a way that makes it obvious how someone’s tasks are essential, it’s much harder to persuade that person to adopt new practices
- Building new workflows is tough: people used to “the old way” will revert to old paths if the new path is hard or confusing, or if it fails to withstand an emergency or important event. It takes time to build habits, and that is what workflow change is – building new habits for getting work done. Not everything that needs to get done will be exciting, either. When making large changes to how people work, a lot of the process will be tough
- Change is tough for managers, too. Some may have never had to help their teams through much change, especially in large companies. When working with technical managers on new workflows for their teams, it’s important to help them help their teams through the tough parts of changing how things get done
- I know I have mentioned prioritization several times. If there is one thing that predicts whether a DevOps adoption will fail, it is the lack of prioritization of time and resources. It’s a tough problem to work through – most of the people involved in a DevOps initiative already have work to do, and if the company has deprioritized IT over time, they probably have more work to do than they can effectively handle. And now they are being asked to learn new tools and skills, while maintaining the existing work as well. Executive support is crucial to setting the right priorities for the long term, and being clear with teams that some tasks being lower priority is ok.