What Is DevOps?

DevOps (a clipped compound of development and operations) is a term used to refer to a set of practices that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably

Where Did DevOps Come From?

DevOps is the offspring of agile software development – born from the need to keep up with the increased software velocity and throughput agile methods have achieved. Advancements in agile culture and methods over the last decade exposed the need for a more holistic approach to the end-to-end software delivery lifecycle.

The DevOps ideals extend agile development practices by further streamlining the movement of software change thru the build, validate, and deploy and delivery stages, while empowering cross-functional teams with full ownership of software applications – from design thru production support.

DevOps is an IT mindset that encourages communication, collaboration, integration and automation among software developers and IT operations in order to improve the speed and quality of delivering software.

DevOps teams focus on standardizing development environments and automating delivery processes to improve delivery predictability, efficiency, security and maintainability. The DevOps ideals provide developers more control of the production environment and a better understanding of the production infrastructure. DevOps encourages empowering teams with the autonomy to build, validate, deliver and support their own applications. With DevOps, nothing gets “thrown over the wall.”

What Are the Challenges DevOps Solves ?

Prior to DevOps application development, teams were in charge of gathering business requirements for a software program and writing code. Then a separate QA team tests the program in an isolated development environment, if requirements were met, and releases the code for operations to deploy. The deployment teams are further fragmented into siloed groups like networking and database. Each time a software program is “thrown over the wall” to an independent team it adds bottlenecks.

The problem with this paradigm is that when the teams work separately:

• Dev is often unaware of QA and Ops roadblocks that prevent the program from working as anticipated.
• QA and Ops are typically working across many features and have little context of the business purpose and value of the software.
• Each group has opposing goals that can lead to inefficiency and finger pointing when something goes wrong.

DevOps addresses these challenges by establishing collaborative cross-functional teams that share responsibility for maintaining the system that runs the software and preparing the software to run on that system with increased quality feedback and automation issues.

What Is the Goal of DevOps?

Improve collaboration between all stakeholders from planning through delivery and automation of the delivery process in order to:

• Improve deployment frequency
• Achieve faster time to market
• Lower failure rate of new releases
• Shorten lead time between fixes
• Improve mean time to recovery

What Tools Are Used in DevOps?

Earlier we briefly discussed some of the tools used in DevOps; here are some of the key tools and practices you need to know.

Source Code Repository
A source code repository is a place where developers check in and change code. The source code repository manages the various versions of code that are checked in, so developers don’t write over each other’s work.

Source control has probably been around for forty years, but it’s a major component of continuous integration. Popular source code repository tools are Git, Subversion, Cloudforce, Bitbucket and TFS.

Build Server
The build server is an automation tool that compiles the code in the source code repository into executable code base. Popular tools are Jenkins, SonarQube and Artifactory.

Configuration Management
Configuration management defines the configuration of a server or an environment. Popular configuration management tools are Puppet and Chef.

Virtual Infrastructure
Amazon Web Services and Microsoft Azure are examples of virtual infrastructures. Virtual infrastructures are provided by cloud vendors that sell infrastructure or platform as a service (PaaS). These infrastructures have APIs to allow you to programmatically create new machines with configuration management tools such as Puppet and Chef.

There are also private clouds. For example, VMware has vCloud. Private virtual infrastructures enable you to run a cloud on top of the hardware in your data center.

Virtual infrastructures combined with automation tools to empower organizations practicing DevOps with the ability to configure a server without any fingers on the keyboard. If you want to test your brand-new code, you can automatically send it to your cloud infrastructure, build the environment and then run all of the tests without human intervention.

Test Automation
Test automation has been around for a long time. DevOps testing focuses on automated testing within your build pipeline to ensure that by the time that you have a deployable build, you are confident it is ready to be deployed. You can’t get to the point of continuous delivery where you’re fairly confident without any human intervention that your code is deployable without an extensive automated testing strategy. Popular tools are Selenium and Water.

