Scrum Development: What’s involved and scrum artifacts

The Scrum model recommends that projects advancement occurs through a series of sprints. In tune with an agile procedure, sprints are allotted a fixed period of time which won’t be rarely a month long, most commonly two weeks.

Scrum procedureendorses for a complete planning at the start of the sprint, where team members decide how many items they can achieve to, and based upon that a sprint backlog is created – a list of the tasks to be performed during the sprint.

The Scrum team takes a few features to be coded and to be tested during each sprint. Once these features are done which means coding and testingare completed they are integrated into an evolving product or system.

Every day during the sprint, all the team members need to attend a daily Scrum meeting, which should include the ScrumMaster and the product owner. This meeting is timed to 15 minutes or less. During that meeting, team members share what they did on the prior day, what they would be doing on that day, and to find out any hindrances to progress.

The Scrum model sees daily meetings as a way to integrate the work of team members as they discuss the task of the sprint.After each sprint finishes, the team performs a sprint analysis during which the team explains the new process to the product owner or any other stakeholder who wants to provide feedback that could influence the next sprint.

This feedback sessionwithin Scrum software development may follow in changes to the newly delivered process, but it may also result in reviewingor adding items to the product backlog.

The meeting in the Scrum Project Managementprovides an opportunity to focus on the sprint that has ended, and to find out the different opportunities to improve.

The Scrum Artifacts:

The first and foremost artifactin Scrum development is, certainly, the product itself. According to the Scrum model at the end of each sprint, the team should shape the product or system to a statewhich can be shipped.

Another scrum artifact is product backlog. Product backlog includes the complete list of the functionality that needs to be added to the product as per the requirement. The product owner keeps updatingthe product backlog so that the team always works on them on a priority basis.

Few another scrum artifactsare the sprint burndown chart and release burndown chart. Burndown is the part of taskleft in a sprint. It talks about if the task can be finished within the stipulated time.

Pursue Agile mind-setto survive crises

Many mid-level software firms and financial institutions have seen two of the worst crisis in the past decade: dotcom crisis and sub-mortgage crisis. Before the crisis, people were so optimistic that big long term project plans were prepared packaging in as much features as possible, running upto 3-4 years.Interest rates were affordably low, andmarket dynamics was such that there was huge demand for each and every product and service.   Extravagant meetings were held at plush hotels, everyone got a big pay check and everyone was provided a smart phone with immediate access to emails. Also, what happened was that people went overboard on ensuring that we were compliant with a formal projectmanagement to ensure process compliance with project management templates. SEPG and similar groups mushroomed who were dedicated towards implementing processes at any cost, even if process overhead reduced project benefits, as focus was on long term goals. Project managers worked in silos without any direct correlation with the business team. They were located in PMO, which were in many scenarios not in the physical vicinity of the business teams.

Then, these crises came and everything came to a standstill. The smart phones started to disappear. Groups were formed to simplify the processes. The goal was to remove hierarchy and make the process more lean and adaptable. Many companies disbanded many of the project-management offices and asked

the project managers to coordinate directly with the business teams so they could be closer to the customers. Also, the focus shifted from mega benefits 3 years down the line to immediate customer priorities. The aim was to provide customers exceptional value consistently, by capturing their requirements sprint by sprint and taking constant feedback.

This shows that in times of crises, transitioning to an Agile mind-set helps a company survive. It helps to cut costs drastically by reducing inefficiency and redundancy. It helps retain customers by providing exceptional value to them, which helps thwart competition. Agile also improves working relationship among all the team members, as it promotes collaboration and flat structure. Agile creates a sense of urgency that is essential to save a sinking ship. Many companies who could not pursue the Agile mentality had to unfortunately shut down, and those who survived realized the importance and value of transitioning into an Agile mind-set so as to avoid / manage similar crises better next time.

Key to Adopting Scrum

One of the most common adopted agile approaches in industry today is SCRUM, more so for agile software development.  In order to adopt the approach, core principles of SCRUM have to be implemented.  Various organizations have implemented agile approach including SCRUM.

Ten keys that help a company identify changes that have to be implemented for SCRUM to meet its needs.

1.   Assess its Suitability

SCRUM is an incremental method which enables a higher level workflow at the team level.  Agile software development has SCRUM as one of the approaches. Scrum at its core has sprints, daily meetings and the product backlog maintains work items. Scrum Master, product owner and the development team are the three roles in SCRUM. Also for the product and process it includes continuous enhancement feedback loops. However scrum is not a good fit for organizational and product software development

