Go Agile

Should You Go Agile?

Agile methods are not for everyone.  Certain things must be borne in mind before going agile.  However, agile methodologies are widely applicable and should be used by more people than are currently using them. 

Code and fix, being the common methodology used in today’s environment, requires the application of more discipline and not adding to the chaos.  The light approach adopted by Agile methods have an advantage over heavyweight methods.  When there is no process at all, it is more than likely, simpler processes will be followed and adhered to. 

For those new to agile methods, the question is where to start.  As with any new technology or process, one needs to make one’s own evaluation to see how it fits into your environment. 

The first step is to try out agile methods on suitable projects.  Agile methods are fundamentally people-oriented, which makes it essential to start with a team keen to try and work in an agile way.  A reluctant team is not only more difficult to work with, but imposing agile methods on unwilling people is fundamentally at odds with the whole notion of agile development. 

It is valuable to also have customers (those who need the software) who want to work in a collaborative way.  Without customer collaboration, one may not see full advantages of an adaptive process.  On the other hand, customers reluctant to collaborate may soon change their mind as they being to understand the agile approach. 

There are those who claim agile methods cannot be used on large projects.  However, ThoughtWorks, an India based firm has been successful with agile projects that involved around a 100-people across multiple continents.  Even so, it would be best to pick a small project to start with.  Large projects being inherently more difficult to handle, it would be better to learn on a project that is easily manageable i.e. small in size. 

Don’t pick a project with little business impact even though it means less damage if anything goes wrong.  However, it also means an unimportant project makes for a poor test, since nobody cares much about the outcome.  Far better, to try agile methods on a project that is a bit more critical than you are comfortable with. 

Again, find someone experienced in agile methods to teach you from his mistakes.  Once a good mentor has been found, make it a point to follow his advice closely. 

Hopefully, you are now convinced about your readiness to use agile methods?  Over the last ten years, lot of experience has been gained in the use of agile methods.  If, your clients are ready and willing, I would advise you to always use an agile approach.  This way, slowly and surely there will be many more converts to the agile approach. 

Agile Solutions – Part I

 The past few years have seen software methodology adopting a new style and going agile!  Well known as Agile Methods, the style is adaptive, people oriented in nature and has stirred up a whole lot of interest. A kick reaction to engineering or plan driven methodologies, agile methods are attempts to compromise between no process and too much process.  As well, Agile Methods tend to be:

 Adaptive Not Predictive

Engineering methods mean a planned detailed software process covering a long time span, while resisting change.  Agile methods, however, welcome it, they are processes that adapt and thrive on change, even to the point of changing themselves.

 People-Oriented Rather Than Process-Oriented

Engineering methods aim at defining processes that work for whoever uses them.  Agile methods assert a process cannot match the skills of a development team, they only play a support role in development team work. Indepth exploration of the differences makes it easier to understand what adaptive or people-centred processes are about, their benefits, drawbacks, and usefulness if used by developer or software customer. 

PREDICTIVE Vs ADAPTIVE

Separating Design and Construction

Design and construction, two fundamentally different activities show that difficult to predict design requires expensively creative people, while easier to predict construction with only once design in place, can easier to predict construction begin.

Unpredictability of Requirements

In every project, developers can be heard complaining that the problem with the particular project is that requirements are always changing.  Not surprising, as in building business software requirements, changes are the norm.  The question is what is to be done as software development is a design activity that is hard to plan for and estimate the cost for, as basic materials change rapidly and much depends on which individual people are involved resulting in unpredictability.

Is Predictability Impossible?

While, predictability is very desirable, however letting it go does not mean reverting to uncontrollable chaos.  All one needs is a process that gives control over unpredictability, which explains what adaptability is about.

Iterations – Controlling an Unpredictable Process

So, the key to an unpredictable world could be either iterative development or frequent production of the final system working version with a sub-set of the required features.  While iterative development may be short on functionality, it is faithful to the demands of the final system.  That is why these features should be fully integrated and carefully tested as the final delivery for best results. A far better process than traditional methods that document the entire process, which means flaws are hidden as in untested code.  However, sitting in front of a system and working with it, reveals all flaws, both in terms of bugs and misunderstood requirements.  Agile, an iterative and incremental process is adaptive in nature and totally able to deal with changes in required features.  So, long term plans are fluid, while the only stable plans are short term plans made for single iterations.  As well, iterative development also gives a firm foundation to each iteration, which means later plans can be based around it. The key question is, how long should an iteration be.

