Frequently asked questions

What is Agile?


The Manifesto for Agile Software Development is the best starting point for understanding Agile.

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.




Ok, but what is Agile?


The big difference between Agile and most other Project Management and Software Development methodologies, that came before it? Agile is an actual approach to project management with an actual definition.

Agile project management and software development is an iterative development methodology that values human communication and feedback, adapting to change, and producing working results.

Agile is iterative, meaning that it is done in pieces (sprints), that typically last 2-4 weeks, with each sprint building and improving off the lessons from the previous sprint.

Agile is all about efficient communication over documentation, convoluted email chains, or excessive meetings. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” If you can communicate something with a 10-second conversation instead of an email, you should.

Agile is about producing tangible, working results after each iteration.

“Working software is the primary measure of progress.” To compare Agile to the editorial process—you deliver a rough draft, then revise based on your editor’s suggestions. You’re not delivering the entire piece all at once on the day it goes to press.




What are the 12 principles of Agile?


The 12 principles of Agile, according to the Agile Alliance, are as follows:

  1. Satisfy the customer through early and continuous delivery of valuable software.

  2. Welcome changing requirements.

  3. Deliver working software frequently.

  4. Work together daily throughout the project.

  5. Build projects around motivated individuals who are supported and trusted to get the job done.

  6. Use face-to-face conversation whenever possible.

  7. Working software is the primary measure of progress.

  8. Maintain a constant pace indefinitely.

  9. Give constant attention to technical excellence and good design.

  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. Reflect on how to become more effective, then tune and adjust accordingly at regular intervals.




What is a real-world example?


The Apple Genius Bar, Looking past the what you may think of the name, the Apple Genius Bar is a great, real-world example of Agile ethos in action.

When you come in with your busted iPhone or iPad, you don’t have to fill out a bunch of forms or wait in a series of lines (it’s more like a waiting gathering). It’s a world apart from your last experience at your local council.

What makes the Genius Bar an Agile process is the focus on communication. The associate you deal with asks you questions and takes notes. In other words: “individuals and interactions over processes and tools.”

You may be saying, “But Apple uses processes and tools, like the iPad they take notes on.” Yes, but the conversation between humans comes first.




It seems simple, how do firms get this wrong?


To take a real-world example. Some firms still have a preference for processes and tools over individuals. For example, they believe that purchasing the right software e.g. Microsoft’s Azure DevOps (other tools available), is sufficient for introducing Agile. Also, by simply renaming current roles and documents to terms commonly used in Agile. E.g. Simply calling a Project Manager a Scrum Master, or Functional Specifications as User Stories.

Which as you understand, simply isn’t Agile.




What is an Agile Coach?


An Agile coach is a person who is responsible for creating and improving Agile processes within a team or a company. They are responsible for guiding teams through the implementation process and are tasked with encouraging workers and leadership to embrace the agile method.




Why do I need an Agile Coach?


Whilst the Agile manifesto and approach is easy and simple to understand, introducing Agile into firms that are process and tool heavy aren’t.

An Agile coach will help all team members to embrace Agile, including Senior Stakeholders, so that they can put their trust in having the right people doing the right thing, other having the right and often expensive processes and tools trying to deliver the right thing.




What is Behaviour Driven Development (BDD)?


Behaviour-driven development (BDD) is an Agile software development methodology in which an application is documented and designed around the behaviour a user expects to experience when interacting with it. Although some methodologies that support BDD can also be used in a Waterfall environment such as Specification By Example (SBE)

Software development is often deluged by overwork, translating directly into wasted time and resource for both engineers and business professionals. Communication between both parties is often the bottleneck to project progress when engineers often misunderstand what the business truly needs from its software, and business professionals misunderstand the capabilities of their technical team.

Shrouded in miscommunication and complexity, the end product is often technically functional, but fails to meet the exact requirements of the business. Behaviour-driven development (BDD) aims to change this.

BDD is a process designed to aid the management and the delivery of software development projects by improving communication between engineers and business professionals. In so doing, BDD ensures all development projects remain focused on delivering what the business actually needs while meeting all requirements of the user.




