23
Second Genration Agile Frameworks

Agile frameworks

Embed Size (px)

Citation preview

Page 1: Agile frameworks

Second Genration Agile Frameworks

Page 2: Agile frameworks

HELLO! I am Abhinav Sabharwal You can find me at [email protected]

Page 3: Agile frameworks

“Scrum is like your mother in law it

points to all your faults”

Page 4: Agile frameworks

Need For New Frameworks ✘While agile is great for small projects things get complicated when project get large

✘As more and more companies are adopting agile new ways are needed to implement agile in more and more diverse environments

✘In today's globalised world teams are not only complex but stakeholders may be scattered across the globe

Page 5: Agile frameworks

Challenges in Agile ✘Challenge #1: Velocity – whether real or only perceived, the velocity challenge indicates that “the business” does not believe that they are getting adequate throughput / value from the technology team ✘Challenge #2: Reliability & Consistency – this challenge is typically shown through Agile teams that consistently over-commit and miss their Sprint goals and deliverables ✘Challenge #3: Vision & Priority – an Agile team that lacks proper business or technical vision and priority is constantly changing directions for each Sprint, or worse yet within a single Sprint

Page 6: Agile frameworks

Challenges in Agile ✘Challenge #4: Quality – teams that have a quality challenge “finish” their sprints and deliverables, but accumulate a significant amount of technical debt in the form of defects and poor design choices

✘Challenge #5: Coordination – a coordination challenge is present when individual teams are reasonably high-performing, but there are miscommunications and inefficiencies between Scrum teams (e.g., missed dependencies, tremendous overhead, integration issues, environment issues, etc.)

✘Challenge #6: Bandwidth – all teams are resource constrained in some form, but a team with only this challenge is otherwise in great shape

Page 7: Agile frameworks

Large-Scale Scrum

Page 8: Agile frameworks

LeSS ✘Large-scale Scrum (LeSS) was created by Craig Larman and Bas Vodde in 2005 to help organizations implement Scrum in their development.

✘ It includes two frameworks, the first of which applies to smaller companies (up to 10 Scrum teams, with 7 members each), while Framework-2 works for up to a few thousand people on one product. ✘LeSS can be thought of as regular Scrum applied in multiple levels to suit large-scale development: it is a minimal framework that offers a high degree of flexibility at implementation.

Page 9: Agile frameworks

LeSS

Page 10: Agile frameworks

LeSS ✘ It is non-prescriptive, and merely gives suggestions. LeSS builds on “basic” Scrum in that it recommends organizing several feature teams under one Product Owner (PO).

✘LeSS is a great choice for small organizations that are growing quickly, and are looking for a framework that helps scale Scrum along with their organization. It allows flexibility over rules, which is both its advantage and its major risk factor: large enterprises may shy away from it in favor of a more structured framework.

Page 11: Agile frameworks

Disciplined Agile Delivery

Page 12: Agile frameworks

D.A.D -Goals Inception Phase Construction Phase Transition Phase

•Form Initial Team

•Develop Common Project Vision

•Align with Enterprise Direction

•Explore Initial Scope

•Identify Initial Technical Strategy

•Develop Initial Release Plan

•Form Work Environment

•Secure Funding

•Identify Risks

•Produce Potentially Consumable Solution

•Address Changing Stakeholder Needs

•Move Closer to Deployable Release

•Improve Quality

•Prove Architecture Early

•Ensure Solution Is Consumable

•Deploy Solution

Ongoing Goals

•Fulfill Project Mission

•Grow Team Members

•Address Risk

•Improve Team Process and Environment

•Leverage/Enhance Existing Infrastructure

Page 13: Agile frameworks

D.A.D- Key Aspects ✘People-first: The disciplined agile delivery framework identifies that "People, and the way they interact with each other, are the primary determinant of success for a solution delivery project."[10] . ✘Learning-oriented: The DAD process framework promotes the ideas that team members should collaborate closely and learn from each other

