20
Agile experience in complex projects Big challenges in big projects Borys Lebeda

Agile Experience In Complex Projects

Embed Size (px)

DESCRIPTION

A presentation from the Ukrainian Agile Gathering IV run by AgileUkraine.org in Kyiv on 5 April 2008.

Citation preview

Page 1: Agile Experience In Complex Projects

Agile experience in complex projects

Big challenges in big projects

Borys Lebeda

Page 2: Agile Experience In Complex Projects

What is complex project?

Worthwhile project is that one brings you one level down in CMMI model. (Tommy DeMarco, Timothy Lister)

Distributed enterprise applicationDistributed team in locations and culturesNo solid corporate cultureNo men, who know entire system

Page 3: Agile Experience In Complex Projects

Lifecycle of technologies and products

Rise

Maturity

Support

FallOrganization tend to raise exactly like their mainstream product

Linear structure organization

Solid team with distributed responsibilities

Structured organization with many teams

Page 4: Agile Experience In Complex Projects

Understanding successful soft

If your software has reached maturity – it’s already successGood features make money.Assigned product owners can be rather distant from decision makers

All those things are distinctive for product owners and has influence on their priorities in both managing software projects and organization.

Page 5: Agile Experience In Complex Projects

Looking for good product owner

In complex organization product owner is usually “assigned from top” personTeam may badly need some brainpower to organize knowledge of product (business analyst)Product owner should:

Have relevant knowledgeBe responsiveBe decisive

Page 6: Agile Experience In Complex Projects

Business analyst in focus

Generally, BA substitutes PO for team, but considered to be team member and helps to organize product knowledgebase

Page 7: Agile Experience In Complex Projects

Creating product knowledge base

Steadily learn how software worksMake it understandable for all team members, SM and POInvolve as many people as you canBusiness analyst and technical writer are organization power of knowledge baseWiki is very suitable here, but technology is less important than culture

BA20%

Dev10%

PO20%

QA50%

Page 8: Agile Experience In Complex Projects

Architecture and architectsPremise:

Design and architecture make no sense for team if it’s only understood to developersDevelopers work inefficiently accordingly to not their own design.

Conclusions: Developers should be fully committed to design and has contribution to architecture.Architecture is a guideline how to create software (to development)Design is guideline how the software has been implemented (to others)Architect is a moderator for guidelines, design & coding standards.Design is up to developers and explains how to develop softwareArchitect concerns on how to not develop the software rather than on how to developArchitecture is “constraints” for design …

Page 9: Agile Experience In Complex Projects

Agile-oriented manager

“The boss of IT all”tracks progress of development to create big picture for customerdistributes responsibilitiesresolves “impediments”looks for new resources and opportunitiesretrieves delivery date

Page 10: Agile Experience In Complex Projects

Tracking progressThe picture big boss want to see most of all:

Each product should have status, progress and deadline.

Meeting deadlines makes him happy.Unclear information makes him unhappy.

…………………………………………

14.06.200874%TestingProject C

12.08.200815%DesignProject B

24.09.20085%AnalysisProject A

DeadlineProgressStatus(Stage)Tasks

Page 11: Agile Experience In Complex Projects

In aspect of stages Agile approach looks less comprehensible and spontaneous

Not done

Done

How to define stages in agile approach if you don’t use SCRUM A?

How to define progress if product back log is changing and team responsible only for one iteration?

Page 12: Agile Experience In Complex Projects

Stages in a single “subproject”

I. product owner issues idea or 1st approach of specificationII. Scope of project is defined. The first sprint is starting …III. Product is ready to be shipped, but there are minor change proposal …

We stop when product owner is satisfied

Page 13: Agile Experience In Complex Projects

How to retrieve delivery date?

Just multiplying team’s expectations is not a dealRisk analysisTwo risks:

Technological risksRequirements risks

Don’t mix investigation, prototyping and development

Retrieving date is anyway empirical

DevelopmentrisksRequirementsrisks

Page 14: Agile Experience In Complex Projects

Agile development

Page 15: Agile Experience In Complex Projects

Agile development team

Responsibilities are changing and staff should be prepared for those changesIdeal model is knights of round tableEach “knight” is a kind of universal soldierBeing ready for changes should be encouraged as well as professionalismRemember: Knowledge base doesn’t replace knowledgeRemember: people are over processes in agileBuild engineering is the most critical

Page 16: Agile Experience In Complex Projects

Agile developer

Page 17: Agile Experience In Complex Projects

Tester, writers, administrators and so on

There are seniors, juniors, DB developers, java developers, script developers among developers.All those developers are team members, don’t they?Why can’t we have people that do not develop, but still have some useful responsibilities?

If you don’t have testers it is at least stupid: you developers are doing tasks for 10$/hour that can be done by 3$/hours by testers

Page 18: Agile Experience In Complex Projects

Other possible team roles

Page 19: Agile Experience In Complex Projects

Experienced problems

Looking for agile-oriented product ownerLooking for agile-oriented manager Establishing continuous integrationModernizing technologiesCreating product knowledgebaseBreaking barriers between involved forcesLegacy issuesRetrieving delivery time?Organize risk analysis

Page 20: Agile Experience In Complex Projects

Agile principles for non-agile projects

No imperative interaction (would you like to herd cats?)Responsive vs. responsibleTransparency vs. commitmentRisk managementWorking software over comprehensive documentation, but comprehensive documentation is still important …