MGMT 651 Week 1 DB Forum 1 Example

Discussion Board Forum 1: Thread and Two Replies

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

Thread by [Student Name]

The prompt, the credit union's projects and the classmates' posts are composites standing in for the course's own forum; Gido and colleagues' textbook, the Agile Manifesto, the peer-reviewed studies and Scripture are real; the requirements follow Liberty's public course guide for MGMT 651.

Thread

Last year our regional credit union ran two technology projects at the same time, and they showed me that the question is not whether agile is better but where it fits. The first was a budgeting feature for our mobile app. A small team of five developers, a designer and a product owner from member services worked in two-week sprints. After every sprint, fifty volunteer members tried the new increment, and their feedback changed the feature twice: members wanted spending alerts more than the charts we had planned, and they asked for the feature inside the existing account screen rather than in a separate tab. The feature launched in four months and is now used by 31 percent of app users.

The second was a conversion of our core banking system. The cutover weekend was fixed by the vendor's calendar and our regulators' expectations, forty systems depended on the core, and every requirement was known in detail because the new system had to reproduce what the old one did. That project followed a detailed plan-driven schedule with formal testing phases, and it was right to. Discovery on that project would have been expensive: a requirement found late meant a missed cutover weekend, and the next available weekend was four months away. The detailed plan, with a rehearsal conversion six weeks before cutover, found the problems while there was still time to fix them.

The authors of the Agile Manifesto put people and conversation, running software, partnership with customers and openness to change ahead of process, paperwork, contracts and fixed plans, while granting that the second set still has value (Beck et al., 2001). The app project lived those values. Boehm and Turner (2003) argue that teams should balance agile and plan-driven methods using risk, and they identify factors such as project size, criticality, the dynamism of requirements, the skill of personnel and organizational culture. The app was small, low in criticality and high in dynamism, which points to agile; the core conversion was large, highly critical and stable, which points to a plan. Serrador and Pinto (2015), studying about a thousand projects across industries, linked heavier agile use with projects judged more efficient and with happier stakeholders, though they also found that up-front planning still mattered. Gido et al. (2018) present the project life cycle and its planning foundation, which even agile teams use at the release level.

The evidence has limits. Weighing the empirical research on agile development as a whole, Dybå and Dingsøyr (2008) found that the strength of evidence was low and that most studies examined a single method. That caution keeps me from treating agile as a universal answer.

The Preacher wrote that for everything there is a season and a time for every matter under heaven (English Standard Version Bible, 2001/2016, Ecclesiastes 3:1). A wise project manager chooses the approach for the season the project is in, not the one in fashion.

Classmates: which factors decided the approach on your last project?

Reply to Simone

Simone, your thread about rebuilding your church's website with a volunteer team was a good example of agile values outside a software company. You described monthly reviews with the pastors, a prioritized list of pages and a launch of the most-used pages first, followed by the rest over three months.

Boehm and Turner (2003) would probably place your project in agile's home ground: a small team, low criticality and requirements that changed as the pastors saw early pages. One factor they emphasize, though, is personnel. Your volunteers changed from month to month, which can strain the close collaboration agile depends on. Conforto et al. (2014), surveying companies outside software, found that some agile enablers were present in those organizations but that adapting agile practices to different settings may require hybrid approaches. A short written guide to your page standards might give new volunteers the stability a rotating team needs without losing your monthly feedback, and pairing each new volunteer with one who has served for several months could carry the team's habits forward.

Gido et al. (2018) also stress defining the project's objective clearly at the start. Did your team agree on a single goal for the site, such as helping visitors find service times and ministries, before the first monthly review?

Reply to Aaron

Aaron, your plan to use Scrum for revising your hospital's 600-page policy and procedure manual was creative, and I liked your idea of two-week sprints with nurse managers reviewing each chapter.

I wonder whether parts of the project are more plan-driven than they look. Policy changes must pass the compliance committee, and your thread mentioned that accreditation surveyors will review the manual in eleven months, which is a fixed date and a high-criticality factor in Boehm and Turner's (2003) terms. Serrador and Pinto (2015) found that agile use was associated with success but that planning before execution still contributed to results, which suggests a hybrid might serve you well, and Conforto et al. (2014) found that organizations outside software often need exactly that kind of adapted model: a fixed plan for the approval and accreditation milestones, with sprints inside each chapter's drafting and review.

Gido et al. (2018) describe the baseline plan as the reference against which progress is measured, and the accreditation date gives you one whether you want it or not. Sprints would still give nurse managers early drafts to react to, which is where agile helps most in document work. How often does the compliance committee meet, and could its schedule set the length of your sprints?

References

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for agile software development. https://agilemanifesto.org/

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

Dybå, T., & Dingsøyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9-10), 833-859. https://doi.org/10.1016/j.infsof.2008.01.006

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

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

Serrador, P., & Pinto, J. K. (2015). Does agile work? A quantitative analysis of agile project success. International Journal of Project Management, 33(5), 1040-1051. https://doi.org/10.1016/j.ijproman.2015.01.006