Agile Discussions, OR
The Final Paper, Transformed
Are you agile? Do you know how to identify and apply agile ideas appropriately to a range of project situations?
Being agile means delivering value in small slices early and often. Learning requires doing, failing, re-doing, until you achieve mastery. These two principles change everything.
Case in point: The final paper. What a terrible idea! One big deliverable, no intermediate feedback, no chance to iterate, no chance to learn.
Instead in this course you show what you've learned the way you would in real life: by helping people solve their development problems, in an iterative conversation.
Your Task
You will be presented with several requests for advice from developer or managers of different projects. Though a request will focus on one issue, these project have a number of challenges and potential pitfalls, just like real life. Some of the most important issues are below the surface. Don't ignore what the requester asks, but it may be the wrong question.
- Read the cases. They are on Canvas in the Agile Consultant module.
- Analyse the underlying issues and come up with one or more recommendations that an agile expert would come up with.
- See below for advice on advice.
- Use the Agile Consultant link on Canvas to get the form for selecting and submitting your advice for a case (exercise)
- Submit and wait for responses.
- When you get the responses, address them and resubmit.
You can only submit one piece of advice at a time per exercise, but you can do more than one case at the same time.
You should generate two different good pieces of advice, one
piece of advice at a time. Start with your most important advice. When you get
a Got it! Thanks!, go to your second piece of advice. When the case is
marked Done, you're done with that case.
Advice on Advice
You're going to get very brief responses from the advisee. The Responses Explained page explains why they might occur. To avoid getting these
- Focus on what you think is the most important problem
- Give just one major piece of advice, not a laundry list
- Talk to the requester, not me! Say "I think you should ..." not "they should ..."
- Ask questions when uncertain, but explain how the answer will affect your advice, e.g., "Your team might be feeling ... in which case .... But if not then maybe ..." Careful! Don't ramble.
- Give just one initial piece of advice. Focus on the most important problem you see.
- Address your advice to the requester.
Common Mistakes
You need to give brief, relevant, actionable, supported advice. Address your advice to the requester. Write it the way you would in a StackOverflow post. Don't write a mini-paper.
Good advice is short, maybe a short paragraph or two, adapted to the context, and supported with evidence, e.g., specific personal experiences, or summary of a relevant case described elsewhere, with a link or book and page citation.
Almost no one does this at the start. Expect many resubmissions. Here are some of the most common mistakes:
- Not talking to the advisee. Don't tell me what "they" should do. Talk directly to the person asking for help.
- Calling a situation a problem. A new team, a lot of requirements, sensitive data -- these are not risks or problems. These are just the facts of the case. What you need to focus on is some important risk that follows from these facts.
- Not saying why the risk applies here. Connect the dots. What connects the facts in this case, explicit or implicit but very likely, to the risk you want to address? No one wants to buy insurance if they don't think they're at risk. Don't force it. If you can't justify it, maybe it's not a real risk here.
- Lecturing! Be brief. Agile is about small slices of value. No one listens to long-winded lectures. All a lecture shows is that you weren't listening to what someone asked.
- Impractical advice. Don't offer solutions a team can't do or a client wouldn't accept. Agile is about lightweight appropriate actions. Don't suggest a cure worse than the disease.
- Generic advice. Don't give "one size fits all" quotes from The Agile Samurai, my slides or elsewhere. Agile is about adapting principles and a variety of techniques to each situation.
- Aspirational, not operational, advice. "Make sure you have a clear vision" is a goal, not an action.
- No support. Avoid unsupported claims. Agile is about data-driven change. Back up your advice with a personal experience, a case you've read, and/or a focused well-reasoned published description from an respected agile source.
- Generic experience! No one remembers a story like "I was on a project and user testing helped our client figure out what to build." People remember and learn from stories with details, like "When we were developing a digital make-your-own flipbook app for a client, the client assumed the end users would be kids aged between 5-10. But early user tests showed that adults enjoyed using the app more so they re-designed some of the look and feel."
- Encyclopedic reference. Don't just say "there's great advice on new projects at ..." That's useless. Give the relevant point, then point to the specific place where it can be found. If it's a book, give the page, not a whole chapter.