What are the Agile Development Principles and how do they help the development team in the delivery of continuous value to the customers?
The Agile Principles
A 59 Seconds Agile Video Animation
The Agile Principles for Developers
A 59 Seconds Agile Article
Besides the Agile Manifesto, one of the most iconic documents for Agile Software Development is the list of Agile Principles. These twelve principles offer more depth than the four basic components of the Agile Manifesto. Not only do they give more depth, but they are more specific to software development as a practice. The Agile Principles affect the entire Scrum team, but they also have a specific influence on the developer role. Developers who follow the Agile Principles are able to work more effectively in Agile environments, and better integrate with Scrum teams.
Agile Development Principles: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The entire Scrum team should obviously want to satisfy customers. However, this has specific meaning for developers on the team. The key points in this principle are early and continuous. Traditional software development does not release working software until very late in the process. Often, the first release is at the very end of the project, after everything is finished. Not only that, but the release is often one of just a few. Future versions usually only address bug fixes, and the time between these releases can be very long.
Developers in Agile software development get working software to customers as soon as possible. Once the requirements are determined, developers work on the highest priority features immediately. A release containing these features goes to customers by the end of the first sprint. The iterative nature of Agile means that customers will receive valuable software at the end of each sprint, with new features in every release.
Agile Development Principles: 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Where traditional development resists change, Agile embraces change. In a waterfall environment, customers agree to a contract at the beginning of the process. Changes to the contract are rarely accepted, and even more rarely are they actually added to the product. No matter if a customer wants to change, or if the market changes, the agreed product is set in stone.
In Agile, stakeholders are always welcome to suggest changes to the product. Since features are only developed at the last moment, changes rarely cause any significant delay or loss of work. For developers, this means less planning ahead and more working in the present. Developers cannot plan significantly into the future, as none of those features are guaranteed to make it into the product. Research can be time wasted if plans change. Instead, developers must focus all of their effort on the task at hand. Any feature in the current sprint is the top priority.
Agile Development Principles: 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Related to the early and continuous release, time is more granular in Agile than in traditional development. Where a waterfall project looks months and years, Agile looks at weeks and months. This shortened time frame keeps development fresh.
For developers, this means that there are fewer things on the back burner at any given time. Developers are actively working on current features. Planned features will begin work in later sprints. Otherwise, there is no room for tasks and features to float around in limbo. This keeps developers focused on the task at hand, and increases productivity.
Agile Development Principles: 4. Business people and developers must work together daily throughout the project.
Communication is key in any project, but especially so in software development. However, traditional development methods have communication isolated. Operational employees communicate with management. Managers communicate with customers. Customers rarely have much of a say in the process at all.
Agile software development opens up communication to all parties. With meetings like the daily stand-up, all roles in a project have representation. Developers, QA, and analysts all participate, along with the Scrum Master. The product owner serves as a representative for customers and stakeholders. This meeting happens daily, and everyone involved contributes. Therefore, everyone gets exposure to all daily operations. Better communication yields better teamwork, and creates a better product. For developers, this means having a voice in the project. Instead of doing work silently, developers can offer feedback and communicate directly with stakeholders and other roles. This communication could be during the sprint reviews for example and allows the developers to take a more active stance on the project, and how it changes in the future.
Agile Development Principles: 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Traditional development is a top-down management style and revolves around managers assigning work to operational level employees. The individuals are less important than the tasks and work. Developers and other operational employees are mostly considered interchangeable.
Agile software development allows Scrum team members to organize themselves. They select the tasks that best fit the individual’s skill set. Management takes a hands-off approach and allows the Scrum team to work within itself. These self-organizing teams allow developers to better cater to what they know. Instead of receiving assignments at random, developers can gravitate toward products and environments in which they work better.
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 Principles
A 59 Seconds Agile Infographic
Prev <— Continue Reading —> Next
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum: