Introduction to Agile

Premise:

Waterfall is DEAD as a SDLC!

But... Can you release too early? Marvin Heery, Social Usability

MPH Consulting Credit to: Pradyumn Sharma of Pragati Software Pvt. Ltd. and

Kyle R. Larson of Advanced Technologies Integration, Inc

Refresh Savannah July 20, 2010

Waterfall review

• Old school • Proven not responsive to todays deadline-driven

application development needs • Rapid development – RAD attempts

– We’ve seen Band-Aids before: • 4GL • Interpreters • Other approaches

• WHY AGILE NOW? – When did Agile thoughts begin? – Been around a while – proven – how many of you use it

now?

The typical sequence for the conventional waterfall management style

1. Early success via paper designs and overly precise

artifacts,

2. Commitment to executable code late in the life cycle,

3. Integration nightmares due to unforeseen

implementation issues and interface ambiguities,

4. Heavy budget and schedule pressure to get the system

working,

5. Late shoe-horning of suboptimal fixes, with no time for

redesign, and

6. A very fragile, expensive-to-maintain product, delivered late.

From: Improving Software Economics Whitepaper (May 2009) Source: IBM Rational Software

Presenters experience

• Degree in CSC – way back – see the gray? • Worked in utility company – COBOL – online CICS • Supported developers – as systems programmer • Went into vendor world for career change • Evolved to application development tools focus

– RDBMS world – 4GLs

• Taught Conceptual Data Modeling with Data Dictionary technologies

• Even evangelized the early OODBMS technologies, including development approaches & supported early adopter level systems

This presentation

• Cobbled together – from others – credits on title slide – originals available if interested

• Not all you want to know

• Hopefully enough to make you want to know more

• Raises some thoughts for implementing UX practices & getting value from Usability Testing – couple slides on parallel tracks!

Bar Camp Phnom Penh Agile Project Management - Scrum 9

Who are you?

• Who here writes code either as part of their job or in their spare time?

• Who writes code with other developers?

• Who follows a software development process when coding?

• Who works with designers for the UX process?

When did I first see Agile?

• Agile development started out in 1994 • 2001 / 2002 timeframe my first exposure • After an internet startup experience • Looking for alternative approaches to develop new

applications I was interested in at the time • Attended Agile (XP) User Group sessions in Atlanta • ISSI – Internet Security Systems (sold to IBM)

– Supported XP User Group – Had embraced Agile tools & methodologies to built their new

products

• Now Agile is being adapted to address organizational change

So, What is Agile?

• Agile Manifesto

• Principles – easy ones to understand

– See List below…

• Implementations in several approaches

– XP, SCRUM… see slide with various flavors…

• Project Management not DEAD but different!

– SCRUM

The values of the Agile Manifesto are supported by a collection of 12 principles 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.

From: Adapting Agile Methods for Complex Environments Source: IBM Rational ( December 2009)

Bar Camp Phnom Penh Agile Project Management - Scrum 13

Manifesto for Agile SD

• Based on the Manifesto for Agile Software Development

– Individuals and interactions over processes and tools – Working software over comprehensive documentation

– Customer collaboration over contract negotiation

– Responding to change over following a plan

Bar Camp Phnom Penh Agile Project Management - Scrum 14

Three styles of software development

Agile – Work is implemented in stages

(iterations), and only enough planning is carried out to complete the next iteration

The Waterfall - Heavy up front

planning, following a traditional engineering approach

Method C – Very little or even none

organized planning

Comparing Waterfall & Agile

Waterfall in Practice

Agile Methods

– Extreme Programming (XP) (Kent Beck, Ward Cunningham, Ron Jeffries)

– Scrum (Jeff Sutherland, Mike Beedle, Ken Schwaber)

– DSDM – Dynamic Systems Development Method (Community owned)

– Crystal (Alistair Cockburn)

– ASD – Adaptive Software Development (Jim Highsmith)

– XBreed (Mike Beedle)

All Agile Methods

• Maximize value by minimizing anything that does not directly contribute to product development and delivery of customer value

• Respond to change by inspecting and adapting

• Stress evolutionary, incremental development

• Build on success, not hope

Agile Software Development Methodologies

• Useful compromise between no process and too much process.

• Suitable for responding to changing customer requirements.

• Adaptive rather than being predictive.

• Work well even for predictable requirements.

• People-oriented as against being process-oriented.

Introduction to XP

• Pioneered by Kent Beck, along with Ward

Cunningham and Ron Jeffries.

• A set of useful guidelines or best practices

for handling software development

projects.

• Strong emphasis on small iterations,

simple design, and testdriven development.

Five Core Values of XP

• Communication

• Simplicity

• Feedback

• Courage

• Respect

Motherhood & Apple Pie?

Overview of XP: Practices

• Primary practices (13) – User stories

– Weekly cycle (iteration planning)

– Test-first programming

– Incremental design

– Continuous integration

– Ten minute build

– Pair programming

– Energized work

– Quarterly cycle

– Sit together

– Whole team

– Informative workplace

– Slack

• Secondary practices (11) – Customer involvement

– Shared code

– Root-cause analysis

– Code and tests

– Single code base

– Incremental deployment

– Team continuity

– Shrinking teams

– Daily deployment

– Negotiated scope contract

– Pay-per-use

Stories

• Story = customer-visible functionality provided by a system.

• Build a list of stories based on discussions with customers. – Just note down the names initially.

• Role of stories: – Estimation

– Scope definition for a release cycle

– Units of planning and monitoring a system

– Prioritization by customers.

– Risk assessment and estimation by developers

• Concept of epics involving grouping stories

Pair Programming

• Two programmers working together for some programming task.

• Benefits: – Knowledge sharing

– Better quality

– Coding standards

– On-going code reviews

– Ease of inducting new team members (mentoring)

– Mutual learning

– Improved productivity

Incremental Design

• Avoid “complete design before implementation”. • According to a Standish Group report:

– 7% of features and functions are always used, 12% are often used,

– 16% are sometimes used, 19% are rarely used, 45% are never used.

• Design what is needed now. Keep investing in the design every day.

• Create spike solutions to tackle tough technical or design problems.

• Design done close to when it is needed is more efficient. • Refactor your design as you go ahead.

Real Customer Involvement

• Customer writes user stories, acceptance tests, and answers queries of developers.

• Negotiates a set of stories to be included in each scheduled release.

• Benefits: – Priorities can be set / adjusted in real-time – No need to have water-tight requirements – Customer is available to help make course corrections as clarity

emerges gradually about the requirements, effort estimates and consequences

– Customer participates in discussions and planning meetings; has greater understanding of technical issues and status of the progress

Quarterly Cycle

• At the macro level, plan work a quarter at a time.

– Identify bottlenecks

– Identify and initiate corrective steps

– Focus on the big picture, where the project fits within the organization.

• Take stock of the project, the team, and its progress.

Other Practices

• Sit Together: – Develop in an open space big enough for the whole

team.

• Whole Team: – Create a cross-functional team, with all the skills and

perspectives needed for the project to succeed.

• Informative Workspace: – Display information about the project status all over in

the workspace. – Place user story cards or big charts for issues that

require steady progress.

Other Practices (cont’d)

• Incremental Deployment: – When taking over a legacy system, gradually take over its

workload beginning very early in the project. No “cut over” during a weekend.

• Team Continuity: – Keep effective teams together. At the end of a project, don’t

send the programmers to the “pool”.

• Shrinking Teams: (Mythical Man-month?) – As the team grows in capability, keep its workload constant but

gradually reduce its size. Free people to form more teams. – If a team is too small, merge it with another very small team.

• Daily Deployment: – Put new software into production every night.

Who plays role of Customers?

• This is where UX practices can be integrated effectively with the Agile Development track

• Create parallel track for UX • Integrate Usability Testing early & often • Use paper prototypes first • Refine level of Usability Testing as cycles & iterative

process generate more robust set of features • UX Practitioner becomes Customer – use internal

company resources as Test Participants at various levels of Testing

• Develop external Design Partners for Test Participants

Proposed Parallel Track Approach

UX Track details

• And as far as integrating design - design is a dependency for development.

• We almost never start a sprint with outstanding design tasks that need to be developed in the same sprint - it almost never works.

• Design should be 1 sprint ahead of development, and the user stories need to be split up that way (any user story that requires design basically becomes an "epic" so it can be split up over multiple sprints).

Introduction to SCRUM

• Another prominent agile methodology.

• Co-developed by Jeff Sutherland and Ken Schwaber in the early 1990s.

• While XP practices are more programmer-centric, Scrum practices are geared towards the project managers.

• XP and Scrum complement each other very well.

Chickens and Pigs

A chicken and a pig are together when the chicken says, "Let’s

start a restaurant!. The pig thinks it over and says,

"What would we call this restaurant?”

The chicken says, "Ham n’ Eggs!" The pig says, "No thanks. I’d be committed, but you’d only be

involved!"

Here’s a Happy Scrum Master (aka Pig)!

Bar Camp Phnom Penh Agile Project Management - Scrum 44

What is Scrum?

Definition from rugby football:

a scrum is a way to restart

the game after an

interruption, where the

forwards of each side come

together in a tight formation

and struggle to gain

possession of the ball when it

is tossed in among them

Scrum

• Term in rugby to get an out-of-play ball back into play

• Term used in Japan in 1987 to describe hyper-productive development

• Used by Ken Schwaber and Mike Beedle to describe their Agile methodology

So how do they play it?

http://www.flickr.com/photos/euan_forrester/2322625115/

Overview of SCRUM

• The core of Scrum is an iterative, incremental process skeleton.

• At the start of each iteration, the team selects what it can implement by the end of the iteration, by looking at the requirements, technology available, its skills and capabilities.

