Managing Requirements in an Agile environment

The transition to agile seems challenging to developers and organizations. The agile manifesto prescribes working code to comprehensive documentation. This principle, when isolated seems to confuse agile practitioners. Recently I was involved in a scrum project, where there was absolutely no requirement definition. While the developers were eager to make scrum “work” for them, there were considerable challenges for the people who were newer to the organization. Organizations that have matured over the decades rely on senior workers to provide subject matter expertise. This may not really be a good idea, since agile projects are fast paced and developers who are also tasked with being SMEs will be challenged for time. A business analyst is critical to agile teams to provide requirements, unless the product owner is able to fill in all the required details for user stories, which does not seem practical. Producing extensive bulky documentation with obsolete information is totally worthless and does not serve anybody’s needs, but unless requirements are clearly defined and the team is clear with the scope, following the agile approach serves no purpose. The organization seemed eager to adopt scrum and at the same time, challenged to break away from the waterfall model. This led to breaking existing functionality many times, incomplete testing, releases rolled back, cost overrun, and frequent conflicts between agile teams, rework, scope creeps and reorganization all of which could have been well avoided.

 Traditional projects require a strong project manager who manages the project right from initiation to final delivery. The requirements, technical and non-technical specifications are core documents for project execution. The project execution and control involves all the functional teams who are primarily managed by the project manager. Hence it is the Project Manager who is essentially responsible for ensuring the successful completion of the project. The Product description defines the essential goal of the project and is detailed in the Project Charter. From the scope statement evolves the work breakdown structure (WBS) which lists all tasks and dependencies. A project plan is developed from the WBS and the timelines, costs and scope is agreed upon by the stakeholders. The project plan has the time allocated to the tasks along with resources and costs. Changes to the scope are managed by the project manager, and the change management plan is laid out in accordance with the organizational policies.  Vendor costs and contract resources if any and will have to be managed and accounted for by the project manager. Hence all the work is accounted for and change requests managed appropriately.

Managing agile projects might seem totally different from the PMBOK approach. A project starts with a vision and an owner or sponsor who defines the strategic need for a specific problem. As with any solution, the project might involve building a system or services that might raise the reputation of the organization, provide a competitive advantage, or address problems that are critical, thereby building a stronger and better system than what is in place. Investments for the specific initiative have specific budgets. The project manager and project sponsors make critical decisions regarding the work and cost involved. From the vision evolves the Epics that represent at a high level large scale development activities. Epics are prioritized, estimated, maintained in the portfolio backlog. Epics are broken into features and features into stories. Project managers or product managers have to ensure acceptance tests are run at the feature level.

Epics contain existing and planned systems to allow current and anticipated requirements that will be implemented incrementally. The development and maintenance involves mature and responsible agile teams without which projects cannot succeed.  The vision document, draft or press release, data sheet are documents that can expected during project initiation.  

At the program level, there are multiple agile teams or pods. The at the program level, teams and activities are organized around an ongoing series of incremental releases. Every release identifies a Potentially Shippable Component which is the result of incremental development of the feature Development of the feature base happens as a standard cadence of iterations that has been. At the program level, the product manager is involved along with feature teams and/or component teams. In addition to the agile teams, project involves System teams for Build, deployment, database administration, system administration and system tests such as performance and stress tests, release management activities involve business owners, product managers, sales and marketing representatives, QA representatives, senior managers, architects and also the company CTO. The program level is focused on the features and customer needs. They bridge the gap between domain and solution.

Features are translated into user stories that are prioritized by the product manager and product owner. The stories are ranked and sized by the team and released at the end of the iteration. The scrum teams are managed by the scrum master who is responsible for the ensuring that the stories are worked and completed and provide status updates when needed. The scrum master must make sure that the team works cohesively and removes all impediments. The product owner is responsible for the scope of work each iteration and for clarifying requirements and questions related to the product and release.

The project manager may not have a role in agile projects. If there is no project manager, the product manager or program manager and product owners and scrum masters along with the teams are capable of organizing the work and coordinating the release. If there is a project manager however, the PM is expected to have a less significant role, but is nevertheless responsible for ensuring the project success. The PM schedules meetings with the project sponsors, product owners, scrum masters regularly and also meets with team members when required; the PM checks on the work during each iteration, ensures that releases follow the plan and all system tasks are completed and the customer needs are met until the final product is shipped.

Breaking the work into releases and working in smaller iterations seems appropriate. In the mid-90s I was working on a migration project at an automotive company. After 2 years and several thousand dollars, the project was cancelled. It was found that the application was not well designed and not worth implementing. The vendor was eventually removed which caused a rift in the relationship, personnel suffering due to job losses. All this could have been avoided if the project was evaluated after every release to meet customer expectations.

Though the transition to agile is harder, project planning takes longer, frequent releases may seem an overhead, agile offers a good solution to avoid disasters. But of course, a strong project manager or product manager and reliable product owners and reliable team members are the keys for success to ensure developers and testers are clear with what needs to done and the why.