PM 400 Week 2 Agile Values and Principles Example

Patrons Before Paperwork: Applying Agile Values and Principles to a Library District's Mobile App Rebuild

[Student Name]

University of Phoenix

PM/400: Agile Management and Tailoring

Week 2 Assignment

[Instructor Name]

[Date]

Desert Sky Library District, its app team, patrons and figures are composites written for a model paper.

Desert Sky Library District, the invented southern Arizona system from Week 1, is rebuilding its mobile app. Patrons use it to search the catalog, place holds, renew items and show a digital library card, but reviews average 2.1 stars, mostly complaining about failed logins and a confusing holds process. Week 1 chose an agile approach for the project. The team is a product owner from digital services, Mei Tanaka, four developers and a designer from an outside firm, a library systems analyst and a scrum master. This paper explains the agile values and principles and how they shaped the team's first month.

The Four Values in Plain Words

The Manifesto for Agile Software Development set out four value statements, each preferring one item over another while stating that the second item still has value (Beck et al., 2001). In plain words: talk to people before reaching for a process or tool; show something that works rather than describing it at length; work alongside the customer instead of arguing about the contract; and when the situation changes, change the plan. The standard treats these values as the basis of an agile mindset, which it distinguishes from any single method (Project Management Institute [PMI], 2021).

Four Themes From Twelve Principles

The manifesto's twelve principles fall into four themes. First, deliver working results early and often, and measure progress by what works. Second, collaborate daily with the business and with users, and welcome changing requirements. Third, build projects around motivated people, trust them, prefer face-to-face conversation and keep a pace the team can sustain. Fourth, pay continuous attention to technical quality and simplicity, let teams organize themselves and reflect regularly on how to improve.

Theme 1 in Practice: Early, Working Releases

The original plan was a full redesign released after six months. In its first planning session, the team asked what patrons most needed. Login failures and holds topped the complaints. The team rebuilt the login and the holds screen first and released them in week four, while the rest of the old app stayed in place. Ratings in the following two weeks averaged 3.4 stars, and holds placed through the app rose by 22 percent. Progress was measured by those results, not by the share of screens redesigned.

Theme 2 in Practice: Collaboration and Change

The district used to learn about patron needs from a yearly survey. Tanaka formed a panel of 30 patrons, including teenagers, older adults and Spanish-speaking families, who try each release on a test build and meet with the team online every second Friday. In week three, panelists said they wanted to see when a held book would arrive at their branch. The team added the item to the backlog and moved it ahead of a planned redesign of the events calendar. Branch staff also join reviews, since they hear patron complaints every day.

A yearly survey tells a team what patrons thought last year; a fortnightly review tells it what they think of what was built last week.

Theme 3 in Practice: Trust and Sustainable Pace

The district's managers were used to approving every design decision. Tanaka asked the deputy director to approve outcomes instead, such as better ratings and more holds, and to leave screen decisions to the team. The team works from the library's offices two days a week so that developers, the designer and the systems analyst can talk face to face. Hoda et al. (2013) studied self-organizing agile teams and identified informal roles members took on, such as mentor and coordinator, that helped teams organize themselves; Tanaka encouraged the systems analyst to act as the team's link to the catalog vendor. The team also agreed to plan no more work than it completed on average in recent iterations, to avoid overtime.

Theme 4 in Practice: Technical Care and Reflection

The old app had grown slowly fragile. The team added automated tests for login and holds and kept each feature simple enough to change. At the end of every iteration, a 45-minute retrospective asks what went well, what did not and one thing to change. In the second retrospective, the team decided that the systems analyst would join daily stand-ups instead of attending only reviews, since catalog questions were slowing developers.

A Challenge the Team Did Not Expect

Not every principle was easy to apply. Daily collaboration with the business assumed that someone with authority over library services could attend reviews, but branch managers work public service desks and could rarely join on Friday afternoons. The team moved one review a month to a Tuesday morning before branches open and recorded short demonstration videos for the others. A second difficulty was the outside firm's habit of reporting hours worked rather than features finished; Tanaka asked that iteration reports show only what patrons could now do, which brought the firm's reporting in line with the principle that working results measure progress.

Where the Right-Hand Items Still Matter

The values do not discard contracts, documentation, plans or processes, and a public library needs all four. The contract with the development firm sets payment per iteration and requires accessibility to recognized standards for people with disabilities. Patron data protections are documented and reviewed before any release that touches accounts. A product roadmap gives the board a view of the next six months. The difference is that these items serve the work rather than control it.

Signs of an Agile Mindset

Dingsøyr et al. (2012) reviewed a decade of research on agile methods and noted that the field needed better explanations of why agile practices work, beyond descriptions of the practices themselves. For Desert Sky, the practical test is behavior. Five signs show the team is working with an agile mindset: releases reach patrons at least monthly; backlog order changes after patron reviews; decisions are made by the team without waiting for approval; retrospectives produce changes that are carried out; and the team talks about patron outcomes more than about tasks completed.

Conclusion

Agile values and principles changed how Desert Sky's app team worked in its first month: early releases fixed the worst problems, a patron panel replaced a yearly survey, managers approved outcomes rather than screens and the team invested in tests and reflection. The district kept the contracts, documents and plans a public body needs, using them to support the work. The result so far is an app patrons are beginning to rate well.

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/

Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile software development. Journal of Systems and Software, 85(6), 1213-1221. https://doi.org/10.1016/j.jss.2012.02.033

Hoda, R., Noble, J., & Marshall, S. (2013). Self-organizing roles on agile software development teams. IEEE Transactions on Software Engineering, 39(3), 422-444. https://doi.org/10.1109/TSE.2012.30

Project Management Institute. (2021). A guide to the project management body of knowledge (PMBOK guide) (7th ed.). Project Management Institute.