“Metagility” by Dr. David A Bishop

Agile methodologies have become a popular and widely accepted method for managing software development.  However, despite this success, managing agile methods has proven to be a real challenge for most companies, particularly those with complex products such as IoT devices and large development environments.  As such, agile methods are changing.  Many companies have been forced to adopt a hybrid version of agile and waterfall techniques, and this hybrid approach is fast becoming the norm rather than the exception in the industry.
Metagility is a new framework that provides a comprehensive approach for managing a new and highly effective breed of agility from the executive level on down.  Based on scientific theory and practitioner research, it is the definitive playbook for those seeking the optimal solution for adapting agile to more complex product development and organizational contexts. This desk reference shows organizations how to manage both agile and waterfall techniques to outperform their competition in industries with very high technological change, turbulent markets, and innovation.
“Bishop’s Metagility uses a vortex as a means to coordinate parallel product development activities. It’s an exciting new way to think about managing software development in the age of digitalization.”
— Richard Baskerville, Regents’ Professor, Georgia State University
“Dr. Bishop’s book offers tremendous value to executives tasked with leading others to improve speed to market. Lessons drawn from careful study of a number of organizations are thoughtfully deployed to create a toolkit that readers can use to develop and leverage agility.  It’s a guide that will make the reader a better leader.”
—Nathan Bennett, Ph.D., Co-author of Riding Shotgun and Academic Advisor to the COO Circle
“Whether your organization is in the midst of an agile transformation or you are looking to become more agile than you already are, this guide clearly shows how to achieve both within today’s most challenging situations.”
—Dr. Neda Barqawi, Founder of Knovalytics and Serial Entrepreneur
“Metagility is a must read for organizations going through an agile transformation. It is full of useful, research-based information that is critical to implementing agile enterprise wide. This is the best guide available for leveraging agile principles across the entire organization to maximize business value.”
—Hank Caughman, Director of US Development, Urjanet
About the speaker
Dr. David A. Bishop is a technologist, consultant, researcher, entrepreneur, and instructor with over 25 years of experience in telecommunications, transportation, airline, government, and utility industries.  David holds a Bachelor of Computer Engineering degree from the Georgia Institute of Technology, an MBA with a concentration in IT management, and a Doctorate in Business Administration from Georgia State University.  He is an inventor of several U.S. patents.
David is CEO and Founder of Agile Worx, LLC, ( a firm that provides program and project management software tools, training, and consulting services. He is a member and committee chair for the International Electrotechnical Commission (IEC) based in Geneva Switzerland, a member of ANSI, and a Senior Member of the IEEE and the Association for Computing Machinery. David is also founding chair for the Atlanta chapter of the IEEE Technology and Engineering Management Society. <br> <h3>Auto Generated Captions</h3>

has joined the meeting
it would not be due hearing yes cool
great so uh welcome everyone this is a
triply dams webinar on meta meta agility
we have David
who’s in gracious enough to host this
webinar for us
thank you David so much for your time
no problem thank you should we wait a
couple of minutes to see if more people
join or should we get started I guess we
can wait another manager – okay the ties
are you able to us be my screen yes I am
able to see your screen and I hope
they’re Donuts is also able to see your
screen okay
and I mean when I could just give up the
way out David everyone who is on the
call game does a technologist consultant
researcher you know and our instructor
recover 25 years of experience in
telecommunications transportation air
line utilities mistreats David holds a
Bachelor of computer engineering degree
from Georgia Institute of Technology and
MBA with a concentration in IT
management and a doctorate in business
administration from charge less lately
instead he is an inventor of several US
patents tim is the CEO and founder of
child works firm that provides program
and project management software tools
training and consulting services
his number and committee chair for AI
international electrotechnical
commission using based in Geneva
Switzerland the member of ancienne side
and the senior member of I tuple and
Association Mallikarjun
actually min email with us David is also
a founding chair of Atlanta chapter
vitally technology and engineering
management society that could happen
okay okay
thank you very much for the introduction
my pleasure thank you I’ll go ahead and
art my slideshow here should um just to
fill that quick instruction for everyone
else if you do have to speak with
yourself otherwise just mute yourself so
that we do not have any background noise
and it is good for everyone else on the
promise with with that David it’s all
yours okay thank you very much and are
you able to see my screen okay yes okay
person all right fantastic okay so the
title of today’s talk is a minute ility
managing agile development for
competitive advantage and this is the
title of a book and I wanted to start
off usually I start off by if it’s a
kind of an audience I usually start off
by asking a couple of questions but in
this case we may save questions till the
end right
agile transformations is the main topic
we’ll talk about today and if you may
have been involved in agile
transformations and when I usually often
will ask we start off by asking the
Nino’s you could think about one word I
think I think we have some noise you
could please mute usually I kick off the
talk with a question of if you could
characterize agile transformation with
one word you know what would it be and a
lot of times you know the words are not
very positive a lot of times there’s
fear there’s failure or there’s kind of
a like lackluster results and I had this
same experience about ten years ago and
I worked for a company who was trying to
undergo an agile transformation we try
numerous times and we had a couple of
failures and then we managed to sort of
get into a mode where we were sort of
half agile or half waterfall and and
then it eventually we managed to hit the
target but it took quite a bit of work
and that’s where I had gotten involved
at the time and I decided to I was
trying at the time I was trying to solve
this problem and I tried to sat back and
Bob well how can I attack this issue
doing the meeting okay
i sat back and thought well how can I
attack this issue how can I solve this
problem obviously agile is a is a
wonderful concept and it’s worked for
many companies and organizations but
there’s still a large segment of
organizations and companies out there
that have had trouble with it so how do
we get past this issue and so I embarked
on this on this journey which I’ll touch
on today of is essentially my agile
journey of how how I got into this
business and how I am the solution that
came out of it and it’s been a long
journey but a really interesting and a
really really fun one and so let me talk
a little bit about the agenda of what
we’re going to cover today so we’re
going to start off a little bit about my
agile story I’m going to talk to you a
little bit about how I got here
and why I’m doing this today we’re going
to talk a little bit about how agile has
changed and we’re going to talk about
the performance and limitations of agile
I’m going to introduce the concept of
net agility and what that is and some of
the components of net agility including
hybrid agile implementations agile for
tissa T and we’re agile development is
expected to evolve from here so this
gives you kind of a high-level overview
of the talk that we’re going to cover
today and
so you know it I’ve seen a lot of blogs
recently about lackluster agile
transformations or life Leicester
results with agile transformations or a
lot of issues or problems with respect
to doing it many
this has been a relatively well accepted
mode of business in recent years but a
lot of companies are still having
trouble with it and like I said about
eight or ten years ago I was involved in
the similar situation and I thought I
like to sweep under Zamora jinjo Childre
yes if you just logged in please do your
phone thank you
so so I my agile story and started out
with an organization that was trying on
a number of occasions to conduct an
agile transformation we had marginal
success and I sat back and thought you
know what is missing here
what is it that’s not that’s missing
from many of these approaches we even
brought in some very smart people at one
point some consultants who you know were
supposed to be experts in making this
happen and they did succeed either and
this is a common theme that I’ve heard
throughout the industry when I talk with
agile consultants and agile coaches many
of them have seen the same thing happen
and so I sat back and thought what is
missing and how can someone like me you
know try and change this this trajectory
obviously it’s not there’s a lot of
success stories out there but there’s
probably a huge segment of not so good
success with respect to these
transformations and so creating because
moving your slides
I don’t think we assume that resisting
the first slide
ok maybe oh yeah no it did move the tape
said ok it’s not actually doing the
presentation more because mission your
entire PowerPoint telescreen very rapid
citizen trade show all right well let me
try something a little different here
I’m going to just share my whole screen
and then start the slideshow here how
does that sit on straight oh okay and
you can you see me change the slides yes
we can do into this late okay all right
good all right I think this will work a
little bit better than all right thank
so um so what was missing well to make a
long story short I you know I basically
what was missing was engaged business
research you know much of agile dogma
and agile consulting and agile
transformation work is based on
experience this is what we found at one
company and so we’re going to come into
your company and try and make the same
thing happen and it works to a certain
extent but with the research shows that
IT environments are highly contextual
that means that one is very different
from the other and so it’s almost
difficult very difficult to determine
what’s going to work at one company and
is going to duplicate in another
organization and another and another and
many agile consultants approach this on
kind of a trial and error basis um which
you know is fraught with a lot of you
know they try one thing that works and
then they try something else and you
know the hit rate is not always that
great and of course the misses that
happen during that process and cause
some disillusionment among your clients
with respect to the transformation so
what is essentially missing is a
research-based approach you know an
experience is good and developing
processes based on experience is not a
bad thing but I think in order to have
the best of breed approach you need to
augment that with engaged business
research and so everything that I’m
talking to you about today is based on
research that’s been conducted within
organizations and then analyzed through
a scientific method logical approach as
opposed to hey this was just one
experience and this is what we think
this is how we interpret that one
experience there’s actually a very
a qualitative interpretive qualitative
research study with a grounded Theory
analysis that is the basis of the work
that I’m talking to you about today so
information that I’m sharing is based on
that research that’s been peer reviewed
and published you know as well as so
it’s not just one opinion I think it’s
very important that you know any
information we bring forth is based on
something that’s been peer reviewed and
published I think that’s very important
and and so what that process does is it
gives you the tools to sit to be able to
say hey this is by using this analysis
we can take this experience and figure
out what is going to be translatable or
generalizable across a number of
different contexts or situations and
when you do that you know that you’ve
got something
and so I many years ago like I said I
started on this journey 10 years ago I
went back to school and got a PhD and
obtained the skills to be able to do
this kind of analysis and then I
conducted a research study at my company
and a number of other case studies as
well to develop this research and so
that’s what makes MIT agility unique is
the research-based characteristics that
it’s based on as opposed to just
practitioner knowledge or experience so
let’s talk a little bit about the agile
manifesto for a moment I’m assuming
everyone is familiar with agile
development or at least the basics of it
the fact that agile is based on the four
tenets of the agile manifesto and many
of you have probably familiar with what
those are the agile manifesto was
published around 2001 I believe by a
number of industry experts and it’s
based on four tenets now the research
has shown over the past 18 years or so
since that was published that agile has
more somewhat or the in its application
and its usage and
so what I’ve done here is based on that
knowledge I’ve helped Millis trations on
how agile has changed today compared to
2001 so and I’ve taken each of the four
tenets one by one now of course the four
tenants are broken down into twelve
principles if you’re familiar with the
agile manifesto but I won’t go to the
twelve principles they basically are
broken down from these for all tenants
here which you’re the most important
thing to look at so if we look at the
first tenant of the agile manifesto if
you remember back in 2001 we said that
individuals and interactions over
processes and tools in other words we’re
placing a higher importance on
individuals and interactions over just
the processes and tools around them but
that it changed that has changed based
on what we’re seeing today the way the
way it really shakes out today is that
it’s individuals and interactions plus
processes and tools because today’s
tools have matured and tools actually
facilitate the interactions and drive
the processes you know back in 2001 you
had a very you have very primitive tools
out there you had version control and
and divided E’s and things like that but
you really didn’t have a whole lot of
very sophisticated tools around
requirements management and
collaboration I can do today you’ve got
a number of tools out there today like
Java and many others who who have a lot
of collaboration slack is another
example a lot of collaboration tools
that actually facilitate the
interactions and drop so tools have
become just as important as the
interactions and in fact integral to the
interactions and then the the kinds of
individuals interactions have changed
globalization has led to more complex
teams and interactions you’re working
with people from all over the world in
different time zones just like we are
right now and so we had you know richly
agile is with
focused on co-located teams but that’s
very rarely the case today many teams
are large and distributed all over the
world and so we have to have different
modes of interaction and tools to assist
in that and then you know obviously
agile is a process there’s no doubt
about that
agile is a process and it’s not to
process agnostic it simply isn’t and so
this is an illustration of how this
first tenant has changed so let’s go to
the other three
the second tenet of the agile manifesto
was working software over comprehensive
documentation right where we’re focused
on you know developing product putting
product out there getting software out
there to the user we don’t have time to
spend on tons of comprehensive
documentation and I can remember back
during that time when I was working in
this industry for a big telecom we would
spend hours developing these very long
sop documents which were pretty
exhaustive and took a lot of time to
write well today let’s change some what
it’s it’s working product with
documentation and the first key word
there is product as opposed to software
because today it’s not just about
software anymore it’s about products in
fact the better term to use is that it’s
not just about software anymore it’s
about devices if you look at all the
innovation that’s happening today the
innovation is all about devices your
smart phones and smart devices and smart
meters and IOT the center stack in your
car smart cars
smart everything but these are all
devices not just software and that has
increased the complexity and has brought
for some challenges with respect to
agile development which is what men
agility is based on
and then we go we move over to the
documentation on the right hand side
well we have to have documentation but
it’s taken a different form instead of
these long-form documents that we used
to have many years ago our documentation
today is in the form of artifacts like
ethics user stories decision comm all of
which have to be documented for tools
whether it’s requirements management
tools or whether it’s something like a
bet or whether it’s a collaboration
tools all these interactions and
requirements let’s be document but it’s
done so with artifacts more so as
opposed to long-form documentation and
if I go there’s quite a bit of
background noise if you could please put
yourself on mute I’d appreciate it all
right so the third tenet of the agile
manifesto what we used to say back in
2001 is the customer collaboration over
contract negotiation in other words
we’re focused on you know working with
the customer as a partner and not
focusing so much on nailing them down
with a with a inflexible contract but
today let’s change some why today we say
customer collaboration includes
contracts and negotiation in other words
the customer collaboration process
includes contracts and negotiation it’s
one of the same it’s a continuous
inclusive interaction it has to happen
it’s not you know one thing separate
from the other and collaboration happens
faster through a variety of different
stakeholders both internal and external
so it may not just be a developer or
working with someone customer side it
could be product managers product owners
a variety of people working with clients
or customers and developing the solution
this collaboration is complex it happens
on a number of different levels to
creative a successful product
so lastly the fourth the fourth
component of the agile manifesto is a
real biggie this one we used to say that
responding to change was more important
than following a plan right it’s all
about responding to the market that’s
all about we’re not really interested in
plan based approaches anymore we really
just want to respond to the change and
respond to the customer needs because
our customer needs are more important
than following a specific lockstep plan
but that is changed as well
today the way this is really implemented
in practice based on the research is
that today we say responding to change
while following a vision so it’s not
about having this specific plan per se
but it’s about having a vision so you
want to respond to change but at the
same time you don’t just respond to
every single change out it comes your
way you have to respond that change
responded I change within the boundaries
of the vision that you’ve established
through your company and this change
always has to be evaluated for its
business value and adherence to your
strategic goals so while you may not
have a specific solid you know plan the
next development plan for the next two
or three or four years you’re definitely
going to have a vision of where you want
to be and every change that comes your
way always needs to be evaluated against
those strategic goals that you set forth
in your vision so that’s essentially how
the agile manifesto has changed over the
past 18 years basically what we’re
seeing out there in the industry today
and the next thing I wanted to cover was
add your performance and limitations so
we see how agile has changed but how
does it perform what are the good the
bad and the ugly so to speak well the
good points are that about agile is
that’s been fairly well accepted
worldwide as fairly ubiquitous today as
a development process if most most
development organizations have heard of
it and the
try to adopt or adapted to their
situation in some way with different
levels of success of course but most
developed software development
organizations have heard about agile and
it’s been proven to improve quality and
reduce cycle time that’s a given that’s
been shown in the research it’s also
been shown to improve job satisfaction
productivity and customer satisfaction
and a lot of negative stereotypes with
respect to agile we don’t really hold up
for example a common myth against agile
is that it’s an undisciplined approach
but anyone who’s who’s tried to adopt
agile knows that it takes a lot of
discipline to do correctly and actually
keep it going so and this comes from
again from from from the research study
that you’ll find is references in the
book but then of these negative
stereotypes don’t quite hold up now
what’s the what’s the bad and the ugly
side of all this well
agile has been shown to have difficulty
with large complex products or
development environments one example is
embedded systems so an embedded system
is essentially as the device put it
bluntly is a product where you have
Hardware firmware and software
components that are developed on
separate tracks but at some point have
to be released as a cohesive product so
your Sno phone for example is an
embedded system it’s got hardware it’s
got firmware and it’s got software on it
same thing with your you know that your
service back in your automobile part
meter on your house
IOT devices in general are embedded
systems and pretty much this is a very
important context because to be honest
most of the innovation happening today
is with embedded systems it’s about
devices right I mean 15 and 20 years ago
was about websites and e-commerce and
things like that and of course that’s
quite easy to do in an agile way if you
want to put out a new release you just
go ahead and update your website
whenever you feel like it but it’s a lot
more difficult to do with embedded
that iterative releasing and constant
change taken it’s very different and
much more complex contact and again much
more important today because this is
where all the interesting stuff is
happening to be honest and ethical debt
has been a problem with advil sometimes
your technical debt can grow out of
control and we’ll touch on that a little
bit later in the presentation and of
course large distributed teams agile
sometimes has some challenges with large
distributed teams because it was
originally focused developed for Cotto
doing the meeting so there are there are
essentially different processes or
different approaches that you have to do
with agile to make it to it make it
adaptable for that context and of course
lack of strategic vision sometimes
because agile is an iterative
development method it’s a mini company
many many teams have a habit of becoming
a little bit myopic in other words
they’re focused on the next iteration
the next iteration and they lose sight
of where it is they really want to go
longer term so it’s very important to
have that strategic vision very very
critical to long-term success so excuse
me just a moment
how do we solve these problems and
what’s the situation and this this is no
secret to anyone here on the call
probably but one of the things I’d like
to mention as i’ma talk about in this
slide is the kind of environment that we
work in today so I have talked to you a
little bit about agile transformation
attempt at how agile its development
itself has changed but the world that we
work in today has changed dramatically
even compared to just 15 or 20 years ago
we had these concepts of
hyperaccelerated markets which I found
through the research so in short
energy innovation is moving faster today
than it ever has been it keeps keeps
moving faster and faster and it’s
becoming an even bigger challenge today
to manage to get your innovation
innovative products out to market before
your competitors do with the highest
possible quality and customer
satisfaction and this this phenomenon
creates what I refer to as agile
whirlpools or vortices which is
something I documented through the
Medici leti research and it’s all about
it’s all about how do we meet – this
challenge of hyperaccelerated markets
how do we get our products complex
products to the market with the most
innovation and the highest quality and
bringing the biggest value to your
customers in your market and gaining
that early large critical initial market
share so that you can be ahead of the
competition it’s very hard to do is
getting harder to do every day and so
manage ility essentially addresses that
which we’ll talk about but this slide
here just sort of lays the land as to
what kind of environment we’re working
in today and that’s what MIT agility is
all about so we asked me earlier what is
method ility well the word met agility
essentially means the management of
agility and it is essentially a new
methodology that’s come out of the
research that I’ve done and this
research is based over ten years of work
it’s been published in some
peer-reviewed journals and has now been
published as a practitioners guide which
I’m talking to you about today and what
it’s composed when it’s essentially
composed of as I researched a number of
companies that were attempting agile
transformation and leveraged a
scientific qualitative analysis to
determine what they were doing right
what they were doing wrong
and what was working across all these
organizations and not only what was
working but what was working extremely
well during this research process not
only did I find you know some complete
information about working well and what
wasn’t working so well I found that some
of my case studies evolved into when I
tell him a meeting okay excuse me so I I
found that many of the case studies
evolved into what I call a super agile
adaptation then enabled them to become
number one in their market and this
turned out to be very very interesting
so there were some companies that
weren’t doing so well there were some
companies that were doing very well
there was one of piece of small subset
of companies so we’re taking agile and
really taking it to where it was
enabling them to become number one in
their market and this super agile
annotation is what I documented
amenability and I documented the
components of this super agile
adaptation so that you can conceivably
duplicate these these characteristics in
your organization and potentially
achieve the same results to become
number one in your market or at least a
gain leading market share and so when
you think about that that’s very
powerful and that’s that’s that’s the
cool thing about research is it allows
us to find knowledge that’s developed
knowledge is extremely powerful far
above and beyond what you might find
just with a few sub few small
experiences from a practitioners
so what are some of the components of
met agility well obviously there’s a 300
page textbook on it you can find the
textbook on Amazon or on J Ross
publishing actually I think you can go
to Google and just type in met agility
and you’ll see tons of websites come up
I think it’s available pretty much
anywhere even on read Shaw or
electronically but what I wanted to do
here next is to go over some of the
components met agility at least at a
high level to give you an idea of what
it’s composed of specifically this super
agile adaptation that I’m talking about
so the first component is hybrid agile
implementations and so when we talk
about hybrid agile implementations a lot
of agile consultants they cringe they
don’t like to hear that right well
you’re you know hybrid agile as you’re
cheating you know that’s scrum or Paul
or rajole or you know there’s all sorts
of bad words associated with hybrid
agile implementations but the research
has definitively shown and I’ve
documented this in the book and provide
a number of references for it that this
has become the leading approach for many
organizations today many companies our
firsts are managing two different hybrid
agile implementations very successfully
and this is where agile is headed you
may see the agile manifesto itself morph
into more of a hybrid approach and
that’s very important to know it’s not a
bad thing it’s actually a very good
thing so if you have an organization is
considering a hybrid agile approach it’s
not necessarily cheating and the
research shows that there’s a lot of
other companies doing the same thing the
trick is how do you do it because you
know what is the right mix of waterfall
and agile processes it’s going to give
you the most bang for your buck and
that’s where that’s what the trick is
and that’s what we’ve documented in the
book as well so what do we base this
assumption that
hybrid agile is a an acceptable approach
well there’s a number of case studies
that have shown that they’re doing it
but one diagram that I like to bring
forth is farland diagram and Arlo is a a
researcher in and throughout this talk
I’m going to mention a few researchers
in the engaged business research space
who have done a lot of work with agile
because I like to show that everything
I’m telling you is based on solid
peer-reviewed material as opposed to
just my opinion for Waters’s opinion or
one person’s approach which is much more
pervasive in the agile consulting
industry so there’s a researcher named
Barlow who came up with a method for
determining whether you should adopt a
pure agile approach or maybe a more
waterfall or plan based based approach
or hybrid agile all for your palate you
may need to use any one of these three
approaches depending on your context but
what this diagram does at a very high
level is give you an idea of how to make
that determination and in a nutshell
here if you look at the diagram I’ve got
here on the top right adopt a hybrid
walk agile waterfall approach this is
based on a lot of reciprocal project
interdependencies so when you have a lot
of reciprocal or complex inter
dependencies on your projects you may
need to consider more of a hybrid
approach especially if your team size is
also quite large and distributed so it’s
essentially a function of your your the
complexity of your inter dependencies
and the sizes of your teams and and so
if you’ve got large teams and a lot of
complex inter dependencies a hybrid
approach definitely a valid way to go
and this bit of research here shows that
that is very true and very valid and the
embedded systems context which we talked
about earlier is definitely one of those
that has enough complex project
interdependencies because of the
multitrack development the fact you have
essentially three separate products
hardware firmware and software developed
on different tracks but have to be
released as one cohesive test product
that’s that’s that’s it in a nutshell
right there reciprocal interdependences
and I’ll take you through a little bit
about what those look like in such an
organization in just a moment so I want
to talk a little bit about agile
assessments so you know obviously I just
showed you a diagram of how to determine
whether a hybrid agile approaches a way
to go or not or whether you should go
pure agile or waterfall it usually
begins with an assessment you know I may
come into an organization to do an
assessment of their teams and their
current processes and their current
development environment and their
product lines so on and so forth
and I want to share some common problems
that I often find in these assessments I
have a 25-point assessment process which
is documented in the book by the way so
it’s not a consultants secret if you
will it’s in the book but you can you
can look that up and go through the 25
points that I typically do during an
assessment and some of the common
findings I’m sharing with you some of
the common findings from those types of
assessments here some common problems
found in organizations where they
typically tried a jold that haven’t
really gotten success out of it that
they want they often have too much work
in progress there’s a lack of a product
called role technical debt is often out
of control and I’m going to show you in
a few slides why technical dead and how
technical debt can sometimes get out of
control often there’s too many releases
running in parallel competing for
resources and commitments are made
before the team’s really understand the
requirements to do some typical findings
and some of the common organizational
challenges I found is that there’s a
lack of automation infrastructure
particularly test automation
you know being able to have test
automation is very important and also
lack of a performance baseline if you
don’t know where you are it’s hard to
know where to go so you have to
establish that performance baseline so
how do i typically attack some these
problems we often go well oftentimes at
least in the short term to try and you
know add some quick and early value I
will focus on helping them work about 20
to 30 percent of the backlog trying to
figure out okay what’s what’s the top
fifth or the top third of the backlog
that we can try and work through now and
try to aggressively work through that
help them establish teams that can stay
together and establish a release cadence
with only one release and flight at the
time and then of course there’s
typically a number of cultural issues
around communication collaboration
empowerment Trust and that sort of thing
so I tried to earlier from a short-term
perspective hit these top five points in
addition to well as part of the solution
plan that I’ll create for them so it was
a good idea to try and share with you
some of the typical findings of some of
these assessments out there so what are
some other components of men agility
well we talked about the hybrid agile
approach well how does that work exactly
well there’s a number of moving parts to
it but probably the biggest piece is
mapping the stage gating on to the
iterative development process well how
do you do that well at a high level you
you you basically graft your stage
gaining onto your iterative development
by by utilizing your stage gates as a
check and balance so the stage gates are
essentially a sort of a check and
balance at various stages of development
process that allows you to sort of sync
up your different tracks of development
and it provides some kind of Santa to
sanity checking against the iterations
to make sure that your you know do they
buddy has what they need to do the
proper reporting to upper management as
well as metrics and customer
communication and collaboration and and
those types of things you know you you
just can’t get away from and I think and
some some some agilent’s may believe
that well you know it’s not really all
that important to focus on metrics or
reporting or or that sort of thing or
deadlines so to speak well you have to
virtually every project it’s going to
have some kind of deadlines now they may
be flexible they may be you know more of
like a window as opposed to a hard court
date it just depends but any business is
going to have to have especially when
you’re developing embedded systems or
products you’re going to kind of a
timing and the stage gating acts as a
check and balance against theater
development provide you that that those
waterfall characteristics of reporting
and sanity checking and and and
checkpoints that your your your business
is simply just going to have to have
another component in addition to and if
I could ask again if you if you just
join the call recently if you could
please put yourself on you there’s a
good bit of background noise thank you
another component of men agility is the
scrum scrum with a hybrid approach so
you know a scrum it’s not necessarily a
requirement with agile you may have
agile implementations that don’t have
scrum at all and they use something else
but most of our successful case studies
used from scrum seems to be probably the
most often and the most successful of
the process rituals I guess if I could
call it that
that’s essentially what scrum is it’s a
set of rituals a set of meetings or a
set of inter connections or interactions
that help facilitate the agile process
but I’m going to show you in a later
slide how those are not the only
interactions that happen
and most of our best most successful
case studies but one thing I wanted you
to take away from this slide here is it
essentially shows you how the stage
gating process is grafted on to the
scrum process within a hybrid agile
environment I just showed you a slide
that was kind of at a high level just a
second ago and this drills down one more
level into that and one important
takeaway here is that many many agile
lists will focus on the scrum process
itself they focus on the development and
testing teams and they focus on the
stand-up meetings and their
retrospective and they focus on
everything that happens at stage two and
afterwards if you look at this diagram
here you’ll see where the scrum process
starts at Stage two and progresses
afterwards from behind that but there is
a pre scrum process that happens in the
beginning and that’s where you have a
lot of your requirements development
requirements decomposition and
comprehension and use case development
and this often happens before your scrum
teams get involved and/or the scrum
teams would start developing and many
agile consultants don’t focus on this
enough and this is where much of the
process breaks down because this is
where your technical debt gets out of
control because in the pre scrum process
if your product owners or your business
analysts are not developing requirements
in an agile way if they’re still
following a waterfall mode of
requirements development they’re going
to blow your release out of the water
they’re going to create tons and tons of
requirements that you don’t necessarily
need and those requirements are going to
be difficult to prioritize and you’re
going to start rubbing those
requirements into your teams and
overload your development teams and it’s
going to slow the whole process down and
I’ve seen this happen with a number of
our case studies where we are undergoing
an agile transformation many often
change and one of those roles or changes
is the role of a business analyst so you
may have a business analyst who’s there
possible for gathering requirements in a
waterfall situation and that person will
usually become a product owner in an
agile world which is a different role
but they don’t change the way they do
business often times because when you
when you build requirements in a
waterfall environment that’s very
different from agile because when you’re
in a waterfall situation and you’re
gathering requirements you’ve got you
know that you have that hard plan based
approach you’re trying to predict what
you think the customer is going to want
and most business analysts will
brainstorm and try and think of as many
requirements as they possibly can to
pack into that release so that they
don’t miss anything because they’re
worried about missing something right
because in a waterfall situation you’re
not supposed to be able to change or you
try to avoid that at all costs and so
the BH they go overboard and they will
it’s not really overboard in a waterfall
situation is the correct approach but
when you’re in an agile situation you
don’t want to do that you don’t want to
brainstorm and create as many
requirements as you possibly can you
want to focus on what the customer needs
and it’s all about customer
collaboration and developing those
requirements along with the customer not
about brainstorming and creating as many
as you possibly can and so many bas
don’t do that when they transition to
agile and that blows up the whole
process and that’s where it often fails
and so I offer some courses on how to
coach bas to transition to product
owners and how to change the way that
they decompose requirements and manage
requirements because most of the
problems are upstream when it comes to
filled agile transformations from what
I’ve seen in my experience here so
another characteristic of met agility is
this is just an illustration of release
management with hybrid agile this gives
you an idea of how releases are managed
with a hybrid agile environment so you
have your your gate stage gate approach
there at the top and you have your
various gates at the different points in
the process and this shows you
essentially how the different
requirements are demoed at various
points throughout the stage gate and
you know how many how you can
essentially have your first release and
your next release coming in behind that
and I think the next and on the next
slide there’s another slide that
illustrates how that process takes place
but essentially you have a staggered
release train where you have you know
your your your developing teams are
focused on one release in flight
primarily and you may have one team left
behind to focus on our priorities and
one team that’s focused on a release
already in production that may be
working on on defects or fixes of that
sort so um
another component met agility is the is
how the different tracks of development
work together and this is very important
this is very important these here so
I’ve talked a little bit about Hardware
firmware and software in the context of
embedded systems and how much I would
last a meeting how they’re able to
develop products on different tracks but
have to release a product cohesively as
one unit right and so the research has
shown that each of these different
development organizations within the
same company adopt agile in very
different ways but they use methods they
use of unique approaches to keep up with
each other and this is based on the
super agile adaptation that I talked
about so not only do you have a hybrid
agile approach of the organization but
your different development tracks will
adopt agile very differently so if you
look at the if you look at the inner
rings here the center is customer
management and that’s because all three
development environments hardware
firmware and software directly work with
the customer so it’s not just one or the
other everyone works with the customer
as I mentioned earlier customer
collaboration occurs on a number of
different levels with a variety of
stakeholders the the inner ring the
software ring that’s the fastest-moving
ring and
where is the software teams typically
have a complete or a pure agile
implementation they won’t have their
two-week sprints they’ll have they will
have you know regular scrum meetings and
they will usually have a six month or
less release cycle so there and and the
unique role that they’ll play in this
organization is they function as the
early responders so if you if you’ve
ever had a chance to observe an embedded
system organization and how they work if
there is a problem they will try and
find a software solution before they
find anything else so for example with
the recent Boeing 737 max failure right
they attempted to solve that problem
with a software fix because obviously a
software fix is going to be a lot easier
to accomplish and a lot quicker to
accomplish than a hardware or firmware
fix so in embedded systems organizations
your soccer teams serve as an early
responders they’re going to be the
strike force to try and solve any
problem out there through a software
solution because that’s the fastest way
it can be done the next thing that you
have is through firmware teams so your
firmware teams are developing software
that has to sit on top of the hardware
and a lot of times this type of firmware
has a number of constraints usually with
respect to processing power and memory
and they they serve as sort of a shared
resource between the hardware and
software teams because both of those
teams have to use them to get their jobs
done especially when it comes to testing
and prototyping and proof of concepts
and your firmware teams often have a
partial agile adaptation so they’ll be
agile that day instead of two-week
Sprint’s they’ll typically have maybe 30
days prints and they won’t have
stand-ups everyday they may have
stand-ups you know maybe once a week or
something like that and this is very
important because one of the biggest
reasons for agile transformation failure
in some of these organizations as they
try to push too much processed on wrong
butl without adapting
so for example a good example to
illustrate that is with the I think
prices law or the Pareto principle which
says that 80% of the work is done by 20%
of the workforce and in firmly cases and
some of the case studies was more of a
90/10 split where 90 percent of work is
done by 10 percent of the workforce so
you want to be very sensitive to that 10
percent so if you’re pushing a lot of
process onto that 10 percent you may get
some a lot of pushback and that’s going
to make it very difficult for your for
your admiral implementations to stick
many many my advocate focuses I possibly
to say that because they walk out the
door the transformation melts away and
it doesn’t stick all the reasons it
doesn’t stick is because people don’t
want to do it they’re not going to do
something they don’t want to do so you
have to you have to be able to adjust
your implementation based on the needs
of these different teams and be
sensitive to that 10% and and since the
firmware teams don’t move as quickly as
the software teams and don’t change it
quite as often they don’t have to have
two-week sprints 30 days is enough you
know and their release cycle is going to
be a little bit longer and then of
course on the outer ring you have
Hardware your hardware teams are are
tied to manufacturing they’re going to
have more of a staged gating approach
they’re going to have longer release
cycles but at the same time they have
ways of trying to keep up with the rest
of the organization they do that through
rapid prototyping is one way to do it
at the firm where teams the software
teams need some kind of new need a
prototype of some kind of test against
or to prove out a new technology the
hardware teams will try and create this
through rapid prototyping to give them
something to work with so they can
develop against it or it’s actually
released and then of course sea level
projects is a number another way they
catch up sea level projects are projects
that are our low-cost project are
typically that 100,000 the project that
hundreds can can make happen very
quickly to try and meet a specific need
it might be a customer need or it could
be an internal need
um but these are low-budget projects
that they can get done and knock out
very quickly so it allows them to be
agile as well even though they may not
have you know the agile scrum process
and their organization this gives you an
idea of how these different release
adapt to agile and work together so
another component of a met agility is I
think there’s someone else needs to be
put on mute if you if you just join
please put yourself on me there’s some
background noise um thank you ah so
another component of men agility is the
idea of agile for tissa T or the ideal
of how I feel can be measured okay I
think we have some some quite a bit of
background with someone with some nasal
issues if you could put yourself on on
mute I’d appreciate it so uh another
again another component is how agile can
be measured that’s a big question in the
industry many tools companies and I
think when we went to a Gartner Expo a
while back and HP and a number of
companies had this question well how do
we measure agility how do you put a
number on it or can you put a number on
well you can and that’s what that’s
another thing that came out of this
research was the idea of agile or tissa
T and business momentum and these are
two measurements that came out of the
research that I developed and they’re
based on a grounded theory and now
assistance so they are entirely new
concepts that I’m trying to put forth
out there into the into the ether so to
as ways to manage how how you can tell
how agile you really are and that’s very
important and it based on having an
agile method of rating measurements so
in order to be able to have agile or
distant momentum as measurements you
have to have yes to base your measuring
your measurements
strategy on the agile triangle as
opposed to the Iron Triangle and so I’m
having a little bit of a difficulty
there all right so the Iron Triangle I’m
missing a graphic tier that I wanted to
show but the Iron Triangle in the agile
triangle are two different especially
two different ways of looking at metrics
so if you remember the agile triangle is
using the Iron Triangle from project
management is based on scope scheduling
cost right everything has to fit in with
this idea of scope scheduling cost but
the agile triangle is not focused on
scope scheduling cost it’s focused on
value quality and constraints and that’s
that’s very important so any kind of a
critical component of an agile
transformation is having an outer
measurement a pro and that agile
measurement approach has to be based on
the agile triangle which is based on
value quality and constraints as opposed
to the old scope scheduling cost
approach and well what is value of what
is quality and what are constraints
exactly well your your your quality is
essentially your you have two types of
quality you have X intrinsic quality and
intrinsic quality and X intrinsic
quality is quality as its perceived by
your customers and that essentially is
what value is it’s a is your product and
it’s perceived by your customers whether
they perceive it as high quality or high
value whether it works right or whether
it provides the features that they want
that’s value and then intrinsic quality
is quality as its perceived internally
within your organization so your
developers and your testers are going to
know about the quality of your product
they’re going to know how many defects
it has against it and how many problems
it has and how buggy it may be and so
that’s intrinsic quality and then the
third component is constraints where
your constraints are your budgets
primarily your budget resource
constraints teamer strange that kind of
thing and so your measurement strategy
has to be based on those items and once
you develop a measurement strategy based
on that agile triangle of value quality
and constraints then you can develop the
edge of artistic and business momentum
metrics that come on top of that to tell
you how agile that you really are so
metrics we talked about metrics that’s
one component of agility or met agility
so to speak well how about what are some
other components another component of
met agility is the idea of market
agility market agility is the ability of
the business to adapt to these hyper
accelerated markets that we talked about
earlier and it’s a function of product
genesis and reaction to market pressures
so it’s very important to understand
what market agility is because it sort
of leads up into what agile or tissa tea
and business momentum really mean so
this whole process of hyperaccelerated
markets that I talked about earlier it’s
driven by this market pressure this
central pool or this whirlpool so to
speak which is a theme of what MIT
agility is about and so the components
of market pressure include market share
your customer base the future direction
that you’ve established for your
organization that we talked about and of
course customer appetite you know when
you’re collaborating with the customer
there’s only you’re going to essentially
use the customer as as a tester and
there’s only so much of that they can
take there’s so many only so many
iterations of new product they can take
because you may be able to produce tons
of iterations of a new product but you
know it’s
point they’re going to say hey we can’t
take any more because every time we take
a new version of this product we have to
do a lot of testing and betting and it’s
a lot of work on our part to train our
new employees on it and all this other
stuff so your customer has an appetite
on how much innovation they can handle
and how much change they can handle or
so government regulation is often a big
component especially with IOT you know
IOT embedded systems in general embedded
systems development often has a number
of constraints that are meet a higher
level of quality and regulation and just
standard talk where many of these
products as I mentioned earlier are
components within automotive vehicles or
jet flight systems or utilities and
power systems and of course there’s a
lot of government oversight with respect
to that stuff and as opposed to you know
an e-commerce website right so
government regulation is a big component
of market pressure in these contexts and
of course that market pressure drives
the product Genesis process the product
Genesis process is a component of net
agility where you’re you’re establishing
what it is that you’re wanting to build
and that’s a component of market timing
and prioritization process of
comprehending and decomposing your
requirements and sort of refining that
scope of what the product is going to
look like that scoping process leads up
to this business momentum phenomenon
that I’m knitted earlier and business
momentum is essentially using I think we
have some more background noise or it’s
like a little chime in the background if
you could please put your put yourself
on mute I’d appreciate it
and so this what its business momentum
well if you remember from physics
momentum equals mass times velocity
business momentum is essentially the
size of your portfolio multiplied by
velocity or thus your scope multiplied
by your timeline and so it gives you an
idea of how much momentum you’ve got
going in your organization with respect
to your product Genesis and another
component of C we talked about the idea
of market agility and that is composed
of market pressure and product Genesis
well processability is the other side of
it which we just talked about is the
ability of your global organization to
to meet or to match that product
Jennison process within its constraints
and so here I have a stylized diagram of
the target diagram that I showed you
earlier which shows how the different
components of our the different tracks
of development adapt to agile
differently and of course what these
what these different tracks do is they
develop this system release which is the
final product that they all try to work
together on that systems release has to
meet the expectations of the
requirements which is the outcome of
product Genesis well how do they make
these two parts come together how do
they make market agility and process
agility come together to match and and
and and create this final product well
this is this happens through a process
of agile orchestration and this agile
orchestration process is what I
documented in agility and it illustrates
how the organization makes these two
pieces come together and it’s based on a
number of different components I think
we’ve got some music playing in the
background if you could put yourself on
you okay thank you all right so I add
what is agile orchestration exactly well
it’s the process of making adjustments
by way of special interconnections and
interactions to bring the system’s
released in alignment with the
expectations set by the business which
is essentially what your product Genesis
is it links your strategy with your
execution in essence and you know a big
component of agile is interconnection
throughout your interactions that’s very
important and it still is even with a
hybrid approach
but it’s very rare that you’ll actually
see anyone put any rhyme or reason
around those interconnections and
interactions which I’m going to show you
in a couple slides here now this next
slide sort of as an illustration of this
entire process as it works together and
this is sort of a theoretical concept
that came out of men agility it’s the
idea of the agile whirlpool where you
have these hyperaccelerated markets that
are driving this very strong market
pressure and you have product Genesis at
the center which is driving this this
idea of what the product is going to be
about and you have your your process
agility composed of your hardware
firmware and software teams that are
trying to match what is being driven by
the market but what does this what does
this illustration really mean well it’s
sort of a theoretical illustration you
know if you remember I think when
Einstein Illustrated relativity
relativity he came up with the idea of
the elevator right and you probably
heard his elevator illustration this is
something kind of similar I think it’s
very useful to use an illustration to
create a theory and agile or tissa T is
a is based on a grounded Theory analysis
that’s important to mention and so if
you have a summative like a flow of
water innovation is often illustrated as
being a flow and if you have a flow of
water in a river the water that’s in the
center of the river is going to be
flowing faster than the water that is
closer to the bank because it slowed
down by friction and so if you put a
four tissa T meter which is like a
little windmill on top of a buoy and if
you stick that into the water at the
point to where those two different flows
meet it’s going to spin very fast you’re
going to have a high level of vorticity
because the flow of water closer to the
bank is moving a lot slower than the
water in the center of the river and so
that’s going to give you at some point
in the flow you’re going to have very
high vorticity and so as with this
illustration here
if your product Genesis and the market
pressure is moving much much faster than
your hardware firmware and software
teams are then you’re going to have
hearing Holub or Tiffany because that
market is moving very fast they’re
already they’re already ahead of you and
you’re struggling to keep up with them
and so you’re going to have that very
high for Tiffany rate at the point of
your where you’re trying to develop your
product and if if you’re if your heart
what you ideally want is you want your
process agility you want your hardware
firmware and software teams to be able
to match what is being driven by the
market and if that happens then the
flows of water are going to be at the
same rate and your agile vorticity is
going to be zero or close to it so
that’s essentially what agile or tissa T
measurement is is it puts a number on
how agile you really are if you have
zero vorticity then you’re as a Jalees
you possibly can be you have a very high
number then you may have some work to do
and so this is a unique concept it
actually puts a number on how agile you
are and again I think that’s a very
unique concept there’s there’s nothing
quite like it out there and that’s
something unique that men agility is
brought forth based on this research and
it’s it’s pretty special so and of
course well how do you determine that
agile or tissa T well again you have to
create a metric solution based on the
agile triangle and with in other words
we developed about a hundred different
metrics based on an agile triangle and
so we can work with organizations to
sort of tune trade in tune and customize
a metrics or a program of portfolio
management solution that will provide
you not just the dials and knobs but the
music to see what’s going on and it will
give you an edge of artistic measurement
to show you how to adjust and reach that
reach that high agile vorticity or the
zero agile vorticity so to speak
so we talked about agile orchestration
and we talked about how it brings these
two components of the organization
together through interconnections and
interactions but what is this what does
this look like you know we talk about
agile we often talk about
interconnections or interactions and how
important they are but it’s very rare
that we put any rhyme or reason behind
it well okay I know I’m supposed to do a
lot of interactions but what does that
really mean and you know is it just
water cooler conversations or is it
meetings or is it stand-up meetings and
and by the way how do I document all of
these different interactions that are
happening and how do I track everything
that’s going on without losing the
decisions and learnings that come out of
these interactions so during the
research what I did is that I threw a
grounded theory analysis I determined
well what are the different
classifications of interconnections in
our interactions and I came up with
these with these six different
categories dependencies inter
dependencies linkages which are
scheduled meetings between domains
status points which are essentially
metrics or monitoring points reporting
and decision points these are formal
meetings or process points between
stakeholders for making decisions
oftentimes these are tied to the stage
gating that I mentioned earlier or they
could be tied to demonstrations for user
acceptance or or like I said you know
decisions within the stage gate process
these are formal meetings or process
points then you have touch points which
are more informal interactions that
occur to you know among developers or
testers to resolve problems or follow
all of them progress and these these are
very very important it’s very important
that you have the proper tooling in
place to document the outcomes of these
kinds of touch points you know tools
like slack or Jireh any type of
collaboration tool is going to help you
do that because these kinds of touch
points become very very important that’s
important to document what happens
during these interactions otherwise
you’re going to forget
or people aren’t going to find out about
them and there has to be a way to bring
these kinds of decisions made in these
situations forward and so in some of
these so for some of these
interconnections and interactions you
already have by for example indecision
points and me formal meetings you’re
probably already taking meeting minutes
or something like that which could also
be integrated into the collaboration
tool and of course that is processed at
is points are of course documented as
being part of a tool but not everything
is documented you know as part of the
process so that’s where collaboration
tools can help with touch points but
it’s very it’s very important to with
the men agility concept that you
implement these different types of in
executive and inside the book I actually
go into detail and outline all the
different ones all the different
decision point meetings the kinds of
meetings and who typically attends those
meetings and and what the focus of the
meetings are and what the general
outcomes are I go over metrics and the
different types of metrics that are out
there and available of course there’s
tons of good metrics available but you
really need to focus on the ones that
are going to be the most helpful and
based on the research I found there’s
certain metrics that are much more
important than others and it’s not
always about velocity which is a
velocity or capacity or work in progress
which is what we focus on in an agile
world well work in progress is very
important your your cumulative flow
diagram it’s probably one of the most
important metrics and I go into detail
in the book about that too as well as in
the we have a metrics package that we
have available as well that you can
download for about 25 20 bucks 20 25
bucks from the publisher and it includes
many of the basic metrics that we’ve we
created based on the research that has
been shown to be the most helpful in
this situation so again this slide puts
some rhyme and reason behind this blurry
concept of interconnections and
interactions which in an agile world is
often sort of
okay we don’t really know what all that
means where this sort of gives you this
gives you a very defined set of
interconnections that you can implement
in your organization so the Met agility
framework so this is an overview of what
we just talked about and this is the
framework that meant agility is
essentially based on and it includes
everything we just talked about you’ll
see the process agility and market
agility and you’ll see those components
broken down into their sub components
for example in market agility we talked
about market pressure and the components
that compose it product Genesis and the
components that compose it as well as
process agility and the components that
compose it like hybrid agility and what
composes that hybrid agile approach as
well as how the customer is managed
through negotiation and expectations
management and the process of agile
orchestration so agile orchestration
having having two key components the
interconnections and interactions
composed of all these different
categories we just talked about as well
as making adjustments so within those
interactions you’re making adjustments
with respect to customer acceptance and
resources and reassessing the value of a
specific requirement or a need and
adjusting the scope accordingly and so
this framework is a there’s a number of
frameworks out there in the market today
you’ve heard of obviously there’s dsdm
there’s less there’s a safe and of
course you know you could probably put
scrum in that category too and a lot of
times these frameworks are not
necessarily mutually exclusive you can
have safe you can have met agility you
can have scrum you can have Kanban you
could have all those things in the same
organization in the same environment
really because they kind of play they
attempt to solve the problem at
different levels you know safe is
safe is essentially a strategic Idol
framework for the enterprise so it’s
focused at a very high level it’s
focused on trying to agile eyes all
aspects of your business including legal
and marketing and all that sort of thing
whereas scrum is at the opposite end of
the spectrum it’s focused on your
development teams and the rituals and
processes around how your development
teams work together and interact and the
rituals that they undertake to to
improve themselves and prove the product
and Kanban is it even probably a more
granular level because it’s it’s all
about flow so Kanban is focused on the
idea of flow the idea of controlling
your work in progress at certain certain
points in the development process to
improve the flow of product and it’s
wonderful to see how that process works
if you ever have a chance to work
through a Kanban board but the Kanban
doesn’t necessarily always address the
issues that we found in the pre scrum
process so to speak that I mentioned
earlier this idea of requirements
compass decomposition and comprehension
that often is the result of
out-of-control technical debt and
bloated releases that can bog down teams
very quickly that’s a problem that’s
often not addressed and so what is
managed ility where does it fit in and
that lexicon or that spectrum well I
think it essentially it’s below safe but
it’s above it’s above scrum it’s sort of
somewhere in the middle there met
agility is focused on your product
development engine it’s focused on is
something like safe is going to be
focused more on incremental progress
across your entire company and scrum is
focused on your teams met agility is
focused on your product development
engine so what it try what of what are
the temps to do the research is again
document that super agile adaptation
that we talked about and what that
company did is they leveraged agile to
become number one in their market and
they did that by focusing on the product
development engine and in
creating agile in a unique way into that
product development engine so if you
want to win the race and I’m a car guy
by the way so if you want to win the
race you want to have a powerful engine
and you want to have a light body you’re
not worried about air conditioning or
power windows you’re worried about the
transmission and the engine and the
tires and you’re worried about getting
that product out the door as quickly as
possible with the highest possible
quality and that’s what MIT agility does
met agility is focused on what it takes
to get that innovative product out the
door focuses on your product development
engine which includes your teams but
it’s not necessarily worried so much
about some of the more abstract aspects
of the company that safe might be
focused on which is you know your
marketing maybe or your legal team and
things like that and other aspects of
the company this is again the company
that was our the the the the case
studies that were most successful that
managed to leverage agility to become
number one in the market this is what
they did well how do you know if agile
frameworks are really agile anyway we
talked about agile frameworks I’ve
listened not named off a few of them and
there’s been a lot of discussion as to
whether some of these frameworks are
really agile or not I’ve been to a
number of agile conferences which argue
about complain about say for example is
not really being all that add role and
as well as others there’s a number of
different ones out there
well again I go back to the research
because that’s when is what I think is
the most valid I can give you an opinion
but let’s just look at the research and
see what the research says well there’s
an add to research researcher from
Australia named here in convoy and he’s
done a lot of agile research and he came
up with a taxonomy for determining if a
framework or methodologies agile or not
um and I thought that was very
interesting and so this is just an
excerpt from that by the way it’s not
the entire taxonomy
but I just cut out an excerpt from his
research here to illustrate to you
nothing is probably the most important
component he said that agile frame any
agile framework or methodology should
never detract from economy quality or
simplicity and so anytime I look at an
agile framework or methodology I had
that in mind and of course he has a
thorough taxonomy but to me this is what
stuck out so anytime you look at the
methodology or a framework you want to
try and figure out hey is this really
agile keep this in mind it does this
framework that you’re looking at is it
focused on quality is it focused on
economy is it focused on simplicity or
does it detract from these in any way
that’s a better way to put it and
oftentimes when I look at these
frameworks they’re anything but simple
and you can look at for example the safe
framework it’s very complicated and very
process heavy which you could argue is
the antithesis of what agile is all
about but that’s not to say that it
can’t be helpful or can’t provide some
results it just may not be as agile as
you might think based on this criteria
and so that’s what the men agility
framework does is it’s a economic it’s
focused on quality and value it’s
focused on outcomes and it’s simple
compared to many out there and so you
want to try and use this criteria and I
would encourage you to look up convoys
paper and read through it it’s got an
interesting taxonomy there on how to
determine whether you know a framework
really is agile or not and I’m it was
all the frameworks I’ve seen out there
I’ve rarely seen proponents of these
frameworks go back to the research and
prove what they’re saying is true well
if you think your framework is agile can
you provide some research peer reviewed
published research that proves that to
be so it’s very rare that you’ll see
that and again I think it’s part of what
makes what we do it ad your works and
very unique
so how is agile going to change I showed
you at the beginning of this talk how
agile has changed and it’s changed quite
a bit in the last 18 years hasn’t it and
it’s going to continue to change and
evolve over time
and the research that I’ve done has
shown that it’s going to change and
primarily the following ways these are
just some high points that I pulled out
of some of that learning it looks like
data science along with advanced tooling
will drive decisions so I think you’re
probably going to see maybe more
artificial intelligence driven by data
and data analytics that it’s going to
drive decision-making it’s going to
drive you know team sizing and resource
allocation and you know these these
program and portfolio management tools
are becoming more and more sophisticated
and it may be that based on AI and data
now data analytics that you know a lot
of management decisions might be made of
tools as opposed to your boss and hey
that might be a good thing right
approaches to commute communication must
be continually evaluated so you have to
constantly re-evaluate how you’re
communicating reevaluate your your
interconnections and interactions that
are going on in your organization and
adjust accordingly agile is becoming
integral to strategic planning you know
so agile is not just a development
process it’s not just a team
organization process it’s a new way of
doing business and so agile is as part
of that conversation that’s part of you
know figuring out what your vision is
going to be and how you’re how you’re
conducting your strategic planning and
establishing those strategic goals for
your business
agile is a big part of that it has to be
if you really want to achieve what it’s
meant to do for you and that is to
become a leader in your market to gain
that early critical market share that’s
so important
and that is the biggest reason why some
of these case studies that were very
successful with this super agile
adaptation is they were able to leverage
this process
to gain that early critical market share
before the competitors were and once
they did that you know they were a force
in the market to be reckoned with and
and it was they did not diminish after
that because gaining that early critical
market share is so important and of
course Kanban is becoming more and more
prevalent seeing and hearing a lot more
about Kanban there are a lot of Kanban
training courses out there they’re
becoming a little bit popular Kanban is
a wonderful process for managing flow
I’ve gone to some of these courses as
well working a Kanban board and seeing
it work is a wonderful process the other
side of that though is that some of the
courses that I’ve seen out there they’ll
spin like the first day or two going
over a Kanban board and then after that
there’s this there’s a lot of management
fluff and you know that’s not so
interesting to me but the combine
concept itself is a solid one and it’s
becoming more prevalent also in order to
maintain success companies have to
constantly seek out new markets in some
of our case studies even though they
were very successful and in some cases
had this super agile adaptation over a
period of time they failed to seek out
new markets they tried to stay with the
same market instead of you know trying
to branch out into other things and that
has slowed down innovation and slowed
down growth and in some of those cases
but because if they gained enough early
critical market share that I mentioned
earlier they had such a huge business
momentum but they’ve kept going and even
though they haven’t really innovated
much in the last few years or found any
new markets they’ve had so much business
momentum based on their early success so
they’ve managed to keep going for a
while and and may be able to do that for
quite some time but in order to continue
that growth you have to constantly seek
out new markets because they all have a
life cycle
and that’s very important
agile evolution and natural selection
well I think agile is naturally going to
evolve and companies that don’t adapt
some mode of agile development they’re
going to fade out whereas companies that
do are going to survive and I think
agile itself is going to continue to
evolve and change as it has over the
past 18 years and I think that you’re
going to see and hear more about hybrid
agile implementations
and so that is as the end of my talk
there again if you have questions I can
take a few of those questions now be
happy to I just want to make you aware
that you can check out our website or
you can contact me at david at agile
works comm we have a book check out the
book met agility it’s pretty much
everywhere you can type in met agility
on Google and pull it up and buy it it’s
on Amazon it’s a Barnes & Noble it’s
available electronically and also as a
hard copy it is a hardcover book but
also I have a series of courses that I
offer training courses based on the
module II process I have courses on
metrics metrics development courses on
requirements management and requirements
decomposition as well as coaching the
process and the men agility approach
itself I’ve got about six courses right
now and I’m the process building a few
more so if you’re interested in those
you can check those out and of course we
offer consulting services as well to
help implement this framework into your
organization and our consultants are
engineers and managers and PhD level
advisors not just you know most agile
consultants or many agile consultants
our motivational speakers or just
coaches we’re actually like myself for
actually technical people and engineers
and developers who’ve been in the
trenches like yourself and so I think
that gives us an edge in terms of
understanding the problems in developing
solutions that are most helpful because
a lot of us know where the problems are
because we’ve been there and someone who
hasn’t had that experience it typically
does not so I want to thank everyone for
attending this call and thank I Triple E
Tim for give me the opportunity to speak
to you through this webinar and again if
you have some questions I’ll be happy to
answer any I know if it’s been a
a long talk but we’ll be happy to talk
some more if you have questions yes
yes yeah hi this is Paul Babbitt maybe I
missed it earlier but I mentioned
technical depth technical debt but I
didn’t catch what that was technical
debt yeah technical debt so when you’re
creating requirements in an agile
environment you’re creating requirements
and you go through a process of
prioritizing those requirements and then
feeding those requirements into into the
development team committees books and
not all those requirements are going to
make it in when you go through that
process you may decide okay this is a
requirement with you ask a meeting this
is a requirement we can do today so
let’s put it in our backlog and so the
requirements that you can get to that
you can’t do it’s jumping it’s the right
time for or for whatever reason maybe
it’s a lower priority those technical
what those requirements are going to go
into the backlog and that backlog can
get very very large over a period of
time and so you have to keep working
that backlog because the idea is that
those are eventually things that you do
want to do and and that backlog may be
customer requirements but it may also be
technical or architectural changes or
improvements on the system that you need
to do at some point as well and those
also go into the backlog and so your
technical debt is essentially all the
things that you want to do that you keep
putting off and it can grow and grow and
grow if it’s not aggressively worked
great thank you all right
anything else
I think I saw a question I was looking I
got some a couple of texts here I was
looking at a question I think there was
a question from yes from John Taylor and
he was asking me about how this applies
and medical devices
you really can’t run and truly hide your
process so you know biomedical is
essentially an embedded system
biomedical is an embedded system and it
is you’ve got two Hardware firmware and
software that develops these devices and
John is mentioning this double-a mmm i
CRI 45 I’m not sure what that is but you
know in many embedded systems and I’m
assuming this is probably some sort of
regulation and requirement that’s unique
to the biomedical field many embedded
systems have unique regulatory
requirements they have to meet or
certain quality requirements they have
to meet based on the industry that
they’re in and that’s what makes it
makes it difficult for those to be agile
but met agility provides a way of doing
that and pretty much any context and
that’s because you’re separating out
your hardware firmware and software in
such a way as to you know many of the
requirements focus around the hardware
or the firmware and so those tracks can
move a little slower in order to meet
those those regulatory requirements but
oftentimes what we try to do is if
there’s a specific regulatory
requirement of something around a
specific industry we can often make an
adaptation to meet that need because
we’ve done so much work with embedded
systems which is what this is focused on
so I’m getting a few texts here
so so Myron McGee was asking is there
more to be found about team development
and the critical buying process in the
book yes I think so I have a chapter of
the book I also have a course based on
the chapter in the book which is called
soft skills to agile transformation or
soft skills to managing agility and it
goes to the process of how to sell the
idea to your executives and your team or
your project managers in your PMO office
and that’s very important and so I do
have a chapter in the book dedicated to
that as well as of course let’s see here
a couple of trying to are there any are
there any other questions okay some what
I’m just looking here was there between
agile scrum and Kanban well I kind of
touched on it a bit earlier but scrum is
basically a set of rituals it’s a set of
rituals that consist of you know a
series of meetings to facilitate the
agile process so it has you have the
stand-up meetings you have your
retrospective meetings you have your
sprints and it’s just a way to organize
your team interaction is essentially
what’s from is and scrum is a way to
implement agile you can have agile
without scrum but very often these days
it almost goes hand-in-hand because it’s
definitely the most popular series of
rituals that companies implement was
from and indeed we found the same thing
with our case studies and Kanban is that
even lower level Kanban is is a way to
manage flow so Kanban consists primarily
of what many people refer to as the
Kanban board and what that does is you
put limits on your work and progress for
each stage of the development process
and by following a set of rules
as requirements flow through this
development process you can get rid of
blockers and essentially in a nutshell
what it does is it increases the the
flow of product out the door you can
actually see where you might have when
you start out with you know a lot of
requirements or development work that
are backed up in one segment of the
development process and as you go
through the Kanban go to the follow the
Kanban rules of facilitating the flow of
that work you can see those those cues
those work-in-progress cues go down and
and so that’s very neat how that works
but I would say that it’s kind of an
even lower level than then scrum it’s a
more granular level I would say all
right see any other questions I’m just
looking through some text here to see if
I making sure I’m not missing anything I
anyone has any more questions they want
to ask through the voice – that’s fine I
don’t see I don’t think I have missed
any other questions any concerns or
again you can you can go through the
website agile – works comm wor X and
I’ve got some some of my publications
out there and some our training courses
are out there and a little bit about
what we do for consulting as well as a
no review of the tools we’ve developed a
Minimum Viable Product for a program
portfolio management tool based on the
Medici leti concept you can take a look
at that – initially we thought that the
software is going to be the most
important but as it turned out many
people are more interested in the
methodology and the training and the
consulting around it and the software
has become tertiary instead of primary
as far as interest goes and so I’ve been
focusing mostly on socializing the
methodology and the book and and our
training courses and consulting around
that and the software solution being
kind of an add-on as if anyone is
interested in going through that process
a lot of times when we develop a
strategy after doing our assessment we
may create a you know customized
software solution for you
any of it I never see any uh any
questions score
I guess Wow I started
I certainly appreciate everyone being on
the call today and listening in and if
you think of questions later you can
email me david at advil – works calm
that’s works with an ex WRX
and feel free to reach out to me I’m on
LinkedIn as well and of course we have a
contact form our website and our full
name your kind of website ooh seven
seven four nine pick 159 four so feel
free to reach out don’t be shocked yeah
so let me hear David I think we’re not
getting any more questions thanks a lot
for taking a pitch webinar on meta
agility I’m quite sure all of us enjoy
the whole talk and there will be a lot
of questions so this is more about how
we implement and how we practically do
things so I expect a lot more coming a
communication on of it also David I
would request you to see if you can
write a blog or I think there is an
article already in the EMR from Tim’s if
you could also give us a blog we would
like to feature it on the website along
with the recording of this webinar so I
would request you to see if you could do
that but I would like to really thank
you for the time and the wonderful
presentation you did and thanks from
James and all of us you also being a
chapter chair you’re part of this
community so thanks a lot for this
wallet again giving us your time well
thank you very much for the opportunity
is always a great to be able to interact
with everyone in this community so I
really appreciate it and I enjoyed it as
well sure Linda what do you if you like
to close the VD
thanks a week and thanks David I really
appreciate your time and thanks to
everyone who joined if you have any
further questions you could reach out to
David directly if not you could send us
an email as well we will try and I help
you with that if there’s nothing else I
think we are good for the day thank you
so much appreciate everyone’s time yeah
thank you thank you thanks everyone
thank you has left anything has left a
meeting Oberon has left a meeting
has left the meeting


About the author

Ravikiran Annaswamy

Add Comment

Click here to post a comment

TEMS – 5 Focus Areas

Moving Product/Services from Idea to Market

Identifying and Implementing Successful Projects, and Systems

Integrating Technology for Capability and Productivity

Developing from Engineer to Leader

Balancing the Norms of Society, Government, and Regulators

Message from IEEE TEMS President

Attend upcoming Conference

TEMSCON Europe 2021


Follow us on Twitter

%d bloggers like this: