Slideshare.net (beta)

Slide 1: Agile experience in complex projects Big challenges in big projects Borys Lebeda

Slide 2: What is complex project? Worthwhile project is that one brings you one level down in CMMI model. (Tommy DeMarco, Timothy Lister)  Distributed enterprise application  Distributed team in locations and cultures  No solid corporate culture  No men, who know entire system

Slide 3: Lifecycle of technologies and products  Rise Linear structure organization  Maturity Solid team with distributed responsibilities  Support Structured organization with many teams  Fall Organization tend to raise exactly like their mainstream product

Slide 4: Understanding successful soft  If your software has reached maturity – it’s already success  Good 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.

Slide 5: Looking for good product owner  In complex organization product owner is usually “assigned from top” person  Team may badly need some brainpower to organize knowledge of product (business analyst)  Product owner should:  Have relevant knowledge  Be responsive  Be decisive

Slide 6: Business analyst in focus Generally, BA substitutes PO for team, but considered to be team member and helps to organize product knowledgebase

Slide 7: Creating product knowledge base  Steadily learn how software works  Make it understandable PO 20% for all team members, SM and PO  Involve as many people Dev QA as you can 10% 50%  Business analyst and technical writer are organization power of BA 20% knowledge base  Wiki is very suitable here, but technology is less important than culture

Slide 8: Architecture and architects Premise:  Design and architecture make no sense for team if it’s only understood to developers  Developers 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 software  Architect concerns on how to not develop the software rather than on how to develop  Architecture is “constraints” for design …

Slide 9: Agile-oriented manager “The boss of IT all”  tracks progress of development to create big picture for customer  distributes responsibilities  resolves “impediments”  looks for new resources and opportunities  retrieves delivery date

Slide 10: Tracking progress  The picture big boss want to see most of all: Tasks Status(Stage) Progress Deadline Project A Analysis 5% 24.09.2008 Project B Design 15% 12.08.2008 Project C Testing 74% 14.06.2008 ………………………………………… Each product should have status, progress and deadline. Meeting deadlines makes him happy. Unclear information makes him unhappy.

Slide 11: In aspect of stages Agile Not done approach looks less comprehensible and spontaneous How to define progress if product back log is changing and team responsible only for one iteration? How to define stages in agile approach if you don’t use SCRUM A? Done

Slide 12: Stages in a single “subproject”  I. product owner issues idea or 1st approach of specification  II. 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

Slide 13: How to retrieve delivery date?  Just multiplying team’s expectations is not a deal  Risk analysis  Two risks: Development risks Requirements  Technologicalrisks risks  Requirements risks  Don’t mix investigation, prototyping and development Retrieving date is anyway empirical

Slide 14: Agile development

Slide 15: Agile development team  Responsibilities are changing and staff should be prepared for those changes  Ideal model is knights of round table  Each “knight” is a kind of universal soldier  Being ready for changes should be encouraged as well as professionalism  Remember: Knowledge base doesn’t replace knowledge  Remember: people are over processes in agile  Build engineering is the most critical

Slide 16: Agile developer

Slide 17: 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

Slide 18: Other possible team roles

Slide 19: Experienced problems  Looking for agile-oriented product owner  Looking for agile-oriented manager  Establishing continuous integration  Modernizing technologies  Creating product knowledgebase  Breaking barriers between involved forces  Legacy issues  Retrieving delivery time?  Organize risk analysis

Slide 20: Agile principles for non-agile projects  No imperative interaction (would you like to herd cats?)  Responsive vs. responsible  Transparency vs. commitment  Risk management  Working software over comprehensive documentation, but comprehensive documentation is still important …