Common Mistakes in Scrum – Irregular Status Meeting
Standup meeting needs to be conducted every day by Scrum master in order to drive team focus towards sprint goals. This meeting helps to track daily updates of sprint tasks, calculate project velocity, and drive the team in a correct direction. Standup meetings are useful in determining dependent factors, project hurdles at an early state. Standup meetings are generally of 15 -20 min in duration. Meetings are typically conducted at the same location and at the same time every day. Ideally meetings are conducted during early business hours, which facilitate t6o utilize rest of the business hours effectively. The general common mistake of a Scrum team is having either irregular status meeting or missing key stakeholders to the standup meeting. Scrum master should make sure the standup meeting is conducted regularly on daily basis and all necessary stakeholders are present for the meeting.
Common Mistakes in Scrum – Out dated Burn down charts
Burn down charts is a consolidated worksheet which has all necessary information about different functional modules, resource estimates and other necessary metrics. Burn down charts has all necessary details about tasks, estimated hours, daily updates, load factor, and project velocity. Burn down charts should be updated daily tracking day-to-day status of the project. Missing periodic updates of BDC is a common mistake, which can be avoided by making BDC access available for all team players.
Common Mistakes in Scrum – Over/Under Estimation of Tasks
Sprint estimation is estimated before the sprint cycle, in sprint planning meeting. Based on the task estimations and priority of the estimates, features are committed in Sprint commitment meeting. Hence estimation of task plays a vital role in Scrum cycle. Over estimation of tasks reduces resource efficiency and under estimation can hamper the product release. To avoid mistake of over or under estimation, historical statistics, dependent variables, and resource availability needs to be considered while estimating a feature.
Common Mistakes in Scrum – Missing Statistical Information
Historical data provides good information about project and team capabilities. Though historical information doesn’t have a complete set of necessary information for estimating a task, it will provide a better starting point. Project velocity, load factor, resource utilization are some of the statistical methods needs to be formulated in order to identify project state.
Project velocity = ∑ Estimates of user stories that were finished in a iteration.
Error Tolerance = (Total burned hours)-(Total Estimated hours)
Resource utilizations rate = Total estimated hours / Total development hours
Common Mistakes in Scrum – Lacking Scrum of Scrum
A project of medium to large size has many scrum teams working for business goal. Scrum teams sometimes primarily focus on team functionality, which may cause project myopia. When multiple scrums works for a common business goal, Scrum of scrum meeting has to be conducted regularly to discuss about various dependent factors, interdependent features, release dates, and other project specific details.
What is Rational Unified Process?
Rational unified process is a disciplined software development methodology which targets on producing high quality software deliverable. Rational unified process encourages systematic development while classifying tasks, assigning tasks and responsibilities within a development organization. Rational unified process was developed by Philippe Kruchten, Ivar Jacobsen, and others at Rational Corporation (Kruchten, 1996) (Kruchten, The Rational unified process: an Introduction, 2000). Rational Unified Process inherits its process structure and use cases structure from Objectory Process. Rational Unified Process inherits its iterative development and architecture from Rational Approach.
Principles of Rational Unified Process
The Rational Unified Process supports an iterative approach to development that helps in identifying risk proactively, reducing re-factor cost, and building models with easy exit strategy. Rational Unified Process recommends using use-cases and scenarios to capture functionality requirements. The Rational Unified Process supports component-based software development. Components are non-trivial modules, subsystems that fulfill a clear function. RUP encourages visual software models to depict architectures and component. Frequent verification of quality should be reviewed with respect to the requirements based on reliability, functionality, application performance and system performance. Control changes to software are recommended by the process. The process describes how to control, track and monitor changes to enable iterative development.
Life Cycle of Rational Unified Process
Rational Unified Process consists of four sequential processes during design and development of business solution. The four sequential processes includes: Inception, Elaboration, Construction and Transition. These phases are iterative in nature and yields products in each field. Iterations are between two weeks to six months.
Life Cycle of Rational Unified Process -Inception
In this phase overall domain descriptions are prepared. Document requirements are organized with proper use-cases and technical specifications. During this phase business case for the system is established and delimited the project scope. All key entries are identified and coupled communication is identified at higher level. Identify use cases is an important step in this phase. Business case includes success criteria, risk analysis, resource requirements, and game plan to be implemented. Inception phase yields use-cases, vision documents, high level business case and glossary, higher level risk analysis, project plan, and prototype. Evaluation is performed iteratively in each phase. Stakeholders conducts regular meeting to discuss about scope definition and cost estimates. Conflict of interests and initial risk assessment are resolved while stakeholders are in process of having concurrence among team. Cost estimates, Risk factors, task estimations, resource estimations and schedule estimates are evaluated in these meetings. Prototypes developed in phase-1 are evaluated by its depth and breadth. Relative analysis of actual expenditure vs. planned expenditure is performed as part of evaluation criteria. Project can be rethought or cancelled or proceed in this phase.
Life Cycle of Rational Unified Process – Elaboration Phase
This phase plays a vital role in laying foundation for project architecture. This phase primarily helps in analyzing problem domains, developing flexible project plan, developing flexible architectural foundation, identifying risk and eliminating them. Architectural foundation can be performed from results of phase-1, i.e scope definition, requirements, and major high level functionality. This phase is helpful in identifying risk analysis, and value analysis and decision can be taken whether or not to commit to further phase: construction and transition phase. Executable architecture is built in iterations depending on project size, scope, cost, and time lines. After this phase , most use cases are defines, actors are identified, Software architecture is described, and a prototype is created. Evaluation is performed based on vision of the product stability, architecture stability, relative analysis of actual resource expenditure vs. planned expenditure, and risk factors identified. The project may be aborted or considered based on the result of milestones achieved in this project.
Life Cycle of Rational Unified Process – Construction Phase
In construction phase all remaining components and application features are developed and integrated in the product. All developed features are thoroughly tested. Construction phase is a manufacturing phase where focus should be on managing resources, controlling operations, optimizing cost, meeting timeline, and maintaining acceptable quality. Successful elaboration phase yields successful construction phase. A robust architecture developed in elaboration helps as skeleton for construction phase. There are scenarios where parallel construction increments can be spawned. Construction phase results in software products integrated on adequate platform,
User manual, release notes, and other proprietary documentations. The results of the construction phase: either alpha, beta, are developed iteratively and rapidly which helps in developing high quality product with rapid pace.
Life Cycle of Rational Unified Process – Transition Phase
This phase is to transition the software deliverables to the user community. This phase is attained when the product reach suitable maturity and stability. As the product development is iterative in nature, defects are resolved in subsequent releases. This phase primarily focus on activities required to release stable products, product tuning, product configuring and resolving issues. The primary objective of the transition phase includes achieving baseline targets, user confidence and self supportability, and concurrence with vision documents.
Key Players of Rational Unified Process
RUP process can be classified into three main components: Activities, Artifacts, and workers. An activity is a unit of work that an individual is asked to perform in that role. It can also be described as a granular, modular functionality which a role expects. Activity can varies from few hours to few days. Finding actors, developing modular functions, writing use cases are some of the examples of Activities. RUP has workers like developers, architects, designers, design reviewers, configuration managers, business process analyst, business reviewers, business designers, course developers, toolsmith , testers, project managers, stakeholders.
Feature Driven Development
Feature Driven Development (Palmer & Felsing, 2002) is a software agile methodology which has gained significance in early 2000’s. Feature Driven Development focuses much on design and building phases. FDD is flexibly designed to work with any specific process model of software development methodology. Like other agile methodologies, FDD advices incremental development by practicing best practices and frequent monitoring. FDD is an enhancement of iterative and incremental approach. FDD enables the reliable delivery of working software in a disciplined fashion with information flowing across the project.
Feature Driven Development – Factors Addressed
Feature-driven development (FDD) is an example of a feature-centric process. There are some other feature centric development processes apart from FDD. The development process EVO is feature-centric as to some extent is DSDM, with its requirements catalogue. Feature centric process helps in handling a project by considering following factors
What must we do next to add value to the client?
How are we progressing against time and budgets?
What issues and risks does the project face?
How can the issues and risks be addressed or mitigated?
What should we do next?
Life Cycle of Feature Driven Development
FDD consists of five sequential processes during design and development of business solution. The five sequential processes includes: Develop an overall model, Build a feature list, Plan by features, Design by feature and build by feature. In initial phase overall domain descriptions are prepared. Having got acquaintance with business functionality, domain expertise, overall scope of the project, key players involved in process development initiates overall model design. Phase -2 conducts a initial project wide activity to identify all the features to support overall model designed in Phase-1. Phase-3 targets to produce the development plan.
Life Cycle of Feature Driven Development – Building Overall Model
In this phase overall domain descriptions are prepared. Having got acquaintance with business functionality, domain expertise, overall scope of the project, key players involved in process development initiates overall model design. Document requirements are organized with proper use-cases and technical specifications. Domain experts and key team players walkthrough the requirements. After initial walkthrough, the overall domain is further divided into different domain areas. Detailed walkthrough is held for domain members. After each walkthrough small development teams works effectively to produce object model.
Life Cycle of Feature Driven Development – Building Feature List
This phase conducts a initial project wide activity to identify all the features to support overall model designed in Phase-1. Feature list designed in this phase targets to address all supporting requirements. This Phase can also be stated as functional decomposition of domain model obtained from Phase 1. Major features list are prepared initially, which further divided into feature sets. There will be a review panel including Domain experts, Chief Programmers, Architects and other key players, who performs value-analysis on feature list. Generally features are listed as
Eg: Calculate the total of course fee for all students, these results in calculating total revenue of an organization.
Life Cycle of Feature Driven Development – Plan by Feature
This phase is an initial project wide activity which targets to produce the development plan. This phase targets to prepare high level plan where list of all features are listed based on the priority and their dependencies. Project manager, development managers, chief programmers and other key player’s acts together to prepare a sequential list of all features listed in phase-2, and sort the features based on the priority of the features. Identifying interdependency between different features prior to implementation is an important part of this phase. Schedule and major milestones are set for this feature test. A project schedule is identified by keeping following features under consideration.
Inter dependencies between the features.
Balancing load across different teams and class owners.
Risk factors involved in implementing the feature.
Complexities involved in implementing the feature.
Any Other external factors.
Life Cycle of Feature Driven Development – Design and Build Feature
After obtaining set of feature list with priorities, Class owners helps in the formation of feature teams. Feature teams handles a small group of features, which are subset of feature list obtained from phase-3. Design and development are incremental in nature. Iteration is generally scheduled for 1-2 weeks. In this phase system goes through sequential process of product development: Design, Development, Unit testing, Integration and System testing. After successful iteration, the completed feature is pushed to main build while other design and building iteration starts with new set of features .Classes are migrated to the build after a successful code inspection. The Chief Programmer is accountable for individual classes being promoted, through feedback from the developers.
Life Cycle of Feature Driven Development – Key Players
The six key roles in a FDD project are: project manager, chief architect, development manager, chief programmer, class owner, and domain experts. The five supporting roles comprise release manager, language lawyer; build engineer, tool smith, and system administrator. Testers, deployers and technical writers also play a vital role in FDD development. Project manager is the person who has ultimate say in the lifecycle of FDD. Project manager looks after administration and financial aspects of the project. Chief architect is responsible for system design. Development manager is responsible for monitoring daily developmental activities, identify the risks proactively, resolves any issues, plan releases and plan resources. Class owners are responsible for formation of feature teams and building class he was assigned to.
Who is this Class Owner?
Class owners are responsible for formation of feature teams and building class he was assigned to. Class Owners reports to Chief programmers. Class owners are accountable for analysis, design, implementation, testing and documentation of the class. Class owners plan for next iteration, monitors current iteration and supports any previously developed classes.
Who is this Chief Programmer?
Chief Programmer is responsible for identifying different classes and different class owners. He plays an active role in analysis, design, implement, test and documentation phase of overall project. He plays a vital role in design and deve
lopment of features. Chief programmers communicate frequently with each other in order to identify risks, reduce complexity, and analyze technical feasibilities.
Who is this Domain Expert?
Domain experts are the person who has possessed wide domain level knowledge and system behavior. Domain experts can be users, business owners, business analyst, and clients. Domain experts communicate the business logic to key players of the project. Domain manager leads domain experts and strives for smooth communication flow.
What is the duty of Chief Architect in FDD?
Chief architect is responsible for system design. He is responsible for overall design of the system and he conducts design sessions, design review sessions held with the team which helps in identifying risks proactively. Based on the complexity of the system, Chief Architect can decentralize the architectural work among different system architects.
What is the duty of Project Manager in FDD?
Chief architect is responsible for system design. He is responsible for overall design of the system and he conducts design sessions, design review sessions held with the team which helps in identifying risks proactively. Based on the complexity of the system, Chief Architect can decentralize the architectural work among different system architects.
Dynamic System Development Methodology
Dynamic system development methodology (DSDM-Consortium) is a non proprietary framework maintained by DSDM symposium*. DSDM symposium is a non-profit organization. DSDM is a vendor independent framework. DSDM is a systematic approach of handling a project in an effective and efficient manner. DSDM facilitates an interesting framework to develop functionality in better and amicable manner, deliver functionality efficiently and effectively, and satisfy the real requirement of the project.
Agile Concepts Page 5