Different Agile methods suggest different time frames, e.g. XP suggests iterations of one or two weeks, SCRUM suggests a month, Crystal stretches it further.  However, the tendency is to make each iteration, as short as one can get away with, as this not only provides more frequent feedback, but tells you where you are more often.

Adaptive Customers

An adaptive process requires adaptive customers, since it gives them much more control over software development processes.  They get to check progress made at every iteration, which allows them to alter the direction of software development, resulting in a much closer relationship with the software developers and the formation of a a true business partnership. The customer benefits due to numerous advantages of using agile methods, such as, much more responsive software development and a usable, although minimal system that goes into production early.  As well, the customer can change system capabilities in keeping with changes in business, is also able to learn how the system is used in reality which allows for risk control and is indeed, a key advantage of iterative development.  Further, keeping iteration lengths small means variations can be seen in different ways.

We continue to talk about Agile Solutions in Part II.

Agile India – Myth Buster

 Introducing Agile in India, the Agile India 2005 conference jointly organized by the Agile Software Community of India (ASCI) (founded by a group of enthusiastic Agile practitioners from companies that practice Agile Software Development methodologies) and Symbiosis Institute of Computer Studies and Research (SICSR) saw a lot of serious discussion and a lot of fun.  It was also a huge success, evident from the fact that Agile / XP are becoming more and more popular in the Indian Software Community.  Which, a bunch of Agile enthusiasts in Bangalore proved by forming an Agile India Users group.  Research on Google searches and you will notice that a large volume of agile development searches are coming from Bangalore, India’s answer to the Silicon Valley in California, US of A.

And, while the rumour floated says, the original Agile Manifesto was drafted by all white males, Primavera Systems Inc., a vendor of enterprise project management software, busts the myth that agile processes will keep development jobs in the United States, by using the agile development process and outsourcing product development to the Indian operation of product engineering outsourcer Symphony Services Corp.  Symphony that uses agile development techniques for eight software companies.

Along similar lines of the East West Great Divide, we have Michael Hugos writing for CIO magazine and website – a part of International Data Group (IDG), the world’s leading technology media, research and event firm, stating that his experience and observations have lead him to conclude, India is capable of being just as agile as America.  A 30-Day Blitz in India and matching his Indian experience with that of IT teams in the United States, he found that on both continents agile concepts slowly took hold, while agility proved to be as much of a challenge for some team members, as it came more easily to others.

Thus, for the bleached half of the Great Divide to debate whether the relative newness of these ideas and cultural norms would make it harder for Indian developers to embrace these concepts is not only racist in nature, it shows that the West continues to suffer insufferably from a superiority complex, a lingering hangover from their colonial days.  It’s just like saying ‘White guys can’t jump’ or in Michael Hugos own words: “What I see though, is that it’s unfair to say Indians can’t be agile just as it’s unfair to say that white guys can’t dance (being a white guy myself, I’m very sensitive to that particular generalization…).”

Hugo writes that across the Great Divide Agile behaviour transcends cultures, with people on both sides starting off with a ‘can-do’ attitude and a high level conceptual system design, followed by a deeper probe into production system creation details, negotiation attempts to cut scope, and much resisted by business people.  This was followed by teams going off to put together the hardware and software components, and on testing saw the components actually worked as envisioned, their enthusiasm was once again fuelled, with renewed cooperation and exploration of options replacing earlier reluctance and bargaining, as the agile spirit manifested itself and they sprinted to the finishing line.

Ergo, not only is it politically incorrect but also down right ridiculous to question Indians or for that matter any ethnic community’s ability to be Agile.  One cannot say traits exhibited in Agile teams are cultural traits, they are traits of an individual and there are people in both American and Indian culture, including other cultures who manifest these traits.  And, for a country like India who is fast turning into a very entrepreneurial country, entrepreneurship means agility, and as history proves that Indians have exhibited more agile entrepreneurship than any other race or culture in their travels and setting down roots across the globe.

While, it is true that India is less experienced in Agile tactics and techniques, it does not mean they cannot and are not learning fast.  Already, a number of firms, such as, Net Solutions and Xebia, employing Agile techniques with considerable success, recommend agile approaches to software development because they deliver value to organizations and end users faster and with higher quality.  As for, Thoughtworks India, their projects are ‘pure Agile’.  So much for generalisations about agility being the exclusive domain of any one culture!  That’s like Hitler and his Nazi’s ludicrous claim that Aryans are a race of blond, blue-eyed giants.  To bust that myth, I’m an Aryan of warm golden skin, brown eyes and black hair.  That makes me feel like jigging to on Boney M’s song:

