As if software development isn’t hard enough, the approach you or your team adopts can make a dramatic difference in project success. Using a traditional project management approach may not lend itself to “learn, discover, and adapt” inherent with software development. Although most Xojo developers are aware of Scrum and other popular agile methodologies, it may be unnecessary to use. Being a Xojo developer and a Certified ScrumManager, my goal is to demystify how agility, specifically Scrum, helps improve product quality, prioritize functionality, and provides an intuitive framework to complete work.
We Have a Process Problem
In my last VP job, my software development organization was having a tough time juggling incoming product management requests. Attempting to manage all of the “incomings” made project schedules challenging to achieve. Being an embedded software organization, we did everything in the traditional waterfall way. Any mention of changing our process to something more agile was met with condemnation and distrust. “No way! That stuff is just a fad. Besides, compared to most software companies, we release products pretty much on schedule.”
The sad truth, however, was that our track record of quality, on-time product delivery wasn’t that good. We had to do something.
Rather than fight the pushback, I found it easier to let the team identify what doesn’t work rather than force-fit some sort of new-fangled agile methodology on them. So, I asked the team, “How can we improve our software development process?” Through intense brainstorming and airborne projectiles (aimed at me!), we were able to compile a list of issues that needed improvements:
- Decisions made throughout a project lifecycle appear ad hoc and reactive. QA (testing) gets involved way too late.
- QA (testing) gets involved way too late.
- By the time the customer sees the product, sometimes it isn’t what they expected.
- Some features aren’t getting completed on time. We usually find this out way too late to course-correct.
- Handoffs at key milestones are ill-defined. By the time the project concludes, the original specifications and design documents barely resemble the actual implementation. And yet, we never make the time to update any documents at the end of a project.
- Requirements are often too abstract with little to no mention of priority or guidance for validation.
Despite what the team wanted to believe; our issues required corrective attention. In an ever-changing work environment, traditional processes were inflexible. We needed to become agile.
Comparing Software Development Approaches
In the software development community, there are two competing schools of thought for managing the process of motivating a team to deliver quality products: waterfall and agile. The figure below illustrates the differences between the two extremes. Waterfall (to the right) tend to be more structured and less adaptable, while agile frameworks are less structured and more adaptable (to the left).
Although not shown in the figure, Kanban is yet another popular agile framework with real-time attention and less structure than Scrum. Kanban would appear on the chart just to the left of Scrum on the continuum. (I’d like to explore using Kanban in a future blog, especially with cloud-based continuous enterprise app deployment.)
Let’s start with traditional waterfall—a step-by-step phased delivery methodology. Completing one step should advance project work to the next step as shown in the figure below:
In actual use, waterfall isn’t exactly linear where one step is completed before going to the next step. Instead, phased work can overlap between milestones. Developers may start the implementation (coding & debugging phase) before the detailed design document has been signed off. Work may spill over to the next milestone work. This approach may not be as intuitive as you might think. According to Agile & Iterative Development, [1] the waterfall method has become unattractive to software developers because of the following:
- Users aren’t always sure what they want and once they see the work, they may want changes.
- Details usually come out during implementation, so committing to upfront schedules is not possible.
- Approved specs are rarely accurate by the time a project completes.
- Disconnected long series of steps with “approved” handoffs can be subjective.
- Success seems far, far away and, in practice, schedules are rarely predictable. This results in the team not seeing any work completed for possibly months. Things get really complicated by the time QA finally gets their hands on the code.
The software industry needed a chiropractic adjustment and the Agile Alliance [2] was formed to focus on time-driven, customer efficiency best practices. The alliance established core values from W. Edwards Deming’s research on achieving quality and productivity improvements. [3] According to Deming, work can be more efficiently completed with small cross-functional teams focused on immediate quality results.
An Introduction to Scrum
Enter the Scrum framework. Scrum is all about being responsive to customer needs with work prioritized in chunks to be completed in fixed-length sprints:
Work is defined in T-shirt-sized estimates (small, medium, large, and extra-large) at the beginning of a project during a Scrum planning kickoff meeting. The team lines up required resources, specifies sprint duration, identifies features (called product backlogs), and establishes a project vision (“Why do this?”). You could say that Scrum works in a series of iterations, each building upon the work of the previous iteration.
The most important work is taken off the remaining work stack in the first sprint planning meeting. The team breaks the work into tasks and assignments so that by the time the sprint ends, the work should have been assigned, designed, implemented, and validated. To mitigate risks, the team meets every day to review what work has been accomplished, what is left to complete, and identify where assistance may be needed. Daily meetings may appear to be overkill, but if a daily 15-minute standup can mitigate project risks, the time is well worth it.
This drastically different approach assumes close-knit collaboration and effective communication. Unfortunately, software developers aren’t usually very proactive at communicating, and that’s where a ScrumMaster steps in. A ScrumMaster facilitates open discussion, communication, and closure of work.
This can take lots of extra time to prepare and communicate to the appropriate stakeholders. A unique characteristic of “Scrumming” software development projects is that a product owner (a.k.a. product manager) and the customer should be represented at Scrum planning, sprint planning, and sprint reviews. During a sprint review, also called a sprint retrospective, the customer has the opportunity to review progress and the team can adjust to that feedback in the next sprint.
In traditional waterfall projects as QA involvement takes place near the end of a project lifecycle adding significant risk. Until all of the critical bugs are found and fixed, the long hours of testing and mitigation pushes any schedule out. Instinctively, Scrum projects integrate QA testers as core development team members from the start.
The figure below demonstrates the impact of involving QA too late in the process:
On waterfall projects, the risk to deliver accelerates resulting in long hours and schedule slips. With Scrum, the risk of late schedules due to quality issues should reduce over time. As developers write code, the QA testers are busy designing, creating, and running tests. I highly recommend investing in test automation to allow code to be tested in nightly builds without human intervention. The use of test automation is critical with Scrum projects because of the need to test constantly. As you might expect, a software product under development is not released until all tests pass.
Managing a Scrum Project
Traditional project managers offer a command and control role that ensures that a project team is sticking to quality, feature, and schedule goals. It’s that constraining “command and control” that doesn’t work with software development. In Scrum, there is a ScrumMaster who acts as a guide, motivator, and coach. The Agile Manifesto identifies the ScrumMaster role as the enabler to let the team self-organize around the needs of project work.
Using a Simple Scrum Tool with Your Xojo Projects
There’s a fair number of Xojo developers who work alone or with small teams. The power and simplicity of working in the Xojo IDE makes interactive coding fun and easy. Why not avoid getting bogged down with any process at all?
The tools and mechanisms to use Scrum can be a little over the top. For that reason, I use a simplified Excel spreadsheet that allows you to easily manage any Scrum project. [4] It is yours to use for free. Just browse the Leading Software Maniacs resources and click on the Download Agile Project Spreadsheet button.
References
- Larman, Craig. Agile and Iterative Development: A Manager’s Guide. Boston: Pearson Education, 2004.
- Agile Alliance. “Manifesto for Agile Software Development.” (www.agilealliance.org).
- Deming, W. Edwards. Out of the Crisis. Boston: The MIT Press, 2000.
- Whitaker, Ken. “Agile Project Spreadsheet.” Leading Software Maniacs. http://www.leadingswmaniacs.com/leadership-resources.html.
Ken Whitaker, of Leading Software Maniacs, has more than twenty-five years of software development executive leadership and training experience in a variety of technology roles and industries. Ken has written several books and articles on leadership, cross-platform development, and graphics/publishing. He is a recognized innovator in blended learning courseware design and the host of workshops on agile project management and executive leadership.
Ken is the creator of PM Chalkboard and most recently the editor for Better Software magazine. He is creating a suite of Spresso productivity apps for creative professionals and the unique The Nerd Herd Game gamification product that redefines learning. This app-based game will be an accessory to a visual book/course called Young Person’s Guide to Project Management currently in development.
Oh yeah, I almost forgot. Ken is working on a three-year visual comix novel project interpreting the musical masterpiece Supper’s Ready from the original 70’s band: Peter Gabriel and Genesis.