Chapter 2 Time boxing & agile models

Timeboxing Model, Agile Models

1. Time Boxing & Agile Models

2. Sofware Process 2 Time boxing Time boxing – fix an iteration duration , determine specs. acc. Development is done iteratively in fixed duration time boxes Each time box divided in fixed stages Each stage approximately equal in duration Each stage performs a clearly defined task that can be done independently Use pipelining concepts to execute iterations in parallel

3. Sofware Process 3 Time Boxed Iterations General iterative development – fix the functionality for each iteration, then plan and execute it In time boxed iterations – fix the duration of iteration and adjust the functionality to fit in Completion time is fixed, the functionality to be delivered is flexible

4. Sofware Process 4 Example An iteration with three stages – Analyis , Build , Deploy These stages are appx . equal in many situations Can adjust durations by determining the boundaries Can adjust duration by adjusting the team size for each stage There is a dedicated team for each stage (A, B, and D) When one stage team finishes, it hands over the project to the next team - Pipelining

5. Sofware Process 5 Timeboxing Execution

6. Sofware Process 6 Pipelined Execution AT starts executing it-1 AT finishes, hands over it-1 to BT, starts executing it-2 AT finishes it-2, hands over to BT; BT finishes it-1, hands over to DT; AT starts it-3, BT starts it-2 (and DT, it-1) …

7. Sofware Process 7 Time boxed Iteration usage This itself very useful in many situations Has predictable delivery times Overall product release and marketing can be better planned Makes time a non-negotiable parameter and helps focus attention on schedule Prevents requirements bloating Overall dev. time is still unchanged

8. Sofware Process 8 Timeboxing execution First iteration finishes at time T Second finishes at T+T/3; third at T+2 T/3, and so on In steady state, delivery every T/3 time If T is 3 weeks, first delivery after 3 wks, 2 nd after 4 wks, 3 rd after 5 wks,… In linear execution, delivery times will be 3 wks, 6 wks, 9 wks,…

9. Sofware Process 9 Timeboxing execution Duration of each iteration still the same Total work done in a time box is also the same Productivity of a time box is same Yet , average cycle time or delivery time has reduced to a third

10. Sofware Process 10 Team Size In linear execution of iterations, the same team performs all stages If each stage has a team of S, in linear execution the team size is S In pipelined execution, the team size is three times (one for each stage) I.e . the total team size in time boxing is larger; and this reduces cycle time

11. Sofware Process 11 Work Allocation of Teams

12. Sofware Process 12 Team Size Merely by increasing the team size we cannot reduce cycle time - Brook’s law Time boxing allows structured way to add manpower to reduce cycle time Note that we cannot change the time of an iteration – Brook’s law still holds Work allocation different to allow larger team to function properly

13. Sofware Process 13 Timeboxing Advantages: Shortened delivery times, iterative , distributed execution Disadvantages: Larger teams, proj . mgmt is harder, high synchronization needed, CM is harder Applicability: When short delivery times v. imp.; architecture is stable; flexibility in feature grouping

14. Agile Models Iterative + incremental process F ocus -> flexibility in producing software quickly and capably Agile: break the product into small incremental builds. these builds are provided in iterations . each iteration typically lasts from about one to three weeks At the end of the iteration, a working product is displayed to the customer and important stakeholders

15. Following are the Agile manifesto principles: Value individuals and interactions over process and tools Prefer to invest time in producing working software rather than in producing comprehensive documentation Focus on continuous customer collaboration to get proper product requirements. R esponding to change rather than on creating a plan and then following it

16. Agility Principles Highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Deliver working software frequently, from a couple of weeks to months Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation .

17. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility Simplicity–the art of maximizing the amount of work not done–is essential. The best architectures, requirements, and designs emerge from self-organizing teams At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

18. THE POLITICS OF AGILE DEVELOPMENT Jim Highsmith states “Traditional methodologists are a bunch of stick-in-the-muds who’d rather produce flawless documentation than a working system that meets business needs” . As a counterpart he states “Light-weight, ‘agile’ methodologists are a bunch of glorified hackers who are going to be in for a heck of a surprise when they try to scale up their toys into enterprise-wide software” Customer Interaction (backbone), Open communication with minimum documentation   - Agile methodology

19. Agile Vs Traditional SDLC Models Agile is based on the  adaptive software development methods Traditional SDLC models like the waterfall model is based on a predictive approach . Predictive methods depend on the  requirement analysis and planning  done in the beginning of cycle with strict change management In Adaptive approach, feature driven development and the team adapts to the changing product requirements dynamically.

20. Human Factors Some of fundamental characteristics and skills that will facilitate the implementation of agile practices at its core. Competency :   The staff should be competent in knowing software and the technologies Collaboration :   Ability to work in a team Cooperate among themselves involved in project Focus :   Common goal : “Deliver customer an increment of working software in agreed time” Continuous adaptations , always improving the process as needed.

21. Decision making:   Development team should have freedom, in technical matters and project. C ompany can suggest good practice, but in the end is the staff (self-organizing) which will adopt the methods or processes that you think best. Development team must learn to deal with conflicting situations, ambiguity and frequent changes, which will facilitate the continual improvement process.