What are the key benefits of Behaviour Driven Development (BDD)?


All development work can be traced back directly to business objectives.

Software development meets user need. Satisfied users = good business.

Efficient prioritisation – business-critical features are delivered first.

All parties have a shared understanding of the project and can be involved in the communication.

A shared language ensures everyone (technical or not) has thorough visibility into the project’s progression.

Resulting software design that matches existing and supports upcoming business needs.

Improved quality code reducing costs of maintenance and minimising project risk.




How do I clearly distinguish and agree priorities?


In behaviour-driven development this is done by using two techniques: value and complexity analysis.

Value analysis helps us to quickly identify low-cost, high-value features in the backlog. Complexity analysis helps us to choose the right development and collaboration approach to the project as a whole, as well as each individual feature.




What is Specification By Example (SBE)?


Specification by example. Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements.




Why use Specification By Example (SBE)?


If your team is new to Agile or Behaviour Driven Development (BDD), then it can be difficult for team members to switch from perhaps a more IT focused ethos, to a more customer centric or Behaviour Driven ethos. Whilst tools and processes alone can’t change this, and this is another example where a good Agile Coach is required. Specification By Example (SBE) aids in the process of switching people over from prior ways of thinking over to Agile and BDD ways of thinking, by having a consistent format.

By having a - Given, When, Then story format. That will be very new to people who have not worked in a Behaviour Driven Development (BDD) friendly environment before.




What is an example of Specification By Example (SBE)?


In this tea buying and shopping cost example, you can see an example of how SBE might be written and used in practice.

Feature: Tea Shipping Costs

* UK customers pay VAT

* Overseas customers don’t pay VAT

* UK customers get free shipping for orders £50 and above

* Overseas customers all pay the same shipping rate regardless of order size

Scenario: Calculate VAT status and shipping rate

Given the customer is from

When the customer’s order totals

Then the customer

And they are charged

Examples: | customer’s country |pays VAT | order total | shipping rate | |

UK |Must | £49.99 | Standard Domestic |

| UK |Must | £50.00 | Free |

| Spain |Must Not | £49.99 | Standard International |

| Spain |Must Not | £50.00 | Standard International |

| USA |Must Not | £100.00 | Standard International |




Isn’t Agile fairly recent?


Whilst the Agile Manifesto was published in 2001, the ethos of Agile has been used for decades prior to this. In fact, you could say that the famous SR-71 “Blackbird” aircraft which first flew in 1964 was developed using Agile techniques.

Agile as skunkworks. This simile struck me quite forcefully the other day, and I have already tweeted to this effect. But the more my subconscious works on it, the more the analogy seems apt. (My apologies if anyone else has already drawn these parallels.)

Skunkworks is what developed the famous SR-71 “Blackbird” aircraft, along with other well-known aircraft. The Skunkworks team was isolated and protected from the rest of the organisation; this one team designed over 30 planes including the U2, A-12, SR-71, F-117, F-22 – just to name a few iconic aircraft.

For those unfamiliar with the term, “skunkworks” is widely used in business, engineering, and technical fields to describe a group within an organisation given a high degree of autonomy and unhampered by bureaucracy, tasked with working on critical, advanced or secret projects.

Even though some have produced amazing products, like the U-2 spy plane and the later SR-71 Blackbird,few skunkwork employees have succeeded in exporting their highly effective ways of working back into their corporate host organisations. Another reason to have an effective Agile Coach to help introduce Agile to your organisation, rather than someone who has worked in an Agile environment.

If you want to learn more about the history of the SR-71 and how the development relates to Agile, there is a good video on YouTube available here.




Why is there a picture of an SR-71?


See the answer to Isn’t Agile fairly recent? for that explanation.





Lockheed_SR-71_Blackbird.jpg
You Ask, We Answer

© 2018 by Alastair Majury. Providing Change Management services in the United Kingdom and overseas. Contact@MajuryChangeManagement.Com or visit https://www.linkedin.com/in/alastair-majury/