Three simple facts to be accepted:
- It is impossible to gather all the requirements at the beginning of a project
- Whatever requirements you do gather are guaranteed to change
- There will always be more to do than time and money will allow
Agile Principle: regular delivery of working, tested software made up of your most important features each and every week.
- Break big problems down into smaller, simpler and more manageable milestones
- Focus on the really important stuff and forget everything else
- Make sure that what you are delivering works (lots of testing early and often)
- Constant looking for feedback
- Change course when necessary
- Become accountable (quality, schedule, budget)
If you like the visibility, have a passion for quality and a fierce desire to execute, working on an agile team can be personally very rewarding. In case the one week delivery is stressing you out, don’t worry about most agile teams start by delivering something of value every two weeks (really big teams every three).
Agile Principle: The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
In agile, the master story list is your project to-do list. It contains all the high-level features (user stories) your customer will want to see in their software.
It’s prioritised by the customer, it’s estimated by the development team, and it forms the basis of the project plan. An iteration is a 1 to 2 week period where you take your customers’ most important stories and transform them into running, tested software.
By tracking your velocity and using it as a predictor of how much you’ll get done in the future, you will keep your plans honest and your team from over-committing.
Agile Principle: Business people and developers must work together daily throughout the project.
Agile Principle: Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
The agile customer
It’s someone closely familiar with the business, who really cares what the software does, what it looks like, and how it works, and who is committed to guiding the team, answering questions, and giving feedback. He also set the priorities (from the business point of view), decides what gets built and when.
Read the full series of articles about Agile Methodology: The Basics, Who and Why, How to Deliver, User Stories, Estimation and Planning.
Read more: Jonathan Rasmusson. “The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)” Pragmatic Bookshelf
9 thoughts on “Agile Methodology The Basics”
I would like to republish your article, which seems to be an easy introduction to Agile, on PM Hut under the Agile Project Management category (I know, the category should be Agile Software Development, but I can’t change it anymore).
Please either email me or contact me through the contact us form on the PM Hut website in case you’re OK with this.
Thank you very much for the offer, this post is the first part, I am preparing few more regarding Agile Development.
Pingback: Agile Methodology Planning | Carlose Lopez | Blog
Pingback: Agile Methodology Estimation | Carlose Lopez | Blog
Pingback: Agile Methodology User Stories | Carlose Lopez | Blog
Pingback: Agile Methodology How to Deliver | Carlose Lopez | Blog
Pingback: Agile Methodology The Who and Why | Carlose Lopez | Blog
Pingback: How to move a slow project to Agile? | Carlose Lopez | Blog
Pingback: Better Performing IT Results in Better Business Value – Carlose Lopez | Blog