Agile – The New Kid in the Block?

www.plays-in-business.com
www.Plays-in-Business.com
Agile – A New Kid in the Block?
What is Agile & Agile Project Management?
Michael Tarnowski, Plays-In-Business.com

Michael Tarnowski
SW Engineer & Coder (C++, Linux)
Project manager (Air Traffic Management)
IT Management Consultant
• Scrum Master (CSM), LeSS practionier, Agile Coach
• QA, PrjMgt, ReqEng, Testing, SDLC
• SW process improvement
(certif. CMMI consultant, ISO 15504 assessor)
• Certif. ITIL consultant
• Certif. CobIT consultant
Agilist & Evangelist in Serious Play@Work:
• Cert. LEGO Serious Play Facilitator
• Cert. Innovation Games Facilitator
• Agile Games Addictß
Agile mantra
No Titles
Only skills

Agile
…is about Values – not about Projects
…has no “Management”
Agile Project Management = Contradiction in Terms

Ok, you want the…
… you will get it now!
within the next slides…jump ahead!

The Summary: Plan-Bases vs Adaptive Development
Agile is…
• People-centric way to create innovative products and solutions
• Market-centric model to maximize business value
• Demand-Driven model based on lean principles
Plan-based development: the plan creates
cost/schedule estimates
• Features are Fixed
• Time and Cost are Variables
• Quality is negotiable, or worst neglect able
Adaptive process: the vision creates
feature estimates
• Time, Cost, and Quality are Fixed
• Features are variable, negotiable
with the customer
Software
Development flows
sequentially from
start point to end
point.
Small Feedback
Loops allowed –
but risky the more
you reach the end!Ship-It: Biz Value
Waterfall, purpose-driven
Agile development is an
incremental and iterative
approach.
Ship at end of each
increment!
Feedback Loops are
appreciated – no risk!
Ship-It: Biz
Value
Ship-It: Biz
Value Ship-It: Biz
Value
Ship-It: Biz
Value
Ship-It:
Biz Value
Agile, value-driven

-6 -
28.11.2016
Not
adding components
incrementally
Stopping at latter phases
causes HUGE loss!
The Summary: Value-Driven, Risk-Minimization
by Henrik Kniberg, http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
Instead
creating stand-alone solutions
– increase value independent
You can stop at each phase
without loss!
By Design Thinking you get 3 innovation
phases!
Shift of Usability
Market Disruption
New Focus Groups
Innovation Shift of Usability
Market Disruption
New Focus Groups
Innovation
Shift of Usability
Market Disruption
New Focus Groups
Innovation

The Summary: Scrum Framework – Pull Principle & Time-Boxing
3 Roles:
Team, Product Owner,
Scrum Master
3 Artefacts:
Product Backlog, Sprint Backlog,
Product Increment
4 Ceremonies:
Sprint Planning, Daily Standup,
Sprint Review, Retrospectives
Product Owner
Prioritizes features:
Product Backlog
Input from End-Users, Customers,
Team, and Other Stakeholders
24 hrs
1 - 2
weeks
Sprint
Daily Scrum
Standup meeting
(15 min)
Sprint Review
Retrospective
(after 4-5 sprints)
Potentially
Shippable
Product
Backlog Refinement
Meeting
(during each sprint)
No Changes!
in Duration or Goal
during Sprint
Sprint 01 Sprint 02 Sprint 03 Sprint n…
Release Planning:
The team has complete control
over the amount of work it takes
on: team pulls only the tasks
they can handle in one sprint.
Sprint Planning
Meeting
Sprint Backlog1
2
3
4
5
6
7
8
9
10
Product Backlog Item
11
12
1
2
3
4
5
6
7
8
The Product Owner ensures
the team takes on the highest
priority work.
Product Increment
Scrum Master
Facilitator for both the Product
Owner and the team.
Has no authority within the team!

Agile, Agile Leadership & Line Management
• There is NO management in Agile.
• The Team manages itself together with Product Owner.
• The team is cross-functional: all needed skills are available instantly.
• T-shaped team members: they have in-depth skills and other broader skills.
• Leadership is given by the team according to competence and demand.
Agile and Traditional Line Management
Line Manager becomes Agile Leader if:
shows the Big Picture and sets the “guard
rails” for the team.
Don‘t Answer – Ask Questions Don‘t Correct Mistakes – Ask Questions
Help Teams Take Ownership
Create a Safe Space to Fail
Let the Team Make DecisionsTrust First and Be Trustworthy
Show the Vision
Connect Team with Customers
Enable & Empower the Team

