Top Banner
© 2012 Systems Plus Agile Awareness
40
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Agile~overview

© 2012 Systems Plus

Agile Awareness

Page 2: Agile~overview

Agile Evolution

© 2012 Systems Plus

Page 3: Agile~overview

Why agile? Why do we need another approach (PMBOK Guide) for managing projects? How do we solve different situations in our everyday life?

© 2012 Systems Plus

Initial Agricultural Revolution Industrial Revolution Information Revolution Hunter Gatherer Wandering  

Planting Crops Herding Animals Start living in one place

Machines Factories Moving to different cities Led to management (project

Management, WBS) 

Information/Collaboration Focus is not only on manufacturing Value is on ownership of knowledge  

Industrial Worker Knowledge workerWork is visible Work is invisibleWork is stable Work is changingEmphasis on running things Emphasis is on changing thingsMore Structured with fewer decisions Less Structured with more decisionsFocus on right answers Focus on right questionsDefine the task Understand the taskCommand and Control Give AutonomyStrict Standards Continuous innovationsFocus on Quantity Focus on qualityMeasure performance to strict standards Continuously learn and teachMinimize cost of worker for each task Treat worker as asset and not as cost

Agile Evolution

Page 4: Agile~overview

Agile Term came into existence during early 2001 & represents ways of delivering the product/software in fast, collaborative and iterative fashion.

Agile Methodologies are contrary to Traditional methodologies (Waterfall etc.) Agile term represents huge set of methodologies including RAD, Spiral, XP, SCRUM, FDD,

Lean, OpenUP and Kanban. Agile Manifesto Published in Feb 2001 by 17 developers at Snowbird Utah.

© 2012 Systems Plus

Agile Evolution

RUP (Rational Unified

Process)

SCRUM

Crystal Clear

XP (Extreme

Programming)

ASD (Adaptive Software

Development)

FDD (Feature Driven Development)

DSDM (Dynamic Systems

Development Model)

1994

1995

1996

1996 1995

1995 1995

2001

Page 5: Agile~overview

Agile Project Management Framework

© 2012 Systems Plus

Page 6: Agile~overview

© 2012 Systems Plus

Kent Beck (Creator XP and TDD Methodologies)

James Grenning (author of Test-Driven Development for Embedded C.)

Robert C Martin("Uncle Bob", is an American software consultant and author) 

Mike Beedle(founder,CEO of e-Architects Inc., company that specializes in application development using distributed objects and Internet technologies. ) 

Jim Highsmith(Author of books on software development methodologies and creator of Adaptive Software Development)

Steve Mellor(developer of the Shlaer-Mellor method and Executable UML )

Arie Van Bennekum(Involved in DSDM Consortium) 

Andrew Hunt(Published the book The Pragmatic Programmer: From Journeyman to Master.)

Ken Schwaber(Co Creator of Scrum)

Alistair Cockburn(Creator of Crystal Methodologies)

Ron Jeffries(Collaborator and founder of XP)

Jeff Sutherland(Co Creator of Scrum)

Ward Cunningham(Collaborator of XP and creator of Wiki)

Jon Kern(with both Jeff De Luca and Peter Coad and had helped shape the charter on FDD.)

Dave Thomas(Co Author of the book The Pragmatic Programmer: From Journeyman to Master.)

Martin Fowler(as per some people introduced the term Continuous Integration.)

Brian Marick( an early proponent of the Context-Driven school of testing,)

 

Agile Original Contributors

Page 7: Agile~overview

© 2012 Systems Plus

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

The Agile Manifesto

INDIVIDUALS &

INTERACTIONSover process & tools

WORKINGSOFTWAREover comprehensive document

CUSTOMERCOLLABORATIONover contract negotiation

RESPONDING TOCHANGE

over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

Page 8: Agile~overview

Principle Shortened VersionOur highest priority is to satisfy customer through early and continuous delivery of valuable software.

Satisfy customer with great software or Produce value early

Welcome changing requirements, even late in development. Agile process harness change for customer’s competitive advantage

Welcome Change

Deliver working software frequently, from couple of weeks to couple of months, with preference to the shorter timescale.

Deliver Frequently or iterative delivery

Business people and developers must work together daily throughout the project Work with business or Daily business collaboration.

Build projects around motivated individuals. Give them environment and support they need, and trust them to get the job done.

