1. 7 principios del pensamiento Lean
1.1. Eliminate waste
1.1.1. Lean-thinking advocates regard any activity that does not directly add value to the finished product as waste
1.2. build quality in
1.2.1. Our process should not allow defects to occur in the first place, but when this isn't possible, we should work in such a way that we do a bit of work, validate it, fix any issues that we find, and then iterate
1.3. Create knowledge
1.3.1. Planning is useful, but learning is essential
1.4. Defer commitment
1.4.1. It's not necessary to start solution development by defining a complete specification
1.5. Delivery quickly
1.5.1. It is possible to deliver high-quality solutions quickly. By limiting the work of a team to within its capacity, we can establish a reliable and repeatable flow of work
1.6. Respect people
1.6.1. We need a lean approach to governance that focuses on motivating and enabling teams—not on controlling them
1.7. Optimize the whole
1.7.1. If we want to be effective at a solution, we must look at the bigger picture
2. Por qué los equipos deben elegir su WOW?
2.1. Contexto cuenta
2.1.1. People and teams will work differently depending on the context of their situation.
2.2. La selección cuenta
2.2.1. To be effective, a team must be able to choose the practices and strategies to address the situation that they face
2.3. debemos optimizar el flujo
2.3.1. We want to be effective in the way that we work, and ideally to delight our customers/stakeholders in doing so
2.4. queremos ser increíbles
2.4.1. A significant part of being awesome is to enable teams to choose their WoW and to allow them to constantly experiment to identify even better ways they can work
2.5. ¿Qué necesitan para elegir y desarrollar su WOW?
2.5.1. You Need to “Be Agile” and Know How to “Do Agile”
2.5.2. Accept That There's No Easy Answer
2.5.3. We Can Benefit From the Learnings of Others
2.5.4. DA Knowledge Makes You a Far More Valuable Team Member
2.5.5. The Disciplined Agile (DA) Tool Kit Provides Accessible Guidance
3. DA mindset está basado sobre
3.1. 7 principios del DA
3.1.1. 1. Delight Customers (when our products and services not only fulfill their needs and expectations, but surpass them. build with the customer in mind, to work with them closely, and to build in small increments and then seek feedback, so that we better understand what will actually delight them.)
3.1.2. 2. Be Awesome modern agile teams make people awesome, and, of course, it isn't much of a leap that we want awesome teams and awesome organizations, too.
3.1.2.1. 2.1 Be reliable, be honest, be open, be ethical, and treat them with respect. 2.2 Share information 2.3 be an active learner. Go beyond our specialty and learn about the broader software process and business environment. 2.4 Seek to never let the team down. 2.5 Points out that we need to be willing to improve and manage our emotional responses to difficult situations.
3.1.3. 3. Context Counts These observations—that people, teams, and organizations are all unique—lead us to a critical idea that our process and organization structure must be tailored for the situation that we currently face. In other words, context counts. Disciplined Agile recognizes that enterprise complexities require far more guidance, and thus provides a comprehensive reference tool kit for adapting our agile approach for our unique context in a straightforward manner.
3.1.4. 4. Be Pragmatic Gráficos DA provides strategies for maximizing the benefits of agile despite certain necessary compromises being made. As such, DA is pragmatic, not purist in its guidance. DA provides guardrails to help us make better process choices, not strict rules that may not even be applicable given the context that we face.
3.1.5. 5. Choice Is Good Systems are holistic and not understandable just by looking at their components. Instead, we must look at how the components of the system interact with each other. When making improvements to how we work, we must consider the following: •How people interact with each other; •How work being done in one part of the system affects the work in others; •How people learn; and •How people in the system interact with people outside of the system. “context counts” means we must make intelligent choices based on the situation we are in.
3.1.6. 6. Optimize Flow Although each team may be but one part of the value stream, they can see how they might align with others to maximize the realization of value.
3.1.6.1. 6.1 Optimize the whole. DA teams work in an “enterprise-aware” manner. They realize that their team is one of many teams within their organization and, as a result, they should work in such a way as to do what is best for the overall organization and not just what is convenient for them 6.2 Measure what counts. quantify the cost of delay,” “Cost of delay” is the cost to a business in value when a product is delayed. 6.3 Deliver small batches of work continuously at a sustainable pace. By delivering consumable solutions frequently, we can adjust what's really needed and avoid building things that aren't. 6.4 Attend to delays by managing queues. By attending to queues (work waiting to be done), we can identify bottlenecks and remove them using concepts from lean, Theory of Constraints, and Kanban. This eliminates delays in workflow that create extra work. 6.5 Improve continuously. continuous improvement (GCI) strategy 6.6 Prefer long-lived dedicated product teams.
3.1.7. 7. Organize Around Products/Services we build dedicated teams focused on delivering an offering for one or more customers. These teams will be cross-functional in that they include people with sales skills, business analysis skills, management skills, and so on. Organizing around products/services enables us to identify and optimize the flows that count, which are value streams. We will find that a collection of related offerings will define a value stream that we provide to our customers, and this value stream will be implemented by the collection of teams for those offerings. But sometimes these are also internal customers as well, other groups or people whom we are collaborating with so as to enable them to serve their customers more effectively.
3.1.8. 8. Enterprise Awareness When people are enterprise aware, they are motivated to consider the overall needs of their organization, to ensure that what they're doing contributes positively to the goals of the organization and not just to the suboptimal goals of their team.
3.2. 7 promesas
3.2.1. 1. Create Psychological Safety and Embrace Diversity Create Psychological Safety and Embrace Diversity Psychological safety means being able to show and employ oneself without fear of negative consequences of status, career, or self-worth—we should be comfortable being ourselves in our work setting. Diversity is critical to a team's success because it enables greater innovation. The more diverse our team, the better our ideas will be, the better our work will be, and the more we'll learn from each other. There are several strategies that enable us to nurture psychological safety and diversity within a team:
3.2.1.1. 1.1 Be respectful. 1.2 Be humble. 1.3 Be ethical and trustworthy. 1.4 Make it safe to fail. “Make it safe to fail so you can learn fast.”
3.2.1.2. Working on small batches
3.3. 8 pautas (guidelines)
3.4. Diagram
4. Agile Manifesto
4.1. 4 Valores
4.1.1. 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan
4.2. 12 Principios
4.2.1. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4.Business people and developers must work together daily throughout the project. 5.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7.Working software is the primary measure of progress. 8.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9.Continuous attention to technical excellence and good design enhances agility. 10.Simplicity—the art of maximizing the amount of work not done—is essential. 11.The best architectures, requirements, and designs emerge from self-organizing teams. 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
4.3. Manifesto is showing its age in several ways
4.3.1. 1.It is limited to software development. The manifesto purposefully focused on software development, not other aspects of IT and certainly not other aspects of our overall enterprise. 2. The software development world has moved on. with agile-proficient companies delivering functionality many times a day 3.We've learned a lot since then
5. Kit herramientas ofrece
5.1. referencia de proceso contextualizada
5.1.1. Implicaciones interesantes para elegir tu WoW
5.1.1.1. 3 niveles de andamios
5.1.1.1.1. Ciclos de vida (6)
5.1.1.1.2. Metas del proceso
5.1.1.1.3. Prácticas/estrategias
5.1.1.2. 1. Every team will have a different WoW
5.1.1.3. 2. We will evolve our WoW to reflect learnings whenever we work with other teams
5.1.1.4. 3. We can purposefully choose to learn from other teams
5.1.1.5. 4. We can benefit from organizational transformation/improvement efforts
5.2. mejora continua guiada (GCI)
5.2.1. Ciclo de mejoramiento PDSA: plan-do- study-act (W. Edward Deming)
5.2.2. Mejoramiento continuo evolucionó a PDCA: plan-do-check-act
5.2.3. OODA: Observe-Orient-Decide-Act (Coronel John Boyd)
5.2.4. La idea básica con la estrategia de ciclo de mejora continua de PDSA / PDCA / OODA es que usted mejora su WoW como una serie de pequeños cambios (Kaizen para Lean)
5.2.5. El valor de DA es que puede guiarlo a través de este paso de identificación ayudándolo a identificar de manera agnóstica una nueva práctica / estrategia que probablemente abordará el desafío que espera abordar. Al hacerlo, aumenta sus posibilidades de identificar una mejora potencial que funcione para usted, acelerando así sus esfuerzos para mejorar su WoW; a esto lo llamamos mejora continua guiada (GCI).
5.2.6. La eficacia de una mejora potencial se puede medir con "goal question metric" (GQM) o una estrategia de "objectives and key results" (OKRs)
5.3. talleres de adaptación de procesos
5.3.1. require an investment in time, but they're an effective way to ensure that team members are well aligned in how they intend to work together
5.4. retrospectivas mejoradas
5.4.1. technique that teams use to reflect on how effective they are and hopefully to identify potential process improvements
5.5. coaching mejorado
6. El kit de herramientas del DA se organiza en 4 niveles (process blade)
6.1. Foundation
6.1.1. Principles (8)
6.1.1.1. Delight customers
6.1.1.1.1. Customers are delighted when our products and services not only fulfill their needs and expectations, but surpass them
6.1.1.1.2. Jeff Gothelf and Josh Seiden say it best in Sense & Respond: “If you can make a product easier to use, reduce the time it takes a customer to complete a task, or provide the right information at the exact moment, you win”
6.1.1.2. Be awesome
6.1.1.2.1. “Take care of your employees and they'll take care of your business.”
6.1.1.2.2. There are several things that we, as individuals, can do to be awesome. Be reliable, be honest, be open, be ethical, and treat them with respect.
6.1.1.2.3. Awesome teams also choose to build quality in from the very beginning
6.1.1.3. Context counts
6.1.1.3.1. The factors are organized into two categories: factors which have a significant impact on our choice of life cycle, and factors that motivate our choice of practices/strategies. The practice/strategy selection factors are a superset of the life cycle-selection factors.
6.1.1.4. Be pragmatic
6.1.1.4.1. Instead of prescribing “best practices,” DA provides strategies for maximizing the benefits of agile despite certain necessary compromises being made. As such, DA is pragmatic, not purist in its guidance
6.1.1.5. Choice is good
6.1.1.5.1. In order to provide people with choices from which they can choose their way of working (WoW), DA has gathered strategies and put them into context from a wide array of sources
6.1.1.6. Optimize flow
6.1.1.6.1. Optimize the whole
6.1.1.6.2. Measure what counts
6.1.1.6.3. Deliver small batches of work continuously at a sustainable pace
6.1.1.6.4. Attend to delays by managing queues
6.1.1.6.5. Improve continuously
6.1.1.6.6. Prefer long-lived dedicated product teams
6.1.1.7. Organize around products/services
6.1.1.7.1. Organizing around products/services enables us to identify and optimize the flows that count, which are value streams
6.1.1.8. Enterprise awareness (conciencia)
6.1.1.8.1. When people are enterprise aware, they are motivated to consider the overall needs of their organization, to ensure that what they're doing contributes positively to the goals of the organization and not just to the suboptimal goals of their team.
6.1.2. Promises (7)
6.1.2.1. 1. Create psychological safety and embrace diversity.
6.1.2.1.1. Be respectful
6.1.2.1.2. Be humble
6.1.2.1.3. Be ethical and trustworthy
6.1.2.1.4. Make it safe to fail
6.1.2.2. 2. Accelerate value realization.
6.1.2.2.1. Work on small, high-value items
6.1.2.2.2. Reuse existing assets (activos)
6.1.2.2.3. Collaborate with other teams
6.1.2.3. 3. Collaborate proactively.
6.1.2.3.1. Within our team
6.1.2.3.2. With our stakeholders
6.1.2.3.3. Across organizational boundaries
6.1.2.4. 4. Make all work and workflow visible.
6.1.2.5. 5. Improve predictability.
6.1.2.5.1. Pay down technical debt
6.1.2.5.2. Respect work-in-process (WIP) limits
6.1.2.5.3. Adopt a test-first approach (enfoque)
6.1.2.5.4. Reduce feedback cycles
6.1.2.6. 6. Keep workloads within capacity.
6.1.2.6.1. Working on small batches
6.1.2.6.2. Having properly formed teams
6.1.2.6.3. Take a flow perspective
6.1.2.6.4. Use a pull system
6.1.2.7. 7. Improve continuously.
6.1.3. Guidelines (8 pautas)
6.1.3.1. 1. Validate our learnings.
6.1.3.2. 2. Apply design thinking.
6.1.3.3. 3. Attend to relationships through the value stream.
6.1.3.4. 4. Create effective environments that foster joy.
6.1.3.5. 5. Change culture by improving the system.
6.1.3.6. 6. Create semi-autonomous, self-organizing teams.
6.1.3.7. 7. Adopt measures to improve outcomes.
6.1.3.7.1. Start with outcomes.
6.1.3.7.2. Measure what is directly related to delivering value.
6.1.3.7.3. There is no “one way” to measure; teams need fit-for-purpose metrics.
6.1.3.7.4. Every metric has strengths and weaknesses.
6.1.3.7.5. Use metrics to motivate, not to compare.
6.1.3.7.6. We get what we measure.
6.1.3.7.7. Teams use metrics to self-organize.
6.1.3.7.8. Measure outcomes at the team level.
6.1.3.7.9. Each team needs a unique set of metrics.
6.1.3.7.10. Measure to improve; we need to measure our pain so we can see our gain.
6.1.3.7.11. Have common metric categories across teams, not common metrics.
6.1.3.7.12. Trust but verify.
6.1.3.7.13. Don't manage to the metrics.
6.1.3.7.14. Automate wherever possible so as to make the metrics ungameable.
6.1.3.7.15. Prefer trends over scalars.
6.1.3.7.16. Prefer leading over trailing metrics.
6.1.3.7.17. Prefer pull over push.
6.1.3.8. 8. Leverage and enhance organizational assets.
6.1.3.8.1. A lot of good work has occurred before us
6.1.3.8.2. A lot of good work continues around us
6.1.3.8.3. We can reduce overall technical debt
6.1.3.8.4. We can provide greater value quicker.
6.1.3.8.5. We can support others
6.1.4. Agile
6.1.5. Lean
6.1.6. Serial
6.1.7. Roles
6.1.7.1. primary roles
6.1.7.1.1. Team lead
6.1.7.1.2. Product owner (PO)
6.1.7.1.3. Architecture owner (AO)
6.1.7.1.4. Team member
6.1.7.1.5. Stakeholder
6.1.7.2. supporting roles
6.1.7.2.1. Specialist
6.1.7.2.2. Independent tester
6.1.7.2.3. Domain expert
6.1.7.2.4. Technical expert
6.1.7.2.5. Integrator
6.1.7.3. Leadership Roles
6.1.7.3.1. PO
6.1.7.3.2. Architecture Owner
6.1.7.3.3. Team lead
6.1.8. Teams
6.1.9. WOW
6.2. Disciplined DevOps
6.2.1. DAD
6.2.2. Security
6.2.3. DAta management
6.2.4. Release management
6.2.5. support
6.2.6. IT operations
6.3. Value stream
6.3.1. Research &dev
6.3.2. bus operat
6.3.3. strategy
6.3.4. governance
6.3.5. marketing
6.3.6. continuos improvement
6.3.7. ventas
6.3.8. portafolio management
6.3.9. product management
6.3.10. program management
6.4. Disciplined Agile Enterprise (DAE)
6.4.1. enterprice architecture
6.4.2. people management
6.4.3. information technology
6.4.4. asset management
6.4.5. transformation
6.4.6. finance
6.4.7. vendor management
6.4.8. legal