The Summary: Agile Adoption Benchmarks
Reasons for Agile Adoption
2015, http://techbeacon.com/survey-agile-new-norm
Project Success and Failure RatesIs Agile better than Waterfall?
No – Any methodology by itself is not a recipe for success. Projects can be
different, in terms of duration, budget, complexity, number of stakeholders.
Agile is not a „one size fits all” approach. Waterfall projects suits to some
types of projects and Agile to others, usually smaller, less critical, more local
scope, more oriented to end-user. Risk of failure is a nature of software
development.
Does Agile projects manage risk better than
Waterfall?
Yes – But it does not mean that failure will be avoided by using Agile
methods. Failure is also a nature of software development. Agile methods
provide a good toolset that helps to minimize and manage risk effectively.
Simply because agile requires better collaboration, more communication, end-
user involvement, shorter, more iterative phases with quicker delivery of
results. The success mostly depends on the stakeholders of the project, –
success is the success of a team, not the project itself.


When should I use Agile/Scrum vs Waterfall?
• https://www.linkedin.com/groups/52030/52030-6197093360415551489
• https://hbr.org/2007/11/a-leaders-framework-for-decision-making

The Summary: Common Misunderstandings
Desi, https://www.flickr.com/photos/desiitaly/2201907500/
Wrong!
Take regulations as additional features; control the process
Agile Doesn’t Fit in Regulative Environments
Wrong!
No Command-n-Control. Agile Leaders are servants leaders for the team
In Agile there is no Management, or Leadership
Wrong!
Full-Time is better but not necessary
In Agile all Team Member must be Full-Time
assigned in one project
Wrong!
Documentation has to have value!
In Agile there is no Documentation
Wrong!
Co-location is better but not necessary
In Agile all Team Members must be co-located
Wrong!
Agile has more planning!
In Agile there is no Project Plan resp. Planning
Wrong!
Requirements spanning sprints improve the flow.
In Agile Work must Fit in a Sprint

Ok, you wanted the Summary… you got it…
we are finished.
Stop here reading!
Oh, you want more Details?
Go ahead…

Waterfall vs Agile
U.S. Army, https://www.flickr.com/photos/familymwr/6023129479
Since 1999
There’s A Fight…
Software Development Methodology

Put it Short…
Agile is about working smarter, rather than harder.
It’s not about doing more work in less time.
It’s about generating more value with less work.
Agile (Project) Management… more than a Buzzword
Classic Art Wallpapers, Construction of the Tower of Babel by Pieter Bruegel the Elder, https://www.flickr.com/photos/124699450@N03/14277509465/

Agile is a Change of Mindset in Product Development
Plan-based development (the plan creates cost/schedule estimates)
vs.
Adaptive process: the vision creates feature estimates
Agile (Project) Management… more than a Buzzword
Classic Art Wallpapers, Construction of the Tower of Babel by Pieter Bruegel the Elder, https://www.flickr.com/photos/124699450@N03/14277509465/

Value Driven Development
PLAN-BASED DEVELOPMENT (WATERFALL)
Plan-based development: the plan creates
cost/schedule estimates
• Features are Fixed
• Time and Cost are Variables
• Quality is negotiable, or worst neglect able
VALUE DRIVEN (AGILE)
Adaptive process: the vision creates
feature estimates
• Time, Cost, and Quality are Fixed
• Features are variable, negotiable
with the customer
Quality
Time Cost
Features
Quality
Time Cost
Features
Value &
Vision-
Driven
Plan-
Driven
Constraints
Estimates

Traditional Critique on Waterfall

Agile Product Development
Agile Framework „Scrum“
Lean Methode: Kanban
Trust the team. – The people
doing the work know it best.
Make reliable commitments.

Partially Done Has No Value
http://blog.nongkhaidesign.com/tag/udon-thani/
Definition of Done (DoD)
Definition of Done are consistent acceptance criteria
across all User Stories (Requirements). It is a
simple list of activities (writing code, coding
comments, unit testing, integration testing, release
notes, design documents, etc.) that add verifiable/
demonstrable value to the product.
The DoD drives the quality of work and define when
a User Story has been completed.

