Agile Methodology

Agile Delivers Benefits Early

By practicing agile according to its values and principles, unnecessary activities are removed, and benefits are delivered early. The long, tiring requirements gathering workshops, tedious weekly/monthly status reports and disengaging weekly/monthly status meetings, are outweighed by the daily interaction with the developers and constant consultation with the stakeholders until best solutions techniques are uncovered. In agile, the rigorous project planning and test planning, and the bureaucratic requirements sign-offs and change request management, are deemed impractical; while working software constantly being delivered to customers is integral and among agile primary focuses.

Furthermore, agile hinges on the engagement, collaboration, and adaptability of the individuals who strive to be self-organizing and to produce innovative ideas. Lastly, the occurrences of having features that never add business value and code that will never get used, are reduced – increasing the savings from the costs of “work not done.”

Different Agile Methods

A number of methods, all adhering to agile values and principles, have been emerging for the past several decades. Each, a blend of practices and techniques, was developed from different viewpoints for different project-team conditions. Here are some of the widely used agile methods in software development today.

Agile Scrum

As described by one of its advocates, agile Scrum employs an iterative, incremental development approach where certainty is optimized, and risks are controlled. Its foundation is on the empirical process control theory which asserts that knowledge arises from experiences, and best judgment is based on what is known.

Agile Scrum simply has three roles:

• The product owner who envisions direction of development
• The scrum master who acts as team coach
• The Scrum team who builds the product.

The responsibilities of traditional roles like project management, business analysis, software architecture, development and quality assurance are taken care by and divided up between the three Scrum roles.

In Agile Scrum, the product owner represents the customers and closely works with the team. Responsible for the product vision, product owners draft and refine items in the Product Backlog, which is done during a drafting of user stories session. A user story is a high-level definition of the requirements. A sprint, which is a time fixed regular occurrence of Agile Scrum, is kicked off with a Sprint Planning meeting attended by the Scrum Master and the Scrum team – typically 5-10 cross-functional individuals. Here the Scrum team selects user stories from the groomed Product Backlog they feel can be completed by the end of the upcoming sprint.

A sprint is many times set up to be two weeks in duration but can be longer or shorter. Whatever length is decided upon remains constant. While the Sprint is in process, the scrum master meets with the scrum team for a daily scrum meeting. In this timeboxed 15-minute daily “stand-up” meeting, everyone tells what tasks they completed the day before, what tasks they plan to complete that day, and whatever problems (blockers) they encountered.

Aside from shielding the team from disruptions, the scrum master motivates and coaches the team for agile best practices. Scrum velocity, which is the rate at which user stories are completed, is tracked through the Burndown Chart. During the sprint review conducted at the end of each sprint, the Scrum team presents the potentially shippable product and the product owner decides whether to accept or reject it based on the acceptance criteria. The scrum team contemplates what went well and did not before selecting and committing to a set of tasks for the next sprint. The sprint retrospective meeting, also held after the completion of every sprint, helps the Scrum team to improve its way of working in the coming sprints.

This Agile Scrum implementation process upholds transparency, inspection, adaptation and especially scalability. Because of this, it is highly useful to large organizations with several ongoing development projects.

Lean Development

Lean development is grounded on the Japanese automaker firms’ Lean Manufacturing. Lean, which is an iterative development method, drives efficiency and delivery of value to the customers. Accordingly, non-value-added features and activities are eliminated. Its team, who has a strong set of skills, is empowered to influence any project decision-making. With a principle of optimizing the Whole, Lean development relies heavily on the collaboration between developers and stakeholders. Lean development defers commitment as much as possible but concentrates more in increasing productivity with built-in quality and fast delivery.

The companies that adopt lean thinking to bring client-value are increasingly growing. Lean helps organizations build quality products effectively and efficiently in alignment with customer goals. This eventually results in maximized gains and minimized costs.

Kanban Development

