Tools: Fitness, Selinium, Cucumber
- Improve quality and responsiveness in the face of changing requirements.
- Tired of failed development efforts.
- Tracking percentage complete.
- Lots of bugs, latency, horrible UAT.
- Over-communicate with the full team involved.
- Daily, everyones always up to date.
- Strive to achieve the minimum viable product to be successful.
- Don't want all requirements up-front.
- Continually make our process better.
- Continuous integration, making sure our builds are always successful.
- Become aware of problems as soon as possible.
- Say what needs to be said; fix what needs to be fixed.
- It's ok to be wrong, transparency is key.
- Don't hide from problems/isses, they always catch up to you.
- Analogy of a family, we can disagree but be respectful.
- People write software (for now) and humans have needs.
- We should all feel sucessful and adequate.
- Technical Success != Business Success
- Are we meeting business goals?
- Don't waste client's money/time.
- Stive for win-win i.e. solid prioritization and proper documentation.
- Don't put unecessary burdens on maintainence team.
- Relentless refactoring
- Automated testing
- Tie it all together with continuous integration
- Multiple skillsets on your team. Take advantage of everyone's unique ability.
- Continual flow through iterations.
- As opposed to waterfall-like rigid steps.
- Turn problems into opportunities.
- Build always broken? Automate the build and testing.
- Pair programming can catch defects.
- CI servers running test suites.
- SQ teams work along-side devs as they complete their stories.
- Goal is to show customers as it's completed. What's done is truly done and tested.
- It's ok to fail as long as you fix it and improve.
- Not ok to fail continuously.
- More important than speed, never sacrifice.
- Push quality to it's limits.
- Don't make huge changes at once. Build iteratively and test frequently.
- TDD helps make calculated changes.
- Checkin multiple times per day if possible.
- Team signs up for work as a whole and estimates responsibly.
- Team is responsible for delivering on-time.
- All team diciplines
- Iteration Manager
- Co-Locate team if possible. Communication inherantly suffers when team is geographically seperate.
- Information should be accessible.
- Anyone can come in the room and know exactly where you're at.
- Walls should tell the story, keeps us transparent/accountable.
- Burndown Charts!
- Srive for forty-hour work weeks. Overtime introduces technical debt and hurts quality.
- Some overtime is ok, but be careful.
- Two team members actively coding together, should play off of each other's ideas well.
- Task-oriented development.
- Physical index cards can help stay business-oriented.
- Customer-driven functionality, no techy terminology.
- We're trying to live in their world, they make the decisions.
- Push ideas off to the backlog so they can incubate and develop instead of rushing into implementing bad ideas.
- Estimate in terms of story-points.
- Use historical data and obtain an good measure of average velocity.
- Keeps realistic expectations and allows you to guage progress well.
- Provided for every story, minimizes assumption.
- Keeps full team on the same page.
- Business defines the release dates.
- Always hit the dates, but functionality is variable.
- Business prioritizes stories for each iteration.
- They are essentially making the decisions on what features are implemented first.
- First day of iterations. Review what stories are being played.
- Review acceptance criteria.
- Team needs slack time.
- Allows time to clean up the process and experiment.
- New technologies NEED to be played with.
- All unit tests/functional tests are run in the build.
- The more automation the better.
- Optimally, anything that builds should be shippable.
- Write the tests before you write the code.
- Gives you the confidence to make changes.
- NEVER check-in broken or non-tested code.
- Design evolves with the application.
- Designing up front accomplishes nothing.
- At least once-daily deployments.
- It means nothing if your code runs locally but not in production.
- Don't do it all at once.
- First decide on your team values. Select a few primary practices to follow.
- Collaborate with the customer.
- Warning, not doing enough can actually hurt your current process (take it or leave it).
- Under communicate, stay in our silos where we're comfortable.
- Not buildling till we know everything.
- Constantly over-committing