The primary key for SCRUM adaptation is to determine the methodology is ideal for the project or various other projects in the company.

2.   Adhere to Core Principles.

The most critical part of SCRUM is to understand the core principals and adopt them. The major cause for failure of a project is not adhering to the core principals of SCRUM.

The outcome of this varies from project cancellation to building the system from scratch.  This leads to the project being delayed, to the over budget and various other issues which affects the user needs.

3.   Tailoring needs for SCRUM adoption.

Playing by the book SCRUM can be a good fit for few projects; few companies tailor the methodology to meet their needs.  However it’s important to play by the book at initial stages of the project so that the fundamentals are understood & approach adopted. Also it’s absolutely necessary to stick to the core SCRUM principles.

4.   SCRUM Roles

Scrum master, Product owner, and development team are the three major roles for SCRUM. When adopting SCRUM for a project it’s important to understand the implications of implementing these roles.

Scrum Master- one who facilitates the scrum process and the team also ensures that the process is being followed, enable cooperation between team members, help in decision making. 

Also he has to take care of outside interference and remove barriers.

Product owner- He defines the features of a product, or organizes the features of a product according to the business value. He works closely with the development team.

Development Team- Determines the set of work that needs to be completed. After completion of each sprint, a demo of the product is shown to the product owner.

5.   Collaboration.

For SCRUM to be successfully adopted there has to be an emergence of a self empowered team. In order to make sure this is done a team must be made up of indivuials from all disciplines required to define, build, validate, and prepare the software for release.  

6.   A balanced perspective.

During the adoption of SCRUM, it’s important to determine the long term visibility for a team in direction of the project.  The long term visibility into the expected functionality of the project is provided in the product backlog in most of the cases. In order to promote a constant understanding of the project a near, mid and long term goal has to be adopted.

7.   The Essentials.

A supporting essential infrastructure is required for a high quality product to be delivered. As a team plans to work to finish each Sprint, they have to maintain the required infrastructure and practices for product development

 This includes a solid build and a test frame work, creating and automatically executing unit tests, validating ongoing daily or continuous builds and developing the guidelines that need to be followed by the team

This reduces risk, validates the quality of the product and also enhances the productivity of the team. 

The maintenance of an essential infrastructure should start from the first Sprint and continue for the duration of product development.

8.   Supervise the Architecture.

The principle of SCRUM is that the requirements, planning and design emerge throughout the project.  However without supervising the project a company can end up with two undesirable results.

One a team can over engineer in a particular Sprint building up an infrastructure and system that’s never required,

Two a team can spend very little time designing a Sprint and later realise the fundamentals are too weak to support the objective of the project. 

It’s essential that while adopting scrum a company has to ensure that couple of indivuials from the team guide the architecture of the product as it is developed.

9. Multiple aspects of a product.

While adopting scrum one common mistake that a company usually commits is, designing a product solely based on the end user value they provide.  This doesn’t provide a complete perspective of all the work necessary to release a product that will meet the end user’s requirements and comply with all the company constraints.

To make sure the product does both the below three aspects are recommended.

1. The customer value has to be defined.  This should include the functionality, non functionality requirements such as how scalable, robust and fast it has to be.
2.  The technical value of building a new infrastructure for software development has to be defined.
3. The business value for the entire product development has to be defined.

10. In the end, purpose of adopting Scrum.

When a company is thinking about deploying a customized version of Scrum, the methodology will not meet the requirements in the first Sprint of the project.  It’s necessary that the company deploys short Sprints in the starting of the project and learn from the experience and make necessary changes where ever required.

Few common areas that need to be refined during adoption of scrum is

1. Change in the definition of done once the Sprint is over.
2. Modifications in how a team works during the Sprint
3. The team composition has to change
4. Scrum Methodology supported by additional software development. Processes and practices.
5. Constant refinements to balance between change and long term visibility.

Common mistakes during Retrospective Sprint Meetings

Scrum relies upon continuous improvement and adaptation. In a Scrum project, the Retrospect Sprint Meeting is an important element of inspect and adapt Scrum framework. It is the final step of a sprint. All Scrum Team members attend the meeting, which is facilitated or moderated by the Scrum Master. It is recommended, but not required for the Product Owner to attend.

