Agile

by

Scrum Master- A Wizard

We all know agile Scrum framework is prevailing these days. Every field is adapting scrum as it provides transparency in work and help maintaining trust among the people. With increase in the use of Scrum and Agile, one name which we all hear is a ‘Scrum Master’. When organisation think of creating a Scrum team and developing there deliveries through agile; everybody looks at Scrum Master as a wizard.

In below paragraphs, I will be discussing about the Scrum master role and its expectations. What is the perception of teams for a Scrum Master? What does a scrum master do and what a team should expect from him (not on a broader prospect).

In standard organisation, Scrum Master is the most debating and challenging role. Every person in the organisation has its own perceptive regarding it. People generally think the role is confined to five aspects of scrum i.e. scrum ceremonies. People also misinterpret the exact essence of servant leadership.

In context of above, scrum master is a change agent for cultural shift of an organisation to adapt agile mindset. He is the one who ensures agile processes are adopted in the organisation. He works towards increasing transparency and winning the trust of people; by clearing the communication channels between team member’s including product managers and stakeholders.

Scrum master is a pioneer to show the right path which lead to team’s success (not individual). He is a motivator, a transformation and influential leader who believes in empowering the teams and at the same time takes all stakeholders along to reach a common goal of agility.

Scrum master facilitates the ceremonies, and make sure that all stakeholders adhere to the process. The process is more of a discipline, where the Scrum rules (time boxing, regular cadence etc.) play very important role.

Will continue the discussion in upcoming articles with the points that a scrum master is an integral part and member of team. Scrum master works closely with team to achieve the milestones. He has to indulge and involve with people of different mindsets to remove impediments for a quality delivery. Success is achieved by following the process, clear communication, trust and coordination of the team’s.


PaisaBazaar IN CPL - Credit Card

Share this:
Share
by

Spike vs Stretch

Much awaited discussion point’s are below on Spike v/s Stretch. We sometimes get confused to take story as a stretch or a Spike. Below written will explain you the clear difference between a Spike and a Stretch story.

1. Spike:
Spike is an invention of Extreme Programming (XP), is a special type of story that is used to drive out risk and uncertainty in a user story or other project facet.
At the end of a sprint, the spike is done or not-done, just like any other story.

Spikes may be used for a number of reasons:

  • The team may not have knowledge of a new domain, and spikes may be used for basic research to familiarize the team with a new technology or domain.
  • The story may be too big to be estimated appropriately, and the team may use a spike to analyze the implied behavior, so they can split the story into estimable pieces.
  • The story may contain significant technical risk, and the team may have to do some research or prototyping to gain confidence in a technological approach that will allow them to commit the user story to some future time box.
  • The story may contain significant functional risk, in that while the intent of the story may be understood, it’s not clear how the system needs to interact with the user to achieve the benefit implied.

2. Stretch:
A stretch goal is a task or story that has been scheduled into a Sprint but that is not committed. It is considered a cherry on top, so a task that the Team hopes to get done in the sprint but isn’t absolutely sure they’ll get to.
Stretch stories are useful to help a Product Owner ensure that they have defined enough stories for the team to continue work uninterrupted during a iteration when things go well. That said, the designation of “stretch story” is only valid for the current iteration.
If the team does not complete a stretch story, that story simply becomes one of many stories available to the Product Owner to consider for inclusion in the next iteration. Since priorities can change, the Product Owner may or may not choose to include that story in the next iteration.

Share this:
Share
by

Agile – Agile and Waterfall are two distinct methods of software development

The Waterfall model can essentially be described as a linear model of software design. Like its name suggests, waterfall employs a sequential design process. Development flows sequentially from start point to end point, with several different stages: Conception, Initiation, Analysis, Design, Construction, Testing, Implementation, and Maintenance.

The Agile model proposes an incremental and iterative approach to software design. It was essentially developed in response to the limitations of Waterfall, as a way to give designers more freedom. The design process is broken into individual models that designers work on. There is no pre-determined course of action or plan with the Agile method. Rather, designers are free to respond to changes in requirements as they arise and make changes as the project progresses.

waterfall-vs-agileWaterfall challenges

Traditional Waterfall treats analysis, design, coding, and testing as discrete phases in a software project. This worked OK      when the cost of change was high. But now that it’s low it hurts us in a couple of ways.

Poor quality

waterfall-poor-qualityFirst off, when the project starts to run out of time and money, testing is the only phase left. This means good projects are forced to cut testing short and quality suffers.

Poor visibility

waterfall-poor-visibilitySecondly, because working software isn’t produced until the end of the project, you never really know where you are on a Waterfall project. That last 20% of the project always seems to take 80% of the time.

Too risky

waterfall-too-riskyThirdly you’ve got schedule risk because you never know if you are going to make it until the end.

You’ve got technical risk because you don’t actually get to test your design or architecture until late in the project.

And you’ve got product risk because don’t even know if you are building the right until it’s too late to make any changes.

Can’t handle change

waterfall-cant-handle-changeAnd finally, most importantly, it’s just not a great way for handling change.

The Agile ApproachAgile-ApproachInstead of treating these fixed stages Agilists believe these are continuous activities.

By doing them continuously:

  • Quality improves because testing starts from day one.
  • Visibility improves because you are 1/2 way through the project when you have built 1/2 the features.
  • Risk is reduced because you are getting feedback early, and
  • Customers are happy because they can make changes without paying exorbitant costs.

Making the Choice Between Agile and Waterfall

So, how do we choose? First, we change the game a little (which is what most software development organizations do) by defining our own process. It’s a variation on the traditional Waterfall methodology. This helps to improve the team’s understanding of requirements and communication with the customer.

In this way, we strive to be as iterative as possible without compromising our overall system architecture.

We consider the following factors when considering which methodology to use:

how-select-waterfall-agile

Share this:
Share