Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Walls agile2013
Semelhante a Walls agile2013 (20)
Mais de Mandi Walls
Mais de Mandi Walls (20)
Último
Último (20)
Walls agile2013
- 1. DevOps isn’t Enough for your Dysfunctional Organization mandi walls mandi@opscode.com
- 2. whoami • Mandi Walls • Consultant for Opscode, the makers of Chef • @lnxchk
- 3. What I Do • Visit Opscode’s customers • Help them learn Chef • Listen to their issues and problems
- 4. technical consultant as organizational therapist
- 5. Why DevOps? • Shifting requirements for IT projects • Shifting demands from customers • Shift in the role IT plays in organizations
- 6. Why Dev + Ops • It’s not really just about Development and Operations teams • Everyone has a hand in creating better products
- 8. Deviating from the norms of behavior in a way regarded as bad
- 9. What Makes for Dysfunction • Arbitrary rules • Workflows that people circumvent when they can • Requirements that delay or derail a project
- 10. Origins of Dysfunction • Specialization • Prioritization • Conflict of Incentives
- 11. Specialization • Not a bad thing • Necessary for complex IT structures • Creates functional fanatics
- 12. Prioritization • Conflicting goals • Communication challenges • Resource limitations
- 13. Conflict of Incentives • Classic Dev vs Ops problems • Also affects other teams • Not new, not exclusive to DevOps
- 14. Tools to Get Beyond Dysfunction
- 15. Goals • Goal setting is key • Goals must be communicated • Goals in change initiatives must be measurable
- 16. Communication • Communicate, communicate, communicate • Documentation • Check points
- 17. Self Awareness • What motivates your team members? • What fears or doubts do they have? • Does your team recognize its own dysfunction?
- 18. Training • Good training is priceless • Bad training is incredibly damaging • Training in general is expensive
- 19. Working with People Issues
- 20. Executive Support • Cleaning up dysfunction requires support from high levels in the org • Have to be able to realign people and resources around new goals • Skunkworks projects are tempting, but fail when scope expands
- 21. Management • The power to create or disintegrate dysfunction • May not be empowered to make real change
- 22. Fear • Do I have the right skills? • Will it be hard to do? • Will I get fired?
- 23. Reluctance • This isn’t exciting! • We’ve seen all of this before • I don’t need to know this
- 24. Path of Least Resistance • Are people even following the currently proscribed processes
- 25. Boomerang Projects • A sign of organizational dysfunction when your team decides to ignore an initiative, or “wait it out” because they believe it will disappear or lose traction before it gets implemented.
- 26. Making a Plan
- 27. • So you say you want some DevOps revolution
- 28. • Executive Buy In • Organizational Assessment • Readiness • Pilot Project • Reassess
- 29. Executive Buy In • As discussed earlier, finding a sponsor in upper management smoothes your path • Someone who has influence over all the teams you may need to involve • Someone who is able to prioritize teams, support your goals, and articulate to others why your initiative is important and deserves resources
- 30. Assessment • The fun begins • Where is your process now? • Synchronous discussion
- 31. Who • Talk to everyone • Ask everyone the same baseline questions • You should get a good multifaceted view of the current state
- 32. Baseline Questions • What is the primary goal of the company/team/project
- 33. Baseline Questions • What is the most broken thing about the current process/project?
- 34. Baseline Questions • What would you want to not see change about your project?
- 35. Another Interesting Question • Drive the discussion towards who has influence • Who would they most want to have on the team?
- 36. Generic Questions • Tools being used • Tickets and tracking • Reporting and assessment
- 37. Specific Questions • What’s driving you to DevOps? • How long do deploys take? • What’s your time-to-market?
- 38. Making Sense of Assessment • The full scope of the team • A list of tools and resources being used • A list of potential weak spots to look out for • Set a baseline for your goals
- 39. Readiness • Getting at the squeaky wheels • Training for any new tools
- 40. Build from the Assessment • Determining what to do with the broken pieces • Determining which of your current processes are beneficial and which could be harmful
- 41. Strong Foundation • Align tools and people • Set and communicate goals
- 42. Pilot Project
- 43. Choosing a Pilot Project • Narrow but deep • Shine light in all the dark corners • Involve secondary teams, resources
- 44. Tough Conversations • About goals and values • About the priority of external requirements
- 45. Ultimate Pilot • Greenfield when you can • Work through it end-to-end
- 46. Hostage Situations • Who is able to hold your project hostage?
- 47. Reassess • Along the way, check point your progress • How are you tracking towards your goals? • What went well? What went badly?
- 48. Next Steps
- 49. API All the Things • Make better use of human brains • Common tasks can be automated
- 50. Create a Service Catalog • Not in the SOA sense, but in the “I need some storage” sense • Limit choices, speed up supported requests
- 51. FAQs
- 52. Timelines • How long will this take? I want it to be done in [1,2,6] months!
- 53. Trust • “How do I create a DevOps workflow but keep X team away from the tools?”
- 54. The Dreaded Question • “Do I have to fire people?”
- 55. Can Large Orgs do DevOps? • “I have too many people to do something like DevOps”
- 56. Q&A
Notas do Editor
- Technology companies are taking Agile to the next step: once software is built, it must be operated and maintained in a way that makes customers happy, whether they are external uses of your application or website, or internal consumers of a service being provided. DevOps has done a good job of describing what it means to have an integrated, high performing, collaborative team. Not all organizations are ready to play along. As IT becomes a larger and more integrated part of working with and delighting customers, embracing newer methods and a better attitude towards projects is crucial. It’s not just web-based products that will see this shift. Consumers are looking for more convenience, faster response time, and better choices in all sorts of industries, including healthcare, education, and even government. Consumers are looking for the same performance and attention to their needs from all the companies they deal with.
- DevOps gets the attention it does because Operations and Development often have a contentious relationship. Developers build something and expect Operations to be able to make it work. Operations takes projects from Development and learns whether or not the things truly do work. Often they don’t, creating a frustrating cycle that concepts like DevOps and Agile Operations are trying to help alleviate. Dev + Ops is just the beginning. And it is a beginning that many organizations won’t be able to get to, let alone get through and on to more promising optimizations.
- Dysfunctional is a loaded term. It implies that something is incapable of functioning successfully in its current state. For many companies, simple inertia will keep them rolling for a while. Especially if technology is not the core of their business today. In the future, however, technology will be ever more important. So it’s entirely possible that your organization is perfectly functional now, but will cease to be competitive in the future.
- If your organization exists to provide a service of some kind to some group of stakeholders, your job is to get that service out there and usable. Obstacles arise in any project. The goal is that they shouldn’t be placed in your path by other members of your organization.
- Specialization of technical roles allows individuals to concentrate on all the features and functionality of one particular subcomponent. Storage, networking, and security all usually end up silo’d as organizations grow and their IT needs become more sophisticated. Where silos fail the organization is when they create unscalable walls between the team who wants certain functionality for their product and the team who is capable of providing that resource. Functional fanatics are those people who have lost, or perhaps never actually had, the ability to see the bigger picture with regards to the products and projects that the organization is working on. These folks are heads-down on the niche that they are knowledgeable of and ignore the outside world as much as they can. when a new process or requirement upsets their workflow, they can be belligerent towards the changes they may need to make. Functional fanatics are everywhere, and their obsessions are easily cultivated in IT.
- A team’s goals should be clear and obvious to everyone involved. This is often not the case with complex projects. When multiple teams are working together on a large initiative, coordinating work around common goals requires explicit support and direction. Any large group trying to work together can suffer from weak communication channels. Projects without a central coordinator or project manager who collects information so the whole team knows what is going on often suffer. The biggest challenge to any large initiative is giving it enough resources to succeed, whether those resources are time, people, equipment, etc. DevOps projects are no different. Part of reorganizing your methods and workflows takes time, and it will require people’s attention be moved from their day-to-day work to focus on learning new tools and processes.
- This is where DevOps springs to life in many organizations. When Developers are incentivized to produce more code and Operations is incentivized to keep the products functional so the pager doesn’t go off, the conflict that arises creates a contentious environment. Other teams providing support or secondary functionality that projects require also suffer from misaligned incentives. Particularly with specialized teams, their primary requirements focus on a small slice of the resources available to the organization, but they are deeply dedicated to preserving the performance of those resources. These problems arise in all sorts of places in technical and non-technical teams, but it takes strong management and clear goals to overcome these issues.
- Your team goals and the larger goals and mission of your company or organization must be clear to everyone. when you are asking your team to make large changes, the goals have to be clear and success criteria established. If you want smoother deployments of your projects, your goals should clearly spell out how much “smoother” the deployment should be. If you want to reduce your time to market, you have to know what your current timeframes are and what level will generate success.
- Documentation should be readily available, not hidden behind password controls or other barriers. Regular check points reporting how a project is progressing allow your team members to track their own work against the full projects. They also serve to keep external teams informed of where your project is and when you might need their assistance, allowing them to plan resources better as well. expecting other teams to stop everything they are doing to handle your requirements at the last possible minute causes an organizational immune system reaction - in response to a suboptimal experience with your team, a resource team puts up further barriers in order to protect their own assets, creating more dysfunction.
- Self awareness is something technical people are not particularly good at. Know what your own shortcomings are in order to appropriately address team needs. Not everyone is motivated by the same rewards, and management theory on employee motivation is a highly researched topic. If your team isn’t motivated to perform better and create better products, any DevOps or cultural initiative you launch will fail. Managing to employee motivation demands knowing a team well. When technologies change and people are asked or expected to learn new things, their personal fears about their skills and knowledge can end up making them reluctant to change. You want to create a good environment for learning when you are expecting people to actually learn new things. Many teams don’t even recognize that they are dysfunctional and that they could be working better. Legacy processes create their own organizational Stockholm Syndrome. People find comfort in the expected workflows they have used over and over, even if those workflows don’t produce optimal results.
- To combat the problems that create organizational dysfunction, people need training. recommended DevOps tool sets also require user training. The tools themselves don’t magically create DevOps workflows or success; your team is making an investment in time and brainpower in order to work more efficiently and cohesively. In order to change thought processes and workflows, your team needs to know how to effectively use new processes and workflows. Training takes time. it is time away from work and often feels unproductive, but training helps your team forge new paths and combat bad habits.
- Executive support for initiatives focused on combating dysfunction sets the tone that the project is meaningful and important. The executive sponsorship of a large initiative should have influence over many, if not all, of the teams involved. Getting facetime with an executive in a large organization is challenging, but gives your new project leverage when you encounter broken processes or workflows that inhibit your progress. Large organizations may also grow skunkworks projects when teams are frustrated with roadblocks caused by current workflows. Sometimes these projects gain ground and expand into large initiatives; we’ve seen this a bit with cloud computing use in enterprise. Others stay in the shadows and eventually get steamrolled later, drowned in requirements designed for projects run in the “old way”.
- Line managers and department heads can create dysfunction through their own management style. A command-and-control manager working with more creative employees generates strife within the team. Politics also plays a part, depending on how much clout a manager has with a particular team.
- Affectively negative people in your organization drive attention away from your initiatives towards their own problems and issues.
- Parable of the undefined pathways. Attributed to Disney, that pathways were unpaved at first, and remained unpaved until a worn path was apparent. With IT processes, if people are finding a way around the current processes, either by short circuiting through people or by sneaking through steps.
- There is a dilbert cartoon from a number of years ago that depicts a manager coming in basically on a bungee cord and immediately leaving again. Continuously changing plans and directions before the prior changes have had time to gel damages management credibility and creates an environment where everyone feels like you’ve cried wolf too many times. This particular dysfunction is driven by personnel churn to some degree, but also through impatience.
- You’ll be assessing the organization where you want to create new workflows and a more DevOps-like culture. You don’t have to talk to every person in a 10,000-employee org. You need to get a feel for how things are going and how folks feel about things today. You want to try to meet people in person if possible, it helps create rapport, and helps people feel more comfortable. Also, if you can meet with key stakeholders individually, they are more likely to open up and not shy away from telling their whole story.
- And i mean everyone. Everyone from product management, development, operations, QA, customer support, design, whatever. Treat it as an exercise in learning about the project; pretend you have no prior experience with the project and are gathering data as a new employee. Every portion of the product team has a different view of the project universe. Partially this is because of specialization, partially it is because of weak communication, partially it is just about understanding all of the moving parts of a large project.
- Start with the goals question. When you get lots of different answers, you know you have some work to do just to get everyone on the same page before driving them towards a new workflow
- People love to tell you about their problems. Love it. Seriously. People want someone to listen to their concerns, and professionals who are dedicated to doing a good job and being successful will have a lot of insight into where things are broken and need improvement. You may find that the most broken thing in the project is a person. You might find it’s a piece of software intended to make things easier and more manageable. You may find that it’s general apathy...
- This is basically another open-ended essay type question.
- I ask a “Dream Team” question in many cases. You find that there are one or two super-awesome people who everyone wants on their projects. If you can determine what makes these folks so sought-after, or get one or two of them signed up for your initiative or at least to verbally support you, you can capture a lot of mindshare without a lot of heavy lifting. These influential folks aren’t always managers, or team leaders, or even official technical leaders, but they garner trust and people listen to them.
- You can also find out exactly what everyone is already working with. in large environments, teams often develop their own methods for getting their tasks completed. Tools being used on one team may adversely impact the tools being used on another team. You also want to know where everyone is tracking their work; is it open to everyone? can all members of the project team see what everyone else has in their queue? How do team members report their work status? are they only reporting to their line manager, or do they also report directly to someone on the project in a more generic sense.
- Ask everyone questions about the problems that are driving you to undergo this change of workflow and patterns. If you are after smoother deploys, ask them what’s wrong with deploys. if you are looking for better time-to-market, ask them what holds them back and what they spend the most time on. You’re looking for a baseline to start to set goals against. Knowing that your deploys take 12 hours and 20 people on the phone gives you a starting point to improve from.
- part of your assessment will likely show you who will be an obstacle. you can prepare for those people, maybe by reassigning them or pairing them with someone else. You also want to get your team trained on any new tools they will be using in the pilot project. If your pilot includes moving from hand-built systems to configuration management, get folks trained in advance. if your pilot uses a cloud provider instead of on-premise hardware, get them trained in how they’ll be affected by that difference. you want to make people confident and comfortable that they’ll be able to do their jobs well using new processes.
- : does your team need a reorganization to reposition weak assets? : do you need to find new tools : do you need to train people on some tools
- A few years ago, we suggested doing shallow but wide pilot projects, focusing on a single piece of functionality in your stack and changing its workflow or process. That was not the optimal approach to changing how teams and projects operate. To really change how people are approaching their workflows for modern IT projects, you want to find a project that you can take from soup to nuts. This will give you an opportunity to find all of the resources that are hidden behind brick walls or in black holes. Existing projects that are starting a new version are probably the next best thing to a whole new project, because you’ll be disrupting a lot of the ingrown procedures established in your organization. Total brownfields are difficult to do. If you are asking a mature project that has well established workflows and organizational structures to change, you need to have a good track record of successful change projects already under your belt. These projects aren’t especially good for pilots, but are good for building consensus and internal support later in your change process.
- Deconstructing your project workflow gives you an opportunity to realign goals and values; you may create contention or make people uncomfortable about their roles or influence in the organization. Pilot projects also give you a first look at how important external requirements are. Some are there for accounting, like chargebacks and resource limitations. others are there for security, like time consuming code profiling steps. Others are in place simply because someone felt at one time that it was necessary, like lots of gates around approving releases for production.
- Greenfielding means starting fresh; a new project that is just getting rolling is a good candidate for a DevOps initiative. Existing projects that have process “because that’s the way we’ve always done it” are more difficult to wrangle to a new way of thinking. It also limits how many things you might miss because they are already in place for the existing project. Use this opportunity to flush out all of the steps required to get a new project rolling. it’s important to see the whole project come to life. An article earlier this year about repatriating manufacturing to the US in the Atlantic describes how a consumer product being manufactured in China. When they laid out the line in the US, they discovered that the system as designed was almost unbuildable, requiring a lot of custom welding and specialized work. the deconstruction of the process illuminated the issues with the current product design and allowed the team to rework it and build something better and more efficient.
- Bottlenecks happen. bottlenecks that hold up your timeline for no apparent reason are frustrating. when you work through a pilot project you find these folks and can determine if what they’re doing for you has enough value to derail your project. This is another area in which executive buy-in is key; grease from a higher level fixes more squeaky wheels.
- If your goals were around lowering deployment time? have you improved the deployment time for the current build? if your goal was to improve time to market, how long is it currently taking new features to get through the build system and onto the live environment?
- The old saw about system administrators replacing people with shell scripts or computer programs is a bit scary and partially true. Your company should be getting the kinds of work out of human beings that is hard for computers to do, not copying and pasting configuration settings onto servers or networking gear.
- Think about the kinds of services provided by commercial cloud providers. You can’t get an infinite number of different combinations; you choose which stock configuration best fits your current needs. The predictability of baseline services streamlines planning and speeds up implementation. The fewer choices a team has for particular services, the better they can plan the product behavior around the current offerings. when there are no barriers or limitations to what a product team can request for their product, the more likely it is that they’ll want something totally off the wall. Reward teams who follow the service catalog with quick turnarounds. Want a hole punched in the firewall? Follow these rules and you can have it tomorrow. Need DNS? same idea! You can also attach known charges for accounting and chargeback. The next generation of IT services are self-serve.
- One of the first questions we get when we’re working with a customer new to DevOps, infrastructure as code, and modern process in general is how long will the project take. Think about the projects you work on. How long does it take to get something from the planning stage, through development and QA, and into production? it’s going to take that long to get a whole new process in place. It’s similar to the initiatives that brought Agile to large teams. it takes time, it takes practice, it requires dedication to following the new workflows and using the new tools
- Did you miss something? This is all about collaboration! It’s not about locking down the new tools like you had locked down the old tools.
- Maaaybe? Change initiatives are more successful if you get buy in across the organization and don’t have to let anyone go. If you do have someone who just can’t get on board, it could be time to send them on their way. You may find people who believe the whole project will fail because their part can’t be streamlined or automated.