background preloader

Principles behind the Agile Manifesto

Principles behind the Agile Manifesto
We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams.

http://agilemanifesto.org/principles.html

Related:  Incrémental / AgileScrum

Agile Principles and Values, by Jeff Sutherland Individuals and interactions are essential to high-performing teams. Studies of "communication saturation" during one project showed that, when no communication problems exist, teams can perform 50 times better than the industry average. To facilitate communication, agile methodologies rely on frequent inspect-and-adapt cycles. These cycles can range from every few minutes with pair programming, to every few hours with continuous integration, to every day with a daily standup meeting, to every iteration with a review and retrospective.

The Burn-Down Chart: An Effective Planning and Tracking Tool Burn-downs charts are among the most common sprint tracking mechanisms used by Agile practitioners. Though their application and usage varies (some plot a burn-down chart using story points, whereas others use task count), plotting burn-down using effort remaining is the most effective and efficient way of using burn-down charts. This article looks at creating and updating a burn-down chart using the effort-remaining approach, interpreting burn-down under different scenarios, and examining common mistakes to avoid while using burn-downs. We conclude by looking at some of the benefits of using this innovative tool. Agile Isn’t Just for Geeks Anymore Twelve years ago, 17 software developers convened in Snowbird, Utah to reimagine their craft. They recognized that traditional development methods were out of step with the times. Suddenly, building software wasn’t some arcane backwater. For many companies, it had become the strategic driver for business growth—through commercialization of software-based products or development of custom applications that enabled a proprietary business advantage.

Learning Scrum through Games While this is the session I ran in 2011 it has been replaced by: Learning Scrum Through Games – Goldilocks Iterations II. Last week at Agile Tour Toronto I had the privilege of working with my friend Paul Heidema to help introduce the basic concepts of Scrum in 60 minutes. This is a really interesting challenge, what’s the minimum amount you can teach people and still give them a taste of Scrum. In end we opted for about ~10 minutes of talking heads (spread throughout), ~30 minutes of simulation time and 15 minutes of debrief. We invited our teams to create Children’s Books of the Goldilocks story.

About Self Organizing Teams/ Posted 4/11/2016 12:05:46 PM by CLEMENTINO DE MENDONCA, Professional Scrum Trainer with Scrum.org A question from a budding Scrum Master, who is transitioning from a background as a traditional project manager: “In order to promote team bonding and self-organization, from now on I am going to try something new with the team. Agile, Top Down There’s a recent thread on the Scrum list about how an executive or highly-placed manager could get Agile going. I’ve been one of those guys, and I know a bit about Agile, and here’s how I’d proceed. First, focus management attention on cyclic delivery of running tested software. Second, provide the resources to learn how to do that. D… If You Do, D… If You Don’t. I believe, and it’s pretty well accepted in Agile circles, that you can’t impose Agile practices or methods from above with much chance of anything good happening.

Scrum Master in Under 10 Minutes! - Scrum Methodology Video In Scrum, product features are known as user stories, and they are written from the perspective of the end-user. The product backlog contains the wish list of all the user stories that would make the product great. The product owner represents the users and customers of the product and decides which user stories or items make it into the product backlog. The goal of a given release is to deliver a subset of the product backlog, known as the release backlog. After identifying which user stories will go into a particular release, the user stories become part of a release backlog, which is then prioritized by the development team, who also estimates the amount of time involved in completing each item.

Agile Project Management Handbook v2.0 In today’s ever-changing world, organisations and businesses are keen to adopt a more flexible approach to delivering projects, and want to become more agile. However, for organisations delivering projects and programmes, and where existing formal project management processes already exist, the informality of many of the agile approaches is daunting and is sometimes perceived as too risky. These project-focused organisations need a mature agile approach – agility within the concept of project delivery – Agile Project Management. Since its launch in 2010, DSDM’s Agile Project Management has proved very popular, and has enabled the adoption of Agile Project Management practice worldwide.

Related: