-
Notifications
You must be signed in to change notification settings - Fork 1
Home
[DRAFT] A Guided Approach for Agile Development Teams
The purpose of the this wiki is not to recreate the many good sources of documentation on the various aspects of Agile development. Rather it is meant to answer the many questions that a new Agile Development team will have as the make the transition from doing traditional waterfall projects over to an agile approach.
Team self assessment questions
Frequently Ask Questions
Background Material
Features of this Guide
Behavioural Changes
Maturity Framework
Each feature needs to be visually and technical designed so that you can collect early feedback from users and adapt to their needs.
Features that will provide value to users are broken down into small user stories, coded, documented and reviewed in order to ensure that the team is delivering high quality working software.
Developed software is continuously integrated with the rest of the system using automated testing, static code analysis, and functional testing.
Features are deployed as soon as they are done to Production to get rapid user feedback. If the Product Owner doesn't want a feature to be made available to users, the code is still deployed to Production with the feature toggled off.
- Behavior Driven Development
- Low Fidelity Mockups for rapid user feedback and design
- Description of the Data, logical data model
- High Fidelity Mockups to clarify the Definition of Done for a feature
- Data Model Development (Spreadsheet for logical model)
- Behavior Driven Development (BDD) Scenarios, (Tests)
- Automated Code Generation
- CRUD operations for all data objects
- API to calls on the CRUD operations
- Physical Database Models
- Custom API Specification & System Functions development
- Automated Integration Tests (ensure that APIs function)
- Functional Tests
To find redundant, duplicate, or low value features of the system that based on user research should be retired.
This may result in the retirement of an entire system, however that is not the ideal situation. A system that is retired in its entirety likely had many features that could have been removed previously.
Instead try regularly adapting to users needs and frequently retire the features that users no longer value. This strategy keeps your system as focused as possible on the high value effort and will extend its life by allow teams to spend time ensuring that it stays secure and functional.
How is it done?
- Talk to real users and get their feedback
- Use website analytics to monitor the usage of product features,
- Collect and resolve bugs & defects quickly to ensure that those features continues to provide value to the users.
- Once that feature reaches a point where it is shown for various reasons to no longer provide value, then that feature can be retired.
- The retirement phase should be ongoing from the moment you build your first mock up.
A feature having lots of bugs and defects should not be the reason you retire a feature. Sometimes your features just need a little care and feeding.