Motivate People or Trust Motivated team

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Face-to-Face communication

Working software is the primary measure of the progress Measure software done or Working software

Agile process promotes sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Maintain sustainable pace

Continuous attention to technical excellence and good design enhances agility. Maintain Design or Technical Excellence

Simplicity- the art of maximizing the amount of work not done- is essential. Keep it simple or K.I.S.S

The best architectures, requirements, and design emerge from self-organizing teams. Team creates architecture or Self Organize

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it behaviour accordingly.

Reflect and Adjust

© 2012 Systems Plus

12 Principles Of Agile

Page 9: Agile~overview

© 2012 Systems Plus

Agile and adaptive approaches for linking people, projects and value. DOI focuses on project management side of agile projects. Agile Manifesto and agile methods offer whole project guidance.

We are a community of project leaders that are highly successful at delivering results. To achieve these results: We increase return on investment by making continuous flow of value our focus. We deliver reliable results by engaging customer in frequent interactions and shared

ownership. We expect uncertainty and manage for it through iterations, anticipations and adoptions. We unleash creativity and innovation by recognizing that individuals are the ultimate source

of value, and creating an environment where they can make difference. We boost performance through group accountability for results and shared responsibility for

team effectiveness. We improve effectiveness and reliability through situational specific strategies, processes and

practices.

DOI: Declaration Of Independence

Page 10: Agile~overview

© 2012 Systems Plus

Agile Methodologies

Page 11: Agile~overview

© 2012 Systems Plus

Agile Methodologies

Page 12: Agile~overview

© 2012 Systems Plus

Scrum is not an acronym. First used to describe hyper-productive development in 1987 by Ikujiro Nonaka and Hirotaka Takeuchi, Scrum refers to the mechanism used in rugby for getting an out-of-play ball back into play.

Scrum generates productivity improvements by implementing a framework that empowers teams and thrives on change. A set of rules and corresponding terminology are used to reinforce such common sense techniques as small teams, daily status meetings, not interrupting people who are working, and a single source of work prioritization.

SCRUM

Page 13: Agile~overview

Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.

© 2012 Systems Plus

SCRUM

Three pillars that hold up every implementation of empirical process control:

Visibility: means that those aspects of the process that affect the outcome must be visible to those controlling the process. Not only must these aspects be visible, but what is visible must also be true.

Inspection: The various aspects of the process must be inspected frequently enough that unacceptable variances in the process can be detected.

Adaptation: If the inspector determines from the inspection that one or more aspects of the process are outside acceptable limits and that the resulting product will be unacceptable, the inspector must adjust the process or the material being processed

Although the above pillars guides all aspects of Scrum Projects, there are also four planned opportunities for Inspection and Adaption within Scrum framework:

Sprint RetrospectiveDaily Scrum MeetingSprint Review MeetingSprint Planning Meeting

Page 14: Agile~overview

© 2012 Systems Plus

SCRUM Cont.

The heart of Scrum lies in the iteration (Sprint). The team takes a look at the requirements, considers the available technology, and evaluates its own skills and capabilities. It then collectively determines how to build the functionality, modifying its approach daily as it encounters new complexities, difficulties, and surprises. The team figures out what needs to be done and selects the best way to do it. This creative process is the heart of the Scrum’s productivity

Dimensions of Software Development Complexity

P3opl3

R3quir3m3nts

T3chnology

Page 15: Agile~overview

SCRUM Roles:

© 2012 Systems Plus

The Product Owner The Team The Scrum Master

Represents everyone with stake in project and the final product

Self Managing, self organizing and cross functional

He is responsible for Scrum Processes

Achieves initial and on going funding Responsible for figuring out how to turn Product Backlog into an increment of functionality within an iteration

Teaches Scrum to everyone from implementation to Delivery

Creates overall requirements(Product Backlog), ROI objectives and Release plan

Responsible for developing functionality Making sure process fits into organization culture and delivers expected benefits

Responsible for prioritizing product backlog

Collectively responsible for each iteration and whole product

Removes impediments to progress, assists product owner with managing backlog, communicating vision, goal and backlog items to team.

SCRUM Cont.

Page 16: Agile~overview

© 2012 Systems Plus

SCRUM Flow

Page 17: Agile~overview

