Presenting in place of my colleague of TCS Canada, who is not able to attend due to visa issues
Consumer market for IT products has grown dueto social network growth and use of these applications on mobile devices such as android and tablets.Due to newer interfaced applications, user requirements are changing presenting challenges to software development managers.Iterative approaches available in agile technologies, are flexible to accommodate these changes.Transition is apparent from conventional development strategies such as water fall to more robust agile strategies.Project Managers also need to verify the software development model compliance with the standard business Project Management Book of Knowledge and the Capability Maturity Model.
To define the research theme a comparison of Water fall and Agile methodologies is presented here.Water fall in the essence is a theoretical model,locked to any variation arising due to change in user requirements.Since at the beginning of the project the users are unsure of its requirements itself therefore iterative event based agile method can better accommodate user requirement changes, predict user requirements, and would allow re-coding in iterations to ease out application defects.
Before software development, software development life cycle model needs to be developed for gathering user requirements and determining the objectives of the stake holders. This phase is common amongst Water Fall and Agile. It corresponds to methodology determination step. Due to lack of reasonable iterations, documentation phase in Water fall is a mere introduction of the application being developed. Documentation is very important to develop communication between programmers, testers, Managers for an efficient project execution co-ordination.Once the real development starts, a manager can define application development iterations based on the platform such as iPAD, portal, or Android OR on the basis of interface with social media such as linkedIN, facebook or twitter (Arrow indicates iteration).Need basis evaluation of end product determines the potential risks of failure and help in developing control strategy to avoid such failures, which also introduces flexibility to the product.Final product is refined version of what was expected at the beginning, by the stake holders and is in fact better due to continuous efforts.
The chart indicates a compliance between the steps of AGILE, PMBOK and CMM modules.Although an in-depth analysis can be carried out to prove the research hypothesis but it is beyond the scope of the research (Can be explored in future research)Determining user requirements defines process framework, which is the initiating phase of the PMBOK and CMM initial level.Since documentation is iterative due to changed user requirements therefore it is repeatable and reflects a better planning on part of stakeholders to secure their objectives.Software development involves iterative step of code execution to mine out the defects and fix them in next iteration, corresponds to executing phase of PMBOK, and defined module of CMM level.Evaluating risks enhances control and introduce better management.Final software product is closing phase of PMBOK, and optimize stake holders objectives.
As a software development manager, one needs to predict the user requirements and include them into the iterative release plan.For every release plan software manager defines platform based user stories, run these stories according to iteration planning, completing one step of development and find defects by communicating with the teams of programmers, testers and administrators to learn about the shortcomings/defects and accommodate them in a new user story.
During iterative event based development, the tests meeting the minimum acceptance criteria can be rendered as passed, while others are declared failed. Features involving third party interfaces such as a link to facebook or twitter can be tested during final iteration and can be held back as blocked.The software features which cannot be tested due to some technical reasons can be tagged as inconclusive. Features such transcription of voice message into multiple languages such French, German, Arabic etc. which were never defined during the business model are not application failures and are treated as design intent. (Example, I left a voice message that can only be transcribed in English or Hindi but it was never meant to be transcribed in French or German)Time span is very important due budget and resource constraints and should strictly be met to avoid project failure, the research has defined estimated timelines for each development and testing phase.
To meet timelines there must be a balance between the defect arrival and kill rate.Here we can see the defects in red and their kill in green, balancing out the probability of a failure.Since iterations are going on therefore cases as blocked, inconclusive linger on with the project and are shown as blue line on top.Defects arising can device specific features e.g. one feature may work in iPAD but fail in Android.Software Managers can prioritize the defects according to their product release plan.In order to do that they need to write release notes shared between managers, developers, testers and network administrators.
Assigning weight-age in terms of time is essential since various teams are working together to develop an interactive application.End result of one team may be the initiating point of otherPoker planning is team consented planning method to allocate estimated time for a task. There might be a variation between the allocated time and actual completion time.Teams meet weekly to discuss the iteration user stories, acceptance criteria and display the poker cards with numbers, on manager’s call. The manager closes the poker bidding and counts the majority number to allocate points to a task as accepted points.The difference between points allocated and work hours is due to difference in planned and actual task.Poker planning discloses uncertainty and develops a sense of ownership to individual
Research discussion concludes that AGILE is suitable for complex software development and comply with PMBOK and CMM business models.Few references to follow.Thank you.
Agenda• Exponential growth of consumer market• Challenges for software development managers• Trend towards agile methodologies• Transition of software development phase from plan-driven to event- based agile approaches• Compatibility with Project Management Book of Knowledge (PMBOK) and Capability Maturity Model (CMM) AGILE: Transitional Approach from Plan-Driven to Event-Based Development 2
Methodologies Comparison• Plan Based Water fall: - Locked methodology - Theoretical model - Not very efficient during the implementation phase• Event Based AGILE: - Predicting user requirement in user stories - Code iteration - Re-coding to adapt the defects AGILE: Transitional Approach from Plan-Driven to Event-Based Development 3
Software Development Approach• Process framework: AGILE and Water Fall common feature• Documentation phase: Water Fall documents are mere introductory due to lack of iterations• Iterative software development: No real iteration in Water Fall• Risk Management: Predicts product market value• Final product: Better due to iteration adaptation Fig. 1 Software Development Approach AGILE: Transitional Approach from Plan-Driven to Event-Based Development 4
Entities Compliance Level• Process framework: PMBOK S. AGILE PMBOK CMM initiating phase, CMM Initial phase No. Levels• Documentation phase: PMBOK 1. Process Frame Initiating Initial planning phase, CMM repeatable work phase 2. Documentation Planning Repeatable• Iterative software development: 3. Iterative Software Executing Defined PMBOK Executing phase, CMM Development defined phase 4. Risk Management Controlling Managed• Risk Management: PMBOK Controlling phase, CMM Managed 5. Final Product Closing Optimizing phase• Final product: PMBOK Closing Table: 1 Compliance Level between Entities phase, CMM optimizing phase AGILE: Transitional Approach from Plan-Driven to Event-Based Development 5
Real Time Development• User stories are part of AGILE iterative software development phase and are chosen based on the acceptance criteria defined for built- in software features• Carried over user stories are modified according to the bugs fixes and redefined features. This may result in redundancy• Ensures quality assurance and seam less testing and development to assure perfect end product for Fig. 2 User Story Developments users AGILE: Transitional Approach from Plan-Driven to Event-Based Development 6
Iterative DevelopmentNormal conditions for test cases• Passed• Failed• Blocked• Inconclusive• Design Intent Treated as No DefectDevelopment Criteria• Release plan is often spanned over months• Iteration spanned over weeks• Acceptance test cases takes days to complete AGILE: Transitional Approach from Plan-Driven to Event-Based Development 7
Iteration for Defect Kill• Balance between defect arrival and kill rate is crucial for project success• Active defect line shows the unsettled design issues• Defects are device specific such as virtual phone, iPAD, Android• Defects are prioritized by software managers• Release notes are defect specific documents to develop understanding between developers, testers, network Fig. 3 Defects Arrival and Kill Rate administrators and managers AGILE: Transitional Approach from Plan-Driven to Event-Based Development 8
Manager Role for Software Development• Poker Planning is commonly used planning method for software development projects to estimate the hours required for development• Points allocated to a task and actual hours spent on the job are called “burn out ratio”• Managers may change the acceptance criteria and can add time stamped notes to explain additional features of the application Fig. 4 Planning Poker for Hourly Tasks AGILE: Transitional Approach from Plan-Driven to Event-Based Development 9
Conclusion• AGILE, PMBOK, and CMM are in compliance with each other• AGILE’s flexibility and adaptation has rendered it as best method for software development managers AGILE: Transitional Approach from Plan-Driven to Event-Based Development 10
References Boehm B., “A spiral model of software development and enhancement,” Computer, vol. 21, no. 5, pp. 61– 72, 1988. Gilb T., “Evolutionary delivery versus the waterfall model,” ACM SIGSOFT Software Engineering Notes,vol. 10, no. 3, pp. 49–61, 1985. Agile Alliance Manifesto for Agile Software Development, Retrieved 24th August 2012. Available at: http://www.agilemanifesto.org . Erickson J., Lyytinen K., and Siau K., “Agile Modeling, Agile Software Development, and Extreme Programming: The State of Research.” In Journal of Database Management, 16(4), 2005, 88-100 Packendorff J., “Inquiring into the Temporary Organization: New Directions for Project Management Research,” Scandinavian Journal of Management. Vol. 11, No. 4, pp. 319 333, 1995. AGILE: Transitional Approach from Plan-Driven to Event-Based Development 11
References Brodman, J. G. and Johnson, D. L., “What small businesses and small organizations say about the CMM.” In Proceedings of ICSE ‘94 May 16- 21, Sorrento, Italy. Hayes, W. and Zubrow, D., “Moving on up: Data and experience doing CMM-based software process improvement.” Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA CMU/SEI-95-TR- 08, Sept. 1995. Molokken-Ostvold, K., Haugen, N.C, “Combining Estimates with Planning Poker.” IEEE Software Engineering Conference, Australia, ASWEC, April 2007 THANK YOU AGILE: Transitional Approach from Plan-Driven to Event-Based Development 12