MGMT 651 Week 2 DB Forum 2 Example

Discussion Board Forum 2: Thread and Two Replies

MGMT 651 Agile Project Management, Discussion Board Forum 2 (thread and two replies)

Thread by [Student Name]

The prompt, the device startup and the classmates' posts are composites standing in for the course's own forum; Gido and colleagues' textbook, the Scrum Guide, the published studies and Scripture are real; the requirements follow Liberty's public course guide for MGMT 651.

Thread

Our startup has twelve people building a pendant that detects falls among older adults living alone and calls for help. Our first plan was sequential: three months to design the hardware, two to write the detection algorithm, two to build prototypes and one to test them with older adults. When we finally ran lab trials with volunteers falling onto mats arranged as rugs, chairs and bathroom floors, the algorithm caught only 52 percent of falls and raised false alarms when wearers sat down quickly. Seven months of work had produced a device we could not sell, and we learned it in month eight. Our investors asked a fair question: why had no one tested the algorithm on real falls in month two?

The problem was that we had treated discovery work as if it were defined work. A defined process, like assembling the pendant once its design is final, produces predictable results from known inputs. Detecting falls is different: no one could know in advance how real people's movements would look to our sensors. Takeuchi and Nonaka (1986), describing how leading companies developed new products, compared their approach to a rugby scrum, with overlapping phases and a team that moves forward together, rather than a relay in which each phase hands off to the next. Our relay had passed the algorithm to testing far too late.

We moved to two-week Scrum sprints, and every sprint now ends with fall trials and a review with a geriatric physical therapist who advises us. The Scrum Guide describes Scrum as founded on empiricism, with three pillars: transparency, inspection and adaptation (Schwaber & Sutherland, 2020). Each sprint makes our detection rate visible, inspects it against new kinds of falls, and adapts the algorithm. After six sprints, the detection rate reached 91 percent with far fewer false alarms. Moe et al. (2010), in a case study of a Scrum team, found that self-management suffered when members worked as specialists in separate areas, which weakened the shared commitment Scrum relies on. We saw the same risk: our firmware and data science specialists at first worked in parallel, and we improved only after pairing them on each sprint's fall scenarios. Gido et al. (2018) describe the project life cycle as moving from initiation through planning and execution to closing, and Scrum keeps that life cycle at the level of the release while repeating a small cycle every two weeks.

A proverb ties lasting plans to the advice gathered before acting (English Standard Version Bible, 2001/2016, Proverbs 20:18). Empirical process control is a disciplined way of seeking counsel, from data and from the people the work is meant to serve, every two weeks instead of once at the end.

Classmates: what part of your current project behaves like a defined process, and what part only reveals itself as you go?

Reply to Brenda

Brenda, your thread compared the daily safety huddles on your hospital unit to Scrum's daily stand-up, and the comparison is a good one. Both are short, regular and focused on what is blocking the work today, and both depend on people speaking up about problems early.

I would add one distinction. The Scrum Guide describes the daily scrum as an inspection of progress toward a specific sprint goal, followed by adaptation of the plan for the next day (Schwaber & Sutherland, 2020). Your huddles inspect safety conditions, which is valuable, but your unit's improvement projects may not have a sprint goal for the huddle to inspect. Takeuchi and Nonaka (1986) emphasized that teams in their rugby approach shared a clear, challenging goal set by management while working out the means themselves.

A sprint goal also changes what the huddle is for: instead of reporting conditions, the team would be checking progress against a promise it made to itself two weeks earlier. Your unit's falls reduction project could be a natural test: a two-week goal, such as having every high-risk patient's bed alarm checked at each shift change, would give the huddle something specific to inspect and the team a reason to adapt the plan. Would your nurse manager be open to setting two-week goals for that project?

Reply to Kevin

Kevin, your thread argued that your plant should run its packaging line with Scrum, holding sprint reviews every two weeks. I admire the energy behind the idea, and your line's quality problems, nearly two percent of cartons relabeled by hand, sound frustrating.

I wonder whether the packaging line itself is a defined process. It turns known inputs into the same output thousands of times a day, which is the kind of work a fixed, standardized procedure suits. Gido et al. (2018) distinguish projects, which are temporary efforts with unique outcomes, from ongoing operations, and Scrum was built for projects whose details only emerge as the work proceeds. Where agile may fit is in your improvement project to reduce mislabeled cartons: the causes are not yet known, so short cycles of trying a fix, measuring and adapting would make sense there. Conforto et al. (2014) reported that firms beyond the software world tend to blend agile practices with their existing methods, and your plant sounds like a candidate for exactly that blend.

Standard work on the line would then give the improvement team a stable baseline to measure each sprint's change against, which is exactly what empirical control needs. Could your team run the mislabeling project in sprints while leaving the line's standard work as it is?

References

Conforto, E. C., Salum, F., Amaral, D. C., da Silva, S. L., & de Almeida, L. F. M. (2014). Can agile project management be adopted by industries other than software development? Project Management Journal, 45(3), 21-34. https://doi.org/10.1002/pmj.21410

English Standard Version Bible. (2016). Crossway. (Original work published 2001)

Gido, J., Clements, J., & Baker, R. (2018). Successful project management (7th ed.). Cengage Learning.

Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology, 52(5), 480-491. https://doi.org/10.1016/j.infsof.2009.11.004

Schwaber, K., & Sutherland, J. (2020). The Scrum guide: The definitive guide to Scrum: The rules of the game. https://scrumguides.org/

Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business Review, 64(1), 137-146.