Pipeline Orchestration
A pipeline is like a manufacturing assembly line that happens from the time a developer says, “I think I’m done,” all the way to the time that the code gets deployed in the production or a late-stage pre-production environment.

Unifying Enterprise Software Development and Delivery
The VersionOne Enterprise Agile Platform unifies agile application lifecycle management and DevOps, providing a full picture of your entire software delivery pipeline in a single platform. VersionOne® Continuum™ for DevOps is an enterprise continuous delivery solution for automating, orchestrating, and visualizing the flow of change throughout the software delivery cycle.

The conflicts and complaints wall

COBIT and ITIL,  Differences and connections

 ITIL (Information Technology Infrastructure Library) 

ITIL could be seen as the way to manage the IT services across their lifecycle, ITIL describes in more detail the parts of enterprise IT that are the service management enablers (process activities, organizational structures, etc.).

COBIT (Control Objectives for Information and Related Technology) 

COBIT is about how to Govern the Enterpise IT in order to generate the maximum creation of value by the business, enabled by IT investments, while optimizing the risks and the resources.

The distinction between the two is sometimes described as “COBIT provides the ‘why’; ITIL provides the ‘how.’” While catchy, that view is simplistic and seems to force a false “one or the other” choice.

COBIT is based on five principles:

1. Meeting Stakeholder Needs
2. Covering the Enterprise End-to-End
3. Applying a Single, Integrated Framework
4. Enabling a Holistic Approach
5. Separating Governance from Management

And seven enablers:

1. Principles, Policies and Frameworks
2. Processes
3. Organizational Structures
4. Culture, Ethics and Behavior
5. Information
6. Services, Infrastructure and Applications
7. People, Skills and Competencies

ITIL focuses on ITSM and provides much more in-depth guidance in this area. 

There are five stages in the ITIL Service Lifecycle:

1. Service Strategy
2. Service Design
3. Service Transition
4. Service Operation
5. Continual Service Improvement

The Scrum Master role

Scrum Masters are those who fully understand Scrum, and help the Scrum Team by coaching them, and ensuring that all Scrum processes are implemented correctly.

The Scrum Master is a management position, which manages the Scrum process, rather than the Scrum Team. Is a servant-leader for the Scrum Team.

Besides ensuring that the Development Team understands and uses Scrum correctly, the Scrum Master also tries to remove impediments to the Development Team, facilitates their events, and trains and coaches them.

The Scrum Masters help the Product Owners too, by helping or consulting them on finding techniques, communicating information, and facilitating related events.

The responsibilities of the Scrum Masters are not limited to the Scrum Team. They should also help those outside the Scrum Team understand the appropriate interactions with the Scrum Team to maximize the value created by the Scrum Team. The Scrum Master usually leads the organization in its effort to adopt Scrum.

There is not Project Manager role in Scrum, and none of the 3 roles of Scrum (Product Owner, Scrum Master, Development Team) act as a traditional project manager.  

Sometime  people consider the Scrum Masters to be the equivalent to traditional project manager,  but it is not true, because the Scrum Master responsibilities are very different than a traditional project manager.

The project management responsibilities are distributed among the three roles of Scrum and there is no centralized project management in Scrum.

Evolución del Management

Management 1.0:  jerarquías

La gestión clásica viene definida de arriba abajo. Hay directores, gerentes, jefes, encargados, coordinadores…, un cúmulo de despropósitos diseñado para que el trabajo descienda hasta la base, de forma que la motivación de la capa inferior sea tan baja que las ganas de hacer un buen trabajo no lo compense ningún salario.

 La toma de decisiones se vuelve tan lenta que, cuando se decide algo, ya es demasiado tarde y la realidad ha cambiado tanto que o bien es un tema obsoleto o en realidad habría que hacer en ese momento justo lo contrario de lo decidido.

Management 2.0:  Orientado a Procesos (Teoría de las restricciones o Gestión de la Calidad)