‘Brown Girl in the Ring!

Tra la la la la!There’s a brown girl in the ring!

Agile Testing

As new and better software development ways are being uncovered, the following holds much value i.e.:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

 Two key imperatives underlying these values are: 

Work Code

A general thumb of rule is that programmers are more comfortable getting on the computer and getting it to do something, than writing documentation.  Similarly, Agile believes in the Hands-On Imperative and extends it even to users.  Why?  Because, most mental activities need external resources, with different resources making us think in different ways.  And, that is why people who document or design models, think differently from those working on software.

Because, Agile projects understand that, they deliver working software (or perhaps executable proto-types) as quickly and as frequently as practical.  Development is a rapid series of functionally complete releases the user can try out.  Each release being the first chance a user’s had to think about new features, means re-work on the release is just part of the job, not a crisis. 

Open Communication

With little or no documentation, Agile projects keep everyone in synch due to increased human contact i.e. face-to-face conversation and collaboration.  XP has people programming in pairs, with most often a customer representative working most days in the bullpen with the developers.  Scrum holds daily stand-up meetings that create and preserve group understanding.  Crystal, perhaps the least dogmatic process conceivable, nevertheless insists on frequent retrospectives.  All these techniques tend to foster communication that documents cannot replace.

And, since all Agile methods want a customer to be part of the team, with a suitable customer representative on hand, one does not require a detailed requirements document.  You have a question, simply turn around and ask it!  Worried the right question won’t be asked?  Well, you can implement something and show it to your customer for a quick reaction.  Without much ado about nothing, you’ll quickly learn if you’re going off track. 

Agile Testing

These same imperatives can also underlie Agile Testing, and most obviously apply to Agile development projects.  However, they work, though less well on conventional projects, as well.

But, first abandon the idea that communication is about one party communicating with requirements and design documents, while the other comes back with test plans and bug reports.  You know full well that documents tests are based on are flawed i.e. incomplete, incorrect, and ambiguous and to be viewed only as interesting texts, partly fictional, often useful.

Agile testing communication should be all about joining in and encouraging ongoing project conversation.  Testers and developers need to sit in the same bullpen or share offices.  Testers should be made help particular developers, rather than just testing how pieces of the product work.  ‘Drop-in meetings’, short, informal discussions, etc. help in test status reports via big, public, simple-to-read charts that answer specific development questions, such as, which product parts are working well.

Communicating with the customer is as important as communicating with developers, as more often than not, the customer is trying to figure out what is needed, what they want, whether they are getting it.  And, they can only do this by testing the working code and talking to the developers and testers.  Testers should sit down with them as try out the product sample, as creating tests together is an excellent way for both to learn what matters.

Hands On helps developers improve and complete the product and value tests they can run as they develop.  While, Agile Testing may not be the answer to all projects, neither are any of the Agile Methods.  Acutally, no single approach is, but experimenting with different project styles is essential if a standardised software development practice is to be arrived at. 

Agile Maintenance

 Introduction

The purpose of this document is to explore suitable maintenance metrics for agile methods. Software maintenance defined as ‘the process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment’, comprises of four kinds of software maintenance, e.g.:

1. Corrective maintenance corrects faults in hardware or software.
2. Adaptive maintenance makes a computer programme usable in a changed environment.
3. Perfective maintenance improves the performance, maintainability, or other attributes of a computer programme.
4. Preventative maintenance prevents problems before they occur.

 Agile Methods

General

Relatively new, light weight software development methods and processes, Agile methods attempt to reduce the bureaucracy of the software development process, so as to minimize time to market. 

Adaptive rather than predictive, agile methods welcome change and are people-oriented rather than process-oriented engineering methods.  The Agile model is about small projects, bug reports and story cards, developer estimate, customer prioritisation of bugs, bug tracking database, QA test and writing functional acceptance and failing unit tests, fixing unit and functional tests, regression testing before release.

Maintenance

Designed to handle changing requirements, so that the product can be maintained right from the start, Agile maintenance methods have been successfully used.  Since, maintainability is dependent on product environment; both product and documentation need to be maintained.  And, as product structure predicts the effectiveness of a maintenance process, it proves itself to be a far more practical method, as internal measures are available earlier than external process measures. 

Maintenance process is about making product changes i.e. to codes, documents, etc. whenever necessary, with maintenance done using agile methods validated, based on the same measures as other processes. 

Conclusions

