Your SlideShare is downloading. ×
0
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Agile Experience In Complex Projects
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Experience In Complex Projects

2,040

Published on

Report on agile gathering IV in Ukraine, Kyiv. …

Report on agile gathering IV in Ukraine, Kyiv.
cirka 45 min

Published in: Business, Technology
1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,040
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
83
Comments
1
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Transcript

    • 1. Agile experience in complex projects Big challenges in big projects Borys Lebeda
    • 2. What is complex project? <ul><li>Worthwhile project is that one brings you one level down in CMMI model. (Tommy DeMarco, Timothy Lister) </li></ul><ul><li>Distributed enterprise application </li></ul><ul><li>Distributed team in locations and cultures </li></ul><ul><li>No solid corporate culture </li></ul><ul><li>No men, who know entire system </li></ul>
    • 3. Lifecycle of technologies and products <ul><li>Rise </li></ul><ul><li>Maturity </li></ul><ul><li>Support </li></ul><ul><li>Fall </li></ul>Organization tend to raise exactly like their mainstream product Linear structure organization Solid team with distributed responsibilities Structured organization with many teams
    • 4. Understanding successful soft <ul><li>If your software has reached maturity – it’s already success </li></ul><ul><li>Good features make money. </li></ul><ul><li>Assigned product owners can be rather distant from decision makers </li></ul><ul><li>All those things are distinctive for product owners and has influence on their priorities in both managing software projects and organization. </li></ul>
    • 5. Looking for good product owner <ul><li>In complex organization product owner is usually “assigned from top” person </li></ul><ul><li>Team may badly need some brainpower to organize knowledge of product (business analyst) </li></ul><ul><li>Product owner should: </li></ul><ul><ul><li>Have relevant knowledge </li></ul></ul><ul><ul><li>Be responsive </li></ul></ul><ul><ul><li>Be decisive </li></ul></ul>
    • 6. Business analyst in focus Generally, BA substitutes PO for team, but considered to be team member and helps to organize product knowledgebase
    • 7. Creating product knowledge base <ul><li>Steadily learn how software works </li></ul><ul><li>Make it understandable for all team members, SM and PO </li></ul><ul><li>Involve as many people as you can </li></ul><ul><li>Business analyst and technical writer are organization power of knowledge base </li></ul><ul><li>Wiki is very suitable here, but technology is less important than culture </li></ul>
    • 8. Architecture and architects <ul><li>Premise : </li></ul><ul><li>Design and architecture make no sense for team if it’s only understood to developers </li></ul><ul><li>Developers work inefficiently accordingly to not their own design. </li></ul><ul><li>Conclusions : </li></ul><ul><li>Developers should be fully committed to design and has contribution to architecture. </li></ul><ul><li>Architecture is a guideline how to create software (to development) </li></ul><ul><li>Design is guideline how the software has been implemented (to others) </li></ul><ul><li>Architect is a moderator for guidelines, design & coding standards. </li></ul><ul><li>Design is up to developers and explains how to develop software </li></ul><ul><li>Architect concerns on how to not develop the software rather than on how to develop </li></ul><ul><li>Architecture is “constraints” for design … </li></ul>
    • 9. Agile-oriented manager <ul><li>“ The boss of IT all” </li></ul><ul><li>tracks progress of development to create big picture for customer </li></ul><ul><li>distributes responsibilities </li></ul><ul><li>resolves “impediments” </li></ul><ul><li>looks for new resources and opportunities </li></ul><ul><li>retrieves delivery date </li></ul>
    • 10. Tracking progress <ul><li>The picture big boss want to see most of all: </li></ul><ul><li>Each product should have status, progress and deadline. </li></ul><ul><li>Meeting deadlines makes him happy. </li></ul><ul><li>Unclear information makes him unhappy. </li></ul>………………………………………… 14.06.2008 74% Testing Project C 12.08.2008 15% Design Project B 24.09.2008 5% Analysis Project A Deadline Progress Status(Stage) Tasks
    • 11. 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?
    • 12. Stages in a single “subproject” <ul><li>I. product owner issues idea or 1 st approach of specification </li></ul><ul><li>II. Scope of project is defined. The first sprint is starting … </li></ul><ul><li>III. Product is ready to be shipped, but there are minor change proposal … </li></ul><ul><li>We stop when product owner is satisfied </li></ul>
    • 13. How to retrieve delivery date? <ul><li>Just multiplying team’s expectations is not a deal </li></ul><ul><li>Risk analysis </li></ul><ul><li>Two risks: </li></ul><ul><ul><li>Technological risks </li></ul></ul><ul><ul><li>Requirements risks </li></ul></ul><ul><li>Don’t mix investigation, prototyping and development </li></ul><ul><li>Retrieving date is anyway empirical </li></ul>
    • 14. Agile development
    • 15. Agile development team <ul><li>Responsibilities are changing and staff should be prepared for those changes </li></ul><ul><li>Ideal model is knights of round table </li></ul><ul><li>Each “knight” is a kind of universal soldier </li></ul><ul><li>Being ready for changes should be encouraged as well as professionalism </li></ul><ul><li>Remember: Knowledge base doesn’t replace knowledge </li></ul><ul><li>Remember: people are over processes in agile </li></ul><ul><li>Build engineering is the most critical </li></ul>
    • 16. Agile developer
    • 17. Tester, writers, administrators and so on <ul><li>There are seniors, juniors, DB developers, java developers, script developers among developers. </li></ul><ul><li>All those developers are team members, don’t they? </li></ul><ul><li>Why can’t we have people that do not develop, but still have some useful responsibilities? </li></ul><ul><li>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 </li></ul>
    • 18. Other possible team roles
    • 19. Experienced problems <ul><li>Looking for agile-oriented product owner </li></ul><ul><li>Looking for agile-oriented manager </li></ul><ul><li>Establishing continuous integration </li></ul><ul><li>Modernizing technologies </li></ul><ul><li>Creating product knowledgebase </li></ul><ul><li>Breaking barriers between involved forces </li></ul><ul><li>Legacy issues </li></ul><ul><li>Retrieving delivery time? </li></ul><ul><li>Organize risk analysis </li></ul>
    • 20. Agile principles for non-agile projects <ul><li>No imperative interaction (would you like to herd cats?) </li></ul><ul><li>Responsive vs. responsible </li></ul><ul><li>Transparency vs. commitment </li></ul><ul><li>Risk management </li></ul><ul><li>Working software over comprehensive documentation, but comprehensive documentation is still important … </li></ul>

    ×