Planning Fallacy – Cone of Uncertainty
EstimationvsVariability
Project Duration
Make them here once you had
change to clearify things
But management asks
for DETAILS HERE!
Don‘t make promises here!

Waterfall & Agile – The Essentials
http://blog.presentationload.com/efficient-agile-project-management/
WATERFALL
Software Development flows
sequentially from start point to
end point.
Small Feedback Loops allowed –
but risky the more you reach the
end!
Ship-It: Biz Value
AGILE
Agile development is an incremental
and iterative approach.
Ship at end of each increment!
Feedback Loops are appreciated – no
risk!
Ship-It: Biz Value
Ship-It: Biz Value
Ship-It: Biz Value
Ship-It: Biz Value
Ship-It: Biz Value

-22 -
28.11.2016
Potential Shippable Product… Restrain to minimal releasable features
http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
Value-Driven Risk-Minimization
Not
adding components
incrementally
Stopping at latter phases
causes HUGE loss!
Instead
creating stand-alone solutions
– increase value independent
You can stop at each phase
without loss!
By Design Thinking you get 3 innovation
phases!
Shift of Usability
Market Disruption
New Focus Groups
Innovation Shift of Usability
Market Disruption
New Focus Groups
Innovation
Shift of Usability
Market Disruption
New Focus Groups
Innovation

• an increased visibility, during
the project life-cycle;
• a better adaptability;
• delivering biz value starting
with the first iterations;
• managing lower and lower
risks.
https://www.versionone.com/agile-101/agile-software-development-benefits/
Benefits of Agile Software Development

Agile – Pull Principle
http://www.synagila.com/en/agile-project-management/
The team has complete control over
the amount of work it takes on.
The Team pulls only the tasks they
can handle in one iteration.
Product Management (PO) ensures the
team takes on the highest priority work.
Kanban principle, Toyota Production System (TPS),
Taiichi Ohno and Eiji Toyoda: 1948 – 1975.

Product Owner
Scrum MasterSelf-organized
Team
Scrum Master is facilitator for both
the Product Owner and the team.
He manages how information is
exchanged.
He removes obstacles -
“impediments” - that are impeding
the team's progress.
He protects the team from outside
distractions.
He has no authority within the
team (thus couldn’t also be the
Product Owner!)
Product owner is responsible to
have a vision of what he or she
wishes to build, and convey that
vision to the scrum team.
Someone from marketing, product
management or anyone with a
solid understanding of users, the
market place, the competition and
of future trends.
No Management!
self-organized team
Scrum Framework:
A Scrum team includes 7-14
members, plus or minus two.
Scrum teams are cross-
functional, including the
skills (but ideally not the job
titles) of software engineers,
architects, programmers,
analysts, QA experts, testers,
UI designers, etc.
Scrum Framework: 3 Roles – No Manager!

Scrum Framework – Pull Principle
Scrum Master
Product Owner
Prioritizes features:
Product Backlog
Input from End-Users, Customers,
Team, and Other Stakeholders
24 hrs
1 - 2
weeks
Sprint
Daily Scrum
Standup meeting
(15 min)
Sprint Review
Retrospective
(after 4-5 sprints)
Potentially
Shippable
Product
Backlog Refinement
Meeting
(during each sprint)
No Changes!
in Duration or Goal
during Sprint
Sprint 01 Sprint 02 Sprint 03 Sprint n…
Release Planning:
The team has complete control
over the amount of work it takes
on: team pulls only the tasks
they can handle in one sprint.
Sprint Planning
Meeting
Sprint Backlog1
2
3
4
5
6
7
8
9
10
Product Backlog Item
11
12
1
2
3
4
5
6
7
8
The Product Owner ensures
the team takes on the highest
priority work.
Product Increment
3 Roles:
Team, Product Owner,
Scrum Master
3 Artefacts:
Product Backlog, Sprint Backlog,
Product Increment
4 Ceremonies:
Sprint Planning, Daily Standup,
Sprint Review, Retrospectives

