Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wordpress-seo domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/garryhan/public_html/59secondsagile.com/wp-includes/functions.php on line 6114
Agile Product Manifesto - Part 2 - 59 Seconds Agile

Agile Product Manifesto – Part 2

What is the Agile Product Manifesto and how does it help the development team in delivering value to the customers?

The Agile Manifesto

A 59 Seconds Agile Video Animation
The Agile Manifesto with 59 Seconds Agile

The Agile Product Manifesto for Developers – Part 2

A 59 Seconds Agile Article

Agile Product Manifesto: Customer Collaboration

Software development has traditionally been a 1-way street. Customers tell a company what they want, and the developers create it. There can be some initial negotiation on the contract, but once both parties agree, the conditions are mostly static.

The problem with following a contract in traditional development is very similar to following specifications. Both the customer and the development team figure out more about a project as time goes on. Customers might not realize what they really wanted until the contract has been finished or development is in its advanced stages. By this point, changes to the contract are not possible. Everyone is stuck with what the contract said, even if it isn’t applicable anymore.

Instead of making a contract at the very beginning, Agile software development gets customer feedback through the entire process. The Scrum team and stakeholders work toward the end product together. This gives customers more control over the project and allows them to give input about what they do or do not like. It also gives developers a better idea of what they are creating. Instead of sticking to a contract that gives few behavioural details, developers can ask stakeholders about feature details. This gives them better information to work with while creating a product that stakeholders will be happier with.

Agile Product Manifesto: Responding to Change

Any project has a plan, but different management styles allow a plan to be more or less tentative. Some management styles require a team to follow the plan to the letter. Any deviation is unacceptable. Other styles use a plan only as a suggestion and adapt to the situation as necessary.

Traditional development is known for following a very strict plan. With the contract drafted at the beginning of the process, everything is mostly set in stone. This puts a number of limitations on the developers. Since deviation from the plan is considered bad, there are fewer ways to deal with problems that might come up. Because of this, setbacks can be very punishing. If developers come to a problem without a clear fix, the release date can be pushed back much further than anticipated.

Agile software development uses a less rigid approach to plans. These reactionary methods allow developers the space to fix problems in their own way. Teams can work together to come up with a fix that solves the problem, while still giving stakeholders what they want. The inspect and adapt process around sprints allows the Scrum team to look at what may have gone badly, and do things better the next time a problem comes up. If one solution doesn’t work, there are numerous others that they can use.

While the Agile Manifesto is not a long document, it has huge value for development teams. The four simple priorities give the Scrum team better control and more options. Developers benefit specifically and work more effectively on a team that follows these practices.

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.

Prev <— Continue Reading —> Next

Learn More

Agile Project Management Training Courses

The Agile Manifesto

A 59 Seconds Agile Infographic
59 Seconds Agile - The Agile Manifesto
59 Seconds Agile – The Agile Manifesto

Prev <— Continue Reading —> Next

Our Favourite Agile Books

We found these books great for finding out more information on Agile Scrum: