Eliminate Unhealthy Tension to Achieve Agile Success!
The success of implementing an Agile methodology within a software development group is dependent on establishing trust amongst the various roles of the product development team.
A typical team consists of a Business Analyst, a Product Manager, Project Manager, Developer(s), Tester(s) and possibly a validation representative. Establishing trust among each role is dependent on the establishment and communication of clearly defined responsibilities and areas of authority within each role. If these responsibilities and authority levels are not defined and understood by each role, then it is guaranteed that team members will stray into areas of authority they do not have causing conflict and friction within the team. All too often the time is not taken to clearly define roles and responsibilities before converting to an Agile methodology which results in the following negative effects:
- Finger pointing and blame between roles
- Low morale and disillusionment with the Agile methodology
- Potential turnover and loss of key contributors
- Disappointment with the actual benefits gained by implementing Agile
So the obvious question is “How should a product development group be organized with clearly established roles and authority levels to improve the probability of Agile success?” Before I answer this question, in the spirit of full disclosure I would like to acknowledge that the framework I am about to explain was originally taught to me by a VP of Software Development whom I greatly respect and admire. I have simply added information concerning the symptoms of healthy and unhealthy tensions between groups. Understanding unhealthy tension is useful to identify when your group is suffering from a misalignment of responsibilities. This framework is based on dividing a product development group into specific Functional Areas, or Levers, which Executive Management can apply pressure to as needed to correct issues as they arise. Interactions between each Functional Area can be monitored for specific symptoms which indicate whether the team is experiencing healthy or unhealthy tensions.
Like death and taxes, it is impossible to avoid tension on a software development project. Tension is naturally created by the need to satisfy specific business needs and meet commitments related to the success criteria of a project. It is imperative that a BA or PM is able to determine whether the project is experiencing healthy tension or unhealthy tension. Healthy tension naturally occurs as a result of a collaborative team all striving to achieve the same goals. When each Functional Area is operating within their realm of responsibility and authority an environment of trust and respect develops amongst team members. This healthy environment results in a highly functioning collaborative team willing to go the extra mile for each other to solve problems and deliver high-value solutions to the business. Unhealthy tension is the direct result of Functional Areas straying outside their realm of responsibility and authority. When this occurs the team which has their area of authority breached will react negatively and the seeds of team discontent will be sown. By now you are probably wondering what these Functional Areas are and how their responsibilities and authority levels are defined.
Our department has had success implementing an Agile methodology by organizing the development group into the following four distinct Functional Areas or Levers.
- Product Management & Business Analysis (Product Managers & Business Analysts)
- Technical Delivery (Developers and Testers)
- Risk Management (Project Management/PMO/Scrum Masters)
- Process Governance (QA/Validation)
The Product Management & Business Analysis group is responsible for working directly with our customers to understand their unmet business needs. Product Managers work to understand the marketplace and industry in which your company’s solutions compete to derive a product development roadmap. The roadmap is prioritized and optimized for maximum revenue and market share gains. The Business Analysts work closely with the Product Managers to interpret these unmet business needs into clearly defined requirements. Product Managers prioritize the requirements for development and ultimately are responsible for approving the final product for release after they are satisfied the solution meets the business needs. The Product Management & Business Analysis group has full Authority over the selection of business analysis tools, the organization and writing of requirements, product level decisions related to solution functionality and the ultimate approval of each software release. Symptoms of healthy tension within this group are characterized by the Technical Delivery team questioning requirements and their associated business needs as well as helping Product Management ensure the correct business needs are being solved. Symptoms of unhealthy tension in this group are BA’s taking orders and writing them down or writing requirements according to how the technical team or project management team prefers them to be written. Once other teams start dictating the structure and organization of the requirements, you will see significant unhealthy tension between the groups.
The Technical Delivery team consists of the Architects, Technical Managers, Developers and Software Testers responsible for developing and testing the solution. This team is fully responsible for selecting the software development and testing tools, designing the system architecture, writing code, testing the application, developing the test strategy and providing timelines for completion of the work. They have full Authority over the architecture choices and decisions, the technical implementation of solutions, and the overall test strategy and testing toolset. You may be a bit surprised that the Technical Delivery team has authority over timelines in this structure. During our implementation of Agile, this was an enormous source of contention and strife. The Project Management group and Executive Management struggled with giving up their command and control practices of dictating deadlines they felt were realistic or necessary. The reason for providing the Technical Delivery team with the authority over timelines is to place the responsibility for estimating the effort and duration of the work directly with the people doing the work. Dictating deadlines to technical teams typically results in unhealthy tension. This is especially true when an unrealistic deadline dictated by management results in the team working nights and weekends to finish the work! This is a common example of functional areas straying outside their realm of authority. Unfortunately, our Technical Delivery team suffered through much unhealthy tension over this misalignment throughout a two-year development project. The best defense against this occurring on your teams is to ensure the consistent delivery of commitments made during the sprint. Once management experiences consistent delivery of sprint commitments they will be less likely to dictate irrational deadlines.
The Risk Management group is comprised of the Project Managers and is typically referred to as the Project Management Office or PMO. The PMO is responsible for monitoring project risks and reporting on those risks, reporting overall project status, removing roadblocks and facilitating team collaboration. They have complete authority over the metrics used to report risks to the project and project status. Symptoms of healthy tension within this group are characterized by the PMO collaborating effectively with Product Management, Business Analysis, and Technical delivery to identify and understand risks to the project and identify roadblocks they can assist with. For example, other teams may be struggling with obtaining external resources to answer questions or having hardware infrastructure acquired and setup. The PMO can effectively work to remove these types of roadblocks to facilitate project completion. Signs of unhealthy tension within this group consist of differences of opinion on project scope leading to arguments about scope creep, the PMO dictating excessive process details such as the time/frequency of Agile meetings, and the PM’s dictating how requirements are written and organized. During our implementation of Agile, we suffered through each of these symptoms. The PMO had a difficult time releasing their command and control mentality and trusting the teams to make correct choices on the use of Agile tools and completing their work. When the Agile process is supposed to deliver great efficiency benefits, it is easy to place far too much emphasis on the process. At one point, we even heard from the PMO that if people didn’t follow the process they would get people who could! Obviously this caused a serious amount of unhealthy tension amongst the groups. As time went on and the delivery teams were consistently delivering high-quality software, it became easier to convince the PMO to release control and empower the teams to choose how they should work within the process.
The Process Governance group consists of the Quality Assurance team. They are responsible for ensuring adherence to departmental process, documenting validation processes and training the department on those processes. Their authority consists of defining the minimum requirements needed to adhere to the external regulations our products are required to meet. Healthy tension in this group is identified by QA understanding the complete SDLC and collaborating with the other Functional Areas to implement the most efficient processes to satisfy regulations. Unhealthy tension can be identified by repeat process noncompliance. This can indicate a passive-aggressive approach against a process that is considered to be inefficient or unnecessary. Occasionally the QA group strays outside their authority and recommends certain changes to how requirements are organized. Our team experienced this when QA requested that all completed requirements affected by Change Requests have their iteration path updated to reflect the path in which the CR was completed. This request was based entirely on how their validation reports worked and would have caused a tremendous amount of busy work for little value. Fortunately, the teams collaborated and chose an agreeable solution which allowed QA to get the information they required via a simple query from our requirements tool.
While I have spent considerable effort outlining an effective organization structure to implement Agile, I must also explain the responsibilities and authorities which are common to the entire development team. The entire team is responsible for ensuring that solutions are developed to satisfy well-defined business needs. This is the entire team’s responsibility. The team is also collectively responsible for ensuring all regulatory requirements are met and processes are followed. Successful Agile implementations will provide the entire team with the authority to choose the Agile tools necessary for their particular team based on the team’s experience. This is absolutely critical and can only be accomplished by management and the PMO releasing some of their command and control tendencies. As our teams matured throughout the course of a two-year project, it became apparent that daily standups and retrospectives every two weeks were becoming ineffective. Providing the team with the empowerment to decide when to change the Agile tools and the frequency of their use ensures healthy tension is maintained. When the team is self-directing and self-correcting issues as they arise without management interference, you know you have a healthy team. Symptoms of unhealthy tension within a team can typically be spotted pretty easily. Finger pointing and blame between functional areas, the team working excessive hours to achieve objectives, low morale, turnover, and requiring management intervention to solve team disagreements are all very common symptoms of unhealthy tension. If you are experiencing any of these symptoms, it is likely that functional areas are beginning to stray outside of their realm of authority. If management keeps their hands on the four levers I have outlined it is easy for management to make a correction.