D359 is HRM 3570 Agile HR in the WGU catalog, 3 competency units, and the catalog describes it as agile and design thinking approaches that make the HR function flexible and responsive to change. It is the most method driven course in the HR sequence: the content is a set of working practices, and the assessments generally want you to apply them to an HR problem rather than to explain what they are. Knowing the vocabulary is table stakes here, not the deliverable.
Agile is a method here, not an attitude
The most expensive misreading of this course is treating agile as a synonym for fast, flexible or open minded. Written that way, a submission produces paragraphs about being responsive and scores nothing, because the aspects are looking for the machinery.
The machinery is small and learnable. Work is broken into increments that produce something usable. Increments run on a fixed cadence. Each increment starts with a decision about what will be delivered and ends with a look at what actually happened. Priorities live in one ordered list rather than in several competing plans. The people doing the work decide how to do it. And progress is judged by what is delivered and used, not by activity.
Design thinking sits alongside that as the front end: understanding the employee's experience of a process before redesigning it, defining the problem from what you learned, generating options, building a rough version and testing it with real users. In an HR context, users means employees and managers, and testing means trying a draft process with a small group before rolling it out.
Put those together and the deliverables in this course stop being mysterious. You are usually being asked to take a slow, annual, one shot HR process and re express it as an iterative one that ships something small, learns from it and improves. That is the whole game.
WGU records the outcome as Competent or Not Competent, with no letter grades and no ordinary grade point average, and performance assessment work can be revised and resubmitted without any penalty attached to the result. There is a pleasing symmetry here: the course teaches you to ship an increment and learn from feedback, and the assessment model lets you do exactly that with your own submission.
Turning scored aspects into iterations of your own draft
If your course is assessed by a performance assessment, the aspects your evaluator scores are your backlog. Order them, size them, and write in passes rather than trying to produce a finished document in one run.
Here is the budget arithmetic with a twist that suits the subject. Suppose the rubric shows seven scored aspects and you are targeting about 2,100 words. Subtract 200 for the scenario and 100 for the close, leaving 1,800 across seven aspects, or roughly 257 words each. Now split the writing into two passes rather than one. In pass one, give every aspect its heading and about 120 words of content, which gets you a complete but thin document in a single evening. In pass two, spend the remaining 137 words per aspect where the first pass exposed weakness.
That approach is worth the extra structure because the alternative is what actually happens to most students: three polished aspects, four empty ones, and a deadline. A thin complete draft can be finished. A partial excellent draft cannot.
A structure for an agile HR deliverable
The common deliverable is a proposal to redesign an HR process using agile and design thinking methods, addressed to an HR leader. The layout below shows the method rather than describing it.
| Section | What it demonstrates | Artefact it can carry | Weak version |
|---|---|---|---|
| Current process | How the process runs today and where it hurts | Process map with cycle times | A complaint with no timings |
| Empathy work | What employees and managers experience | Interview themes or a journey map | Assumed needs presented as findings |
| Problem definition | The redesign question in one sentence | A defined problem statement | A problem so broad no increment could address it |
| Prioritised backlog | What gets built, in what order, and why | Ordered list with a stated prioritisation basis | A list with no ordering logic |
| Iteration plan | Cadence, scope per increment, definition of done | Two or three iterations laid out | A schedule that is a waterfall plan in new words |
| Roles and ceremonies | Who decides priority, who does the work, what meetings exist and why | Roles table | Ceremonies listed with no purpose attached |
| Feedback loop | How each increment gets tested and what happens to what you learn | Review cadence and measures | Feedback collected with no route into the next iteration |
| Change management | What resistance is likely and how it is handled | Stakeholder plan | Assuming everyone will welcome the new method |
Evidence craft when the subject is a method
Method subjects attract two weak sourcing habits: citing whichever framework website appeared first, and citing nothing at all because the ideas feel like common sense. Both cost aspects.
Anchor the method claims in published work. The founding agile literature and the established design thinking texts are citable, and citing the original rather than a summary demonstrates that you read past the poster. Peer reviewed research in operations, information systems and organizational change gives you evidence about when iterative methods outperform planned ones and when they do not, which is what lets you write a balanced justification rather than an advertisement. Professional HR bodies publish case material on applying these methods inside HR functions specifically, which is the closest evidence to what your prompt is asking about.
Be honest about the limits. Iterative methods work poorly where the requirement is fixed by law, where the process must be identical for every employee for fairness reasons, or where a partial release would create risk. Naming one such boundary in your proposal is often worth an aspect, because it shows judgement rather than enthusiasm, and enthusiasm is what most drafts in this course are made of.
What earns Competent, and what comes back
Passing proposals are concrete. There is a cadence with a number of weeks attached. There is a first increment small enough to be delivered inside it. There is a definition of what done means for that increment, and a way of finding out whether it helped. A reader can see the first three weeks of work.
Returns cluster in three places. Vocabulary without machinery, meaning a document that names the ceremonies and never says what would actually be built. A plan that is sequential work relabelled, where iteration one is analysis, iteration two is design and iteration three is rollout, which delivers nothing usable until the end. And an absent feedback loop, where user testing is mentioned but nothing describes what happens to the results.
Six mistakes that cost time in D359
Defining terms instead of applying them. A glossary paragraph is not an application aspect, and it is where a lot of word count quietly dies.
Iterations that deliver nothing. If nobody can use the output of increment one, it is a phase, not an iteration.
Skipping the empathy stage. Design thinking starts with what employees actually experience, and a redesign built on assumption loses the aspect that asked for user input.
Backlogs with no priority basis. Say what ordered the list: value, risk, effort, dependency. An unordered list cannot be justified.
Ignoring where the method does not fit. Compliance driven processes have hard constraints, and acknowledging them strengthens the proposal.
Leaving out measurement. Cycle time, satisfaction, adoption. Without a measure, no iteration can be reviewed and the loop is decorative.
Where our help starts and stops
We work on the written deliverable: mapping the rubric to sections, planning the passes, drafting a model proposal with its artefacts so you can study the structure and rewrite it in your own voice, and reading a returned evaluation to name the edits that will clear it. If D359 carries an objective assessment on your plan, that exam is proctored and our role is preparation only, meaning a study plan, practice questions and an honest readiness call. We are never present during an assessment, never take one for a student, and never ask for or handle WGU portal credentials.
Redesigning a process for D359?
Send the scenario, the task instructions and the rubric. We come back with the backlog, the iteration plan shape and a straight read on whether your increments actually deliver anything.
Three questions students ask about D359
Do I need software development experience for Agile HR?
What counts as an increment in an HR context?
Should I use a specific agile framework by name?
Where D359 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.