Sprints: A time boxed iteration (2-8 weeks) build a potentially shippable product. includes a sprint planning meeting, Daily Scrums,

Development work, Sprint Review Meeting, Sprint Retrospective.

During sprint no changes are made that effect sprint goal.

Scope may be clarified or renegotiated as new information becomes clear.

Development team cannot change

© 2012 Systems Plus

SCRUM Activities

Sprint Planning Meeting: Is used to define what will define a sprint and how it will be achieved. time boxed for 8 hrs.( 4 hrs. explain, 4 hrs. plan) Product owner explains team product backlog , ordered by priority Team asks questions to clarify user stories so that they can break it into tasks. PO, SM and team is involved. Outcome is Sprint Backlog

Page 18: Agile~overview

Daily Scrum: Is 15 minutes time boxed daily meeting. Meeting happens at same place and same time. Each member provides answer to three questions:

What has been achieved since last meeting? What will be done before next meeting? What obstacles are in way?

Daily scrum for pigs (chickens welcome to listen) Discussion parked until after scrum

© 2012 Systems Plus

SCRUM Activities Cont.

Sprint Review Meeting: Is held at the end of the sprint & last about 1hr per wk of

sprint Scrum team demonstrates what is accomplished during

sprint. Very informal ; no PowerPoint slides, lectures, diagrams. Participant includes PO, SM, Scrum Team, management,

customer Project is assessed against the sprint goals defined in

sprint planning meeting Ideally team completes each product backlog item brought

into sprint backlog

Page 19: Agile~overview

© 2012 Systems Plus

SCRUM Activities Cont.

Sprint Retrospective Meeting: Is usually the last thing of the sprint. time boxed for 3-4 hrs. Attended by SM and Scrum team and occasionally PO different formats go for lunchOutside park CEO to attend

Page 20: Agile~overview

Product Backlog: Prioritized features list, containing short descriptions of all functionality desired in the

product. Typically contains features, Bugs, Technical work & Knowledge acquisition. It is

Visible to all Single source and copy of truth Dynamic

It helps guide roadmap planning.

© 2012 Systems Plus

SCRUM Artifacts

Page 21: Agile~overview

© 2012 Systems Plus

SCRUM Artifacts

Sprint Backlog: Task identified by Scrum Team during Sprint

Planning User Stories in Product Backlog are broken into

Tasks. Team estimates how many hours each task will

take.

Burn Down Chart: is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. Variation of Sprint burn down is Release burn down chart.

Page 22: Agile~overview

© 2012 Systems Plus

The main goal of XP is to lower the cost of change in software requirements. With traditional system development methodologies, like the Waterfall Methodology, the requirements for the system are determined and often "frozen" at the beginning of the development project. This means that the cost of changing the requirements at a later stage in the project — something that is very common in the real-world — can be very high.

Extreme Programming (or XP) is software development centric agile methodologies. While scrum focuses on project management level with focus on prioritizing work and getting feedback, XP focuses on software development good practices.

Extreme Programming (XP) Flow

Page 23: Agile~overview

Extreme Programming (or XP) is software development centric agile methodologies. While scrum focuses on project management level with focus on prioritizing work and getting feedback, XP focuses on software development good practices.

Core values of XP methodologies are:Simplicity: focuses on reducing complexity, extra features and waste. “Find the

simplest thing that could work” is the phrase team should keep in mind.Communication: focuses on making sure each member knows what is expected out of

them and what other members are working on. Daily Stand Up meeting is key component of communication

Feedback: team should get impression of suitability early. Failing fast can be useful.Courage: It takes courage to allow our work to be entirely visible to others. In Pair

programming, team members share codes, often makes bold simplifications and changes the code. Automated build and tests makes sure developers have confidence to make important changes.

Respect: is essential on XP projects where team work together as a team and everyone is accountable for success or failure.

© 2012 Systems Plus

Extreme Programming (XP)

Page 24: Agile~overview

© 2012 Systems Plus

Extreme Programming (XP) Flow

Page 25: Agile~overview

© 2012 Systems Plus

XP Practices

XP Is Based on several simple but powerful core practices.

Page 26: Agile~overview

XP expects participation from Whole Team, Whole team refers to all contributors to XP sitting in same physical location as members of same team including Customers.

XP emphasis on the notion of generalising specialist as opposed to role specialist.