Simplicity – An Agile Principle: “the art of maximizing the amount of work not done”
You must attend more than 4 meetings a week?  You can't be productive!
You must deal with more than 1 project at a time?  You can't be productive!
You have to ask more than 1 agreement level?  You can't be productive!
You have to report same tracking data in more than 1 computer application?
 You can't be productive!
You have several handovers / departments / people to solve a task?
 You can't be productive!

blog.crisp.se
Scaling Agile – Agile Project Management
Scaled Agile Framework – SAFE
http://scaledagileframework.com/
Large Scale Scrum – LeSS
https://less.works/less/framework/index.html
Nexus – https://www.scrum.org/Resources/The-
Nexus-Guide
Minimize handovers –
Less meetings as possible!
Continuous Value Stream(s)
http://www.cio.com/article/2974436/agile-development/comparing-scaling-agile-frameworks.html
Project / Product LevelProduct A
Product C
Product B
SM‘
PO‘
SM‘
PO‘
SM‘
PO‘
Team LevelTeam 01
Team 03 Team 02
Team 04
SM
PO
SM
PO
SM
PO
SM
PO

Sprint Planning Meeting with all teams (≥120 pls, 2 days)
Scaling Agile – Agile Project Management
Scaled Agile Framework – SAFE
http://scaledagileframework.com/
Large Scale Scrum – LeSS
https://less.works/less/framework/index.html
Nexus – https://www.scrum.org/Resources/The-Nexus-Guide
http://www.cio.com/article/2974436/agile-development/comparing-scaling-agile-frameworks.html
Minimize handovers –
Less meetings as possible!

Customer
Collaboration
Individuals &
Interactions
Working Systems &
Software
Responding to
Change
Customer
Interaction
High Performing
Teams
Iterative
Development
Adaptability or
Flexibility
Contract Negotiation
Processes & Tools
Comprehensive
Documentation
Following a Plan
known as
known as
known as
known as
valued more
than
valued more
than
valued more
than
valued more
than
Traditional MethodsAgile Principles (12)Agile Values (4)
Agile Principles & Values
• People-centric way to create innovative products and solutions
• Market-centric model to maximize business value
• Demand-Driven model based on lean principles

http://agilemanifesto.org/

Traditional Team & Agile Team
Forbes, http://www.forbes.com/sites/stevedenning/2016/09/08/explaining-agile/
AGILE TEAM
• Autonomous (self-organized)
• Team responsibility – ”blame the team”
• No silo-ing – Cross-functional
• Much interaction
BUREAUCRATIC TEAM
• Top Down
• Individual responsibilities – ”blame the person”
• Trend to “silo-ing”: department boundaries
• Little Interaction

Exercise 1: Identify one as a aggressor, the other as your protégé.
Station yourself in between both thus your body works always as a
shield for the protégé.
Observation: The group doesn’t reach an equilibrium - it keeps always moving and never stops
Exercise 2: Identify one as aggressor, the other as your shield.
Station yourself in between both thus your shield always protects
you from your aggressor.
Observation: The group comes to a collapse: it stops moving
Exercise 3: Station yourself in between both thus you
three always forms a equal-sided triangle.
Observation: The group stabilize: it moves only to adapt change.
Self-Organized Teams
Exercise: Group is constantly moving in a room or space. Everyone takes for herself 2 persons
in the group – without making them public.

Agile, Agile Leadership & Line Management
• There is NO management in Agile.
• The Team manages itself together with Product Owner.
• The team is cross-functional: all needed skills are available instantly.
• T-shaped team members: they have in-depth skills and other broader skills.
• Leadership is given by the team according to competence and demand.
Agile and Traditional Line Management
Line Manager becomes Agile Leaders
shows the Big Picture and sets the “guard
rails” for the team.
Don‘t Answer – Ask Questions Don‘t Correct Mistakes – Ask Questions
Help Teams Take Ownership
Let the Team Make DecisionsTrust First and Be Trustworthy
Show the Vision
Enable & Empower the Team

Agile Progress Tracking: Taskboard, Burndown-Chart
Agile Project Mgt Tools:
• Jira, Atlassian.com (DOORS, SAP interf.)
• Ralley, CA Software
• VersionOne.com
• …..
„Total Value“ of all
implemented
requirements in a sprint
„How many“
requirements are
implemented in a
sprint (Velocitity)

