Yet Another Agile Methodology

Yet Another Agile Methodology A simplistic approach to address most non-Agile pain points A whitepaper that helps you identify what approach to going Agile suits you best

Ravi Warrier [email protected]

August, 2007

Based on my experience with projects, its teams and the customers and by doing a simple analysis of what are the most common pain points of these three entities, I have come to an approach that can be applied in the world of Offshore Contractual Software Development (OCSD). By OCSD, I mean all IT companies in the world that provide services such as software development, testing, or maintenance of existing systems to external customers that are not located in the same location (most commonly – in another country). I came up with this approach by simply collating a list of all the problems that the customer and the vendor teams would want to do away with, thereby benefitting from its absence. I took the 6 most common problem statements (and presumably the most troublesome) from the list to derive this methodology. The Six Most Common Pain Points (in no particular order): 1. Less or No Visibility / Lack of Effective Communication Mechanism: Customers often complain that they have no clue of what happens in the projects they are sponsor. Project teams work in silos and provide no or little information about the problems faced in the project or the execution status. The customers also would prefer some visibility of the product during the development cycle. 2. No Improvement in Processes: Project teams find it hard to change existing processes for the lack of empirical data. Imbibing of good practices and avoidance of impediments would help the project teams to plan and perform better; but existing methods to capture such information in the organization is a painstaking task with (sometimes) heavy and subjective templates to be filled. 3. Bloated Software: Most of the times both customers and vendors realize late in the stages of development, that the features that are developed add no or little business value to the users. At this point, customers (and sometime vendors) change requirements or chop features to make the application lean. This results in hefty re-work and decreases the stability of the system. 4. Poor Quality: If this list was ordered in ascending ranks of problem statements, this one would be on the top. While customers complain frequently on the poor quality of deliverables from project teams, the project teams in turn blame inadequate time lines and frequent change requests for this monster’s existence. Whatever the reason maybe, we might be able to salvage this problem. 5. Effort and Schedule Overruns: Incorrect estimations, re-work (due to any reason) and inconsistent planning are the usual culprits for effort and schedule overruns. Overruns such as these cost vendors and customers up to 300% of the actual contractual obligations, averaging at 60% most of the times. 6. Ever Changing Requirements: Customers are meant to be finicky, but their nature causes many projects to miss their quality, schedule or budgeted cost goals. If requirements can be frozen, approximately 80-85% of projects would not fail to deliver as promised.

My concoction to reduce most head-aches Based on the list I presented above, I created a hybrid process using practices of three different agile methodologies. Here is the recipe of practices I recommend as “must have” with additional practices as optional condiments.

Must Have Practices (Set One) – Increasing Visibility Deliver Frequently (Also known as ‘Small Releases’ in Extreme Programming and ‘Frequent Delivery of Products’ in DSDM). This practices suggests that you have frequent releases of “potentially shippable software” that allows the customers to see gradual (and incremental) progress during the execution of the project. The frequency is suggested to be between 1 – 4 weeks in length and at the end of every such period some functional piece of software must be delivered or demonstrated to the customer. This is possible with the adoption of iterative and incremental development approach. The frequency at which release are made also depends on the volatility of requirements. Higher the rate of change requests, shorter should be the duration.

Optional Practice Whole Team – Extreme Programming (Also known as ‘Active User Involvement’ in DSDM) This practice involves not only the project team members, but also Customer teams and End Users in an active dialog to verify and validate the progress.

Must Have Practices (Set Two) – Improve Processes Daily Scrums, Sprint Retrospectives – Scrum (Also known as ‘Continuous Improvement’ in Extreme Programming) The purpose of this practices is to communicate – ‘What works’ and ‘What Could Work Better’. Daily Scrums are internal team meetings where the team members inform each other on task updates and problems they faced. Sprint Retrospectives are done at the end of iterations to identify good practices and problems that can be avoided in future sprints. Thereby, fine tuning existing processes to work better.