Originally Kanban was a key part of the Toyota Production System (TPS). It later became a part of Lean Thinking and in 2004 began being used as a software development tool. It stresses the need to reduce DIP (Design in Process) inventory, improve quality and reduce waste, visualize workflow, and to measure, manage, and reduce cycle time. It calls for frequent, incremental delivery, and to balance demand against throughput in order to avoid bottlenecks. It also stresses the need to adapt your “normal” processes to fit the context of the job you are currently doing, and to keep to a minimum the need for a behavioral change of your software developers. It also encourages the need for a slack time among developers in order to have continuous improvement.

In Kanban, the amount of work is matched to the team’s capacity. There are no time set sprints. Quality is rarely shortcutted to make a deadline. Without overburdening the team, Kanban allows delivery of the product in a continuous mode. More flexibility in the flow, better quality, and better transparency throughout the organization minimizes cycle time, promotes higher developer efficiency, and results in faster delivery.

Kanban, which has no defined roles, has two primary components in its workflow – the amount of queue and work-in-progress. Individuals, who sometimes enlist the know-how of an agile coach, focus on the work that is actively in work-in-progress. Once a task is completely done, the developer can freely pull an item off the top of the queue provided the work-in-progress limits are kept. WIP limits, based on the team’s capability, are agreed upon by the developers themselves. For instance, with a team of 5, the team may be only allowed to handle two work-in-progress jobs simultaneously. Anytime during development, an introduction of additional features and enhancements are acceptable. While Scrum’s key metric is velocity, Kanban’s key performance indicator is the team’s cycle time – the amount of time a work item spends in development. Kanban is better able to forecast future work delivery by having actual cycle time records of the team.

For teams that are just getting started in agile, Kanban is a highly favorable methodology option. It supports developers to reach a point of being more agile with its directness. Kanban has a very simple core – visualize work, limit work in progress, improve quality, and enhance flow.

Scrumban

Scrumban has the workflow of a Kanban. However, it has required roles, and practices ceremonies such as planning, daily stand-up, review, and retrospective meetings which are all similar to agile Scrum. While Agile Scrum does planning before every sprint, Scrumban planning takes place as often as needed, and especially if there is a blockage in work-in-progress that prevents a team from pulling items from the queue. Daily meetings in Scrumban discuss in 15 minutes, items “done” yesterday, to be done today, and any work blockers. Review meetings aim to get constant feedback from clients for the developers to proactively respond to and adapt. The retrospective meeting is usually scheduled after every review meeting.

Scrumban, which seemingly is a hybrid of Kanban and Agile Scrum, suits maintenance-type of projects. Event-driven works like helpdesk and support, and even new product development projects with several unexpected user stories or frequent bug-fixing tasks, mostly opt for Scrumban. It eases challenges regarding workflow and resources.

Extreme Programming

Extreme Programming or XP, is another emerging agile discipline whose core values are simplicity, respect, communication, feedback, and courage. Aiming for high-quality quick delivery, XP observes relatively shorter cadences, focuses on continuous planning, fine scale feedback, customer satisfaction, and enablement of the whole team, The team collectively owns the code they write which follows coding standards and regularly undergoes refactoring. XP practices include test-driven development, pair programming, and continuous integration. Encouraging concepts like “The Planning Game” and “System Metaphor”, XP observes the straightforward flow of activities. During iteration planning, which precedes iterative development, is when extreme programmers prioritize user stories, fix bugs, and perform spilled over tasks according to business value. Once cadence starts, extreme programmers implement the Iteration Plan. Transparency on what is happening is observed through open communication with the customers. The different perspectives and ideas discussed and shared during the daily interface, to a degree, prepares the programmers on how to respond positively should there be setbacks along the development.

XP has simple rules that outline XP itself. When collectively practiced, these rules bring the whole team in tune and enable them to respond confidently to any project condition. Today, many software development companies, and especially those who have projects with high risks and changing requirements, are implementing XP. XP becomes effective once individuals have fully adopted XP principles including responding to feedback, upholding simplicity, and embracing change.

Crystal Method