Agile Project Mgt Tools: Testing & Deployment
Continuous Integration system always builds and passes its tests, including all
deliveries from different sub-teams.
Continuous Delivery system always builds and deploys to the test environment and
passes its tests.
CD doesn't mean every change is deployed to production
immediately.
It means every change is proven to be deployable at any time.
Continuous Deployment system is always ready to deploy to production through a
largely automated process.
Continuous Deployment
Continuous Delivery
Continuous Integration
Deploy to
production
environment
Acceptance
test
Deploy to
testing
environment
Unit &
Integration
tests
Commit code
Automatic Testing and Continuous Integration

• VersionOne.com
• …..
Agile Project Mgt Tools: Release Planning
„Total Value“ of all
implemented
requirements in a sprint
„How many“
requirements are
implemented in a
sprint (Velocitity)
Release planning = Task-
+ Resource-
+ Time-Management
+ Traceability of all artefacts
(Req., Code, Tests, QA)
Progress Monitoring

Agile Project Mgt Tools: Reviews & Collaboration
(Code) Reviews as Communication / Learning to Code
• Discus code during coding
• Tool supported code reviews: Remote discussion and logging of comments
New understanding of “reviews”:
Review =/= formal inspection of QA / “QA criticism”
Review == Peer collaboration & getting help from other developers
SQA reviews: inspection of the communication log files only!
Do a tool survey! – Here commercial tool
Crucible,
Atlassian: code-hosting platform FishEye and
Review software Crucible
Plays-In-Business.com has no affiliation with Atlassian, VersionOne, or another tool vendor!

Agile Project Mgt Tools: Documentation
• Simplifying SW documentation process – living
documentation, instead of silos, and wikis with non-read
docs.
• PDF, Word, HTML – automatically created from codebase,
configuration files, in-house scripts.
• Script-based approach: describe system behavior through
all levels in a semi-formal language (e.g. Gherkin)
• Requirements (DOORS)
• Specifications (plain TXT)
• Code comments (Matlab, C, Java)
• Test specifications
• Test case definitions
• Test run scripts
• Test result protocols
Do a tool survey! – open source!
language Gherkin
documentation tool Doxygen
test frameworks: Cucumber, SpecFlow, etc.
Plays-In-Business.com has no affiliation with Atlassian, VersionOne, or another tool vendor!
• VersionOne.com
• …..

Common Misunderstandings
Desi, https://www.flickr.com/photos/desiitaly/2201907500/
Wrong!
Take regulations as additional features; control the process
Wrong!
No Command-n-Control. Agile Leaders are servants leaders for the team
Wrong!
Full-Time is better but not necessary
In Agile all Team Member must be Full-Time
assigned in one project
Wrong!
Documentation has to have value!
Wrong!
Co-location is better but not necessary
Wrong!
Agile has more planning!
Wrong!
Requirements spanning sprints improve the flow.

• Agile probably has more planning.
• Agile Planning is spread out through the whole development.
• Sprint is planned and strictly monitored on a daily level.
• In addition, most Agile projects will start with an initial iteration – Sprint 0 –, or even a classic
high-level analysis phase to determine the overall scope and complexity, fill the initial
product backlog, and provide overall estimation on cost and timing – ideally resulting in
high-level architectural blueprints and a release (e.g., Minimum Releasable Feature) plan.
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Planning
Tasks
Planning
Tasks
Planning
Tasks
Planning
Tasks
Planning
Tasks
Executing
Tasks
Executing
Tasks
Executing
Tasks
Executing
Tasks

• Colocation is the ideal situation for Agile (and really any project!), but increasingly rare in
today’s globalized business environment.
• There are great software-based tools that replace physical task boards; some as simple
as Excel, SharePoint, and web-cams or sophisticated tools as Rally or Jira.
• Distributed Teams certainly take more effort and skilled leadership – but it is not a show-
stopper.

• You can have as much documentation as you need.
• Documentation is just another deliverable.
• If it brings you any value the schedule it and produce it like anything else.
Paul, https://www.flickr.com/photos/doberdad/2264130166/

In Agile all Team Member must be
Full-Time assigned in one project
• Ideal situation but more often than
impossible.
• Carefully manage with part-time team
members
• There is danger lurking here: Some of
the key staff needs to have a significant
availability.
• Be careful not to create wasteful and
superfluous bottlenecks
• A high fluctuation of team members will
make it impossible to make future
predictions using velocity.
CéLOGIK, https://www.flickr.com/photos/celogik/23382369164/

