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.