Some of the items shared by Phil included talking with the customers about what they think they want may not actually be what they truly want. If the customer comes from a background of fixed-price or traditional waterfall projects, there may be problems down the line. It may be better not to promise them "A, B and C" but rather "3 months effort toward your highest priorities." Much of the problem the customer might have with this is a level of comfort and trust. Getting them to agree to or "fixed budget, not fixed bid" can be somewhat of a Jedi mind trick, per Phil, but keep in mind that they still see and believe in the "illusion of predictability."
The stakeholders and executives don't understand nor should be expected to on Day 1. The ScrumMaster should coach and educate them, but that takes time. In the beginning, Phil recommended "taking the customer's temperature" often and hand-holding as often as needed. If they are steeped in classic waterfall and Gantt charts, it might be helpful to create project management plan documentation (how and why the project will be run and what the checkpoints are) to help educate and address their concerns and felt needs. Remember that, although people trump process, politics trumps people.
The importance of a strong Product Owner came up several times, and many agreed that many issues come out of any gap with this role filled well. If possible, recommended your ideal candidate for the role. Regardless of who the Product Owner is, be clear in what you need from them. Explicitly tell them, "Here's what I expect from you," and remind them of the aspects and importance of their role whenever it appears they are drifting in engagement or leadership. It was recommended to schedule regular meetings to walk through the backlog (separate from Sprint Planning) in order to establish a rhythm. By reviewing or scrubbing the product backlog together, you not only help the project overall, but also coach by modeling what it means to maintain and have ownership of the backlog.
Don't leave epics untouched because epics are risk in the plan. Decompose them into user stories early on. Also, address "dark matter" (general unknowns or vagueness) within the first few sprints. Prioritize by risk and architectural significance, as well as business value, so as to retire risk as soon as possible.
Please be sure to check back later for updates on the next APLN meetings and join the APLN OC group on LinkedIn.
Hi Scott,
ReplyDeleteIs it possible for you to post the slides from the "2/4/2009 Agile Architecture" presentation?
Posted - thanks. SD
ReplyDelete