What is Agile?

Agile is an umbrella term for a number of different methodologies, tools, techniques, practices and frameworks.

Steve Jobs once said, “People don’t know what they want until you show it to them.” Software development and the defining of business processes is an iterative process, which is greatly improved by capturing the views of the end user during creation.

Agile is about empowering people, treating them as intellectual individuals, as Peter F. Drucker said, “The best way to predict the future is to create it.”

AGILE IS ABOUT DELIVERING “BEST POSSIBLE VALUE” NOT MAXIMUM POSSIBLE VALUE

That’s why most Agile approaches define a project vision focusing on value of delivery, not on a fixed product. Agile respects that not all requirements can be known at the outset, particularity when the outcomes are intangible and subject to an evolving of understanding. With each iteration, the customer is able to review the output and shape the product with the help of the product owner.

Agile conflates:

  1. adjective — the general idea of being more nimble, lean and iterative.
  2. noun — a concrete set of methodologies for how to structure product development.

Before

Traditional approaches were based on sequential processes or a waterfall of events, collectively known as Plan driven. Tasks were managed around a paradigm of the process:

  1. Concrete - all work is understood before execution
  2. Well-defined - the inputs and outputs are consistent
  3. Pre-determined - the steps are predefined before development

Benefits

Every step is clearly defined clearly, so this model is exceptionally easy for software engineers to develop a solution rapidly and accurately.

Waterfall is easy to budget against, as the product is defined before development, so fix pricing is easy to define and agree on between developers and the business/product owners. Changes on route are managed through change requests.

Disadvantages

Developing a system is usually performed in tandem with defining a business process. Businesses do not stand still during a development phase. As processes are defined and put into practice, feedback occurs for improvement. The traditional Waterfall approach captures these improvements in the next working release or phase of the project. However, there may be a long time between phases.

The rigid approach of the Waterfall process can restrict innovation, as the business may see issues in their initial design during early demos of the product, but are unable to act on them until later phases.

Agile

Agile is change driven, built around a paradigm of change and adaptation.

The agile empirically adaptive process control model encapsulates the following:

  1. Frequent inspection and adaptation occurs as work proceeds
  2. Processes are accepted as imperfectly defined
  3. Outputs are often unpredictable and unrepeatable

Benefits

Agile respects the urgency and importance of priorities conveyed by the customer by providing incremental delivery with flexible sequencing.

Release cycles are shorter and the customer is engaged throughout the development process, this allows for business process design issues to be captured early.

The process is nimble and allows for innovation and redefining to the end users goal, making for a more usable product that is focused on business value.

Disadvantages

Agile can sometimes be mixed with other managerial processes when being implemented and result in confusion around the delivery, shifting the delivery from an iterative business focus to a slower siloed quality focus.

Costing projects can be harder to achieve as the output is not predefined for the whole project. Using statistical processes and burn-down charts can help with predicting the team’s speed to deliver and remaining booked resource; but according to TechRepublic, NPR used agile to reduce programming costs by 66%.

Manifesto

There are many ways to be Agile, Scrum, Extreme Programming, Crystal Clear and other frameworks. In order to find a common ground between the various implementations a Manifesto was devised:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  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

12 Principles

Twelve Principles of Agile Software development expand on the sentences that make up the values defined in the manifesto:

  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 a 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 maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Implementations

Two of the most popular implementations are Scrum and Kanban. However, the principles are more important than the practices.

Kanban 

Kanban is all about visualizing your work, limiting work in progress, and maximizing efficiency(or flow). Kanban teams focus on reducing the time it takes to take a project(or user story) from start to finish. They do this by using a kanban board and continuously improving their flow of work. 

Scrum 

Scrum teams commit to shipping working software through set intervals called sprints. Their goal is to create learning loops to quickly gather and integrate customer feedback. Scrum teams adopt specific roles, create special artefacts, and hold regular ceremonies to keep things moving forward. 

Glossary

The Calendar - the available time allotted to the project is split into blocks, often around 2 weeks, known as sprint cycles. Each project team is allotted a number of cycles. Project stakeholders review the work at the end of each cycle.

Daily stand up - 15minute limited meeting with 3 questions to each member:

  1. What did you do yesterday?
  2. What are you working on today?
  3. What are your obstructions?

Stories - units of work are known as stories, they are written and assigned at the start of a cycle. The syntax for a story is:

  • “As an X I can Y so that Z.” For example: “As a user, I can save calendar events so that I can keep a customized calendar.”

Roles - three roles:

  1. *Product Owner *- represents the “voice of the user.” Answers questions that arise, prioritizes work, and decides when work is completed to satisfaction.
  2. Scrum Master – scrum master removes any obstacles that impede the team.
  3. Product Team – responsible for collaborating on how to complete the work.
Warning - For Scrum to work there must be separation of the 2 roles "Product owner" and "Scrum Master". It means there’s someone whose main job is looking after the product right alongside someone whose main job is looking out for the process.

Meetings - to have a truly iterative approach to product development, you’ve got to iterate the process too. You have to put real thought and effort into optimizing how the team communicates and collaborates. That’s why there’s a meeting about meetings.

Acceptance - Stakeholders can reject the team’s work. This is important, but will only cost the team one cycle (2 weeks), as opposed to many months from a Waterfall project.

Diversity - Encouraging ownership in the product by the team also encourages the team to share additional skills and curiosity, e.g. a developer who is also very good at cryptography may have good ideas for where to focus cybersecurity testing.

Eavesdrop - Team members should be in close proximity (by location or always on video conferencing), this enables them to eavesdrop on one another’s progress, offer ideas and work together to solve issues. Meeting notes, wireframes, and other project-related assets are all stored on an internal wiki, where anyone can dip in and see the latest updates on any project in a cycle, or what’s ahead on our project roadmap. This can reduce management meetings.

Ref