April 1st, 2014
by inflectra
(aka The Changing Role of the Modern Father)
One of the difficulties of moving from waterfall to an Agile development process is the breaking down of silos of responsibility, including that of the product owner. No longer the deliverer of the requirements 'master-specification', the product owner now participates throughout the entire process, sharing the requirements management task and taking on new, varied and, sometimes unexpected, responsibilities.
It is often stressed that the most important change required to successfully transition from a traditional waterfall development process to one with agile characteristics, is a change in mindset or culture. It's not enough to modify the process or reassign roles; the natural way of thinking for every individual in the team must embrace the unpredictability and flux inherent in agile processes. It may not be clear this week, exactly what you'll be working on next week, so if you need a structured, predictable environment, stay away from agile development. And that goes for product owners, (often Product Managers) too; they will need to be flexible and adaptable, with a flair for rapid decision making.
In a traditional development processes, usually referred to as the waterfall model, the product owner would elicit, record, organize and prioritize the requirements before developers are even assigned to the project. With that phase of the project complete, the requirements would be handed over and then product owner waits. And waits. And then waits some more. The whole affair is like an 18th century pregnancy where the father is crucially involved at conception, but does nothing more until delivery of the baby when he is then denied entry to the delivery room. Conversely, modern life has the father as an integral part of the whole process; attending classes and then the birth itself. Product owners are the modern fathers in agile software development, where responsibilities are mutual, roles less uniquely defined, and everybody plays a part in seeing that everything goes well. Ownership (parenting) is shared.
The product owner in a modern, agile environment must be involved at all times, helping with quality, design, testing and of course, requirements prioritization. But critically, the product owner must not lose sight of the need to document the requirements. At this point, agile extremists might start banging the table, insisting that requirements management as we know it, has no place in agile projects. But let's not throw out the (new born) baby with the bathwater; as with everything agile, we must be flexible and accept a broader understanding of the term 'requirement'. Let's include pictures, user stories, use cases, screen shots and flowcharts. Stakeholder wants and needs are still what drive the project and although we may not do traditional specification-style requirements management, we would still be wise to formally manage stakeholder input.
Whether requirements are specified textually, visually or using some other medium, it is important to properly record these wants and needs from stakeholders, if for no other reason than to avoid losing them while they are shuffled around in each re-prioritization, awaiting their turn in the agile development process. Adding defects to the requirements list and then organizing requirements into tasks only increases the need for some degree of formal software management. Using a tool can help keep order and prevent agile chaos. By then integrating the documentation of testing into the mix, we can get a good grasp of each iteration or sprint.
This doesn't mean you have to give up the whiteboard and post-it notes. If your team responds well to the visual and tactile experience of a meeting around the whiteboard, keep it up. Don't fix it if it ain't broke; but don't ignore opportunities to improve the process either – that's one of the tenets of agile development. If there are tools to protect the investment of your time around the whiteboard by transcribing decisions and recording outcomes, then why not use them? Sometimes team members are required to work remotely, (especially in bad weather) where access to the whiteboard is impossible without some space-time engineering, in which case, on-line access to the same information becomes invaluable. Don't be a victim of an over-zealous cleaner who decides it's time you had a clean whiteboard. Whiteboard meetings should be short and focused, consequently the effort needed to record any outcomes should be equally small; if it's not, you're not doing it right!
Change is seldom absolute but instead is often about degree and such is the case with documentation of requirements in Agile projects. Take advantage of technology, and make sure use of a tool is a constant and integral part of every team member's responsibilities, not just an administrative task for the product owner. Agile requires team parenting.
SpiraTest
SpiraTeam
SpiraPlan
RemoteLaunch
Rapise
KronoDesk
TaraVault
SpiraCapture
Cloud Services