22. Trust and respect:   Team must be consistent Team demonstrate trust and respect needed to make a strong team. Main Objective: Make the team strong enough that the whole is greater than the sum of its parts . Self organization:   Self organized Team to perform the work. Continuous evaluation for process improvement Self organization has technical benefits : Team selects how much work believed to be capable of performing the iteration and commits.

23. There Is Nothing Noble In Being Superior To Your Fellow Man; True Nobility Is Being Superior To Your Former Self. 

24. Some Agile Methods Rapid Application Development (RAD) Extreme Programming (XP) Rational Unify Process (RUP) Adaptive Software Development (ASD) Feature Driven Development (FDD) Crystal Clear Incremental SDLC Scrum Dynamic Software Development Method (DSDM)

25. Sofware Process 26 EXTREME PROGRAMMING (XP) eXtreme P rogramming (XP) is one of the most popular An XP project starts with user stories , which are short description of user needs Details are not included User stories written on a separate card Team estimates time to implement a user story – Rough Estimates Release planning is done Defines which stories are to be built in which release, & release dates Encourages Frequent and small releases Acceptance tests built from user stories; used to test before release Bugs found in AT are fixed in next release

26. Sofware Process 27 XP – Overall Process

27. Sofware Process 28 Overall Process Development done in iterations of a few weeks each Iteration starts with planning, in which stories to be implemented are selected – high risk high value are chosen first Details of stories obtained during the development are implemented Failed AT of previous iteration are also fixed

28. Sofware Process 29 XP - Summary Well suited for situations where volume and pace of requirements is high Customer is willing to engage heavily with the team The team is collocated and is not too large (less than 20 or so) Requires strong capability in team members

29. P rototyping + Iterative development with no specific planning Focus: Gather customer requirements E arly testing of the prototypes by the customer using iterative concept R euse of the existing prototypes (components ) C ontinuous integration and rapid delivery No detailed preplanning - easier to incorporate the changes Team comprises of developers, domain experts, customer representatives and other IT resources Rapid Application Model (RAD)

30. RAD Phases Requirements planning phase Structured discussion of business problems Does System planning and analysis Users, managers, and IT staff members discuss and agree on business needs, project scope, constraints, and system requirements. It ends when the team agrees on the key issues and obtains management authorization to continue

31. User description phase automated tools capture information from users Users interact with systems analysts and develop models and prototypes that represent all system processes, inputs, and outputs. Use tools & techniques to translate user needs into working models.  C ontinuous interactive process to understand, modify, and eventually approve a working model.

32. Construction phase Uses productivity tools, such as code generators, screen generators, etc. inside a time-box. (“Do until done”) Users continue to participate and suggest changes or improvements Tasks are programming and application development, coding, unit-integration, and system testing.

33. Cutover phase System installation, user acceptance testing and user training Resembles the final tasks New system is built, delivered, and placed in operation Tasks are data conversion, full-scale testing, system changeover, user training.

34. RAD Strengths Changing requirements can be accommodated. Progress can be measured. Iteration time can be short with use of powerful RAD tools. Productivity with fewer people in a short time. Reduced development time. Increases reusability of components. Quick initial reviews occur. Encourages customer feedback. Integration from very beginning solves a lot of integration issues.

35. RAD Weaknesses Dependency on technically strong team members for identifying business requirements. Only system that can be modularized can be built using RAD. Requires highly skilled developers/designers. High dependency on modeling skills. Inapplicable to cheaper projects as cost of modeling and automated code generation is very high. Management complexity is more. Suitable for systems that are component based and scalable. Requires user involvement throughout the life cycle. Suitable for project requiring shorter development times .

36. When to use RAD Reasonably well-known requirements User involved throughout the life cycle Project can be time-boxed Functionality delivered in increments High performance not required Low technical risks System can be modularized

37. Sofware Process 39 Rational Unified Process(RUP) Iterative model Software development is divided into cycles, each cycle delivering a fully working system Each cycle executed as separate project Execution of a cycle is broken into four consecutive phases, each phase ending with a milestone achievement

38. Sofware Process 40 Phases in a Project Inception phase: ends with Lifecycle Objectives milestone; vision and high level capability of system defined Elaboration phase: Lifecycle architecture milestone ; most requirements defined and architecture designed Construction phase: Initial operational capability milestone Transition phase: Product release ; transition product from development to production

39. Sofware Process 41 Phases and Milestones

40. Sofware Process 42 Execution of phases Each phase itself can be done in multiple iterations, each iteration having an external/internal customer Generally construction has multiple iterations; elaboration can also be meaningfully done in multiple iterations

41. Advantages of Agile Model R ealistic approach Promotes teamwork and cross training F lexibility to developers Functionality can be developed rapidly and demonstrated Resource requirements are minimum. Suitable for fixed or changing requirements Delivers early partial working solutions Good model for environments that change steadily Minimal rules, documentation easily employed Enables concurrent development and delivery within an overall planned context. Little or no planning required Easy to manage

42. Disadvantages of Agile Model Not suitable for handling complex dependencies. More risk of sustainability, maintainability and extensibility. Strict delivery management Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong direction. High individual dependency, since there is minimum documentation generated. Transfer of technology to new team members may be quite challenging due to lack of documentation.

43. Sofware Process 45 Summary Process is a means to achieve project objectives of high QP Process models define generic process, which can form basis of project process Process typically has stages, each stage focusing on an identifiable task Many models for development process have been proposed Model should be selected based on the nature of the problem