I debated whether I should pollute my philosophy and literature blog with a post about software development methodologies, and then I rationalized its inclusion with the thought that a post about software development methodologies is very much about people, their perceptions, psychologies and egos, and hence, it belongs! So, here it goes ... an open-minded, practitioner's viewpoint.
First, let me say that there are purists, and then the rest of us. This article is for the rest of us! This opening remark is not to put down the purists - they have done a marvelous job evangelizing the methodologies, and the most recent one being the agile methodology. A wikipedia link for starters, and the reader may navigate on to any level of detail: http://en.wikipedia.org/wiki/Agile_software_development.
Without writing any more about the much-written-about topic, it suffices to summarize that the agile methodology is about rapid, incremental, monotonic improvement. This is where this methodology aligns with my philosophy of playing the financial markets - short term gratification, continuous net positivity in transactions, resulting in a monotonic growth in your portfolio. This involves enormous focus on managing the downside risks (my popular quote: exit strategies are enormously more important than entry strategies - you may enter a trade that turns out good in retrospect, and the exit strategy needs to maximize the gain that comes from it, or you may enter a trade that turns out bad in retrospect, and the exit strategy needs to get you out with minimal damage)
I'll put forth my views on a practical agile methodology in a principles-centered approach:
Principle 1. Agile helps manage budget and timeline risk.
The key to managing project risk is achievement of frequent and regular achievement of client-releasable software builds, that can be shown to internal and external stakeholders. The shorter the sprint, quicker can any feedback be provided and lesser is the misalignment between what is desired and what is achieved.
Principle 2. Agile drives the entire organization to common goals.
The agile methodology is not about structuring the work of software developers, but the entire organization. "Together we succeed, and together we fail". This is not to imply a divided blame when we fail, but a collective ownership of the quality of the output. Whether the requirements are well-defined or not, whether the code written is of good quality or not - these and other situations are caught in near-real-time and acted upon. Capacity imbalances by functional expertise are identified quickly and may be escalated to management without delay.
Principle 3. Agile minimizes rework through early detection of architecture, implementation, or performance issues.
Requirements, code, test scripts, and documentation reviews by cross-functional teams drive completeness in the common understanding and objectives. Documentation and performance do not become haunting after-thoughts.
Principle 4. Cross-functional Teamwork minimizes formality of interfaces and reduces delays in issues resolution.
Skills frequently exist across functional teams to help each other out. Frequently, developers may suggest changes to requirements to make them easier to implement, business analysts may spot awkwardness in code structure and suggest improvements, documenters may identify user-unfriendliness and bring that to the table before too late.
Principle 5. Collocation of the team is ideal, can rarely be practical. Contemporary technology can provide reasonable alternatives.
There do come times when extreme output needs to be produced in a very short amount of time, and there is no substitute for collocated teams to achieve this. Technology start-ups invariably launch in this mode. It has well been recognized that this model is not scalable, and communications technologies need to be brought to bear for economic efficiency. Work-tracking/ bug-tracking systems offer logical equivalents to physical scrum-boards, conference calls become inevitable alternatives to huddle room meetings. The time zone differences between the locations of team members poses another challenge. Minimally, the teams need to find two daily touch points - preferably one at the beginning of the day and one at the end of the day - and it turns out even better if the beginning of the day of one team is near the end of the day of the other and vice versa. The teams need to avoid falling into the trap of everybody working 24/7, as that mode is not sustainable in the long term.
Some Imperatives:
Imperative 1. There must be a long term view, a macro-level work-plan that the tactical agile methodology is a part of.
The natural tendency in practical agile is to be obsessively short-term-focused. While the execution must be short-term-focused, it must fit in the larger picture - and that can include the configurability of the product, an overarching goal that the client has, or some other long term view.
Imperative 2. Sufficient capacity needs to be reserved for architectural work, and a healthy balance between current production issues and enhancements.
Another natural tendency is to be obsessed with resolving client issues, to the extent that roadmap work and architectural improvements fall by the wayside. Potholes need to be fixed, but the girders of the bridge need to be rust-proofed, as well!
Imperative 3. Automation of Quality Assurance.
Inclusion of Quality Assurance feedback within the sprint cycle can improve the overall quality of the released build. This not only includes unit and integration testing at the technical level but also user-simulated testing at the functional level. Daily builds and automated nightly testing is the ideal. Weekly builds and automated weekend testing may be a livable compromise. The first order of business upon the availability of testing results must be the review of the test case failures and their rationalization. If the failures were as expected, the order of business for the QA team is to adjust the test scripts. If the failures were not expected, the order of business for the development team is to fix the code before any new code is written. Ideally, the sprint stories within a sprint are mutually non-interfering, and a delay in one story need not slow down others. This may not always be the case, and the scrum meeting offers an opportunity to discuss, assess and replan.
First, let me say that there are purists, and then the rest of us. This article is for the rest of us! This opening remark is not to put down the purists - they have done a marvelous job evangelizing the methodologies, and the most recent one being the agile methodology. A wikipedia link for starters, and the reader may navigate on to any level of detail: http://en.wikipedia.org/wiki/Agile_software_development.
Without writing any more about the much-written-about topic, it suffices to summarize that the agile methodology is about rapid, incremental, monotonic improvement. This is where this methodology aligns with my philosophy of playing the financial markets - short term gratification, continuous net positivity in transactions, resulting in a monotonic growth in your portfolio. This involves enormous focus on managing the downside risks (my popular quote: exit strategies are enormously more important than entry strategies - you may enter a trade that turns out good in retrospect, and the exit strategy needs to maximize the gain that comes from it, or you may enter a trade that turns out bad in retrospect, and the exit strategy needs to get you out with minimal damage)
I'll put forth my views on a practical agile methodology in a principles-centered approach:
Principle 1. Agile helps manage budget and timeline risk.
The key to managing project risk is achievement of frequent and regular achievement of client-releasable software builds, that can be shown to internal and external stakeholders. The shorter the sprint, quicker can any feedback be provided and lesser is the misalignment between what is desired and what is achieved.
Principle 2. Agile drives the entire organization to common goals.
The agile methodology is not about structuring the work of software developers, but the entire organization. "Together we succeed, and together we fail". This is not to imply a divided blame when we fail, but a collective ownership of the quality of the output. Whether the requirements are well-defined or not, whether the code written is of good quality or not - these and other situations are caught in near-real-time and acted upon. Capacity imbalances by functional expertise are identified quickly and may be escalated to management without delay.
Principle 3. Agile minimizes rework through early detection of architecture, implementation, or performance issues.
Requirements, code, test scripts, and documentation reviews by cross-functional teams drive completeness in the common understanding and objectives. Documentation and performance do not become haunting after-thoughts.
Principle 4. Cross-functional Teamwork minimizes formality of interfaces and reduces delays in issues resolution.
Skills frequently exist across functional teams to help each other out. Frequently, developers may suggest changes to requirements to make them easier to implement, business analysts may spot awkwardness in code structure and suggest improvements, documenters may identify user-unfriendliness and bring that to the table before too late.
Principle 5. Collocation of the team is ideal, can rarely be practical. Contemporary technology can provide reasonable alternatives.
There do come times when extreme output needs to be produced in a very short amount of time, and there is no substitute for collocated teams to achieve this. Technology start-ups invariably launch in this mode. It has well been recognized that this model is not scalable, and communications technologies need to be brought to bear for economic efficiency. Work-tracking/ bug-tracking systems offer logical equivalents to physical scrum-boards, conference calls become inevitable alternatives to huddle room meetings. The time zone differences between the locations of team members poses another challenge. Minimally, the teams need to find two daily touch points - preferably one at the beginning of the day and one at the end of the day - and it turns out even better if the beginning of the day of one team is near the end of the day of the other and vice versa. The teams need to avoid falling into the trap of everybody working 24/7, as that mode is not sustainable in the long term.
Some Imperatives:
Imperative 1. There must be a long term view, a macro-level work-plan that the tactical agile methodology is a part of.
The natural tendency in practical agile is to be obsessively short-term-focused. While the execution must be short-term-focused, it must fit in the larger picture - and that can include the configurability of the product, an overarching goal that the client has, or some other long term view.
Imperative 2. Sufficient capacity needs to be reserved for architectural work, and a healthy balance between current production issues and enhancements.
Another natural tendency is to be obsessed with resolving client issues, to the extent that roadmap work and architectural improvements fall by the wayside. Potholes need to be fixed, but the girders of the bridge need to be rust-proofed, as well!
Imperative 3. Automation of Quality Assurance.
Inclusion of Quality Assurance feedback within the sprint cycle can improve the overall quality of the released build. This not only includes unit and integration testing at the technical level but also user-simulated testing at the functional level. Daily builds and automated nightly testing is the ideal. Weekly builds and automated weekend testing may be a livable compromise. The first order of business upon the availability of testing results must be the review of the test case failures and their rationalization. If the failures were as expected, the order of business for the QA team is to adjust the test scripts. If the failures were not expected, the order of business for the development team is to fix the code before any new code is written. Ideally, the sprint stories within a sprint are mutually non-interfering, and a delay in one story need not slow down others. This may not always be the case, and the scrum meeting offers an opportunity to discuss, assess and replan.
No comments:
Post a Comment