Traditionally, quality assurance ensures the quality of a product once it’s built in order to shield customers from receiving defective product. TQM suggests that rather than putting quality assurance at the end of the product cycle, feedback loops be placed at every step of the product building process so that the actual causes of defects can be identified and fixed. Fixing causes of defects can continually increase customer satisfaction at continually lowers costs.
Out of all the Agile methodologies I have studied so far (XP, Scrum, AUP, and MSF), I really like the fact that MSF provides a Team Model that goes into details about how project teams should be structured. While it may be obvious to some, I know from experience that properly structuring teams is not something that that comes naturally to many organizations. In fact some organizations have less success with agile only because of their ineffective team structures.
MSF Team Model is based on the following basic principles:
- A team of peers with clear accountability, shared responsibility and open communications. Each role is accountable for a specific share of the quality of the overall solution.
- Advocacy for all key constituencies that must be represented on a successful software project. Every perspective is represented to provide the checks and balances that prevent errors of omission and lopsided decisions.
- Stretch to fit to the scale necessary for the specific project. Constituencies may be combined in small teams or further refined as teams scale for larger projects.
There are 7 advocacies that are represented in the MSF Agile Team Model. In my opinion it’s imperitive that these advocacies have proper representation in order to ensure success of a given project. Since MSF offers a stretch-to-fit approach, it’s possible to map these 7 advocacies into fewer role clusters as determined by the phyical size of the team.
Following are the advocacies and their respective focus as presented by the MSF Team Model:
Product Management
Goals
- Understand, communicate, and ensure success from the standpoint of the economic customer requesting the solution.
Functional Areas
- Marketing
- Business Value
- Customer Advocacy
- Product Planning
Responsibilities
- Acts as customer advocate
- Drives shared project vision/scope
- Manages customer requirements definition
- Develops and maintains business case
- Manages customer expectations
- Drives features vs. schedule vs. resources tradeoff decisions
- Manages marketing, evangelizing and public relations
- Develops, maintains, and executes the communications plan
Program Management
Goals
- Right solution is delivered at the right time and all expectations are understood, managed and met.
- Deployed solution will meet qualities of service & business objectives, and be viable in the long term.
Functional Areas
- Project Management
- Solution Architecture
- Process Assurance
- Administrative Services
Responsibilities
- Drives development process to ship product on time
- Manages product design and specifications
- Facilitates communication and negotiation within the team
- Implements and ensures standards
- Maintains the project schedule and reports project status
- Drives implementation of critical trade-off decisions
- Develops, maintains, and executes the project master plan and schedule
- Drives and manages risk assessment and risk management
Development
Goals
- Implementation, estimates, high quality maintainable code and unit tests.
Functional Areas
- Technology Consulting
- Implementation of Architecture and Design
- Application Development
Responsibilities
- Specifies the features of physical design
- Estimates time and effort to complete each feature
- Builds and/or supervises building of features
- Prepares product for deployment
- Provides technology subject matter expertise to the team
Quality Assurance
Goals
Functional Areas
- Test Planning
- Test Engineering
- Test Reporting
Responsibilities
- Ensures all issues are known
- Develops testing strategy and plans
- Conducts testing
- Reports test results
Release/Operations
Goals
- Timely readiness and compatibility of infrastructure.
Functional Areas
- Infrastructure
- Support
- Operations
- Commercial Release Management
Responsibilities
- Act as advocate for operations, support and delivery channels
- Manage procurement
- Manage product deployment
- Drive manageability and supportability trade-off decisions
- Manage operations, support, and delivery channel relationships
- Provide logistical support to the project team
User Experience
Goals
- Provide user documentation and training
- Understand and communicate users’ context, and ensure usability from user perspective
Functional Areas
- Technical Communications
- Training
- Usability
- Graphic Design
- Internationalization
- Accessibility
Responsibilities
- Acts as user advocate on team
- Manages user requirements definition
- Designs and develops performance support systems
- Drives usability and user performance enhancement trade-off decisions
- Provides specifications for help features and files
- Develops and provides user training
For Agile methodologies to really work with the promised increase in efficiency, it’s important that all participating team members be generalists rather than specialists.
For some companies migrating to Agile from other traditional methodologies, this may not be the case. I have worked with companies that have well-defined and assigned roles for Business Analysts, Database Administrators, Front-end Developers, Back-end Developers, etc. When such companies move towards Agile, they face a problem of optimal resource allocation and utilization.
As an example, a developer may not be productive while a DBA is creating new tables in the database and writing stored procedures. Once the DBA is done with his tasks, he may not have enough to do until the start of the next iteration. Since Agile is iterative, and iterations can’t overlap, this may result in poor resource utilization and may adversely effect the overall efficiency.
Before starting to implement an Agile methodology within your organization, it is important to make sure that your IT human-resource infrastructure actually supports it. While Agile may work in companies with specialized IT roles, it is definitely not designed and optimized for those scenarios.
Currently I am working at a company with a fast-paced environment, very aggressive deadlines, and historically a high rate of failure in the form of poor product quality and missed deadlines. Back when I started at the company, I introduced them to Agile methodologies and how they could benefit the organization in higher employee and stake-holder satisfaction, fewer or no missed deadlines, and better product quality. After some initial mixed reactions I was able to get them on board with the idea — or so I thought!
While I have been successful in implementing many of the Agile practices such as earlier stakeholder involvement, EDUF, iterative development, code refactoring, unit testing, continuous integration, etc. in a relatively short amount of time, I still have to deal with the fact on a daily basis that they have to have very good estimates too far in the future. They must have this information from a budgetary standpoint and in order to be able to make executive decisions in advance about whether or not to proceed with a given project.
I have tried my best to explain how the Agile estimation works, and how trying to estimate too far in the future could be a wasted effort, but after all the time and energy spent, I am beginning to think that perhaps the Agile philosophy is not for all mindsets after all!