Con el aumento de la complejidad, motivado  fundamentalmente por la tecnología, hubo personas que se dieron cuenta de que era necesario hacer cambios, porque se estaba llegando al techo de eficacia en esas organizaciones.

 Pero entonces llegaron metodologías que pueden funcionar bien en cadenas de montaje, pero que en el trabajo relacionado con el conocimiento de las personas es decepcionante, como Six Sigma, Teoría de las restricciones o la Gestión de la calidad total.

Management 3.0:  la gestión de la complejidad

La organización se basa en redes. No importa que se construya distintos departamentos con muros  , todo está relacionado y si quieres hacer un buen trabajo, esos muros deben ser derribados.

Por otra parte, la gestión deja de fundamentarse en departamentos y beneficios, pasando a estar centrada en las personas y las relaciones entre ellas. Jurgen  va aún más allá  y define las Empresas no como un engranaje que debemos hacer funcionar, sino como un organismo vivo cuya complejidad hace inviable que podamos aspirar a tenerlo todo bajo control.

La gestión y el liderazgo se dan la mano en el Management 3.0. 

No se trata de poner un nombre más, sino de entender que la complejidad no se puede controlar con procesos rígidos, salvo casos excepcionales, y la diferencia entre una empresa que sobrevive y otra que no radica en las personas que componen esa organización y la forma de relacionarse entre ellas.

Nexus is the exoskeleton of
scaled Scrum

What is Nexus?

Nexus is a framework that drives to the heart of scaling: cross-team dependencies and integration issues.

It is an exoskeleton that rests on top of multiple Scrum Teams who work together to create an Integrated Increment. It builds on the Scrum framework and values.

The result can be an effective development group of up to 100 people. For larger initiatives, there is Nexus+, a unification of more than one Nexus. 

Download The Nexus Guide

https://www.scrum.org/Resources/The-Nexus-Guide/Downloads

-------------------------------------------------------------------------------------------------------------

9 keys to understand the Nexus Integration Team.  By  Jerónimo Palacios 

It’s all about solving dependencies

Nexus is focused is solving the primary source of issues and problems when scaling beyond two Scrum Teams: dependencies. No matter how nvolved your corporate culture is or how well your retrospectives are facilitated, if you join more and more teams working in the same product, you’ll face integration issues. Remember that the goal is deliver a Done Increment, integrated, at the end of the sprint. Thus, is important that someone remains accountable and responsible to deal with integration issues.

The Nexus Integration Team is a role, performed by several people

The Nexus Integration Team is compound by the Scrum Master, the Product Owner and whomever needs to be there to make sure that Integration actually happens to deliver a Done Increment at the end of everyNexus Sprint. That may be proper representatives from the team, a DevOps guy or one member from each Scrum Team.

And still, is a Scrum Team

The Nexus Integration Team behaves as another Scrum Team within the Nexus. While its main focus isIntegration that facilitates a Done Increment that may be inspected during the Sprint Review, it may pull and work other Product Backlog Items that are relevant for producing the Increment.

And yet, its composition may change

Dependencies and integration may vary from Sprint to Sprint. While Scrum Teams are relatively stable, the NIT will change to reflect challenges. Because at the beginning of a Scrum project the focus will be on a DevOps tooling infrastructure and later may be on End-to-end testing, the NIT will inspect and adapt its membership to show those challenges. What will remain stable is the Product Owner and Scrum Master membership.

While being responsible for Integration does not mean that it has to perform integration itself

Imagine having to integrate the work from seven Scrum Teams every sprint. Crazy, huh? The way theNexus Integration Team achieves its goals is not by doing actual work but rather facilitating that integration exists across the different Scrum Teams on the Nexus.

Tooling, tooling, tooling

And the best way to achieve Integration resulting on a Done Increment is tooling. Rather than spending infinite hours figuring out where a problem resides, a smart Nexus Integration Team works on setting up a tooling infrastructure that supports Continuous Integration, Deployment and Delivery, ensure the cohesion of tools across teams the closer the end of the pipeline is.

And Teaching. And Coaching. And Patience