Don‘t Take away Ownership
Don‘t Answer – Ask Questions
Don‘t Correct Mistakes – Ask Questions
Help Teams Find Trust
Let the Team Make Decisions
Trust First and Be Trustworthy
Show the Vision
Enable the Team
Nina Matthews https://www.flickr.com/photos/21560098@N06/6722653055/sizes/l/
• Agile teams do not need managers directing their work.
• The manager’s role is to set the team up for success and then support from the outside –
from the boundary of the team itself
• The question for an agile manager becomes, “How can I array people to best increase
throughput?” rather than, “How can I maximize ‘my’ people being utilized at 100 percent?”

• Take regulations as additional, non-functional requirements.
• The regulations rarely tell you how to work.
• Regulations typically provide criteria that your process needs to meet.
• Integrate regulations in the Definition of Done.
• Following the regulation in your process is a question of investment in the tool chain.

• If you do Hard Core Scrum from the Book – YES.
• However, let stories (requirements) span sprints to improve flow.
• Nevertheless, slice huge stories in smaller chunks as often as possible.
• Small stories (requirements) are equivalent to small pieces of work
Sam Greenhalgh, https://www.flickr.com/photos/zapthedingbat/2208241379/

In Agile there is no Design
• Agile probably means MORE DESIGN.
• Design is inherent all the way through development at every planning meeting
Jamie, https://www.flickr.com/photos/jamiesrabbits/7640990538/

Agile Adoption… a Long and Windy Way
eflon, https://www.flickr.com/photos/eflon/8842584616/
You can not change people! – Change their (working)
environment instead. – Then people change their habits.
You can not create a new culture – the people define it.
Show by example.
• Change Leadership style from micro-managing to
showing Big Pictures instead.
• Create flat hierarchies – stop procedural hand-overs.
• Empower people.
• Create a trustful atmosphere.
• Give autonomy, mastery, goals
• Do not Scale Agile – Grow Agile!

Agile & Waterfall: Project Success and Failure Rates
Successful Challenged Failed
Agile 39% 52% 9%
Waterfall 11% 60% 29%
Successful: Delivered on time and on budget, with required features and functions.
Challenged: Late and over budget, or with fewer than the required features and functions.
Failed: Canceled prior to completion or the product was delivered but never used.
https://www.infoq.com/articles/standish-chaos-2015
https://www.scrumalliance.org/community/articles/2015/october/adopt-scrum-for-competitive-advantage

Reasons for Agile Adoption

Is Agile better than Waterfall?
Is Agile better than Waterfall?
No– Any methodology by itself is not a recipe for success. Projects can be different, in terms of
duration, budget, complexity, number of stakeholders. Agile is not a „one size fits all” approach.
Waterfall projects suits to some types of projects and Agile to others, usually smaller, less critical,
more local scope, more oriented to end-user. Risk of failure is a nature of software development.
Does Agile projects manage risk better than Waterfall?
Yes– But it does not mean that failure will be avoided by using Agile methods. Failure is also a
nature of software development.
Agile methods provide a good toolset that helps to minimize and manage risk effectively. Simply
because agile requires better collaboration, more communication, end-user involvement, shorter,
more iterative phases with quicker delivery of results. The success mostly depends on the
stakeholders of the project, – success is the success of a team, not the project itself.


When should I use Agile/Scrum vs Waterfall?
• https://www.linkedin.com/groups/52030/52030-6197093360415551489
• https://hbr.org/2007/11/a-leaders-framework-for-decision-making

Agile Adoption Rates
Major uptick in Agile adoption began
to occur in 2009-2010
Most current Agile orgs have adopted
in just the past 5 years

http://searchsoftwarequality.techtarget.com/photostory/4500251243/VersionOne-surveys-Agile-
development-for-2015/1/Top-Agile-project-management-tools
Why Do Agile Projects Fail?
Agile is not the Silver Bullet!

Agile – The New Kid in the Block?

More Related Content

What's hot

Viewers also liked

Similar to Agile – The New Kid in the Block?

More from Michael Tarnowski

Recently uploaded

Agile – The New Kid in the Block?