Must Have Practice (Set Three) – Right Features for Best Business Value Design Improvements & Simple Design – Extreme Programming, Fitness for Purpose (DSDM) Constant design improvements during the life cycle of the project help identify unnecessary functionality and also prioritize features that would result in higher ROIs for the customer. Weeding out dead weight from the project will result also in higher productivity and better quality. This can be done as a part of planning or retrospective meetings by the team involving the customers and end users. Demos at the end of iterations also help the customer/end users to realize what is important to them and what is not.

Must Have Practices (Set Four) – Increasing Quality Code Standard – Extreme Programming, Continuous Testing – Extreme Programming (Also known as ‘Integrated Testing’ in DSDM) Defining Coding Standards and Guidelines for project teams to follow will help in standardizing and maintaining the quality of code. Practices such as continuous testing allow project teams to identify defects early on during the development compared to the late detection of defects as in the Waterfall model.

Optional Practice Pair Programming – Extreme Programming Another method of organizing development teams is to pair programmers to work together on the same piece of work on one terminal that is shared between the two. One writes the code (called the driver), while the other one reviews it in parallel (called the navigator). The pair takes turns in playing each role. This pair is also rotated on other tasks. Two of the primary advantages of this practice are that two minds work on the same code resulting in better logic and the fact the code is reviewed as it is written, resulting in better code sooner.

Must Have Practices (Set Five) – Sticking to Planned Effort and Schedules Planning Game – Extreme Programming (Also known as ‘Planning Poker’ in Scrum) Sustainable Pace – Extreme Programming As per agile practices, the estimation for effort and scheduling needs to be done by the project team and not managers or customers. The team will based on their experience suggest the amount of effort and time that it will take to carry out tasks. This leads to a stronger commitment from the team and increases their productivity since they now have full responsibility and accountability of sticking to their commitments. Sustainable Pace suggests that the team work at a sustained pace through the project (for e.g. 40 hours/week) and avoid spikes in effort to meet deadlines. Planning that is carried out keeping in mind this practice is more effective and realistic.

Optional Practices Self Organizing/Managing Teams – Scrum (Also known as ‘Empowered Teams’ in DSDM) Giving the team the responsibility of planning and estimating may not be enough. It is advisable that the team is also empowered to meet their commitments. Hence, having a self managed team proves beneficial to the project.

Generating Burn-down Charts – Scrum A burn-down chart reflects on the progress the team has made so far in the iteration. It is a graphical representation of the current velocity of execution of the team versus a steady pace. This allows the team to visualize the amount of work remaining and hence move things to a higher gear.

Must Have Practices (Set Six) – Stabilizing Requirements Product Backlog – Scrum (Also known as ‘Base-lining Requirements at a High Level’ in DSDM) Sprint Backlog – Scrum A Product Backlog is a list of all functional and non-functional requirements of the project. It may also include tasks that need to be carried out to clear impediments or resolve dependencies. Having a product backlog allows the team to see a larger picture, though only the requirements that will go into immediate production need to be detailed. A Sprint Backlog on the other hand is a sub-set of the Product Backlog and contains only those requirements/tasks that the team is undertaking for the current iteration. While the iteration is in progress, the customer (Product Owner) is free to modify all product backlog items except those that have moved to the sprint backlog. As mentioned above in practices set one, if the requirements volatility is high, then it is better to have shorter durations for iterations. As you might have noticed, even though the practices are categorized as per the problem statement it immediately solves, it also would help reducing or eliminating other problem which might not figure in the List of Six.

Disclaimer These practices have been borrowed from various agile methodologies, but each of these methodologies has more practices that it suggests implementation. And since, we do not in this concoction of practices implement all practices of a particular methodology; we should not claim to be practicing that methodology. However, by taking a dose of this mix, you can claim to be “agile”. All credit for defining the above practices go to organizations of respective agile methodologies. But however, I take full credit for this tangy cocktail!