Being less dependent on documentation processes, Agile methods usually produce less documentation, making the development process more dynamic, with product design evolving during implementation.  Therefore, it is but natural to doubt the maintainability of products produced using Agile methods.  However, it has been proved that it is possible by offshore firms like AgileCollab and XCbia.  With sufficient experience in using Agile methods in client projects, they know how to maintain end products these methods produce.

All About SCRUM – Part II

Yesterday, we talked about SCRUM characteristics, phases and game plan, taking up from where we left off, today we discuss controls, deliverables and again characteristics. 

SCRUM Controls

Playing constantly at the edge of chaos, complex, unpredictable projects make it necessary to institute management controls to prevent the resultant mayhem.  Actually embodying general, loose controls, SCRUM methodology is the primary control that helps construct deliverables successfully. SCRUM methodology controls include:

• Product / Project Backlog, such as, bugs, defects, customer requested enhancements, competitive product functionality, competitive edge functionality, and technology upgrades.
• Release / Enhancement, backlog items that represent viable release based on requirements, time, quality, and competition variables.
• Changing packets or product components / objects to implement new release of backlog items.
• Packet changes that occur to implement backlog items.
• Technical problems that must be solved to implement a change.
• Risks effecting project success are continuously assessed and responses planned.
• Solutions are found to resolve project risks and problems, and often lead to change.
• Issues Overall project and project issues that are not defined in terms of packets, changes and problems.

Jointly managing product / backlog backlog, issues, risks and solutions using these controls, management and teams review, modify and reconcile them at every Sprint review meeting.

DELIVERABLES

As market intelligence, customer contact and developer skills are the key deliverable determinants, the delivered product with its content determined by environmental variables, including time, competition, cost, or functionality, turns out to be completely flexible, and undergoing various environmental adjustments, it is deliverable anytime during the project. 

Typically, new release SCRUM Project Team is made up of a small team of full time developers, documenters and quality control staff, including marketing, sales, and customers.  All, not a normal part of any traditional release process, as their unnecessary interference can lead to complications.  A SCRUM approach, however, welcomes such controlled involvement, as it helps to increase the appropriateness, usefulness and marketableness of released content and its timing. 

A metaphor for the game of Rugby, SCRUM methodology and  SCRUM projects are characterised as under:

• Flexible deliverables with environment dictated content.
• Flexible schedules, since deliverables may be required sooner or later than initially planned.
• Multiple team project comprising of no more than six members.
• Frequent team progress reviews of one to four week cycles.
• Intra and inter-collaboration.
• Object Oriented, as each team addresses a set of related objects. 

Flexible throughout, SCRUM methodology frees developers to devise ingenious solutions that adapt well to environment changes, while its controls deal with product backlogs efficiently and quickly. 

All About SCRUM – Part I

To make it easirer to understand SCRUM, we once again SCRUM out, reiterating what we said in SCRUM – All About Commonsense And Chaos Control.

An agile method, SCRUM is an enhancement of the commonly used iterative / incremental object-oriented development cycle

The SCRUM approach used at leading edge software companies with significant success has seen several variants of it in play for new product development, with high performance small teams at Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, and Hewlett-Packard, where it was first noticed.

A management, enhancement and maintenance methodology for an existing system or production prototype, it plans software product releases based on the following variables:

•  Customer requirements – how the current system needs enhancing.
• Time pressure – what time frame is required to gain competitive advantage.
• Competition – what competition is up to, and what is required to best them.
• Quality – what the required quality is, given the above variables.
• Vision – changes required to fulfil system vision.
• Resource – availability of staff and funding.

Forming part of a software enhancement project’s initial plan, these variables can change during the project.  Therefore, any successful development methodology has to take these variables and their evolutionary nature into account.  The system development process being a complicated and complex one means, maximum flexibility and appropriate control is necessary.

SCRUM Methodology Characteristics:

• Planning and Closure: The first and last phases consists of well-defined processes, inputs and outputs and understanding well how these processes are to be carried out.
• Sprint: This phase comprises of many unidentified or uncontrolled processes that require external controls.  Accordingly, controls including risk management, are put on each iteration of the Sprint phase to avoid chaos while maximizing flexibility.
• Non-linear and flexible Sprint uses explicit process knowledge if available; tacit knowledge if not and relies on trial and error to build process knowledge, using sprints to evolve the final product.
• Closure: This phase involves remaining open to environmental complexity, including competitive, time, quality, and financial pressures, throughout.  Deliverables can be changed any time during the planning and Sprint phases.
• The deliverable is determined during the project based on the environment.

So, primary SCRUM characteristics can be identified as under:

PROJECT STAGES	SCRUM
Defined processes	Planning & Closure only
Final product	Set during project
Project cost	Set during project
Completion Date	Set during project
Responsiveness to environment	Throughout
Team flexibility creativity	Unlimited during iterations
Knowledge Transfer	Teamwork during project
Probability of success	High

 PHASES

SCRUM is made up of the following groups of phases and is all about:

Pre-game:

• Planning: Defines a new release based on current backlog, together with schedule and cost estimate which is considered limited analysis, while new system development is considered as conceptualization and analysis. 
•  Architecture: Comprises of architecture modification and high level design, including designing implementation of backlog items.

Game

• Development Sprints involve multiple, iterative development sprints, or cycles, used to evolve the system, developing  development new release functionality, in respect to time, requirements, quality, cost, and competition variables.  And, interaction with these variables defines end of the phase. 

Postgame

Closure: This phase is all about preparing for release, including final documentation, pre-release staged testing, and release.

Phase Steps

Each phase follows the following steps:

Planning

•  Developing a comprehensive backlog list.
• Defining delivery date and functionality releases.
• Selecting release of the most appropriate for immediate development.
• Mapping product packets (objects) for backlog items in selected release.
• Defining project team(s) for building the new release.
• Assessing risk and appropriate risk controls.
• Reviewing and adjusting backlog items and packets.
• Validating / re-selecting development tools and infrastructure.
• Estimating release cost, including development, collateral material, marketing, training, and rollout.
• Verifying management approval and funding.

Architecture / High Level Design is about:

•  Reviewing / assigning backlog items.
• Identifying necessary changes backlog items implementation.
• Performing domain analysis for building, enhancing, or updating necessary to reflect the new system context and requirements.
• Refining system architecture.
• Identifying problems / issues in developing / implementing changes.
• Holding design review team meetings with re-assign changes as required.

 Development (Sprint)

This phase is an iterative cycle of development work, with the management determining time, competition, quality, or functionality are met, iterations are completed and the closure takes place.  Also known as Con-current Engineering, development consists of:

·         Meeting with teams to review release plans.

·         Distribution, review and adjustment of product conforming standards.

·         Iterative Sprints, until product is deemed ready for distribution.

A Sprint is a set of development activities conducted over a pre-defined period, usually one to four weeks, with intervals based on product complexity and risk assessment.  Each Sprint consists of one or more developing, wrapping i.e. creating an executable version of changes, reviewing and adjusting. 

Each Sprint is followed by a review, with the whole team and product management present and participating, and can include customers, sales, marketing and others, all together determining the next review based on progress and complexity.  These Sprints usually have 1 to 4 weeks duration.

Closure

When the management team feels time, competition, requirements, cost, and quality variables concur on a new release, the release is declared closed and entering the closure phase, which prepares the developed product for general release.  Closure tasks include integration, system test, user documentation, training material preparation, and marketing material preparation.

That’s for the day, next time, we’ll talk about SCRUM controls, deliverables and advantages.

SCRUM – All About Commonsense and Chaos Control

We take up from Taking Agile Mainstream and talk exclusively about a popular agile method i.e. SCRUM.

SCRUM is an agile process that has proved useful in the management and control of complex software and product development, and has not only been successfully used in simple projects; it has also changed the way entire enterprises do business, increasing productivity, while reducing time. Basically, it is an iterative, incremental process for developing products or managing work, producing a potentially shippable functionality set at the end of every iteration, SCRUM attributes are as follows:

• It is an agile process for managing and controlling development work.
• It is the outside wrap for existing engineering practices.
• It is an iterative, incremental team-based approach to develop systems and products for rapidly changing business requirements.
• It effectively controls the chaos resulting from conflicting interests and needs.
• It is a way to improve communications and maximize co-operation.
• It is useful in detecting and removing any issues that get in the way of product development and delivery.
• It maximizes productivity.
• It can be scaled for single projects to entire organizations and can control and organize development and implementation for multiple inter-related products and projects with over a thousand developers and implementers.
• It gives everyone a feel good feeling about their job, their contributions, firm in the belief that they have done their very best.

 Whether, implemented at the beginning or middle of a project, or when a development effort is in distress, SCRUM can if there are no major changes, help teams build and deliver demonstrable product functionality within thirty days.

A set of inter-related practices and rules, SCRUM optimizes the development environment, reduces organizational overhead, and closely synchronizes market requirements with iterative proto-types.  Using SCRUM, one can construct the best possible software with available resources within required release dates, delivering useful product functionality every thirty days as requirements, architecture, and design emerge, even when using unstable technologies.

