Tactical Scrum
I have been working at Fellowship Tech for a little over a year now. One of the most striking things I noticed after coming on board, and something I'm still consistently impressed with, is how well the company as a whole really "gets it" when it comes to software development as a continuous process.
We adhere to a project management methodology named Scrum, after the scrummage that occurs during rugby games, when all players hunker down side by side, in order to push the entire team forward. While sports analogies are well and good, I think of scrum more along the lines of an infantry division.
Here's why…
A development team that utilizes scrum is said to be "self governed." Meaning, while executives drive the overall vision and strategy of a company, it is up to those in the trenches to make it happen. Whereas a commander must have a broad idea of how a military campaign should play out, he delegates authority and trusts his troops to decide, in the field, how to accomplish their objectives.
This privilege of self governance demands a certain level of responsibility, and there are several key roles to be filled if one's scrum team is to be effective.
Sarge
At the heart of the scrum process is the scrum master. Typically someone with project management experience, this person can be thought of as a sergeant at arms, one who keeps the group in-line and on-track. It is his duty to ensure that development groups operate as efficient units. Anything affecting team cohesion is flagged as an impediment to be removed.
A good scrum master keeps a watchful eye over the entire team, ensuring that due diligence such as code reviews are done, and that the process is not being circumvented or slighted. He understands that in order for scrum to work, there must be complete buy-in from the team, and strives to make it happen.
Comm.
On a scrum team, product owners are not unlike a squad's field communications specialists. They relay information to the team from headquarters (and vice versa), helping to shape and define the parameters of success. They are on the team, but their purpose is to serve as a proxy for those outside and/or above the development group, who have a stake in the outcome.
Those best suited to a PO role have business analyst experience or can empathize with users of the software. They are often voices of reason and temperance when things get tough, because they care about the continuity of the product.
Infantry
This classification comprises the bulk of the team. Not given to any particularly fancy scrum related titles, they are simply referred to as developers. Without these guys, the army simply would not exist. Amongst them are programmers, database admins, system architects. They do the heavy lifting - holding the front line, steadily advancing toward the objective.
Agile, Mobile, Hostile — Hoo-rah!
It is because of them that the scrum process is effective. At our company, development teams work in three week iterations, dubbed scrum "sprints." I think of it as securing that next strategic hill, bridge, or landmark. After each incremental victory, the team identifies the next logical target to tackle. Acting in concerted effort, they are indeed a formidable force to be reckoned with.
Medic!
Disturbingly common is how many groups operate without the support of good quality assurance specialists. On our team, as part of our definition of done, if QA has not reviewed it and deemed it solid, our product simply cannot be shipped with that feature. Ideally, QA wouldn't be needed, spending the day like the Maytag man, awaiting a call for help that never comes.
Yet in the real world, despite the best planning and the most earnest of efforts, things get messy. Perhaps nobody is as much appreciated, yet unsung, as those in our QA department. They are truly a top-notch group, two of whom have degrees in computer science. I cannot tell you how helpful it is to have professionals who assess the symptoms of a problem, and suggest an efficient remedy.
Recon
There is some ambiguity and ongoing debate amongst scrum centric developers and project managers, as to where the user experience aspect of web design fits into the team workflow. To me as a UX developer (aka designer), this is purely pedantic. In reality, to exclude design from the software development process is to invite confusion later on down the line.
In this regard, myself and others on our UX team serve as scout snipers, running at least one sprint ahead of the server side developers, in order to plot a course of action. This affords ample time to build design patterns and refine interfaces. In terms of problem solving, we frequently dispatch issues with a surgical "head shot" so to speak, without having to involve the entire dev team.
Not unlike snipers, designers typically pride themselves on keen visual awareness and quick acclimation to new environments. They are also brash and cocky enough to believe that otherwise big problems can be solved with magic bullets. I mean, what can't be done with Fireworks, CSS, and JavaScript — right?
Though we map out UX sprints well ahead of when templates will be wired-up on the server side, each dev team is allotted a designer. This means that we are each simultaneously a member of two groups. On the dev sprint side, we are seen as zero-hour scrum resources, to be called upon as needed.
We account for this by budgeting enough flex time within our UX design sprints, to allow for tasks to be assigned to us from our respective development sprints. In this way, we can venture "out ahead" of the larger teams, but also circle back to help fortify the effort. To me, this is how scrum ought to be done.
V-Day
Ah, deployment. This is the day (or most likely, late evening) that marks the culmination of a well executed series of sprints, providing new functionality to customers, enhancements to existing features, and a better overall piece of software in general. As a team member, one cannot help but feel a bit elated, as the escalated stress of the release date subsides. You congratulate fellow comrades on their diligence, and are equally encouraged by them.
As a team, you are collectively aware that a shared sense of accomplishment is only as valid as future sprint successes. And so you go, once again into the fray, gauging the level of effort and number of hours it will take to plant that next triumphant flag in the sand. The process begins anew. Marching orders, reconnaissance, digging-in locked n' loaded — all to build better software.
That's what scrum is all about.