Articles, Blog Posts, Books and Quotes on Agile Project Management
It’s important for people to believe that openness given can lead to openness received. This openness must extend to admitting mistakes when necessary. […] When people admit to mistakes, others in a group are more apt to do so as well. It’s always better to know about mistakes earlier than later. Being open about them has the added benefit of giving critics less ammunition.
“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?
Scrum Expert Copyright © 2009-2024 Martinig & Associates