Over 50-organizations have used it successfully, seeing significant improvement in productivity.  SCRUM, not only improves an organisation’s existing engineering practices; it delivers product increments to users and is a development framework based on values, practices, and rules, quickly implemented and repeated.

SCRUM can produce financial products, Internet products, and medical products by ADM, successfully breaking the log jam where such organizations are unable to produce shippable products, causing great concern to engineers, management, and investors.  However, SCRUM broke the log jam beginning incremental product delivery, often the first shippable products being shipped within the same quarter.

A respected agile method, Net Solutions, an offshore web design and development firm is a firm believer in SCRUM, using it to great success in its many projects.

Taking Agile Mainstream

This blog, perhaps, repeats what we talked about in Agile Introduction For Dummies – Part I and Agile Introduction For Dummies – Part II, but it is essential to ensure that one understands the dynamics of Agile methodology clearly.  So, here we go once again!

The past few years have seen software methodology adopting a new style and going agile!  Well knownas Agile Methods, the style is adaptive; people oriented in nature and have stirred up a whole lot of interest.  It is also seen as an antidote to bureaucracy or licence to hack. A reaction to engineering or plan driven methodologies, agile methods are an attempt at compromising between no process and too much process, providing just enough process to gain a reasonable pay-off.  As well, Agile Methods tend to be:1.       Adaptive rather than predictive.  Engineering methods mean a planned detailed software process covering a long time span and a nature that resists change.  Agile methods, however, welcome it, trying to be processes that adapt and thrive on change, even to the point of changing themselves.2.       People-oriented rather than process-oriented.  Engineering methods work at defining processes that will work for whoever uses them.  Agile methods assert a process cannot match the skills of a development team, only playing a support role in development team work. Exploration of the differences in detail makes it easier to understand what adaptive or people-centred processes are about, their benefits, drawbacks, and usefulness if used by developer or software customer. 

PREDICTIVE Vs ADAPTIVE

Separating Design and Construction

Design and construction, two fundamentally different activities show that difficult to predict design requires expensively creative people, while construction is easier to predict, and only once design is in place, can easier to predict construction begin. 

Unpredictability of Requirements

In every project, developers can be heard complaining that the problem with the particular project is that requirements are always changing.  Not surprising, as in building business software requirements, changes are the norm.  The question is what is to be done as software development is a design activity that is hard to plan for and estimate the cost for, as basic materials change rapidly and much depends on which individual people are involved resulting in unpredictability. 

Is Predictability Impossible?

Generally speaking, one cannot say predictability is not predictable.  While, it is very desirable, however letting it go does not mean reverting to uncontrollable chaos.  All one needs is a process that gives control over unpredictability, which easily explains what adaptability is all about. 

Iterations – Controlling an Unpredictable Process

So, what is the key to an unpredictable world?  Is it iterative development or frequent production of the final system working version with a sub-set of the required features?  While iterative development is short on functionality, it is otherwise faithful to the demands of the final system; hence these features should be fully integrated and carefully tested as the final delivery for best results. A far better process than traditional methods where before doing anything else, the entire process is documented, and as one knows documents can hide all sorts of flaws, as does untested code.  However, sitting in front of a system and working with it, allows these flaws to become truly apparent, both in terms of bugs and misunderstood requirements. Agile, an iterative and incremental development process is adaptive in nature and can totally deal with changes in required features.  This means fluid long term plans, as the only stable plans are short term plans made for single iterations.  AS well, iterative development also gives a firm foundation to each iteration, which means later plans can be based around it. The key question is, how long should iteration be.  Different Agile methods suggest different time frames, e.g. XP suggests iterations of one or two weeks, SCRUM suggests a month, Crystal stretches it further.  However, the tendency is to make each iteration, as short as can be got away with, as this not only provides more frequent feedback, but allows you to know where you are more often. 

Adaptive Customers

An adaptive process requires adaptive customers, since it gives them much more control over software development processes.  They, not only get to check progress made at every iteration, they can also alter the direction of software development, which often results in a much closer relationship with the software developers, a true business partnership. The customer benefits, as there are a number of advantages to using agile methods, such as, much more responsive software development and an usable, although minimal system that goes into production early on.  As well, the customer can change system capabilities according to changes in business, and is also able to learn how the system is used in reality allowing for risk control, which is indeed, a key advantage of iterative development.  Further, keeping iteration lengths small means variations can be seen in different ways. 

PUTTING PEOPLE FIRST