Retrospect Sprint Meeting provides an opportunity to identify best practices, process improvements, and bottlenecks. However, in many cases, teams fail to make complete use of this. During the meeting, Team members identify the things that went well and document the items for future action. However, more often than not, these are forgotten and the team continues to work on the tasks related to next Sprint. Let us learn about some of the common mistakes.

Lack of participation from team members.It is usually not mandatory for the Product Owner to attend the meeting. Presence of Product Owner definitely helps the team in identifying improvement opportunities. If the product owner prefers to attend, he/she should not try to dictate or advocate agenda of these discussions. Some of the improvements might be related to Product owner. In this scenario, team members might prefer not to voice to their opinion.

Pointing fingers at others for mistakes made.It would be a waste of effort and time to figure out the people responsible for the mistake. This should be avoided primarily for two reasons. Firstly, this would not help in finding the solution for the problem and secondly, this would impact the team moral, which can be counter-productive. Team members should focus on

Improper documentation of actionable improvements.Agreed Actionable Improvements are the primary output of the Retrospect Sprint Meeting. They are the list of actionable items that the team has come up with to address problems and improve processes in order to enhance their performance in future Sprints. These actionable items need to be properly documented and each action items needs to be assigned to an appropriate team member. These should also record these in Retrospect Sprint Log. The collection of all Retrospective Sprint Logs becomes the project diary and details project successes, issues, problems, and resolutions. The logs are public documents available to anyone in the organization.

Unfinished action items.Once the Agreed Actionable Improvements have been elaborated and refined, action items to implement the improvements may be considered by the Scrum Team. Each action item needs to have a defined due date for completion. Usually, teams prefer to work on the tasks related to Sprint and neglect the action items discussed during the Retrospect Sprint Meeting. Team members need to be reminded of the action items during the sprint and must be finished before the end of the sprint.

Every organization is different and might face few more issues not discussed in the article. As always, you can make use of these suggestions as per your organization needs.

Scrum teething problems: Trust Deficit

Scrum projects, especially in the early Sprints, reveal hidden problems and issues within the Scrum team. Imagine a Scrum Master on her first Scrum project just days after obtaining her Scrum Master Certification. All team members seem to be interested in her words of advice and are attending all the meetings she asks them to. One of the retrospective meetingsappears to be running effortlessly when unexpectedly a senior developer complains abouttest engineers who would not trust the rest of the team members to provide adequate testing. He claims thatmore than two thirds of the User stories are therefore in the final stages of testing .The Test engineersretort that no one other than them is qualified to do proper testing and complain that Scrum ignores testing. Our Scrum Master sees this as a technical issue: testing needs to be automated to reduce the workload of testers. She even organizes the Scrum training adapted specifically for test engineers. As a result, the Scrum team seems to buy ininto cross-functional teams and the need of automation.

Though the surface problemmay have been solved, the actual issue is lack of trust. What her Scrum master training has not taught her is that when test engineers do not trust the rest of the team; maybethe reverse is also true. Team members are not honest and are afraid to talk about their mistakes and weaknesses. Consequently, the team engages in closed debates and resorts to indirect deliberations and shielded remarks. Eventually the problems bubble out of control, causing far bigger issues.In most organizations, before Scrum implementation,teams usually appear to be working smoothly while hiding their true anxieties from each other. A team that does not debateandengage in healthy conflict also lacks commitment.  Since team members are not expressing their views in open dialogue, they seldom commit to a resolution, although they may show agreement. Unfortunately, it startsa bigger problem: evasion of accountability. This allows the bullies to bulldoze their way through and leads to dissent and team members become more interested in their own results than in the project. When team members are uncommitted toand uninvolved in a well understood roadmap, they fail to confrontfellow team members on activities and behaviors that are counterproductive to the project.

Before confronting team members and their lack of Trust, a Scrum master has to first ask self: AmI willing to be vulnerable?Lack of trust is usually caused by reluctance to be weak. When Scrum Masters fight the urge to constantly advertise how awesome they are and behave honestly, the team sees a leader they can relate to. Then Scrum Master can talk to the members and they will listen as a wholeteam. Next, a Scrum master can try group exercises where everyone shares details they otherwise would not. E.g.what was your worstmoment in high-school? Scrum masters can also try to get the team together outside the normal work environment for this exercise.They should setobjectives for the wholeteam and verify every team member is driven to achieve these objectives. There can bebehavioralgoals and individual objectives aligned with those team objectives. Making some of these changes may be a battle; Scrum masters may have to enlist senior management support to win. It’s the best way to avoid Trust deficit and the resulting breakdown in behavior.