What is Agile?

Agile is a software development approach to making applications for all platforms including desktop, mobile, and the web. It has been gaining more traction these days over the waterfall model, especially in the information technology (IT) industry, and for good reason. Agile’s goal focuses on iteratively delivering high-quality, working software, which means that a working product can be shipped consistently, frequently, and on time. All these contribute to the lowering of project cost, while increasing the value that the project brings to the business.

The Agile methodology is an answer to some of the problems with traditional software development which may include:

• User requirements finalised too early, discouraging continuous improvements.
• Customers are unable to visualise the final product based on requirements.
• Disconnect between customer’s needs and project team’s development efforts.
• Lack of collaboration between customer and project team.
• Long development time before a finished product can be seen.
• Unforeseen changes may contribute to unforeseen costs and delays.

Agile aims to not only address all these challenges, but to also to improve on areas previously not optimal with traditional methodologies, like better collaboration with customers, plus better understanding of all aspects including customers’ industry, pain points, mission, vision, needs, and expectations.

Many organisations that went all-in with Agile have seen significant growth in all metrics mentioned earlier. However, challenges with Agile may arise too, if not implemented correctly, which we will be discussing later as well. But first, let’s go through a bit of Agile’s history.

Agile Manifesto and principles

The Manifesto for Agile Software Development (Agile Manifesto) was originally put together in 2001 by 17 signatories, declaring the values they believe in for developing software, based on their collective experiences in the field. In its entirety:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

● Individuals and interactions over processes and tools
● Working software over comprehensive documentation
● Customer collaboration over contract negotiation
● Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

© 2001, the above authors.
This declaration may be freely copied in any form,
but only in its entirety through this notice.

The four core values seen above are further expanded into the Twelve Principles of Agile Software:

Principles behind the Agile Manifesto

We follow these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximising the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organising teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Workflow of Agile

Equipped with the values and principles, there are a myriad of ways to implement Agile, with frameworks you may have heard of including Kanban, Scrum, or a hybrid of the two called Scrumban. Specifically, for Scrum, there are generally five steps to the workflow.

Discovery and product backlog creation

Early on in the project, research and discovery sessions must be conducted, with the client present, to fully understand the client’s background, their customers, and industry. We then move on to find out the client’s mission and vision, and figure out their pain points to be solved, their needs for the product, and their expectations. Basically, all relevant aspects of their business. These understandings are crucial to create a wishlist or a product backlog of components and features to be incorporated into the product. The items within a product backlog are called User Stories. A User Story typically contains the ‘as a – I want’ structure, for example:

‘As a small business owner, I want to be able to key in my loan requirements and company details, and be presented with all eligible loan products from different banks.’

Sprint planning and Sprint backlog creation

Before development begins, a Sprint planning meeting is conducted where all members of the team assemble to discuss the parts of the upcoming round of Sprint. The Sprint planning need not be short; in fact, the recommended duration of a meeting is four hours.

In the first half, User Stories in the product backlog are prioritised and ranked to determine which features go out, first. The usual length of a Sprint is two weeks, but there are cases it can be as short as a week, or as long as a month. Based on the agreed Sprint length, the team picks the prioritised User Stories to see if it can be done in one Sprint. If so, during the second half of the Sprint planning, the team now elaborates and details all the work that is required to complete the product backlog. All newly determined tasks are called the Sprint backlog.

During the elaboration, if it is determined that a product backlog item cannot be completed in a single Sprint, it should either be split into smaller parts, or dropped back into the product backlog for future Sprint planning.

Sprint and Scrum meetings

As a basic unit of the development in Scrum and other Agile methodologies, Sprint is a time-boxed effort where development and iteration of features are done. As mentioned earlier, they are fixed durations of one to four weeks, depending on the duration and size of a project, but the usual length is two weeks. The focus is always to end a Sprint with a usable product/feature that is ready for deployment.

