MGMT 651 Week 8 DB Forum 8 Example

Discussion Board Forum 8: Thread and Two Replies

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

Thread by [Student Name]

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

Thread

Our hospital system's marketing department has eight people who produce everything from flu shot campaigns to service line brochures and social media. Until last spring we worked from a quarterly campaign calendar set by leadership in January, April, July and October. By the third week of every quarter the calendar was out of date, because a new clinic opened, a physician joined, or a news story changed what patients needed to hear. Requests arrived by email to whoever seemed least busy, and nobody knew what anyone else was working on.

In April we tried agile. The communications director became product owner and kept a single backlog of requests, ordered by value to patients and the system. We worked in two-week sprints with a visible board, held a ten-minute stand-up each morning and showed finished work to service line leaders at a sprint review every other Thursday. Average turnaround for a campaign fell from about six weeks to two and a half, and requesters stopped sending the same email to three people. Gido et al. (2018) describe projects as temporary efforts with defined outcomes, and treating each campaign as a small project inside a sprint gave us that definition.

One part of our work did not fit. Patient stories, our most effective content, require review by clinical leaders and the legal office, and that committee meets monthly. Half of each sprint's patient story work sat waiting. Rigby et al. (2016) argue that agile works best where problems are complex, solutions are not known in advance and customer preferences change, and they caution against applying it everywhere. Our design and writing fit those conditions; the approval committee did not, because its work is a fixed compliance process. The companies outside software studied by Conforto et al. (2014) showed many of the conditions agile needs, yet each had to reshape the practices to its own work. Our adaptation was to separate the work: patient stories now enter the backlog only after approval, and we schedule interviews a month ahead so approved stories are ready when a sprint needs them. Fitting agile teams into an organization that still works in other ways is a leading difficulty in the transformation cases Dikert et al. (2016) collected, and our committee was a small version of that problem.

The Preacher observed that a pair of workers achieves more for its labor than one person toiling alone (English Standard Version Bible, 2001/2016, Ecclesiastes 4:9). The board and the backlog did not make our team work harder; they made our toil visible to one another, which is where the reward came from.

Classmates: which part of your own work could move into sprints tomorrow, and which part would stall like our approvals?

Reply to Monique

Monique, your thread about trying Scrum at your commercial construction firm was candid about the frustration: the superintendents laughed at the idea of two-week sprints for pouring a foundation. I think they had a point, and so did you.

Two of the risk factors Boehm and Turner (2003) weigh, how often requirements shift and how much depends on getting the work right, point in different directions on your job. A foundation pour is critical and its requirements are stable, so a detailed schedule fits it. The design phase you described, where the owner kept changing the lobby and the tenant layouts, is dynamic, and short cycles of design review might help there. Conforto et al. (2014) found that companies outside software often need hybrid approaches rather than pure agile.

One option would be to run design coordination in two-week cycles with the owner's representative while the field schedule stays plan-driven, which keeps the superintendents' expertise in charge of the work they know best. The owner's representative would see design options every two weeks instead of in a monthly packet, which could reduce the late changes that have been delaying your tenant buildout. Gido et al. (2018) note that changes are cheapest early in a project, and frequent design reviews move decisions earlier. Which phase of your current project changes most often?

Reply to Patrick

Patrick, your school district's plan to move all twelve central office departments to Scrum at once was ambitious, and your thread raised the right worry: what happens when the payroll department works in sprints but the board approves budgets only twice a year?

Dikert et al. (2016), reviewing 42 industrial cases of large-scale agile transformation, found that resistance to change, coordination among many teams and the integration of agile with the rest of the organization were among the most common challenges. Starting with all twelve departments at once would surface every one of those challenges at the same time. Lindsjørn et al. (2016) found that teamwork quality strongly affected agile teams' learning and satisfaction, which suggests that a pilot with two willing departments could build the skills and stories that later teams would need. The pilot departments could also work out, in a low-risk way, how sprint-based work connects to the board's twice-yearly budget cycle before every department faces the same question.

The Scrum Guide describes Scrum as a lightweight framework that the team builds on (Schwaber & Sutherland, 2020), which leaves room to start small. Which two departments in your district have the most changing work and the most willing leaders?

References

Boehm, B., & Turner, R. (2003). Using risk to balance agile and plan-driven methods. Computer, 36(6), 57-66. https://doi.org/10.1109/MC.2003.1204376

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

Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87-108. https://doi.org/10.1016/j.jss.2016.06.013

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

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

Lindsjørn, Y., Sjøberg, D. I. K., Dingsøyr, T., Bergersen, G. R., & Dybå, T. (2016). Teamwork quality and project success in software development: A survey of agile development teams. Journal of Systems and Software, 122, 274-286. https://doi.org/10.1016/j.jss.2016.09.028

Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). Embracing agile. Harvard Business Review, 94(5), 40-50.

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