As Problems and Markets Evolve, So Too Must Development Teams
As Problems and Markets Evolve, So Too Must Development Teams
We explore why Agile, Scrum, and DevOps are taking over the world, and what companies must do to stay competitive in an increasingly agile world.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
Scrum is the lightweight project management method which is most often utilized in applying the principles of Agile to software delivery. Within the Scrum framework, volumes have been written about the roles of the Product Owner and Scrum Master. What about the development team?
A development team is composed of individuals, each with their own histories and unique set of skills. Very often they have worked in company with others on loose teams but have primarily contributed as individuals to software projects and have been rewarded commensurate with their contribution to the success of those projects. However, in Scrum, the emphasis is on the delivery of potentially shippable software in short intervals as a team.
A Scrum development team is self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all the competencies needed to accomplish the work without depending on others who are not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity as they plan, act, and deliver together.
The first of the twelve principles in the Agile Manifesto is, “Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.” But with Scrum, the goal has been the delivery of ‘potentially shippable code’ after every Sprint. So why all the excitement around DevOps? DevOps seeks to move from ‘potentially shippable’ to ‘shipped’ – and this shift requires that the development team evolve yet again.
In an article entitled “From Agile to DevOps to continuous delivery: An evolution in software delivery”, the author states that:
"With the release of Jez Humble's breakthrough book, Continuous Delivery …, the notion of treating the entire software lifecycle as a single process—and one that could be automated— was embraced not only by startups but also by Fortune 1000 companies. This helped elevate the value of Agile initiatives that were stalled and blocked and raised the stakes for software delivery as a strategic business initiative. While Agile addressed the needs of developers, the investment in DevOps initiatives and CD offers businesses much higher returns—a way to truly realize the goals outlined in the Agile Manifesto and support them throughout the software delivery lifecycle.”
That a new buzzword, DevOps, has entered our vocabulary certainly seems to herald a new round of transformational initiatives which may or may not succeed as businesses continue to seek the chimera of competitive success. What do team members with backgrounds in development, operations, testing, analysis, architecture, infrastructure, and information security need to know to enter into this brave new world of Continuous Delivery? What tools, processes, methods, and standards will they need to learn and incorporate into existing workflows to benefit from this evolution?
First, by way of clarification, there are three terms that are often used interchangeably: Continuous Integration, Continuous Deployment, and Continuous Delivery. Teams following Extreme Programming engineering practices have been doing Continuous Integration since the mid-nineties. Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. Very often, automated tests, unit, integration, acceptance, code quality, are included in the build to verify code quality.
The next step was the concept of continuous deployment, defined in a paper by Jez Humble again, along with Chris Read and Dan North in 2006 entitled, "The Deployment Production Line." In this monograph, they outlined an approach where not only functional code but also the environments would be created, deployed and kept under version control. This was followed by Continuous Delivery in 2011. In their most recent book, The DevOps Handbook, Gene Kim, Jez Humble, Patrick Dubois, and John Willis use a framework for implementing the positive changes needed to realize the benefits of Continuous Delivery/Deployment comprised of what they call the Three Ways. These are:
The Principles of Flow.
The Principles of Feedback.
The Principles of Continual Learning and Experimentation.
It is the third principal which I believe is the most important to software delivery teams as they take up the DevOps challenge.
The chart below illustrates Westrum’s model of the three types of organizational cultures. It is the Generative culture in which DevOps can flourish and make the kinds of contributions which lead to improved market share among competing businesses. We must move to a culture which encourages team members to investigate in a safe environment and thus grow in their skills.
Westrum’s 3 Organizational Cultures
In order to move to implement the strategy of Continuous Delivery, we must encourage high collaboration and innovation. This means breaking down organizational barriers to team experimentation. We must move along the axis from the Pathological to the Generative.
Historic industries (i.e., automotive, steel, construction) have a tough job ahead of them as they attempt to move from long-standing practices and cultures of command and control to cultures that are built on trust and innovation. Not all will be able to make the shift. Those that can’t, will be left behind as Kodak was. We must stop outsourcing our skilled IT jobs to low-cost areas of the world and invest in our in-house teams. IT cannot be considered a cost center anymore. Every company of any size is a software company and to stay competitive they must all see software and IT as an integral part of their market strategy, brand promise, and product delivery.
So what should be our call to action? It is this: only so long as individuals feel safe within their corporate environment, and empowered to make decisions that are not countermanded by remote management, are teams capable of overcoming the challenges and seizing the opportunities now being realized by the Agile evolution to DevOps. Within that culture of safety and continual learning, skills acquisition with emerging technologies, tools and techniques must be a part of everyone’s job and a continuing goal of the business.
Published at DZone with permission of Daniel Williams . See the original article here.
Opinions expressed by DZone contributors are their own.