The job of the Nexus Integration Team may be exhausting. Because achieving a Done Increment by doing integration itself is out of the question, the work of the NIT requires prodigious amounts of teaching, coaching and patience, using those core practices already present in Scrum to facilitate Scrum Team’s proper delivery.

This sounds a lot like the Scrum of Scrums

Well, no. There is a lot of common sense on the Scrum of Scrums. It is just a meeting. The Nexus Integration Team addresses the flaws of the Scrum of Scrums creating a role that remains accountable for integration. Have you ever heard that complain: “We don’t have time for DevOps infrastructure”. Well, your NIT does.

And if you think you still haven’t got it

Remember the first time you heard of the Scrum Master? It took a long time until people started to understand what a Scrum Master is. Nowadays, nobody argues the existence and benefit of having aScrum Master managing the Scrum process within the Scrum Teams. Yet it is difficult to explain. Well, in a few years no-one will question the existence of the NIT.

Product Owner

The Product Owner role in LeSS is conceptually the same as in one-team Scrum. However, at scale the focus changes slightly toward keeping an overview and ensuring the maximum return on investment (ROI) in the product.

Scaled Product Owner

It’s common in large-scale product development for different people to pull in different directions and for subgroups to focus on local sub-optimizations. Maintaining one Product Owner with one Product Backlog supports whole-product focus.

In traditional large-scale product groups, there’s a group (often product managers) that focuses outward and a group (usually developers) that focuses inward — and never the twain shall meet. In LeSS, the one Product Owner has lots of free time to focus outward on customers and their priorities while also being able to spend some time looking inwards to the teams. He acts as a connector, bringing teams and customers/users together so the teams become more customer focused.

In contrast with other scaled Scrum approaches, it’s possible in LeSS to effectively scale the Product Owner role with just one person because there are fewer roles and positions, and less complexity.

Prioritization over Clarification

There are two key information flows in Scrum related to the Product Owner: (1) prioritizing (ordering) items in the Product Backlog and (2) clarifying items in the Product Backlog. In the first flow (prioritization), information related to profit drivers, strategic customers, business risks, and other business concerns is sought and analyzed. In the second flow (clarification), information is sought to detail the behavior and qualities of items, the user experience, and other feature design concerns.

A LeSS Product Owner focuses on thinking hard about prioritization but collaborates with the teams on clarification. Further, he encourages and helps the teams enter into a direct conversation with true users and customers for clarification. He acts as a connector, not an intermediary.

Why emphasize direct interaction between teams and customers/users? Reasons include: (1) avoiding information loss from handoffs, (2) fostering co-creation of solutions to real customer problems, and (3) improving motivation and empathy for customers by having developers collaborate with them directly.

It’s worth noting that when the teams do most of the clarification work the Product Owner has more time and energy to focus on the big picture, continuously prioritizing and exploring new and strategic opportunities.

Requisitos vs Casos de uso vs Historias de Usuario

Posted on 28 febrero, 2016

¿Qué diferencias hay entre estos 3 conceptos?

Los tres intentan representar las características que tiene que tener un sistema, la diferencia está en el enfoque dado.

Los Requisitos del sistema están escritos desde la perspectiva del sistema y no en la interacción del usuario, representan las características en estado puro.

Los Casos de Uso están escritos como una serie de interacciones entre el usuario y el sistema. Hacen hincapié en el contexto orientado al usuario. Las características que utiliza cada usuario identificado en el sistema. Son la forma de capturar los requisitos del sistema desde el punto de vista del usuario.

Las Historias de Usuario sirven para describir lo que el usuario desea ser capaz de hacer. Además, las historias de los usuarios se centran en el valor que viene de usar el sistema en lugar de una especificación detallada de lo que el sistema debe hacer. Están concebidos como un medio para fomentar la colaboración.