✘Full delivery lifecycle: Unlike first generation agile methods that typically focus on the construction aspects of the lifecycle, the DAD lifecycle addresses the entire project from the point of initiation all the way to production and post-delivery production activities.

Page 14: Agile frameworks

D.A.D- Key Aspects ✘Process goal driven The DAD framework approach is goal-driven rather than prescriptive. Compared to Scrum, which prescribes that all work is managed via a product backlog queue, DAD suggests choosing a work-prioritization strategy based on whatever factors are most important to project stakeholders. ✘Solution focused Disciplined Agile Development matures focus from simply producing software to providing consumable solutions that provide real business value to stakeholders. While software is clearly an important part of the deliverable, being solution focused means taking a holistic view of the overall problem. This can lead to suggested updates in hardware, business/organizational processes, and overall organizational structures.

Page 15: Agile frameworks

D.A.D- Key Aspects ✘Risk-value lifecycle The DAD lifecycle is risk and value driven. It extends Scrum's value-driven lifecycle, which produces potentially shippable software each sprint/iteration, so that it explicitly includes light-weight milestones

✘Enterprise aware Enterprise awareness is a crucial philosophy of the DAD framework. DAD teams work within an organization's enterprise ecosystem just like any other team. An important aspect of enterprise awareness is that DAD has explicit DevOps practices and strategies built right into the framework.

Page 16: Agile frameworks

Scaled Agile Framework

Page 17: Agile frameworks

SAFe Porfolio Level

✘The portfolio management level of SAFe provides aim for the entire system.

✘ This is where the organization’s strategic themes are given life, value and priority as part of the development process.

✘The majority of organizations that can benefit from implementing SAFe either currently have a Portfolio Management Office (PMO), or have a need to generate a group that performs this work.

Page 18: Agile frameworks

SAFe Porfolio Level ✘Portfolio management requires strategy, investment funding, program management and governance.

✘Investment themes drive budget allocations.

✘Themes are done as part of the budgeting process with a lifespan of 6-12 months.

✘Portfolio philosophy is centralized strategy with local execution.

Page 19: Agile frameworks

SAFe Program Level ✘At the Program level, SAFe focuses on the principle of alignment as the efforts of a number of agile teams are integrated to create customer value.

✘Teams are what power the agile release trains. ✘Centralized system for coordinating multiple teams, while giving each individual team

✘Dedicated, streamlined environment to collaborate and deliver working software with ease

Page 20: Agile frameworks

SAFe Program Level ✘SAFe defines an Agile Release Train (ART). As iteration is to team, train is to program.

✘The ART (or train) is the primary vehicle for value delivery at the program level. It delivers a value stream for the organization

✘Between 5 and 10 teams work together on a train. They synchronize their release and iteration boundaries.

✘Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI). A demo and inspect and adapt sessions are held. Planning begins for the next PSI.

Page 21: Agile frameworks

SAFe Team Level ✘At the Team level, SAFe uses the Scrum framework inheriting its Roles, Ceremonies and Artifacts.

✘Once Release Planning has happened at the Program level, a team then plans every Sprint during Sprint Planning at a micro level; as typically prescribed by Scrum.

✘Team requirements are stored in a Team Backlog, which is a subset of the Program Backlog and is managed by the team’s Product Owner.

✘ Team’s Sprint lengths are fixed based on the ART's (Agile Release Train) cadence.

Page 22: Agile frameworks

SAFe Team Level ✘Teams are cross-functional and typically comprised of a Product Owner, Scrum Master, Developers, Testers and any specialized role required (User Experience, Business Analysts, etc...). T

✘Teams have the ability to independently self-organize and complete a requirement from beginning to end

✘A team in SAFe might be 8 to ten people, with everything they need to deliver software, end-to-end

Page 23: Agile frameworks

THANKS! Any questions? You can find me at [email protected]