Scrum Master and Agile Product Development

This article looks to introduce the Scrum Master role within an Agile Product Development environment. The article starts with an introduction into the history of Agile and discusses why use Agile?

The Agile Fundamentals

A 59 Seconds Agile Video Animation

The Agile Manifesto with 59 Seconds Agile

The History of Agile For Scrum Masters

A 59 Seconds Agile Article

Prior to the 1990’s software development was very slow, often taking years to complete development and release the product to market. The industry was following a very formal Management approach for products and software development, with a lot of documentation, procedures, and approvals. There was no space for changes throughout the way, there was no time for it, which means no time to adapt when needed. Although the development was very slow, the business needs were not. The business was changing really fast but the development couldn’t follow its velocity, which resulted in many projects being canceled, products coming to market with outdated technology. Within this scenario, some people started thinking in a different way of developing products to be faster and in accordance with the business needs: that’s when Agile was conceived.

Scrum Master: Why Agile?

While Agile is sometimes thought of as a software development project management approach, it isn’t just for these types of technology-centric companies. Instead, most business organizations can benefit from using Agile as well. Scrum Masters working in non-technology sectors of business can still benefit from getting companies to switch to Agile.

Scrum Master: Responding to Change in Agile Product Development

Agile is great for companies that want to respond quickly and efficiently to opportunities, threats, and events that affect their company. With the landscape of business ever-changing, remaining flexible and responding efficiently to events can keep a company competitive. Since teams work collaboratively and make decisions quickly, utilizing an agile approach to business can be very effective in staying ahead of the competition.

59 Seconds Agile - The History of Agile — 59 Seconds Agile – The History of Agile

Difference between Agile and Waterfall

Waterfall is a heavy, hierarchical approach that emphasizes procedures and documentation along with the software lifecycle. When a software is developed through Waterfall it’s going to follow basically six stages:

Requirements: the team will gather all the requirements for the software to be produced through meetings and interviews with stakeholders, including the customer.

Design: this stage is when the software is going to be designed, to translate the requirements into wireframes and user interfaces.

Implementation: phase to create the code to put into effect the software designed. This code is the essence of the software development, that is what gives ‘life’ to the software.

Testing: time to test the code created to make sure that everything works accordingly to the requirements and design.

Deployment: now the software is completed and tested and it can be placed on the market to be used.

Maintenance: the last stage is to fix and correct possible errors found down the road as well as to make improvements where needed.

In summary, Waterfall believes that each phase of the software development needs to be completed before the next phase can start, to deliver the whole product at once at the hand of ensuring that everything is well documented and approved by the stakeholders.

Now, Agile has some contrasts to Waterfall but also some similarities: it believes that is more important to produce small portions of the software and deliver it constantly, making room for changes throughout the way. It emphasizes people over processes, it gives the development team the autonomy needed so they can work according to their time estimation and knowledge.

…..

Prev <— Continue Reading —> Next

User Stories Applied

A 59 Seconds Agile Book Review

User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.