Los requisitos y los casos de uso se pueden utilizar en desarrollos ágiles de software, pero ambos se apoyan fuertemente en las especificaciones documentadas del sistema, en lugar de colaboración tradicional de los métodos ágiles. Si no existe un enfoque integrado en la colaboración, es posible que se ahonde en una especificación detallada en el caso de uso que se convierte en la fuente de registro en lugar de un mecanismo de conversaciones.

En resumen las diferencias son: los requisitos tradicionales se centran en las operaciones del sistema, con una tendencia a la especificación detallada del sistema, los casos de uso se centran en las interacciones entre el usuario y el sistema con una tendencia similar de las especificaciones detalladas, y las historias de los usuarios se centran en el valor del cliente con una fuerte intención de fomentar la comunicación. 

¿Son las historias de usuario mejor que otros tipos de especificación de requerimientos? Depende de la situación, pero en un ambiente de colaboración, la experiencia indica que claramente sí. Las historias de usuarios no hará que el proyecto sea ágil, o la falta de ellas hará que sea difícil adquirir agilidad.

Si estamos en un contexto no-ágil, ¿ayudan las historias de usuario? Depende del equipo. Si un equipo está inmerso en un proceso de desarrollo en cascada o con procesos iterativos pesados y se utiliza el enfoque de “planificación pesada y requerimientos up-front”, es muy probable que influya en las historias de los usuarios, convirtiéndolas en requisitos tradicionales. Las historias de usuarios son claramente un poco vagas en cuanto a descripción y se prestan a refinamientos sucesivos, la planificación y el diseño por adelantado no es su punto fuerte. La especificación detallada a menudo es la práctica en entornos de procesos controlados y pesados, antes de que comience la codificación de manera que los requisitos se puedan utilizar para planificar el presupuesto y el proyecto entero.

Las historias de usuarios (cuando se utiliza según lo previsto por algunos expertos, p.ej: Cockburn) son demasiado vagas en formato para prestarse a una documentación completa. Pero si, por el contrario, el equipo está abierto a la colaboración con los usuarios, el cliente, los analistas de negocios y los patrocinadores del proyecto y se puede o se desea tolerar el cambio, las historias de los usuarios pueden ser el método de requisitos más apropiado que además ayuda a la colaboración.

The Differences: Lean Startup vs Agile Methodology

Can Lean Startup and Agile Methodology work together?

In today’s dynamic business world, we transform our project planning focus from an expanding control change process to an adaptive process that embraces change: a process that responds to business requests whenever they are made, a process that is flexible enough to change even the process itself.

That process entails practicing Lean Startup with the Agile Methodology, in addition to the traditional project management focus on controlling activities. Leanstartup principles measure ongoing results but then challenge those requirements as needed, as part of a build-measure-learn loop. A true picture of success or failure starts to emerge–and a true picture of failure may induce even the most intractable project sponsors to make significant changes before things go off the rails.

The Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative sprints. Below is a diagram showing the various components of the agile method.

Requirement Analysis– This is equivalent to researching and brainstorming what the product requires. Examples can include general features, architecture discussions, workflow discussions and general product discovery.

Design Document & Prototype-This is the SOW (Scope of work), which will have all the requirements defined for the product.

Iterations, Demo & Feedback– During the development, iterations are needed to test the code as well as get feedback from the customer on progress. Feedback from the customer can include: mockups, front-end designs, and usability.

Identify defects & Resolve Bugs– Bugs and defects are always a constant in the software development process. It is important that there are good Quality Assurance standards to eliminate general issues.

Production & Technical Support– The software application is finally deployed and live. Once this occurs, a support plan needs to be in place for maintenance and general support on potential future issues.

Differences Between Lean and Agile

In the traditional uses of Lean and Agile, the main difference is the following:

Lean is used to help build and define a marketable product. Agile is the means to achieve this in software development. Below is a chart depicting the high level differences from a terminology perspective BUT they equate to the same meaning in a different context.

Both methodologies require a Project Manager to work closely with the development team and customer; driving the pace of the project. As a result, the Project Manager plays an integral role in the success of the overall project.

Agile Development in 3 Simple Steps