A task board is commonly used to track the progress of each individual task. There are many ways to approach this, but generally, there are four columns and they are self-explanatory: Backlog/To-do, In Progress, Testing, and Done. Scrum has an additional leftmost column for User Stories (product backlog) while the Kanban framework doesn’t. However, they share the same principles. Each Sprint backlog task is written on a card or sticky label and pinned/stuck to the ‘Backlog’ column. During development, it is moved to ‘In Progress,’ and to ‘Testing’ during product testing and demonstration to stakeholders. A card is only moved to ‘Done’ once the particular feature is ‘shipped’ or rolled out to production.

Daily Scrum meetings are an essential part of Scrum as its main goal is to keep up-to-date about the progress of the project. It should be held at the same time every day and start regardless of whether all members are present or not. During each Scrum meeting, all present members should talk about the tasks that are done (what’s done), their next tasks (what’s up), and their challenges and problems faced (what’s stuck).

Test and deliver

A full testing of the feature is a must in each cycle, since we want a working product at the end of each Sprint. Being agile and all, testing can be done by a partner developer, but dedicated test engineers can be included to the team too. After testing and bug fixes, a product demonstration is conducted for stakeholders and clients, after which they can collaborate with the project team on further project developments.

Retrospective and next Sprint planning

Unlike the testing phase earlier, Sprint retrospective is mainly conducted to discuss the past Sprint – what was working during the development and what can be improved in the next Sprint. Such feedback must be solicited from clients as well as from project team members. Information gathered can then be used to identify areas for continuous process improvements for the next Sprint. Keep in mind that each successive Sprint is both iterative and incremental. Iterative as in providing improvements to completed work from previous Sprints. Incremental as in adding new features to the product.

Perks of Agile

While there can be advantages to traditional software development methodologies such as the Waterfall model, the perks of Agile are aplenty. Here are just a few of them.

Focus on customers. Agile bases developments on User Stories established during the discovery sessions. Because these Stories are focused on how the customer can perform a particular action or reach a goal, it doesn’t matter what the specifics of the features are, as long as the Stories are fulfilled and don’t contradict one another. The acceptance criteria for features are met when the User Story is possible, which means for every incremental feature release, the software increases its value.

Focus on business value. Just because the Stories are customer-centric, doesn’t mean they aren’t business-focused as well. The close collaboration nature of Agile ensures that the client know what features matter most, and the development team understands the client’s business well enough to be able to prioritise which features to develop first.

Better engagement. Right from the very beginning, the client is already heavily involved in the project, collaborating closely with the product owner to prioritise the product backlog’s User Stories. As a result of seamless communication, the client ends up having a stronger sense of ownership for the product, while the development members are more user-focused, now that they understand the client’s vision better than before. This virtuous cycle will carry on throughout the project’s lifecycle.

More transparency. Similar to engagement, when a client is involved closely with the development process, it makes sense for them to share their pain points and vision for the product throughout the whole process, from backlog prioritising, to Sprint planning, to review sessions. In return for this transparency, the development team also needs to disclose any challenges and snags along the way, and keep the client up-to-date with the latest work-in-progress product.

Predictable cost and time. The lean and effective model Agile adopts helps the project team avoid the many pitfalls commonly faced during a project, thanks to its fixed, two-week Sprints. The pitfalls mentioned include feature creep, which will extend the scheduled deadline, which in turn, will increase cost. In Agile, the client can help estimate the extent to which they want the feature to be developed, and to get a better idea on the cost of developing a feature.

Faster time-to-market. Speaking of estimation, the time-boxed Sprints and a fixed period for each Sprint, ensure that goals can be achieved on time. Not only that, the fact that Agile requires a working product at the end of each Sprint, by the end of the two-week period, there will already be a fully functioning product, albeit a basic one in the early phases. The frequent releases and interim usefulness also provide the opportunity to offer many beta testing sessions for end users to identify bugs and other user experience issues.

Allows for change. While Agile’s structure is made for focusing the efforts, frequent beta tests are instrumental in determining how to continuously improve the software. The frequent feedback from the client, and the relatively short Sprints, allow for an early course-correction should there be any small issues, before they become bigger ones. Said client could also see a working software early and have the chance to reprioritise the product backlog and make change decisions throughout, for the next cycle.