Another attraction of agile methods is that they put people first, since adaptive process execution is not easy task and requires a very effective team of developers i.e. effective both in quality of the individuals, as well as, team blending.  Adaptivity requires a strong team and it bodes well for agile method application to a project, since it is a well known fact that most good developers prefer an adaptive process. 

People Oriented Process Management

A people oriented process, agile process acceptance requires commitment and active involvement of all the team, as these methods like Extreme Programming (XP) requires a lot of discipline to execute, with the less disciplined Crystal approach, far more suited to a wider audience. As well, developers are required to be able to make all technical decisions, with XP getting to the heart by stating that only developers are allowed to estimate how much time it will take to do the work.  This shift in technical leadership requires developers and management to share responsibility and an equal place in project leadership.  While, management still plays a role, it also recognizes the expertise of developers. 

The Role of Business Leadership

However, technical people cannot do the whole process themselves and require guidance in terms of what a business needs, which highlights another important adaptive processes aspect i.e. close contact with business expertise. 

AGILE DEVELOPMENT

The term agile refers to a philosophy of software development which includes many specific approaches under its broad umbrella, approaches, such as, Extreme Programming, SCRUM, Lean Development, etc., each of them having their own particular approach and own ideas..

Extreme Programming (XP)

While, during the late 1990’s, Extreme Programming got the lion’s share of attention, in many ways it still does and it beings with five values (Communication, Feedback, Simplicity, Courage, and Respect).  It further elaborates these into fourteen principles, and again into twenty-four practices, placing a strong emphasis on testing.   While, all processes mention testing, not much emphasis is placed on it.  However, XP believes testing is the foundation of development and has every programmer writing tests and production code, simultaneously, which are then integrated into a continuous integration and build process, yielding a highly stable platform for future development. 

SCRUM

In the 1980’s and 1990’s, Scrum also developed as a highly iterative development methodology that concentrates on the management aspects of software development, dividing development into thirty day iterations (called ‘sprints’) and applying closer monitoring and control, by holding daily scrum meetings.  It places much less emphasis on engineering practices, with many people combining its project management approach with extreme programming engineering practices. 

CRYSTAL

The Crystal family of software development methods approaches tailored to different size teams approach.  Despite varying, all crystal approaches share common features and have the following priorities:

