Each strategic project is a set of related user stories – Liz Rice, MindTheProduct
The lively discussion continues around exactly how strategic is Agile if you constantly run short Sprints. Doesn’t it take longer to be strategic?
Actually no…The two concepts (Agile & Strategic) are not mutually exclusive! I read a very interesting article this weekend by Liz Rice who outlines exactly HOW to do this. She’s keen on being realistic and keeping on track.
Liz advocates using a roadmap and planning to prioritize User Stories needed to build the MVP, keeping in mind that it is best to not bog down in details. Plan for the predictable things and get buy-in from your development teams. We all know priorties can and will change, that’s what Agile does so well. Don’t sweat the small stuff but remember if you don’t consciously integrate critical MVP “must have” features into the Quarterly Plan you’ll be forever dealing only with short-term and “urgent” requests.
And that’s no way to develop world class software.
The main thing
is keeping the main thing
the main thing
A product launch begins when *everyone* involved can say what truly makes your product outstanding and awesome.
No, that’s not a typo.
I didn’t mean “product launch ends” – because if you begin developing product without clarity on this, no telling when you’ll launch. Or what will launch. Or who you should be launching to…
Great blog post from Knowledge BLOG: “What’s wrong with the project approach to software development?” It got me thinking and comparing project management vs. Agile practices.
Projects are work defined as activities and tasks. There’s a start and an identified end.
OK – but factor in complexity, time to do it, size of the team and available (estimated) budget and the wheels come off.
- Project stalls or overruns.
- Agile methods fix this (Strategy Meeting).
ProjMgt Best Practice
Do not begin a project until all goals are well defined and agreed upon. Seriously, who has a crystal ball to share? Let’s break this thing up.
- Success measures, length of time for “agreed upon?” – further out, the less agreement.
- Agile methods fix this (Release Planning, Iteration Planning, Iteration Review).
In a recent straw poll, 40% of product professionals selected “Managing scope /requirements change” as the most important topic for their career. Seems serious…
- Agile methods fix this (Iteration Review, Daily Stand-up, Continuous Adaptive Planning).
Managing Expectations Both Sides of the Aisle
Clear communication between development teams and the business suits (I’m a suit), big #FAIL!
- Mention: Culture clash between “stakeholders’ involvement” and “productive collaboration to build product.”
- Agile methods fix this (Product Owner, Scrum Team).
Continuity, Lessons Learned
Projects are temporary in nature. Teams who work projects are assigned and then reassigned as the projects live/die.
- What about continuity, flow, innovation? I think missing. You lose what you’ve learned.
- Agile methods fix this (Scrum Team, Retrospective Meeting).
Knock It Out
“Why are the honest endeavours of software developers often so disconnected from the delivery of customer and stakeholder value?” – pg_rule, Knowledge BLOG, January 11, 2011.
I think it’s about covered – using any Agile method provides the foundation for collaboration between product visionaries (sometimes suits), development teams and stakeholders to build products that customers want and buy.