• Welcome to the New DevOps Blog for IT Professionals

    Welcome to our new DevOps blog. My name is Volker Will, I lead the enterprise evangelism team for IT Professionals in the Microsoft Developer and Platform Evangelism group.

    My team of technical subject matter experts focuses on evangelizing various technologies and scenarios relevant for IT operations teams in enterprises of all sizes. The focus of our work is driven by existing and even more so by new products coming from Microsoft as well as emerging technology trends in the IT industry. The team combines over 70 years of direct IT Pro experience to provide opinions and recommendations on products and services optimized on the Microsoft platform, including Open Source tools. Whether you’re avid watcher of the Edge Show, if you’ve attended an IT Camp, or if you’re new to Microsoft’s programs designed specifically with you, the IT pro, in mind, my team of technical experts travel around the world to teach and listen to IT pros building a library of technical content and resources on Microsoft Virtual Academy.

    What this blog is about

    Posts on this blog will focus on DevOps and what it means for the enterprise operations teams. Because there are at least as many definitions of DevOps as there are rainy days in Seattle and we will try to not add another and rather use a next post to discuss the relevance of closer collaboration DevOps-style. This blog will focus on sharing best practices, information about tools and products from Microsoft and others. We will share experiences we have had internally at Microsoft, as well as those from customers and partners we talk to. Our goal is to listen and understand how DevOps is emerging and evolving in your organization.  We encourage you to engage in the conversation and share your own thoughts and feedback with us.

    The world is different from yesterday

    Developers and operations teams, all of IT in the enterprise actually, is driven by the business demands to deliver more and better results, richer features and tools in less and less time and of course with higher quality than ever. On the developer side, agile development methodologies have by far surpassed the “old” waterfall model in effectiveness and efficiency. More and more development groups move to new ways of satisfying business requirements fast and furiously. Terms like continuous delivery, MTTD and MTTR define the effectiveness of teams beyond just development.

    Faster moving markets require higher levels of agility from developers. Quicker delivery of new features and bug fixes create the demand for an ever faster moving IT, creating a whole new set of challenges for operations team in the enterprise.

    In this world of Agile, operations teams are often perceived as road blocks on the highway to faster and faster delivery into production. Developers like IT professionals are artists of their profession. Over time they “developed” many creative ways to circumvent operations teams and move their code into production avoiding the operations bottlenecks. “Shadow IT”, one of the better known ways of avoiding the operations team, has emerged and created a whole new set of problems for businesses of all sizes.

    Opportunity, not threat

    This different world of creating software and building solutions demands the evolution of IT. A trend that has emerged over the past few years is DevOps. Our goal with this blog is to help you navigate DevOps and to support you to evolve your organization to better collaborate with your developers and other teams to be successful in a world of continuous delivery. Along the way we intend to share tips and tricks and best practices.

    This will be fun.

    Between now and the next post – and if you have some spare time – here’s a few resources I recommend taking a look at:

    Book: The Phoenix Project

    Book: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

    Book: The Visible Ops

    Blog: Microsoft Open Technology

    Blog: Visual Studio Application Lifecycle Management

    Web: http://www.agilemanifesto.org/

    Web: Visual Studio News

    Web: Edge Show episodes on DevOps

    @volkerw

  • The Three Musketeers of DevOps

    How can any organization launch products, services and solutions without focusing on the three “P”s – People, Processes and Products?

    You need the right people, following appropriate processes using the proper technology or products to accomplish a task or solve a problem. How is this related to DevOps you might ask?

    DevOps is about these three most important assets in any organization: People, Processes, and Products. They are the Three Musketeers of DevOps (Tous pour un, un pour tous).

     *

    Last week I introduced the DevOps blog series starting with what DevOps means to IT Pros.  . Bookmark this site and follow me on Twitter at @volkerw as my team digs deeper into the role of IT Pros within DevOps.  If you’re interested in the underlying technology roadmaps and products available from Microsoft and 3rd parties, a new series will start in May at DevOps in the Cloud.

    Is DevOps a role or function?

    Before we go any further, let’s get this out of the way.  What’s this DevOps all about? There’s as many opinions about what DevOps is as there are people in IT – at least. I’m going to rely on an excellent phrase coined by Adam Jacob, founder of Chef and OpsCode:

    DevOps is a cultural and professional movement. Period. That’s it!

    It is a broad initiative involving most anyone in IT. It is a way of doing work or more narrowly a new way of increasing agility and shortening cycles between application development (Dev) and operationalizing the new application within the business (Ops). Other than the term DevOps might indicate, this movements goes well beyond the Dev and Ops teams. It requires involvement throughout the entire application lifecycle management (ALM) from inception of the idea throughout development, test, and finally deployment, management, and monitoring. But in reality, no one can tell you what DevOps means in your situation. You have to figure it out. Besides all guidance and smart tips, it depends on you and your very specific situation what DevOps means for you. Or to paraphrase a senior leader from a large enterprise who just spoke at ChefConf 2014: “If someone tells you this how to do DevOps, or here is the roadmap, they are full of s**t.” Paraphrasing of course. J

    At times it helps looking at what something is not. Let’s look at what DevOps is not. Below my favorites, derived from the Twelve DevOps Anti-Pattern:

    Neither is DevOps just a person or role nor a new process of doing things. You cannot “do DevOps” just by using a new set of products and tools. DevOps is about collaboration across functional boundaries, involves experimentation and the ability to act fast on feedback. And for any DevOps work to be successful it better creates business value along the whole product lifecycle, from cradle to grave.

    Enterprise IT is no different but some

    Driven by an ever changing business and its requirements to create new and better products and services with a competitive advantage, more and more pressure is put on all groups inside companies. Operations, developers, tester, QA, operations teams, security and networking groups alike, to name a few, feel this urgent need by the business to be not just better than the competition but also faster. Most likely developers experience this first. New features must be delivered faster than ever and with less bugs. If bugs are discovered, hopefully during the testing phase and not by the consumer, fixes must be deployed within hours rather than with a next major update in a few months.

    Startups may have a leading edge as they for one do not maintain a large base of legacy code. And with a strong tendency to use Microsoft Azure and other off-premise cloud based services for their core infrastructure and service delivery, there is way less investment in traditional on premise operations, allowing for greater agility. More often than not a startup displays a different culture than traditional enterprises. The whole company is just 10-20 people strong. Everyone may even work on the same floor, in the same room and close collaboration is their lifeblood. And every step that can be automated saves precious time and resources.

    On the other hand, larger and more mature organizations may have unique sets of requirements, restrictions, and regulations. Large enterprises in particular. Not to mention the boatloads of legacy code that no startup has to deal with. Other parameters like big geographically distributed teams or regulatory restriction pose challenges unknown to most startups. And in cases we see a natural resistance to change in the existing staff.

    Within even large enterprises, however, there might be net-new projects which could easily operate like a startup. Or the next iteration of a service or feature can serve as a greenfield project to try DevOps.

    DevOps is for everyone, large and small, startup as well as well-established enterprises. It is just that there is not one size that fits all..  While following DevOps practices should be in the future of companies of any size, careful introduction and thoughtful selection of the approach is key to its success. All enterprises are different from another, posing different sets of challenges for the teams involved.

    Microsoft believes DevOps can only be effectively implemented with the help of all of the Three Musketeers: People, Process, and Product. Following ideal DevOps practices requires taking on those three in the order listed.

    Over the course of the next few posts we will peek at each of the three musketeers of DevOps and their relevance when embarking on the enterprise journey to DevOps to save the day.

    To get you further started, here are a few additional resources to get you into the right mood for the next post.

    Resources

    -      Big Enterprises Need Big DevOps

    -      DevOps does not equal “Developers managing Production”

    -      Getting Started in DevOps Without Buy-In

    -      No, You Are Not a DevOps Engineer

    -      Where Is IT Operations Within DevOps?

    -      Twelve DevOps Anti-Patterns

    -      Top 11 Things to know about DevOps

    -       

    -      Have fun.

    -      @volkerw

     

    *Photo by Flicker user pasukaru76

     

  • Do not hire a DevOps Engineer

    DevOps is not a person, not a job description, and not a role. I’d be willing to bet you already have the right people with at least some if not all of the right skills currently on staff. They know the environment, the code, networking infrastructure and all. Engineers working on DevOps come from all disciplines as outlined above and most if not all of them are already on your roster.

    In a previous post we looked at the Three Musketeers of DevOps at a higher level. We looked at the term DevOps in general and what it means for companies brand new or more mature, small and large.

    This post will look at each of the Musketeers in more detail and why it is important to consider them in the order presented. What’s the significance of People, Process, and Product for DevOps?

    The People of DevOps

     As with anything new, some people embrace it and see the opportunity, others are adverse to change and see it getting in the way of how things work. IT managers, introducing DevOps top-down, have the difficult task selecting the right team members.

    Reading about DevOps on blogs and in the press you easily get the impression it is about developers taking over operations by coding a bunch of automation scripts and that’s it. No more operations required. Operations through code. With the cloud it has become even easier. No need to know how to setup a physical server anymore. Go to the cloud management portal, spin up a bunch of services and VMs and off you go or even better, use Visual Studio to do development, testing, and deploy.

    While there are phases during the application lifecycle requiring exactly that power and flexibility of the tools, reducing DevOps to just that could not be farther away from it. DevOps means people of different disciplines, different teams, and different cost centers now working together.

    Developers want (and need) freedom to change, to modify, to evolve code. Operations must “keep the lights on” at a reasonable cost. Stability, security, and availability are their mantra. But you cannot stop there. Any group involved in shipping a product (enterprise or not), must be involved at the right time, the right way to contribute its part to the success.

    How to get started with a DevOps Team?

    Especially enterprise Devs and Ops look at DevOps and most see the benefits – if only they could be like a startup. The various roles you need on your DevOps team vary by project. It should contain developers, sys admins, maybe a designer, you need security and networking folk close by and, ideally self-contained.

    Starting with small team working on a narrowly scoped project is good. Take a look at your parameters and decide. Many companies find these DevOps team inside their large organization to be very un-enterprise. That is a good thing. Small and un-conventional is the way to go.

    The most important thing is kept for last as it blends into the next topic. We saw teams failing in the beginning for the simple reason that team members did not feel empowered. Empowered to do what you may ask? Empowered to break the rules. While it highly impacts the people selection process, the team believing in their own empowerment defines your success from the get-go.

    Your company will only be able to take advantage of the DevOps paradigm if your people buy into the idea of the Three “P”, the musketeers of DevOps. Let’s take a look at the processes next.

    The Processes of DevOps

     Your new/old team is pretty excited: “We should have done this a long time   ago.” “I have always said we should do it this way, no one was listing.” “This was our idea all along.” DevOps is a journey more than anything else. Once you have figured out the people you want to take on your journey, time to look at the processes to get to DevOps land.

    First thing the team has to do is selecting the right set of tools, right? Wrong.

    Embarking on the journey requires you to understand or anticipate the roadblocks you may find along the way. You need to understand the scope of your project. Turning to automation or selection products only makes sense, once you fully understand the scope of the problem you want to solve.

    Regardless whether you are working on a green-field project or on improving features of an existing LOB application, the team must identify the scope first. What are you going to focus on solving collectively in a different way?

    Team must be allowed to break rules. IT, especially in larger companies, follows (many times very strict) rules how things are done. Processes that have been implemented over time are based on regulatory demands, best practices like ITIL and ITSM, infrastructure requirements, sometimes by people and skill availability. Following the rules is what keep them out of jail.

    Your DevOps team must be allowed to break the rules. Rules to select the proper tools to get work done. But also refrain from certain established standards. Even access to restricted resources (difficult subject) might be necessary.

    As for the overall processes of delivering results there a many lifecycle best practices to follow. Listen to your new DevOps team. Most members are with the company for some time. They have all the knowledge. They know the issues your current model has. Let them figure it out. Empower them.

    Microsoft provides guidance and suggestions using our tools and services supporting your successes in DevOps. IT pro is playing a key role and should – more than anyone else – drive this motion. Eventually the future success of your company depends on your agility to respond to the demands defined by the business and imposed by new development processes.

    Show me the Money

    As a matter of fact your team has to get out of hiding and start tooting their horn. Your business “allowed” you to find out if and what DevOps can do for them. You better be prepared to show results. And I am not saying you wait until you’re done. On the contrary. It is essential that you demonstrate what you are doing and explaining why you are doing it as often as possible. You probably have a senior executive as sponsor. Make sure he knows what’s going on. He will be under close observation by his boss. She will want to see improved performance and results.

    Doing demos to executive sponsors and to other teams will go a long way helping your company to transition to DevOps, and understanding the benefits, one project at a time. Communicating progress – good AND bad – will do a long way.

    DevOps is not a development best practice, nor is it an operational model. It is not developers forcing a new model onto operations, nor is it operations defining new or restrictive processes. It is the right people, implementing the right processes for the challenge. The following selection takes a look at the third musketeer, Product.

    The Products of DevOps

     We’ve looked at forming an innovative team. The team is allowed to break some rules along their way to delivering results the DevOps way. They start implementing improved processes, enabling them to deliver results in the expected quality and within expected timeframes.

    Now is the time to look at the infrastructure needs. Which tools support the selected processes? Do we have people with experience in certain products? What’s the role of the cloud? To what level should processes been automated? Git anyone? Depending on your resources and timelines, the team might decide to get developers and operations folks together and build the automation tools together.

    A few questions your team will have to answer. Some answers they will have to figure out along the way. And team members will have to learn a few new tricks as well. How many of your Ops people have scripting skills? I mean, like, really? Ruby can be hard, PowerShell is great but can be daunting at first. Working on continuous delivery, developers will have to look at infrastructure stuff. Here’s a situation your team might have to deal with frustration. Which developer wants to deal with infrastructure? Why would an IT pro look at or even touch code? DevOps is about collaboration. Be prepared for anything to happen.

    Mostly driven by demand from the developer community, the Open Source world has created a large number of tools supporting Agile development methodologies and continuous delivery movements required by Dev and Ops. More pointer in the section below.

    The list of tools and products used by companies of all sizes is almost limitless. Especially after recent announcements at the //Build 2014 conference, Microsoft provides plenty support for more agile teams beyond development. Look for pointers in the resources section below. Since cloud and Microsoft Azure are key enabler for DevOps, I suggest you taking a look at a very comprehensive blog post of a co-worker of mine, Brian Keller. He just posted “Building your Dream DevOps Dashboard with the new Azure Preview Portal.” Well worth your time.

    Our global team of IT Pro evangelists talk to customers of all sizes every day. In trainings, briefings, and meetings of all kinds we collect a tremendous amount of information about what works in operations, in DevOps, and more. Starting in May we will start sharing details about the use of Microsoft products and services and Open Source tools and services in DevOps scenarios. You will find pointer to the growing number of posts via their landing page here. And this blog will continue its DevOps journey too.

    I want to close this post with a reminder about how we started:

    Resources

    As always, more resources for you to familiarize or dive deeper

     

    Have fun.

    @volkerw

  • DevOps in the Enterprise – Hype or Necessity?

    Hey IT operations professionals, what do you think? All Hype? What's your CIO thinking? Is she already on board? Has your organization established a DevOps practice? Be it as it may, in most cases developers already have a head start at this using Agile development methodologies for years. It is about time we in operations pay attention.

    The more you read about DevOps, the more confusing it may become. But trust me, it is more than just hype. For a few fundamentals, please check out previous posts in this series. "The Three Musketeers of DevOps" and “Do not hire a DevOps Engineer?

    If I had to name four significant changes in IT over the past, say, 10 to 15 years, it would be the change from waterfall to Agile in 2000, the introduction of DevOps around 2010, the constantly growing adoption of cloud computing, and the fact that most company leaders learned that IT – operations in particular – is not some group somewhere in the basement deploying servers and preventing progress. They understood, IT is everywhere and is engrained all aspects of their business. If a business wants to be successful in today's fast paced world of mobile, cloud, and services, they need a nimble IT more than ever.

    Many understood. The CIO has a seat in the CxO Monthlies. Her participation in almost all business conversations is essential. Her voice is heard and she provides insight and guidance, helping making better decisions for the business.

    This puts a lot of additional pressure on the CIO and her staff. Not that she needs more work. This is where DevOps can come to the rescue. How so, you might ask? CIOs and operations staff across companies of different sizes who empowered teams working the DevOps way see improvements including the following:

    • 50% or greater improvements in software quality
    • Over 60% release more often
    • 50% or more see improve collaboration

    DevOps done right can help operations to become more agile and responsive.

    For as long as IT exists enterprises foster an environment where developer and operations are conditioned to work towards very different goals. Operations tasked with keeping the lights on while at the same time mostly kept in the dark about the business as a whole. Whereas developers constantly forced to create new value for the business. More and faster vs. stability and predictability. A model that has certainly reached its limits in this day and age.

    In new and emerging companies we see very different pattern. Born into fast paced, ever changing markets, and equipped with only little resources, collaboration and communication, and understanding of each other’s work are key. New behavioral pattern more often than not decide over success or failure of a project or the business as a whole.

    Enterprise IT started discovering the benefits of leaner teams and closer collaboration. Here is where DevOps comes in. Looking at in it more detail, in enterprises we see at least 4 areas benefitting from DevOps:

    Application Delivery

    Accelerate initial delivery and continuously update production apps by implementing DevOps practices, and as a result add more value to your business.

    Resource Optimization

    Optimize resources based on demand and taking advantage of Cloud economics where appropriate, through DevOps practices.

    Availability

    Shorten deployment times and recovery time from errors and help ensure SLAs by being involved early on in the lifecycle through DevOps.

    Application Quality

    Shorten MTTD & MTTR and help ensure SLAs by being involved early on in the lifecycle through DevOps.

    Let’s take a closer look.

    Application Delivery

    Situation

    Pressure to innovate and to be better, faster, and smarter than the competition is rising in all industries all the time. IT has been identified as a key player at the CxO table helping mitigate the problem. Business decisions demand higher agility from Dev teams. Business requires faster deliveries in shorter time and higher quality. Bug fixes immediately. Operation is faced with an unprecedented pressure to support ever shorter deployment cycles but other than the Devs they are still stuck with the old model. Dev does what it needs to do and Ops has little to no insight what's coming and is only engaged at the last moment for deployment into production.

    We all know all too well what happens. Developers (have to) resort to building stuff in the shadows, outside of Ops (Windows Azure, under their desk, etc.), and therefore sometimes outside of quality control, more often without operations integration. Operations is more than ever disconnected from Application Lifecycle Management (ALM), and are not perceived by Dev as adding value beyond basic provider of infrastructure. Shadow IT anyone?

    The operations teams in IT are viewed as a barrier instead of a partner and become overwhelmed attempting to reconcile the increased Dev-driven acceleration with traditional practices.

    Solution

    It is not sufficient to enable Devs team to become more agile if the rest of IT stays behind. Ops must be involved as early as possible in the lifecycle. In that sense, an app is not like a child that, hopefully, once old enough leaves the house and cares for itself. An app is a lifetime commitment for the Devs as much as for the Ops teams. And an app has more than just two parents. You need Devs to build it, Ops team to secure, network, deploy, and monitor it.

    The DevOps movement is all about helping to accelerate the delivery.

     

    Resources Optimization

    Situation

    Plenty of work is still run in one-off mode. Only few critical tasks are automated to the extent required to support agility demanded by the business. Lengthy hardware purchasing processes due to budget and datacenter resource restrictions lead to more delays in deployments of new products or features. This situation forces development teams to reach for other solutions like off-premise, public cloud resources. Integration with existing on premise services becomes more and more difficult. Security risks of unknown proportions can arise. Different development teams not talking to each other leads to more waste and not more efficiency. Creation of infrastructure in the cloud can create an unpredictable cost model for the business. Teardown anyone? Money is wasted. Forecasting of resources becomes a nightmare.

    Solution

    In a DevOps model operations and developers would work hand-in-hand with other teams like security and networking. Resources could be allocated appropriately. There will be no surprises when it comes to deployments. Developers will learn from operations how to take advantage of monitoring infrastructure and operations will know about resource requirement before actual in-production deployment.   Operations can help to not only automate the deployment of the infrastructure, but automate the deprovisioning of the infrastructure as well and save costs.

    DevOps can help to optimize resource planning, allocation, and usage.

     

    Availability

    Situation

    Whose fault is it? Problems arising in production or earlier are – in many cases – the problem of operation. They were the last to touch the code. They did not deploy according to specifications (if provided by developers). Troubleshooting becomes an issue due to teams resorting to the age old finger pointing exercise. Longer than expected outages lead to negative business impact due to lack of communications between groups. Lost business is imminent. Even worse for operations – if anything can be worse – is the damaging effect this has on operations teams’ credibility.

    Solution

    Early involvement of operations in the application life cycle will help mitigate situations like these. Joint planning and implementation of application monitoring supported through guidance from operations will help addressing upcoming issues earlier or prevents their occurrence. Operations providing test environments as close as possible to “real world” data will allow dev/test and Q&A to identify issues before production deployments. Predicable deployment in dev/test and production supported by automation and proper tooling, including self-service infrastructure, fosters developer independence without operations losing control or being in the way.

    Best of all, once you have a predictable infrastructure and the provisioning is automated, operations can provide a “repeatable offering”. The IT operations team can now setup and configure (and tweak if necessary) and is able to support features like automatic scaling for testing and in production.

    The DevOps movement can help improve overall availability.

     

    Application Quality

    Situation

    It is an age old problem, operations is holding the bag for issues that could be avoided if they would have been involved earlier during the application lifecycle. A strict separation between development and production deployment supports lack of accountability in development teams. It is the operations people carrying pagers and being called in when apps fail, not the developers.

    Lack of early involvement in the product development process and misaligned priorities between developers and operations lead to sometimes unpredictable results in application deployment and management. As a result poorly written or tested code is – due to missing knowledge transfer – poorly deployed and customers more often are the first to detect issues in production. Again, loss of customer trust and loss of revenue are the result.

    Solution

    In DevOps the fundamental difference is the shared accountability across the whole team. Or as Werner Vogels, CTO of Amazon, points out in an interview with acm: “You build it, you run it.” Using this approach, people are no longer abstracted from their responsibilities. Developers will directly face the consequences of writing bad code. Operations not providing appropriate infrastructure for dev and test will fail their team in making the necessary progress to deliver in time. Deployment into production will no longer be a surprise as operations will know firsthand about application requirements as they have been providing the test infrastructure and automation environment long before the app goes into production. Application problems will be discovered during the application lifecycle since test environments closely resemble production situations.  Furthermore, the Operations team may have products or tools which help to even identify code-level problems and by enabling these tools prior to deployment to production can significantly enhance code quality. Think Application Performance Monitoring with System Center Operation Manager and more.

    Increased application quality can be achieved using a DevOps approach.

     

    Overall

    Working in operations, DevOps can support your desire to innovate rather than focus on just keeping the lights on. This can be your opportunity to champion a different way to achieving better results for the business. A co-worker of mine draw this analogy. “Starting with DevOps, this must be like when virtualization became all the rage and operations was spearheading this effort to the benefit of the business. We in operations mastered this quite well.”

    Today virtualization is common place and operations transformed the business. Cloud computing is another territory to further discover. The beauty is, cloud computing with Microsoft Azure and DevOps go hand in hand and “the cloud” supports a DevOps model extremely well. And with products like Visual Studio, Visual Studio Online, System Center, AppInsights, and other managing and monitoring services in Microsoft Azure you find perfect companions for Devs and Ops to incubate DevOps in your organization.

    Many companies provide Open Source based tools and products that closely integrate with Microsoft Azure and other cloud providers. Microsoft Azure rapidly evolves and supports more and more DevOps scenarios. Industry support will only become better.

    This is the time for operations to get involved. This is the time to provide additional guidance to your business and to advance your career.

     

    Resources

    As always, a list of useful resources for your consideration.

    As a bonus if you read this post before May 7th, 2014, we have a great MVA Jumpstart coming where my team will address the challenges described in this post in more detail. If you have time on May 7th, between 9:00am and 2:00pm PDT, join us for a great live online event and a chance to ask your questions.

    TechEd 2014

    • DevOps focused sessions (excuse the output format)

    Video

    Blog

    Product

    Have fun

    @volkerw

  • Top 10 DevOps Books for IT Operations

    Regardless whether you consider yourself a decision maker in IT or if you are an ITI (IT Implementer), check out our top 10 booklist. Consider it our suggestion for an early summer read.

    Rather than a comprehensive guide to every book you may want to read about DevOps, this post reflects literature my team and I have been reading over time and consider it our must-reads to get started and dive in. My hope is our list will help you exploring the some of the background, some key challenges, and a bit about the general theory behind collaboration and team work.

    And of course we hope you share back you favorite book related to the topic of DevOps. Without any further ado, the list*, in no particular order.

    The Phoenix Project

    Bill is an IT manager at Parts Unlimited. It's Tuesday morning and on his drive into the office, Bill gets a call from the CEO.
    The company's new IT initiative, code named Phoenix Project, is critical to the future of Parts Unlimited, but the project is massively over budget and very late. The CEO wants Bill to report directly to him and fix the mess in ninety days or else

    Visible Ops

    The Core of Visible Ops Visible Ops is a methodology designed to jumpstart implementation of controls and process improvement in IT organizations needing to increase service levels, security, and auditability while managing costs. Visible Ops is comprised of four prescriptive and self-fueling steps that take an organization from any starting point to a continually improving process.

    Test Driven Infrastructure with Chef

    Test-Driven Infrastructure with Chef demonstrates a radical approach to developing web infrastructure that combines the powerful Chef configuration management framework with Cucumber, the leading Behavior-driven development (BDD) tool. Learn how to deliver real business value by developing infrastructure code test-first.

    Team Geek

    In a perfect world, software engineers who produce the best code are the most successful. But in our perfectly messy world, success also depends on how you work with people to get your job done.

    In this highly entertaining book, Brian Fitzpatrick and Ben Collins-Sussman cover basic patterns and anti-patterns for working with other people, teams, and users while trying to develop software.

    Lean Enterprise

    The first and most comprehensive book on bringing the startup mindset into large organizations. Forget vague notions of creating an "innovative culture." This book reveals the methodologies, tools, and incentive structures guiding the world's largest organizations to reclaim their innovation prowess.

    Continuous Delivery

    Getting software released to users is often a painful, risky, and time-consuming process. This groundbreaking new book sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers, and operations,

    Out Of The Crisis

    "Long-term commitment to new learning and new philosophy is required of any management that seeks transformation. The timid and the fainthearted, and the people that expect quick results, are doomed to disappointment." According to W. Edwards Deming, American companies require nothing less than a transformation of management style and of governmental relations with industry.

    The Goal: A Process of Ongoing Improvement

    In this intriguing, readable business novel, which illustrates state-of-the-art economic theory, Alex Rogo is a UniCo plant manager whose factory and marriage are failing. To revitalize the plant, he follows piecemeal advice from an elusive former college professor who teaches, for example, that reduction in the efficiency of some plant operations may make the entire operation more productive.

    Just Culture

    A just culture protects people's honest mistakes from being seen as culpable. But what is an honest mistake, or rather, when is a mistake no longer honest? It is too simple to assert that there should be consequences for those who 'cross the line'. Lines don't just exist out there, ready to be crossed or obeyed. We-people-construct those lines; and we draw them differently all the time, depending on the language we use to describe the mistake, on hindsight, history, tradition, and a host of other factors.

    The Etto Principle

    Accident investigation and risk assessment have for decades focused on the human factor, particularly ‘human error’. This bias towards performance failures leads to a neglect of normal performance. It assumes that failures and successes have different origins so there is little to be gained from studying them together. Erik Hollnagel believes this assumption is false and


    Bonus

     

    clip_image022

    Visual Studio Team Foundation Server 2012: Adopting Agile Software Practices: From Backlog to Continuous Feedback

    This is the definitive guide to applying agile development and modern software engineering practices with Visual Studio Team Foundation Server 2012—Microsoft’s complementary Application Lifecycle Management (ALM) platform. Written by the Microsoft Visual Studio product owner and a long-time Team Foundation Server implementation specialist,

    I am convinced you have additional suggestions!
    Did you find any great book that should have been suggested here? Which one did we miss? What's your favorite anyway?

    Have fun

    @volkerw

    * All references are to the Amazon bookstore