Whether agile is a better methodology than the traditional waterfall methodology?
Modern projects are constrained by several uncertainties in terms of what is expected/what is anticipated in the beginning of the project.
Agile methodology is more people oriented. Agile methodology helps us to increase productivity and reduce risks.
The good news is that this data is increasingly available. The bad news is that the quantity of data is growing so rapidly that it is often outstripping firms’ capacity to effectively utilize it. Rapid response rates (i.e. less than a few seconds) on queries of millions of entries can provide significant competitive advantage for two key reasons. The first reason is the potential insight that comes from data-driven decision making. The second reason is that employees will actually use them for product movement, seasonal and promotional, margins, placement, and product affinity (products typically co-purchased), location.
In-memory business intelligence solutions help solve problem as more (and cheaper) memory now available. Today’s BI solutions can process reports on the fly by loading complete data sets into memory. For the management team, instant response rates (i.e. less than a few seconds) on queries of millions of entries can provide significant competitive advantage; especially in retail where having the right inventory in store at the right time is the primary profit driver. Additionally, for the IT team, using in-memory technology reduces the need to design, build and maintain intermediary data sets.
Scrum is characterized by short time-boxed iterative cycle, adjustable scope, customer satisfaction through quick turnaround time, responding to change quickly, customer collaboration throughout the project.
For example, a tester who is involved in testing the product is part of the Scrum team, but a delivery manager who oversees the project and provides help if any resource-related issue arises is not considered as part of the Scrum team. The three main Scrum roles are – the product owner, the Scrum master and the team.
Product owner (PO): This person is the bridge between the end users and the development team. The product owner has the primary responsibility of translating the product vision to user requirements and of ensuring that the project’s objectives are met by the end product. This role is critical to the project’s benefit realization and meeting the final goal largely depends on the product owner’s ability to create, prioritize, and verify the requirements.
Scrum master: This person is responsible for making sure that the scrum values and principles are followed in the team and more importantly is responsible for helping the team in removing the roadblocks in order to achieve the scrum goals. The person works as the bridge between the team and the management.
The product owner creates the initial product vision – overall requirements
decides on release date and content
is responsible for the profitability of the product (ROI) prioritizes features according to the market value interacts with stakeholders and customers to define the product backlog adjusts features and priority every iteration, as needed accepts or rejects work results.
The Scrum master represents management to the project responsible for enacting Scrum values and practices removes or helps in removing impediments ensures that the team is fully functional and productive
enables close cooperation across all roles and functions shields the team from external interferences.
Team: This is the group of people who are executing the actual tasks of the project like design, development, testing, etc.
Typically consists of 8–12 people. As the key Agile feature is a high level of communication among the team members, the team size is restricted to keep the number of communication channels under control.
Cross-functional team: programmers, testers, user experience designers, etc. This means that the team has all the skills required for the project available within the team.
Members should ideally work full time, perhaps with a few exceptions (e.g. database administrator, network support people).
Teams are self-organizing: ideally, no titles, but rarely a possibility.
Responsible for the quality
Estimates the complexity
Committed to developing functionality.
Extreme programming methodology is built on four guiding values—communication, simplicity, feedback and gcourage. XP programming has a key focus on improving the communication—it may be among the developers or between developers and customer.
Lean Software Development is adopted from Toyota Production System which combines the principles of lean manufacturing and Lean IT principles. The seven principles that form the Lean system are:
1. Elimination of waste
2. Create knowledge—the learning from each phase of the project should be propagated to the whole team and take necessary action based on the learning. For example, if there is a high number of a defect found after the release, then the learning in the unit testing needs to be more stringent which is a learning that needs to be propagated to the team.
3. Quality is in-built—one of the ways of building the quality is refactoring. The customer must see the quality in the delivered system.
Defer commitment—commit only the portion for which you have sufficient visibility. There is no point committing something far off in the future as there may be many changes by the time you reach that point. So, defer your commitment as late as possible. This is the same concept as adaptive planning.
Deliver fast—create small release cycles so that the values are delivered faster to the customer.
Empower the team—in software development, people are the key. So, take the time to motivate the team and build the team over time.
Optimize the whole—see the whole system as an integrated view. There may be different teams working on different parts of the system, but all the team members should have the overview of the whole system and know the purpose of the system. Without this knowledge, the team members can’t produce an effective deliverable.
Requirements
Guides the design of the eventual solution. Without correct requirements you cannot design or build correct product. 60% of projects failures originate with the requirements.
Functional requirements: The system needs to do something. Real time inventory of toothbrushes.
Non-functional requirements/supplement requirements: Not easy to see like security or interface of the product.
Constraint: what is going to pull it back. Next phase is design.
- Product constraints: Reason why the product is being built.
- Client, customer, and stakeholders: people that are interacting with the product
- Users of the product: intended end users and how they affect product usability.
- Requirements constraints: limitations of the project and restrictions on design
- Naming convention: vocabulary of the product
- Relevant facts: outside influences that make a difference to the product.
- Assumption: assumptions developer are making.
- Example: Product budget shall not exceed 50k dollars. The product shall run on the company’s existing machine. Implementation of the product cannot interrupt daily business. The last 5 years of historical data needs to be made available in the product.
Scope of the project– Defines the boundaries and connections to other products.
Functional and data requirements: Things the product must do and data manipulated by the functions.
Data Centric 