What do the U2, SR-71, and F117 have to do with Agile?
What do the U2, SR-71, and F117 have to do with Agile?
The Agile Manifesto was first published in 2001, whilst the U-2 was developed in the 1950s, the SR-71 in the 1960s, and the ‘Stealth Fighter’ F-117 in the 1970s, based on a paper published in the 1960s.
So how is the development of these planes, in anyway linked to Agile?
Because, Agile isn’t new. These planes were developed by Lockheed’s ‘Skunk Work’, and one it’s first products was the P80, developed in the 1940s and in service for nearly 30 years. The designer Clarence L. “Kelly” Johnson, developed some rules and practices for the ‘Skunk Works’, known as Kelly’s 14 Rules & Practices.
These are available to view here:
If you are familiar with Agile, then the principles of these will be familiar.
Majury Change Management will look at a few of these, in relation to these planes, and a bonus plane.
Use a small number of good people
“The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).”
At it’s peak the design of the A12 (the precursor to the SR-71) had 75 engineers, and was designed by hand (no CAD software), for context Boeing when designing the 777 had over 10,000 engineers working on it, who also had the benefit of CAD software to aid them.
What are the key lessons?
ØWhat your team does depends on the situation, which only they can judge
ØTrust your team to make gooddecisions
Ø Hire smart people and give them the freedom and trust to make the right decisions
Simple drawing and drawing release system
“A very simple drawing and drawing release system with great flexibility for making changes must be provided.”
The key message here is to have enough process so that the team has the context (both project and business) that they need, but not so much process that they effectively switch off their brains, and rely solely on the process to make decisions / be told what to do.
Have processes in place that allow teams, to set the right priorities and make the right compromises.
There will be only one object
Not listed on the 14 rules but Kelly also another rule which was
“There will be only one object: to get a good airplane built on time.”
In other words — “Deliver the value that the customer needs”
Deliver the Most Value
In the shortest amount of time
Bring out the best in your team
Official service ceiling of 80,000 ft and an endurance of 12 hours
However, in order to land the U-2 requires a chase car, which is driven by a second U-2 pilot who assists the landing U-2 by reporting the aircraft’s altitude and attitude.
This is because in. order to save weight and increase altitude, Lockheed executive John Carter suggested that the design eliminate landing gear and not attempt to meet combat load factors for the airframe.
The priority was altitude for safer surveillance capabilities
ØHolds the world record it set in 1976 for the fastest air-breathing manned aircraft.
ØRaced the sun and won.
ØBelieved to be able to exceed Mach 3
ØUnable to start its own engines
ØSits on the tarmac dripping fuel
Because the team focused on what mattered to the success of the plane
Whilst the SR-71 and other aircraft before the F-117 were ‘Low Observable’ or ‘stealth’. The F-117 was the first aircraft to see service that was designed with mathematically certainty to be ‘Low Observable’.
It was unstable in all 3-flight axis (Pitch, Yaw, and Roll)
So used the F-16’s flight computer, as the F-16 was unstable in one flight axis and was ‘hacked’ in order to handle a plane that was unstable in all 3-flight axis.
All flat surfaces as computers at the time didn’t have the computational power to design for curved surfaces that are ‘Low Observable’.
Bonus — XFC 130H
Challenge — Have a C-130 Hercules able to land on the field within a soccer stadium in Tehran.
Within 3 weeks (sound like a familiar time period), a team from Lockheed had developed a prototype that was able to take off and land within the specified space.
This was for the Credible Sport concept called for a modified C-130 Hercules cargo plane to land in the Amjadien Stadium across the street from the U.S. Embassy and airlift out Delta Force soldiers and the rescued hostages.
ØThe principles of working in an Agile manner are not new
ØThey have been around since at least the 1940s
ØThey do not only apply to software projects
ØHire Smart people
ØEnsure that your team understands the context of what is to be delivered
ØGive them the freedom and trust to make the right decisions
ØKnow that sometimes good decisions are wrong decisions
ØHave a culture of helpful learning not a blame culture
ØTake the time to develop and refine processes that give your team time the freedom and context required to be a success
If you have any more questions related to Agile or setting up the culture and processes that enable successful project teams, then please don’t hesitate to contact Majury Change Management.
Majury Change Management can aid with the introduction of Agile ways of working, Behavioral Design Development, and more to your organization.
You ask, We answer
aka FAQs (Frequently Asked Questions)
Majury Change Management knows that the subject of Agile and Behaviour Driven Development (BDD), can be daunting.
The term Agile has been used so widely, including being misused, that it can be confusing as to what Agile actually is.
We know your questions will be relative to where you are in your Agile journey. We’ve curated a handful of frequently asked questions which you will hopefully find useful and informative.
For those starting out we know you’ll be asking things like; What is Agile? What is an Agile Coach? What is Behaviour Driven Development (BDD)? What is Specification By Example (SBE)?
We’ve attempted to remove a lot of the mystery and dispel some of the common myths you may have associated with Agile by answering these questions and more. Our hope is to inform you with the detail you need to discuss your Agile requirements more confidently.
We’re sure those of you who are a bit further on in your journey may still have questions, hopefully we’ve answered some of your questions too.
Whatever the stage of your Agile journey if you don’t find the answer to your particular query or would like something explaining in more detail, reach out to us. We don’t bite and we know what we’re talking about.
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:
Satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements.
Deliver working software frequently.
Work together daily throughout the project.
Build projects around motivated individuals who are supported and trusted to get the job done.
Use face-to-face conversation whenever possible.
Working software is the primary measure of progress.
Maintain a constant pace indefinitely.
Give constant attention to technical excellence and good design.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
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 pretentiousness of the name, the Apple Genius Bar is a great, real-world example of Agile project management 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 the DMV.
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
| 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.
Alastair Majury Chartered MCSI, is a director of Majury Change Management Ltd is a highly experienced Senior Business Analyst / Data Scientist with a proven track record of success planning, developing, implementing and delivering migrations, organisational change, regulatory, legislative, and process improvements for global financial organisations, covering Retail Banking, Investment Banking, Wealth Management, and Life & Pensions.
For several years now, Alastair has worked extensively with a variety of financial institutions in order to offer the utmost comprehensive services. As a data scientist/business analyst, Alastair Majury Chartered MCSI is expected to find intuitive and sensible solutions to complex problems.
As a data scientist/business analyst, Alastair Majury Chartered MCSI has worked closely with several high-profile businesses, such as BNP Paribas, National Australia Bank, Standard Life and the Royal Bank of Scotland Group.A graduate of University of Glasgow, Alastair Majury Chartered MCSI earned his M.A. in Economics with Business Economics. Since then, Alastair has undergone several training sessions and earned multiple certifications for a variety of skills. More specifically, he has earned certifications in IAQ, risk management, resource management, and a bevy of other areas. Alastair Majury thoroughly enjoys his work.
What excites him most about being a data scientist/business analyst is that every problem has a variety of solutions. This allows for a great deal of creativity on his part. Providing ingenious solutions to his customers’ problems provides a great deal of satisfaction to Alastair Majury Chartered MCSI. Every single day can be a new and challenging problem.
Although he is a fierce and determined worker, Alastair also manages to find free time to embrace his hobbies and interests. Alastair is a major proponent of philanthropy and charitable endeavors. He constantly finds new and exciting ways to promote charities and philanthropic organizations in his community. He also tries to donate time and funds to said organizations whenever he can. Alastair Majury Chartered MCSI firmly believes that if we all work together towards a common goal, we can find peace.