First Sprint, Lasting Lessons
Agile processes can offer rewarding advantages to traditional software development, but they take time to adopt properly. New teams will likely encounter conflicts and confusion during their first sprint retrospective. Here are five lessons learned that can help your next sprint avoid some common pitfalls.
Adopting Agile processes takes time. When new teams start implementing Agile techniques, they will experience common stumbles and challenges. I’ve seen formerly waterfall teams try to apply classic waterfall design to sprint execution and developers still expecting to see a complete and signed off business requirements document.
Agile is a refreshing shift from traditional software development yet new teams will experience similar lessons learned during their first sprint retrospective. Below are a few common Agile process lessons learned that you can apply to your next sprint.
1. Each sprint should produce a product increment that stands alone
When one team executed their first sprint, their initial approach was to design all the screens in Sprint 1, develop the screens in Sprint 2 and the build the database connectivity in Sprint 3. After Sprint 1, the team had a few wireframes and after Sprint 2, the screens provided a functional flow although no data was committed to the database. When the team started Sprint 3, it was awkward aligning database
Please log in or sign up below to read the rest of the article.