Crystal is another lightweight methodology that fits best for small, co-located teams. It focuses on people rather than processes. It is not at all prescribed and stresses flexibility. It is a family of methods – Clear, Yellow, Orange, Red, and so on – each denotes a certain project weight. For instance, Crystal Clear corresponds to a lightweight and has “no mission critical” development. As the shades become darker, the project it represents is also becoming heavier and having more criticalities. Its techniques, tools, standards and roles are tailored to fit several factors such as team size, criticalities, and project priorities. It avoids rigid policies and processes; Crystal method carries out osmotic communication between developers and expert users.

Crystal methodology with strong points such as focus, frequent early releases, customer feedback, and continuous integration and delivery, is likely to work in smaller companies that have varying project-team configurations. However, because of its flexibility, it is perceived as a non-formal approach, Crystal provides a set of agile values and principles, that Crystal says should result in a successful software implementation if fully followed. The Crystal method cannot stand alone when there are a large number of teams that are not co-located. In those situations it can only be an aid, as a more prescribed structure is needed.

Feature-Driven Development

Feature-Driven Development or FDD is a highly adaptive, highly iterative agile development method. Stress is on the quality of all activities, and FDD delivers a frequent working product as well as providing useful progress and status information. FDD, which is client-centric and architecture-centric, thrives on having minimal overhead and development disruptions.

FDD employs best practices and uses them in a coherent whole. Included in FDD are domain object modeling, developing by feature, class (code) ownership and feature teams. Also, FDD, with software configuration management and progress reporting, does regular inspections and software builds.

Normally, FDD begins with developing an overall model and building a features list – identifying a high-level object model and grouping the features into related sets and areas. After the initial modeling activity, plan-by-feature is performed that results in a development plan defining class owners and feature set owners. It then continues with iterative actions – design-by-feature and build-by-feature – where major efforts of the FDD project occur. The iteration is as short as two weeks (or less), and each iteration goal is to deliver high client-valued features.
Claimed to be direct and highly scalable, FDD suits bigger teams. It has attributes like teams embrace collective ownership, results are visible, and work is done in very short cadences.

Behavior-Driven Development

Behavior-Driven Development or BDD is an agile methodology which focuses on collaboration between developers and business people. The collaborative effort of the development and business sides is to ensure that what the business actually needs is addressed and all user requirements are met. In BDD, business-critical features are prioritized and delivered first. All people involved have to have a shared understanding of the project in order to build the product right and capture what the business requires.

Generally, a BDD project starts with a business person specifying what they want in the product. Then a developer asks questions until both have a common vocabulary also referred to as ubiquitous language After getting answers to the questions needed to be answered the developer writes stories which specify the why, who, how and what, along with corresponding acceptance criteria. The developer then implements the user stories, and the acceptance criteria is transformed into automated tests as part of the implementation progress. These are the same test cases run to verify the software.

The very essence of BDD is to bridge the gap between people in the business and people who develop the product. BDD helps development projects to achieve well-defined business desired outcomes and to deliver quality products that fulfill business objectives.

Agile is more mindset than methodology

In agile, focus starts with people participating in the development activities and the communication between them. The technical people have to learn, share and work together effectively. Collaboration is important not only among those who build the products but with the business people who want them. Once familiar with the dynamics, participating individuals decide what level of processes and tools are suitable for them. As they progress along with the development fine tuning may occasionally be necessary. As the development moves further forward, adjustments are again made in response to advances in the team’s skills, or to new change requests, or any other unexpected specific along the development run.

By continually providing working increments of the product at a precise pace to the user and asking for feedback, Agile demonstrates progress and assures the customer that individuals are committed to getting it done right, and that better alignment between technology and business is valued and necessary. In effect, agile agreements are flexible, and change requests to the project are welcome as long as they are feasible and not prohibitive cost wise. Whether changes are feasible or not will be determined in a discussion between the development team and the user and a decision made jointly.

With the awareness that plans are not written in stone, being able to adapt if it means an increase in business value makes sense and is essential in agile development. With all of these points, agile is not entirely a methodology, but a way of thinking; a mindset.