Agile Consultant Task, OR
The Final Paper, Transformed
This is one of two possible non-team individual tasks you can do to demonstrate non-trivial agile development skills, for an increased grade. Each team member should choose either this task or the application testing task.
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 may focus on one issue, the real issue may be deeper. E.g., if someone says "how can I get teams to be on time for meetings?" the real question may be why are there so many meetings? You can't ignore what the requester asks, but it may be the wrong question.
- Read the cases on Canvas in the Agile Consultant module.
- Analyse the underlying issues in one case and come up with a key recommendation that an agile expert would come up with.
- 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 a response.
- When you get the response, address any issues raised, and resubmit.
You will be told when you're done and what case to focus on next.
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 well 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.