© 2012 Systems Plus

Onsite Customers Product Manager /Owners Domain Experts

Technical Specialists Interaction Designers Programmers

Designer and Architects Testers Coaches- The programmer coach

Project Manager Project Community, stakeholder and executive sponsor

 

XP Roles

Page 27: Agile~overview

Planning Games: XP has two primary planning activities or planning games – Release Planning and Iteration Planning. Release Planning is push for new functionality all the way to production. A Project typically

has one or more releases with no more than two releases happening in a year. During release planning customer outlines the functionality required and developers estimates how difficult it is to estimate. Based on estimates and priorities customer defines a project plan. Initial estimates will be bit imprecise, so process is revisited frequently and improved as estimates and priorities evolves.

Iterations are small development cycles within a release( as Scrum calls it “Sprint”) ideally of two weeks. Iteration planning is done at the start of iteration. Customer describes the functionality required in next two weeks and then developer breaks the functionality into tasks and estimates the work. Based on these estimates and amount of work achieved in prior iteration, team commits the amount of work they can do in next iteration.

© 2012 Systems Plus

XP Planning

Page 28: Agile~overview

© 2012 Systems Plus

XP Test Driven Development Cycle

• RedWrite a little test that doesn‘t work (and perhaps doesn‘t even compile at first)• GreenMake the test work quickly (committing whatever sins necessary)• RefactorEliminate all of the duplication created in merely getting the test to work, improve the design

Page 29: Agile~overview

© 2012 Systems Plus

Lean Software Development

Page 30: Agile~overview

© 2012 Systems Plus

Lean Software Development

Eliminate Waste: To maximize value we must eliminate waste. In software systems, waste can be in form of partially done work, unnecessary features etc. Therefore to increase value we must develop ways to identify and then remove waste.Empower Team: Rather than taking micromanagement approach we should respect team’s superior knowledge of the technical steps required for project and let them make decision to be productive and successful.’Deliver Fast: Maximize ROI by quickly delivering valuable software. Optimize the whole: Aim to see the system as more than the sum of its parts. We go beyond the pieces of project and look how it aligns with organization. As part of optimizing the whole we also focus on forming better intergroup relations.Build Quality In: Lean development does not try to “test-in” quality at the end. It builds quality into the product and continually assures quality throughout the development process using techniques like refactoring, continuous integrations, and unit testing.Defer Decisions: Balance early planning with making decisions and committing to things as late as possible. Amplify Learning: Concept involves facilitating communication early and often getting feedback as soon as possible and building on what we learn.Lean gives us techniques and concepts such as Value stream Mapping, seven forms of waste, WIP etc.

Page 31: Agile~overview

© 2012 Systems Plus

Lean software development is a translation of lean manufacturing and lean IT principles and practices to the software development domain. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community. Lean software development practices, or what is commonly called "tools" are expressed slight differently from their equivalents in agile software development, but there are parallels. Examples of such practices include:

Eliminate Waste Provide market and technical leadership - Your company can be successful by producing

innovative and technologically advanced products but you must understand what your customers value and you know what technology you are using can deliver

Create nothing but value - You have to be careful with all the processes you follow, i.e., be sure that all of them are required and they are focused on creating value

Write less code - The more code you have the more tests you need thus it requires more work and if you're writing tests for features that are not needed you are simply wasting time

Lean Software Development

Page 32: Agile~overview

© 2012 Systems Plus

Create Knowledge Create design-build teams - Leader of the development team has to listen to his/her

members and ask smart questions encouraging them to look for the answers and to get back with encountered problems or invented solutions as soon as possible

Maintain a culture of constant improvement - Create environment in which people will be constantly improving what they are working on - they should know that they are not and should not be perfect - they always have a field to improve and they should do it

Teach problem-solving methods - Development team should behave like small research institute, they should establish hypotheses and conduct many rapid experiments in order to verify them

Build Quality In Synchronize - In order to achieve high quality in your software you should start worrying

about it before you write single line of working code - don't wait with synchronization because it will hurt

Automate - Automate testing, building, installations, anything that is routine, but do it smartly, do it in a way people can improve the process and change anything they want without worrying that after the change is done the software will stop working

Refactor - Eliminate code duplication to ZERO - every time it shows up refactor the code, the tests, and the documentation to minimize the complexity.

Lean Software Development