• Safety (in project outcome, efficiency, habitability.
• Frequent Delivery,
• Reflective Improvement, and
• Close Communication.

Lean Development

Lean movement pioneered at Toyota was an inspiration to many of early agilists, but one should be wary of the engineering separation between design and construction.  However, there are still interesting ideas to be got from the lean direction.

SHOULD YOU GO AGILE?

Using an agile method is not for everyone.  However, these methodologies are widely applicable their use should be seriously considered.  The most common methodology of code and fix often results in chaos, showing that the discipline and lightweight agile approach found missing in heavyweight methods is the better method. Start by finding projects that agile methods can be tried on, and since methods are so fundamentally people-oriented, it is important to start with a team receptive to being agile.  As well, you will also need to find someone experienced in agile methods, having learnt through making mistakes.  And, then you may find out about the many advantages of going agile! 

Agile Introduction For Dummies – Part II

This is a continuation of Agile Introduction For Dummies – Part I. 

While, having much in common e.g. what they value, Agile Methods also differ in practices they suggest, such as, Extreme Programming, Scrum, Crystal Methods, Feature Driven Development, Lean Development, and Dynamic Systems Development Methodology.

EXTREME PROGRAMMING

And, Extreme Programming is undoubtedly the hottest Agile Method to emerge in recent years.  XP owes much of its popularity to developers disenchanted with traditional methods and looking for something new, something extreme. The 12-rules of Extreme Programming, true to the nature of the method itself, are concise and to the point.

• The planning game: Each iteration begins with customers, managers, and developers fleshing out, estimating, and prioritizing requirements or ‘user stories’ for the next release, capturing it in a language that everyone can understand.
• Small releases: An initial version of the system is put into production after the first few iterations.  Subsequently, working versions are put into production anywhere from every few days to every few weeks.
•  Metaphor: Customers, managers, and developers construct a metaphor, or set of metaphors after which to model the system.·         Simple design: Developers are urged to keep design as simple as possible, say everything once and only once.
• Tests: Developers write acceptance tests for their code before they write the code itself, while customers write functional tests for each iteration, with tests being run at the end of each iteration.
• Re-factoring: As developers work, the design evolves and is kept as simple as possible.
• Pair programming: Two developers sit together at the same machine to write the code.
• Continuous integration: Developers integrate new code into the system, as often as possible and all functional tests must be passed code integration, or else the new code is discarded.
• Collective ownership: The code is owned by all developers, and they may make changes anywhere in the code at anytime they feel necessary.
• On-site customer: A customer works with the development team at all times to answer questions, perform acceptance tests, and ensure that development is progressing as expected.

 SCRUM

Scrum, along with XP, is one of the more widely used Agile Methods, it is a process that accepts the development process is unpredictable and formalising the do what it takes mentality has found success with numerous independent software vendors.  Scrum projects are split into iterations (sprints) consisting of the following:

1. Pre-sprint planning: All system work is kept in ‘release backlog’.  During pre-sprint planning, features and functionality are selected from the release backlog and placed into the ‘sprint backlog’, or a prioritized collection of tasks to be completed during the next sprint.
2. Sprint: Upon completion of pre-sprint planning, teams are handed their sprint backlog and told to sprint to achieve their objectives.  The sprint backlog is frozen and remains unchangeable for the duration of the sprint. Team members choose the tasks they want to work on and begin development.  Short daily meetings are critical to the success of Scrum.  Scrum meetings are held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.
3. Post-sprint meeting: After every sprint, a post-sprint meeting is held to analyze project progress and demonstrate the current system.

CRYSTAL METHODS

Crystal methods focus on people, inter-action, community, skills, talents, and communication as first order effects on performance.  Process remains important, but secondary.  All Crystal methods begin with a core set of roles, work products, techniques, and notations, and this initial set is expanded as the team grows or the method hardens.

FEATURE DRIVEN DEVELOPMENT

The Feature Driven Development method comprises of the following core values:

1. Putting in place a system for building systems is necessary for successful scaling of larger projects.
2. Putting together a simple, well-defined process that works best.
3. Ensuring process steps are logical.
4. Get rid of ‘Process pride’ as it keeps the real work from happening.
5. Good processes are moved to the background to allow team members to focus on results.
6. Short, iterative, feature-driven life cycles are considered the best.

 And, feature driven development begins by:

1.      Building a features list.

2.      Planning feature by feature.

3.      Designing by feature and building by feature.

LEAN DEVELOPMENTThe Lean Development Agile method focuses on twelve management strategies, as follows:

1.      Customer satisfaction is the highest priority.

2.      Always provide the best value for the money.

3.      Success depends on active customer participation.

4.      Every Lean Development project is a team effort.

5.      Everything is changeable.

6.      Domain is not the point, however solutions are.

7.      Complete, do not construct.

8.      An 80% solution today, instead of a 100% solution tomorrow.

9.      Minimalism is essential.

10.  Needs determine technology.

11.  Product growth is feature growth, not size growth.

12.  Never push Lean Development beyond its limits.

DYNAMIC SYSTEMS DEVELOPMENT METHOD

Dynamic Systems Development Method (DSDM) is not so much a method as it is a framework with a six stage life cycle.

1. Pre-project: The pre-project phase establishes that the project is ready to begin, funding is available, and everything is in place to commence a successful project.
2. Feasibility study: DSDM stresses that the feasibility study should be short, no more than a few weeks.  And along with the usual feasibility activities, this phase should determine whether DSDM is the right approach for the project.
3. Business study: The business study phase is strongly collaborative, using a series of facilitated workshops attended by knowledgeable staff, who are quickly able to pool their know-how and gain consensus regarding development priorities. This phase results in a Business Area Definition, identifying users, markets, and business processes affected by the system.
4. Functional model iteration: Functional model iteration aims to build on high-level requirements identified in the business study.  The DSDM framework works by building a number of proto-types based on risk, evolving these prototypes into the complete system.  This phase and design and build phases have a common process:
   • Identify what is to be produced.
   • Agree how and when to do it.
   • Create the product.
   • Check it has been correctly produced (by reviewing documents, demonstrating a proto-type or testing part of the system).
5. Design and build iteration: The prototypes from the functional model iteration are completed, combined, and tested and a working system delivered to users.
6. Implementation: During implementation, the system is transitioned into use by creating an Increment Review Document that discusses the state of the system.  Either the system meets all requirements and is considered complete, or there is a missing functionality (due to omission or time concerns).  If, there is still work to be done on the system, the functional model design, build, and implementation phases are repeated until the system is complete.
7. Post-project: This phase includes normal post-project clean-up, as well as on going maintenance. And so, Agile Methods proving popular are here to stay.  As seen, there are many Agile Methods to select from, but before an organization selects and implements an Agile Method, it should decide whether it is ready to go agile or not.