Improves quality. Finally, when you put all of the above together, what you’ll end up with is a product that is likely to be more effective in solving the problem it was designed to address than a product that has been developed using conventional methodologies. This is possible due to the many testings, reviews, and expectation-mismatch identifications that happen during the frequent Sprints.

Challenges of Agile

Agile may come with its own set of challenges, especially if not implemented correctly.

For starters, Agile requires a frequent amount of customer involvement, which is great for the quality of the project, however the client may not have the time nor the interest to be heavily involved, and that may create miscommunications in Story prioritisation down the line.

On the project team’s side of things, Agile works best if all members are completely dedicated and not involved in other projects, given the short Sprint time, and this could be a problem for those who might be involved in multiple projects at once. The close working relationships that are heavily prized in Agile requires all members to work in the same location. This hampers mobility for a multinational organisation and a team that has members working remotely.

The frequent reprioritisation nature of Agile may add additional development time and cost. This is because some features are dependent on the other. Developing Feature B first may not give you a working product at the end of the Sprint as it requires Feature A to be working first. So, the only way to reprioritise Feature B above Feature A, is to merge the two into one Sprint backlog task. This translates to potentially overshooting the allotted time as Sprints are time-boxed.

Not to mention when features are implemented iteratively, it often leads to frequent refactoring of the code. Code refactoring is a process of restructuring the existing software code, without changing the external look and behaviour. Unless if a full scope is considered and predetermined early in the initial architecture and design, frequent refactoring will lead to additional development time and costs. This is especially true in large-scale developments, implementations, and projects with deep integration.

Another criticism against Agile is that the manifesto is now outdated and may not be keeping up with the times, though the reason why the core values are brief is because they were designed to be able to withstand the test of time and emerging technologies. Plus, modern Agile frameworks can be kept up-to-date without changing the manifesto’s core values.

Making Agile work

No two organisations are alike, and what works for one may not necessarily work for another. Agile, as a core methodology, has to be paired with a framework that fits a particular organisation.

Scrum, the de facto standard framework for Agile, is best used for software development. One of the contributing factors towards its popularity lies in the fact that it’s so bareboned. The simple framework can be easily expanded and adapted to suit various types of developmental projects. However, Scrum’s time-boxed Sprints aren’t suitable for unforeseen issues arising, such as outages and product maintenance that are not part of the Sprint.

This is where Kanban comes in. Originated in lean manufacturing, which in turn was inspired by the Toyota Production System, Kanban is Japanese for ‘signboard,’ where it is a lean method to manage work primarily by balancing between available resources with work demands. Instead of pushing, it uses a pull method; meaning work is pulled into progress only when the capacity permits, rather than pre-assigning work to everyone who may already be swamped, and this will prevent bottlenecks. Kanban doesn’t require the Kanban board, but said board can be the perfect way to visualise the workflow, and it has a similar layout to Scrum’s task board.

JurisTech uses a hybrid of the two Agile frameworks, which some might call, ‘Scrumban.’ During the discovery sessions, we will incorporate User Stories into the product backlog, but since we work a lot with traditional financial institutions, we will still produce a user requirements specification (URS) document, following the conventional waterfall model. Now, being agile, we still do accept changes during Sprints, but these will be documented in the URS Addendums.

Our Kanban board can be used for both product development as well as enhancements and maintenance that may not have a fixed time box and are unpredictable. During development, we follow the two-week Sprints and the daily Scrum meetings (we call them stand-ups). Post development, we still perform the traditional user acceptance testing (UAT) before deploying to the production environment. Depending on our clients, some may even allow deployment or shipping of features at the end of every Sprint. But the more traditional clients may prefer only one long UAT session at the end of the project lifecycle, and that’s OK too, for Agile’s flexibility allows for that. Ultimately, there are no hard and fast rules, as the most important thing with Agile is that the goals are clear, the tasks are all accounted for, and work is being done in an effective and efficient manner.