Page 33: Agile~overview

© 2012 Systems Plus

Defer Commitment Schedule irreversible decisions at the last responsible moment - You should know where you

want to go but you don't know the road very well, you will be discovering it day after day - the most important thing is to keep the right direction

Break dependencies - Components should be coupled as loosely as possible to enable implementation in any order

Maintain options - Develop multiple solutions for all critical decisions and see which one works best

Optimize the Whole Focus on the entire value stream - Focus on winning the whole race which is the software -

don't optimize local inefficiencies, see the whole and optimize the whole organization Deliver a complete product - Teams need to have great leaders as well as great engineers,

sales, marketing specialists, secretaries, etc. - they together can deliver great final products to their customers

Lean Software Development

Page 34: Agile~overview

© 2012 Systems Plus

Deliver Fast Work in small batches - Reduce projects size, shorten release cycles, stabilize work

environment (listen to what your velocity tells you), repeat what's good and eradicate practices that creates obstacles

Limit work to capacity - Limit tasks queue to minimum (one or two iterations ahead is enough), don't be afraid of removing items from the queue - reject any work until you have an empty slot in your queue

Focus on cycle time, not utilization - Put in your queue small tasks that cannot clog the process for a long time - reduce cycle time and have fewer things to process in your queue

Respect PeopleTrain team leaders/supervisors - Give team leaders the training, the guidance and

some free space to implement lean thinking in their environmentMove responsibility and decision making to the lowest possible level - Let your

people think and decide on their own - they know better how to implement difficultalgorithms and apply state-of-the-art software frameworksFoster pride in workmanship - Encourage passionate involvement of your team

members to what and how they do

Lean Software Development

Page 35: Agile~overview

Task Kanban Board named after Just-In-Time production method in Toyota Production System (TPS).

A Kanban is a ticket describing a task to do. In TPS, it is used to realize Just-In-Time "pull" production control. In Figure 1, the Kanban Board shows the current status of all the tasks to be done within this iteration. The tasks are represented by cards (Post-It Notes). Status is presented by areas on the board separated and named To Do, Doing, and Done. This Kanban Board helps team understand how they are doing, as well as what to do next. This helps make the team self-directing.

© 2012 Systems Plus

KANBAN TPS Board

Page 36: Agile~overview

Limiting the amount of work that is in progress will contribute to faster completion, better quality, and greater focus on only the highest-priority work. A WIP limit is a policy, an agreed-upon decision about how the work will be processed. Policies can similarly specify how the organization handles types of work items.

A WIP limit defines a stage in the Kanban system. A stage in the Kanban system may span across several workflow states. A limit on WIP constrains how many work items can be in each stage of the workflow at a given time. When a work item is pulled to the next stage of the process, a slot opens and a new work item can be pulled into that stage. A number of workflow states may be grouped together under a single WIP limit.

A significant consequence of a WIP limit is that blocked work “holds up the line.” A blocked work item still counts against the limit, so a situation may arise as more items become blocked, in which no new work can progress until the block is resolved. This drives collaboration, as the team (and any affected external stakeholders) are highly motivated to clear the blockage.

© 2012 Systems Plus

KANBAN TPS Board

Page 37: Agile~overview

© 2012 Systems Plus

KANBAN TPS Board

Three Principles of Kanban

1. Start with what you know2. Agree to pursue incremental, evolutionary change3. Initially, respect current roles, responsibilities and job titles

Kanban five core practices

4. Visualize5. Limiting work in progress6. Manage flow7. Make management policies8. Improve collaboratively using “safe to fail” experiments

Page 38: Agile~overview

In Agile project management, planning is an iterative component of theproject lifecycle.

In the above figure, see the repeated sets of green shading as planning occurs throughout the project lifecycle.

Agile Project Management Framework

Page 39: Agile~overview

K & S – Level 1

Page 40: Agile~overview

ENVISIONDetermine the product vision and project scope, the projectcommunity, and how the team will work together

SPECULATEDevelop a feature-based release, milestone, and iteration plan to deliver on the vision

EXPLOREDeliver tested features in a short timeframe, constantly seeking to reduce the risk and uncertainty of the project

ADAPTReview the delivered results, the current situation, and the team'sperformance, and adapt as necessary

CLOSEConclude the project, pass along key learnings, and celebrate