• The team is then left alone to implement the chosen functionality.

Bar Camp Phnom Penh Agile Project Management - Scrum 49

Functionality of Scrum

SCRUM Process

Bar Camp Phnom Penh Agile Project Management - Scrum 51

The Scrum Team

• Typically 5-10 people

• Cross-functional (Programmers, UI Designers, Database experts etc.)‏

• Members should be full-time

• Team is self-organizing

• Membership can change only between sprints

SCRUM Flow

• Project Vision

• Product Backlog

• Sprint

– Sprint planning meeting

– Daily Scrum meeting

– Sprint review meeting

– Sprint restrospective meeting

Sprint Planning Meeting

• At the start of a Sprint, there is a Sprint planning meeting. In this meeting, Product Owner and Team get together to collaborate about what will be done for the next Sprint.

• Product Owner tells the team what is desired. The Team tells the Product Owner how much it believes it can turn into functionality over the next Sprint.

• Time-boxed to a maximum of eight hours. Divided into two parts. The first part is for selecting Product Backlog, the second part is for preparing a Sprint Backlog.

More on stories – SCRUM/Sprint

• Any user story that can't be accomplished by 1 person during 1 sprint is too large and should be turned into an epic with lots of user stories...

• because...

• a user story = 1 discreet feature implementable by 1 developer during 1 sprint.

• Otherwise, you're back to waterfall.

Sprint

• All work is done in Sprints. • An iteration of 30 consecutive calendar days. • The Team can seek outside help, information, support. • No one can provide advice, instructions, etc. to the

Team during the Sprint. The Team is self-managing. • The Team is committed to the Product Backlog selected

during the Spring Planning meeting. The Product Backlog is frozen, and no one is allowed to change this Product Backlog during the Sprint.

• If the Sprint proves to be unviable, the ScrumMaster can terminate the Sprint and initiate a new Sprint planning meeting.

Bar Camp Phnom Penh Agile Project Management - Scrum 56

Daily Scrum (Standup Meeting)

• Is a short (15 minutes long) meeting, which is held every day before the Team starts working

• Participants: Scrum Master (which is the chairman), Scrum Team

• Every Team member should answer on 3 questions

Bar Camp Phnom Penh Agile Project Management - Scrum 57

Questions

• What did you do since the last Scrum?

• What are you doing until the next Scrum?

• What is stopping you getting on with the work?

SCRUM Masters version

1. What did you do yesterday?

2. What are you going to do today?

3. Are you stuck or waiting on a

dependency?

a) If so, who do you need to help you fix it?

Thanks to our resident SCRUM Master, Kevin L.

Sprint Retrospective Meeting • Conducted by the ScrumMaster. Attended only by the

Team, the ScrumMaster, and the Product Owner

(optional).

• Timeboxed to three hours.

• Team is encouraged to revise its development process to

make it more effective and enjoyable for the next Sprint

• ScrumMaster starts by asking all the Team members: – what went well during the last Sprint?

– what could be improved in the next Sprint?

• Role of ScrumMaster is not to provide answers, but to

facilitate the Team's search for better ways for the Scrum

process to work for it.

• Actionable items to be added to the next Sprint are

devised as high-priority nonfunctional Product Backlog.

Lots more adaptations, considerations

• Marriage of UX (design) principles into Agile processes • YES, designers & developers DO work together • False to say that they don’t in a development team • Key is forming the TEAM – designers being a part of the

TEAM is possible – need to be responsive to the Agile mentality though

• Challenge in outsourced project teams – developers need to get with a set of designers – or converse if designers are driving project they need to “recruit” a set of developers who can participate over life of project & not do an over the fence approach to design & coding

Getting to Agile, using Scrum…

• Research – reading

• Look at successful implementations around you

• Training

• Consulting

• Coaches

• Use the Lawver method – AOL got there, can YOU? – Sneak it in one teams development approach for one project

– Let other teams see your success

– Management will notice

• Make it YOURS

Is this where you want to be?

Questions, Discussion

• What did you learn new tonight?

• What will you do with what you learned?

• Can Agile processes help your teams, company?

• If you did Agile tomorrow how would you start?

• Embracing Agile, building the Team

• Do you see better PM techniques with SCRUM than you do today?

Can you release too early?

• Seth Godin – do you know him?

• The world we live in, as Seth sees it…

– “In the new economy of launch and learn and revise…”

• Can we release too early? Too often?

• So…

– Can Usability Testing early & often with REAL users, watching them get lost in your new features help?

– Will that make you more comfortable that your launch or revision release is going to keep them from getting lost?

– Learn from Usability Testing before you learn from lost users – you might not even know they get lost without watching them!

Thanks!

Marvin Heery MPH Consulting / Social Usability

http://socialusabilty.wordpress.com @socialusability, Facebook.com/SocialUsability

socialusability@gmail.com Using Google Wave?