When do we exercise canceling a Sprint? Who can cancel a Sprint?
Cancellation of a sprint is generally a rare case as there are losses associated with it. Cancellation seems viable only in case of the Sprint Goal is no more valid and changes cannot be finished in the given sprint. A Sprint can be canceled before the Sprint time box ends & only the Product Owner can cancel the sprint. In case of cancellation, the DONE PBI’s (PBI = Product Backlog Items) are marked done and remaining goes back to PB. After this we plan for new sprint.
Issues: This can be a little impractical in case if there are multiple teams working together on the same Product and all the teams are dependent on each other. However, the situation sensitivity needs to be exercised in such cases.
Benefits of Agile:
The perspective for Customer:
When the customer takes a lookout in the market as for going with which technique for Software Development process, Agile Methodology stands perfectly for the need and outreach for the Customers. The Agile Methodology is more responsive to the customer’s request. Not only it gives the customer high valued features but also delivers more quickly with short cycles.
The Benefit for the development team:
Agile has a great role in making a good working environment. It makes the work process very smooth and makes the team enjoy development work. This helps to generate more good output. With Agile Methodology, their work is valued and more quality product is delivered. It also helps in reducing non-productive work.
The Benefits for Scrum Master:
As a Scrum Master, one needs to have good knowledge of Agile Methodology and how to implement the method into Scrum Framework. Agile gives a process for Scrum Master by virtue of which they can easily plan and track task in daily meetings. Agile gives the Scrum Master a good sense of approach and awareness towards the project state and status. The Agile Method also helps the Scrum Master to react to blockages quickly and address them.
The Benefits for Product Owner:
As a product owner, one predicts to have a good sense of approach for the work process so as to get a product of high values. The Agile development method the product owner to develop work aligns with customer needs. As it gives a product of high quality and highest possible values, it gives a good scope to them for a good approach.
The Perspective for Vendor:
As a vendor, with the help of Agile Methodology, one gets focused development on high-value features with increased efficiency It also helps them to reduce wastage and decreases the overhead.
What anti-patterns might a Scrum Master fall into during a Sprint?
Typical Scrum Master Sprint anti-patterns are below. Any of these behaviors will impede the team’s productivity. It is the Scrum Master’s obligation to prevent them from manifesting themselves. Some of the Scrum Master anti-patterns are:
Keeping the Scrum team dependent: In this scenario, the Scrum Master pampers the team to a level that keeps the team dependent on his or her services: organizing meetings, purchasing stickies and sharpies, taking notes, updating Jira—you get the idea of this service level. More critical, however, is when the Scrum Master decides to keep the team in the dark about principles and practices to secure his or her job. This behavior is only a small step away from the dark side.
Flow disruption: The Scrum Master allows stakeholders to disrupt the workflow of the Development Team during the Sprint. There are several possibilities on how stakeholders can interrupt the flow of the team during a Sprint:
The Scrum Master has a laissez-faire policy regarding access to the Development Team.
The Scrum Master does not object when management invites engineers to random meetings as subject matter experts.
Lastly, the Scrum Master allows either the stakeholders or managers to turn the daily Scrum into a reporting session.
Lack of support: The Scrum Master does not support team members who need help with a task. Development teams often create tasks an engineer can finish within a day. However, if someone struggles with a task for more than two days without voicing that they need support, the Scrum Master should address the issue. Importantly, this is also the reason for marking tasks on a physical board with red dots each day if they haven’t been moved on to the next column.
Turning a blind eye to micromanagement: The Scrum Master does not prevent the Product Owner – or anyone else – from assigning tasks to engineers. The Development Team normally organizes itself without external intervention. And the Scrum Master should act as the shield of the team in this respect.
: The Scrum Master sweeps conflict and problems under the rug by not using Sprint Retrospectives to address those openly. This behavior is often a sign of bowing to politics and instead of using manipulation to meet organizational requirements that are opposing Scrum values and principles. If the organization values its underlings for following the ‘rules’ instead of speaking the truth why would you run Retrospectives in the first place? A ‘Scrum Master’ participating in cargo-cult Scrum is again a supervisor than an agile practitioner.
Why is using Agile frameworks necessary in today’s world?
It helps in rapid & iterative delivery of useful software hence giving customer the competitive advantage.
Due to self-organization and empowerment given to technical teams innovation is exercised comparatively more
The profitability increases due to early delivery
If the market is not conducive to the product – we get early feedback and the business can take a decision to No-Go or Pivot or change the product direction.
Face to face conversation reduces documentation overheads and delays and also foster quality
What is MVP & MMP?
Minimum Viable Product & Minimal Marketable Product
An MVP is set of minimum requirements or features with which it looks like the product if shipped can be used by the users well and they feel the major value is delivered. However MMP is the minimal set of a requirement that is ready to be shipped to market and can be marketed that guarantees the usefulness to the customer. MMP is fully realized version however MVP may the one which is not fully ready for market but estimated to be valuable if completed and released.
Example MMP: www.redbus.com released the first version without capability of billing and disbursal of tickets. The caveat here is you must validate that this minimum feature product solves few major problems for the users and they feel it’s good for us. So with Red bus even without payment capability, the users were able to see the buses details and send info about with bus they want to book and bus operators used to call them and reserve seats. SO the major problem of travel and communication hassle was solved.
MVP: Imagine Red bus is ready with the code and can be released however they do not have the real Bus data that can be used by users for booking then they have an MVP but not MMP.
What is Waterfall Method?
Waterfall Model was the first process model to be introduced. The Waterfall Model is a linear sequential life cycle model which is very easy to understand and use. The key principle on which the waterfall model emphasizes is only after the completion of one phase, the working team are allowed to begin with another phase. The Waterfall model is mostly preferred for small projects and there are no uncertain requirements.
Waterfall Model has six different phases for product development. And every phase must be and should be completed before starting with another phase. So, let’s dive in and read different stages of Waterfall Model Suggests.
Requirement Analysis:
The very first phase of the Waterfall model emphasizes on the collection of things which are required for the software development and then documenting it for further use.
System Design:
This very phase of the waterfall model studies the requirement and with the help of that system design is prepared. This phase also helps to specify the hardware and software parts and helps to plan the overall architecture.
Implementation:
In the implementation phase of the waterfall model, the system is developed with small programs called units who are later integrated with the further process of software development.
Integration and Testing:
In this phase of the waterfall model, the units which are developed in the Implementation phase are further Integrated after testing of each individual unit. After all the units are integrated into the system, final testing is done to check if the work processed is up to the expected parameters.
Deployment :
Once all kind of testing is done and if the results are satisfactory, the system is further deployed in the customer environment for the service and its use.
Maintenance:
To cope up with the client environment, the maintenance phase is their who provide regular feedback and help to fix the issues and patches which come up with the product and software.
Should the Scrum Team become involved in the product discovery process and, if so, how?
There are two principal reasons why a Scrum Team should be involved in the product discovery process as early as possible:
The sooner engineers participate in the product discovery process, the lesser the chances solutions will be pursued that are technically not viable or would not result in a return on investment.
Involving a Scrum Team early on ensures that the team and its Product Owner develop a shared understanding and ownership of what will be built.
This helps significantly with allocating resources to the right issues, maximizing value for the customer, and mitigating investment risk by maximizing the amount of low-value work not done.
Involving the Development Team members early in the process ensures their buy-in, and the team’s willingness to participate in all phases of a product’s development. This motivates the team to participate when making changes necessary to accomplish the Sprint Goals defined for each Sprint or product release.
Who should participate in a Sprint Retrospective?
Only the immediate members of a Scrum Team — Development Team members, Product Owner, and Scrum Master — should participate in that team’s Sprint Retrospectives.
Especially noteworthy is that the line-managers of a Scrum Team’s members not be present. Also, they should not be allowed access to the minutes of any Sprint Retrospective.
How much of a Development Team’s capacity during a regular Sprint would you consider adequate for refactoring? Fixing important bugs? Exploring new technologies or ideas?
Apart from Sprints during which there are critical and urgent tasks to address (such as fixing a problem that has taken the website offline), a good rule of thumb is a 15-10-5 allocation of a Scrum Team’s capacity to refactoring, fixing, and research. Specifically, this means dedicating:
15% of a team’s capacity to technical debt and refactoring,
10% of a team’s capacity to bugs, and
5% of a team’s capacity to explorative spikes (when potentially helpful).
A Development Team may, of course, deviate from this rule of thumb depending on the context. Generally, consistently making these allocations will satisfy both the code quality and maintenance requirements of most software applications and build trust among stakeholders regarding the Scrum Team’s capability to deliver valuable product Increments.
Do you expect experienced team members to wait until the next Daily Scrum in order to ask for help overcoming an impediment?
When impeded, members of a Scrum Team should never need to wait, neither for a Daily Scrum nor any other event, to ask for help. A team waiting to ask for help is a team delaying progress. If the more experienced members of a Scrum Team are waiting for the next Daily Scrum before either asking for help or themselves dealing with an impediment, the Scrum Master has team-building work to do.