Articles, Blog Posts, Books and Quotes on Agile Project Management
“After working for some years in the domains of large, multisite, and offshore development, we have distilled our experience and advice down to the following: Don’t’ do it.” “Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum”, Craig Larman & Bas Vodde, Addison -Wesley
This blog post is about what a great Product Owner should be like.
When introducing the concept of Scrum to an organization for the first time, I try to give a reasonably unbiased view of what to expect. I warn the new Product Owner that at first he may feel overwhelmed and struggle to articulate requirements in a clear and actionable fashion. I tell the new ScrumMaster that the innocuous duty assignment “ensure everyone follows the Scrum process” may make her wildly unpopular for a while. I also like to be clear with everyone which problems Scrum can fix and which it cannot.
The Core Protocols are our ‘best practices’ for people, teams of people and organizations that want to get great results – all the time. They are ‘Core’ because they are foundational – they can be used by all teams, anywhere, even if you already have organizational patterns and best practices of your own. They are ‘Protocols’ because they name and prescribe ways that people can interact (behavior), predictably, like the ‘protocols’ followed in diplomacy.
“Behavior change happens, but it happens slowly. It may take several tries from different angles before a team changes their stand-up behavior. Be patient. Keep trying. They will change when they need to, but only if you don’t shield them from natural consequences that follow from poor stand-ups.” Reference: “Coaching Agile Teams”, Lyssa Adkins, Addison Weisley, 315 pages, IBSN 978-0-321-63770-3
Agile values working software over comprehensive documentation – It is 1/4th of the original manifesto. That doesn’t mean don’t document! It means don’t document more than you need to document. Documentation does have value, but the practice of documenting got excessive – that’s why a reaction to the bad stuff earned a spot as one of the pillars of agile. This blog post discusses how do you avoid over-reacting when changing a culture of over-documentation?
I have observed and participated in a great number of sprint reviews. I’ve seen some quirky things from the Scrum teams as they attempt to demonstrate the working software and artifacts they have produced in the sprint.
Scrum Expert Copyright © 2009-2024 Martinig & Associates