[SCRUMDEVELOPMENT] What is agile?

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

My definition and description of agile. Thought some of you might be interested or want to comment.

What is agile?

The domain of Agile is in organizational structures, things like creating cross-functional teams that get things to production in very short cycles. Management gets out of the way and also gets anything else out of the way that impedes the people doing the actual work. This is akin to the world and mindset of lean manufacturing. New roles emerge and old roles and their career paths go away. It’s highly disruptive to adopt.

The critical element is self-managing teams that are free to experiment in a safe space with different ways of working together. Through enlightened trial and error their performance improves. Similarly, the other key idea is that no one actually knows what the product will look like at inception, certainly not in any detail. Customers and development teams collaborate to discover what the product wants to be along the way. Moreover, the world changes while you are doing that and so
 business agility is the ability to turn on a dime for a dime (Larman).

Agile is quite simply a set of principles and values that guide you in conducting small experiments on two levels, discovering what the product is that the customer wants and discovering better ways of working together.

['Alexander Kriegisch' [e-mail] [SCRUMDEVELOPMENT]]

Dear Michael,

I think this is a good explanation of what agile is all about. I am not
sure if it is *the* definition, but you did not claim it was. You merely
said it was *your* definition.

Knowing as much about agile values, principles and practices as many
people in this group, probably every experienced coach or practitioner
could come up with other ways of explaining what agile is and the other
definitions/explanations might be just as valid as yours, accentuating
different nuances. I believe that a good explanation or definition also
depends on the audience because it wants to make a positive impact on
them, considering their previous work experience as well as their
contextual knowledge about agile or lack thereof.

Imagining I was a newbie taking his first agile training class, I think
I would be well guided in thinking through the meaning of your words and
trying to adopt the principles you explained so well. For me this makes
it a good explanation. Consequently I am thanking you.

Kind regards
--
Alexander Kriegisch
https://scrum-master.de

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
My definition and description of agile. Thought some of you might be
interested or want to comment.
What is agile?
The domain of Agile is in organizational structures, things like
creating cross-functional teams that get things to production in very
short cycles. Management gets out of the way and also gets anything
else out of the way that impedes the people doing the actual work.
This is akin to the world and mindset of lean manufacturing. New roles
emerge and old roles and their career paths go away. It’s highly
disruptive to adopt.
The critical element is self-managing teams that are free to
experiment in a safe space with different ways of working together.
Through enlightened trial and error their performance improves.
Similarly, the other key idea is that no one actually knows what the
product will look like at inception, certainly not in any detail.
Customers and development teams collaborate to discover what the
product wants to be along the way. Moreover, the world changes while
you are doing that and so
 business agility is the ability to turn
on a dime for a dime (Larman).
Agile is quite simply a set of principles and values that guide you in
conducting small experiments on two levels, discovering what the
product is that the customer wants and discovering better ways of
working together.

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

And now I am thanking you, Alexander, for your very kind words. Great point about context. This was, indeed, intended for people savvy in business but naive or misguided about agile.

Post by 'Alexander Kriegisch' ***@Scrum-Master.de [SCRUMDEVELOPMENT]
Dear Michael,
I think this is a good explanation of what agile is all about. I am not
sure if it is *the* definition, but you did not claim it was. You merely
said it was *your* definition.
Knowing as much about agile values, principles and practices as many
people in this group, probably every experienced coach or practitioner
could come up with other ways of explaining what agile is and the other
definitions/explanations might be just as valid as yours, accentuating
different nuances. I believe that a good explanation or definition also
depends on the audience because it wants to make a positive impact on
them, considering their previous work experience as well as their
contextual knowledge about agile or lack thereof.
Imagining I was a newbie taking his first agile training class, I think
I would be well guided in thinking through the meaning of your words and
trying to adopt the principles you explained so well. For me this makes
it a good explanation. Consequently I am thanking you.
Kind regards
--
Alexander Kriegisch
https://scrum-master.de

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
My definition and description of agile. Thought some of you might be
interested or want to comment.
What is agile?
The domain of Agile is in organizational structures, things like
creating cross-functional teams that get things to production in very
short cycles. Management gets out of the way and also gets anything
else out of the way that impedes the people doing the actual work.
This is akin to the world and mindset of lean manufacturing. New roles
emerge and old roles and their career paths go away. It’s highly
disruptive to adopt.
The critical element is self-managing teams that are free to
experiment in a safe space with different ways of working together.
Through enlightened trial and error their performance improves.
Similarly, the other key idea is that no one actually knows what the
product will look like at inception, certainly not in any detail.
Customers and development teams collaborate to discover what the
product wants to be along the way. Moreover, the world changes while
you are doing that and so
 business agility is the ability to turn
on a dime for a dime (Larman).
Agile is quite simply a set of principles and values that guide you in
conducting small experiments on two levels, discovering what the
product is that the customer wants and discovering better ways of
working together.

['[e-mail]' [e-mail] [SCRUMDEVELOPMENT]]

I would agree.

Agile Coaching is sharing ideas and mapping out a solution

On Tue, May 1, 2018 at 2:06 AM, Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]<***@yahoogroups.com> wrote: My definition and description of agile. Thought some of you might be interested or want to comment.

What is agile?

The domain of Agile is in organizational structures, things like creating cross-functional teams that get things to production in very short cycles. Management gets out of the way and also gets anything else out of the way that impedes the people doing the actual work. This is akin to the world and mindset of lean manufacturing. New roles emerge and old roles and their career paths go away. It’s highly disruptive to adopt.

The critical element is self-managing teams that are free to experiment in a safe space with different ways of working together. Through enlightened trial and error their performance improves. Similarly, the other key idea is that no one actually knows what the product will look like at inception, certainly not in any detail. Customers and development teams collaborate to discover what the product wants to be along the way. Moreover, the world changes while you are doing that and so
 business agility is the ability to turn on a dime for a dime (Larman).

Agile is quite simply a set of principles and values that guide you in conducting small experiments on two levels, discovering what the product is that the customer wants and discovering better ways of working together.



------------------------------------
Posted by: Michael Wollin <***@mercurysw.com>
------------------------------------

To Post a message, send it to:  ***@eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-***@eGroups.com
------------------------------------

Yahoo Groups Links

['Richard Hundhausen' [e-mail] [SCRUMDEVELOPMENT]]

I recently sat through a class by Craig Larman and it’s interesting that he prefers to use the (original) term adaptive, rather than agile.

He definitely used the “turn on a dime, for a dime” phrase several times.



From: ***@yahoogroups.com <***@yahoogroups.com>
Sent: Tuesday, May 1, 2018 12:07 AM
To: ***@yahoogroups.com
Subject: [SCRUMDEVELOPMENT] What is agile?





My definition and description of agile. Thought some of you might be interested or want to comment.

What is agile?

The domain of Agile is in organizational structures, things like creating cross-functional teams that get things to production in very short cycles. Management gets out of the way and also gets anything else out of the way that impedes the people doing the actual work. This is akin to the world and mindset of lean manufacturing. New roles emerge and old roles and their career paths go away. It’s highly disruptive to adopt.

The critical element is self-managing teams that are free to experiment in a safe space with different ways of working together. Through enlightened trial and error their performance improves. Similarly, the other key idea is that no one actually knows what the product will look like at inception, certainly not in any detail. Customers and development teams collaborate to discover what the product wants to be along the way. Moreover, the world changes while you are doing that and so
 business agility is the ability to turn on a dime for a dime (Larman).

Agile is quite simply a set of principles and values that guide you in conducting small experiments on two levels, discovering what the product is that the customer wants and discovering better ways of working together.

[Markus Gaertner [e-mail] [SCRUMDEVELOPMENT]]

I can second that based upon two trainings I attended with Craig. :)

Best
Markus

Save our Scrum: http://leanpub.com/saveourscrum
--
Dipl.-Inform. Markus Gaertner
Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven
Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de

Post by 'Richard Hundhausen' ***@accentient.com [SCRUMDEVELOPMENT]
I recently sat through a class by Craig Larman and it’s interesting that
he prefers to use the (original) term adaptive, rather than agile.
He definitely used the “turn on a dime, for a dime” phrase several times.
*Sent:* Tuesday, May 1, 2018 12:07 AM
*Subject:* [SCRUMDEVELOPMENT] What is agile?
My definition and description of agile. Thought some of you might be
interested or want to comment.
What is agile?
The domain of Agile is in organizational structures, things like creating
cross-functional teams that get things to production in very short cycles..
Management gets out of the way and also gets anything else out of the way
that impedes the people doing the actual work. This is akin to the world
and mindset of lean manufacturing. New roles emerge and old roles and their
career paths go away. It’s highly disruptive to adopt.
The critical element is self-managing teams that are free to experiment in
a safe space with different ways of working together. Through enlightened
trial and error their performance improves. Similarly, the other key idea
is that no one actually knows what the product will look like at inception,
certainly not in any detail. Customers and development teams collaborate to
discover what the product wants to be along the way. Moreover, the world
changes while you are doing that and so
 business agility is the ability to
turn on a dime for a dime (Larman).
Agile is quite simply a set of principles and values that guide you in
conducting small experiments on two levels, discovering what the product is
that the customer wants and discovering better ways of working together.

[[e-mail] [SCRUMDEVELOPMENT]]

Great question, Michael. What is agile? Where does it come from? Since the discussions at Rational OTUG mailing list back in 1997, I try to keep open questions like those. What is object orientation? What are patterns?, and so on...


The talk by James Coplien last year at GOTO 2017 helps to think harder on that kind of questions:


Polymorphism is GOTO on steroids
https://blogs.wandisco.com/polymorphism-is-goto-on-steroids/ https://blogs.wandisco.com/polymorphism-is-goto-on-steroids/

[[e-mail] [SCRUMDEVELOPMENT]]

For the record, let me please share a direct link to James Coplien's talk:


GOTO 2017 • The Dehumanisation of Agile and Objects • James Coplien

http://youtu.be/ZrBQmIDdls4

[[e-mail] [SCRUMDEVELOPMENT]]

I'm struggling to see value in this definition beyond the content contained in the two pages on Agile Manifesto website. I had to go back and look at it, which I recommend that everyone do from time to time, and it really does seem complete and clear even after all of these years.

Items that aren't included on the Manifesto site, like "creating cross-functional teams", aren't really part of Agile, IMHO. This one in particular seems like a bit of a pipe dream, really. People aren't fungible resources and shouldn't be organized like they are. And, surely the principle that, "The best architectures, requirements, and designs emerge from self-organizing teams.", would win out if the team decided that it wanted to work in a very siloed manner?

I'm not trying to be hyper-critical, but one of the big issues we have in the Agile/Scrum world seems be competing definitions about fundamental concepts. Here we have 4 main clauses in the Manifesto, and 12 underlying principles. It's short, simple and the implications are fairly obvious.

If there was one explanatory item that I'd ever feel was needed it would be this: Users never really fully engage in the software design process until you give them working software to interact with. Requirements, white-board diagrams, meetings, demos, mock-ups, prototypes or any other aid you can try will not elicit the input that you need from the customer to build the right software. The only defense against this is write a minimal amount of working software and get it into the customers hands as soon as possible, then listen to what they say.

It's clear to me that the authors of the manifesto completely understood this. The first 4 principles are all about making that happen.

dave

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

Fair enough, Dave. This was not to replace the Manifesto or for training in any way. This was to explain to professional friends what we are doing, in simple business terms. It’s my distillation. As a distillation, it’s a lossy compression algorithm. But I thought it communicated the nature of the domain in a way that many professionals I know can easily grasp. I’m not sure, though, that I agree with you that the implications of the Manifesto are obvious. If that were true, the glaring delta between the manifesto and what most companies are really doing wrote be a whole lot more apparent to them. IMO. I like the phrasing you have of “working software to interact with,” and I may incorporate that. It is still people collaborating to discover what the product wants to be.

Post by ***@lawpro.ca [SCRUMDEVELOPMENT]
I'm struggling to see value in this definition beyond the content contained in the two pages on Agile Manifesto website. I had to go back and look at it, which I recommend that everyone do from time to time, and it really does seem complete and clear even after all of these years.
Items that aren't included on the Manifesto site, like "creating cross-functional teams", aren't really part of Agile, IMHO. This one in particular seems like a bit of a pipe dream, really. People aren't fungible resources and shouldn't be organized like they are. And, surely the principle that, "The best architectures, requirements, and designs emerge from self-organizing teams.", would win out if the team decided that it wanted to work in a very siloed manner?
I'm not trying to be hyper-critical, but one of the big issues we have in the Agile/Scrum world seems be competing definitions about fundamental concepts. Here we have 4 main clauses in the Manifesto, and 12 underlying principles. It's short, simple and the implications are fairly obvious.
If there was one explanatory item that I'd ever feel was needed it would be this: Users never really fully engage in the software design process until you give them working software to interact with. Requirements, white-board diagrams, meetings, demos, mock-ups, prototypes or any other aid you can try will not elicit the input that you need from the customer to build the right software. The only defense against this is write a minimal amount of working software and get it into the customers hands as soon as possible, then listen to what they say.
It's clear to me that the authors of the manifesto completely understood this. The first 4 principles are all about making that happen.
dave
\

[[e-mail] [SCRUMDEVELOPMENT]]

Hi everyone,


Firstly, I have to say that we see a lot of trivialisation regarding this matter. It seems like everything that is good fall into the "Agile-box" and what is not good in the "traditional-waterfall-box". At least here in Brazil.


When we ask people what Agile is, we usually get answers around "adaptative", "easy to change", "small feedback loops", "fit to purpose", "collaboration", "understand the customer" and some others more passionate ones. But all of these properties was already there before Agile was born.


So, I was wondering how a scientist would measure whether Agile is been effective. How to set the boundaries and not fall into ambiguity or in particular perceptions.


Then I sketched out a particular understanding about what Agile is, and what makes Agile unique, for me, is the sum of those properties, that is represented on the manifesto. So, Agile would be to seek the Agile manifesto values and principles. And that could be measure against actions toward this goal. What bring us to consider that might also exist levels of intensity using and seeking Agile.


If Agile is to adapt to customers, we already had that before. If it is to deliver value or respond to change, also. But if the context is seeking actively to address all the 4 values of the manifesto, using particular practices and techniques, that is a different approach that we can call Agile.


I recognize, though, that is easier to say that someone or some company is doing Agile, even if they don't follow what I said before. And I have no problems with that. The Agile movement spread some good practices and made them popular and took the credit. That is apparently doing good to the practicioners.


***


Another concern that arises from this rational is whether any context could be Agile. And the way I see, it couldn't. Applying Agile to some deterministic nature works might result in waste. The contexts that benefits from experimentation, that ones, would be eligible to be and use Agile.


Bests,
Rafael Buzon






---In ***@yahoogroups.com, <***@...> wrote :

Fair enough, Dave. This was not to replace the Manifesto or for training in any way. This was to explain to professional friends what we are doing, in simple business terms. It’s my distillation. As a distillation, it’s a lossy compression algorithm. But I thought it communicated the nature of the domain in a way that many professionals I know can easily grasp. I’m not sure, though, that I agree with you that the implications of the Manifesto are obvious. If that were true, the glaring delta between the manifesto and what most companies are really doing wrote be a whole lot more apparent to them. IMO. I like the phrasing you have of “working software to interact with,” and I may incorporate that. It is still people collaborating to discover what the product wants to be.

On May 2, 2018, at 9:15 AM, ***@... mailto:***@... [SCRUMDEVELOPMENT] <***@yahoogroups.com mailto:***@yahoogroups.com> wrote:

I'm struggling to see value in this definition beyond the content contained in the two pages on Agile Manifesto website. I had to go back and look at it, which I recommend that everyone do from time to time, and it really does seem complete and clear even after all of these years.





Items that aren't included on the Manifesto site, like "creating cross-functional teams", aren't really part of Agile, IMHO. This one in particular seems like a bit of a pipe dream, really. People aren't fungible resources and shouldn't be organized like they are. And, surely the principle that, "The best architectures, requirements, and designs emerge from self-organizing teams.", would win out if the team decided that it wanted to work in a very siloed manner?






I'm not trying to be hyper-critical, but one of the big issues we have in the Agile/Scrum world seems be competing definitions about fundamental concepts. Here we have 4 main clauses in the Manifesto, and 12 underlying principles. It's short, simple and the implications are fairly obvious.

If there was one explanatory item that I'd ever feel was needed it would be this: Users never really fully engage in the software design process until you give them working software to interact with. Requirements, white-board diagrams, meetings, demos, mock-ups, prototypes or any other aid you can try will not elicit the input that you need from the customer to build the right software. The only defense against this is write a minimal amount of working software and get it into the customers hands as soon as possible, then listen to what they say.

It's clear to me that the authors of the manifesto completely understood this. The first 4 principles are all about making that happen.

dave

\

['Alexander Kriegisch' [e-mail] [SCRUMDEVELOPMENT]]

Hi Rafael.

I am actually tired of hearing or reading this "oh, all that agile stuff
was there before Agile". Yes, it was there, but

a) nobody did it consequently in the combination that comprises Agile
(not even the practices, not to mention principles and values
underneath) and

b) it is still not done by many organisations today which claim to be
agile.

Oh, and BTW: You cannot "do Agile", only be agile.

Disclaimer: I do understand that you embrace the Agile Manifesto in its
full beauty, so this is not to say that I think you don't "get it". I am
just saying I am tired of this line of rationale. ;-)

Kind regards
--
Alexander Kriegisch
https://scrum-master.de

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi everyone,
Firstly, I have to say that we see a lot of trivialisation regarding this
matter. It seems like everything that is good fall into the "Agile-box"
and what is not good in the "traditional-waterfall-box". At least here in
Brazil.
When we ask people what Agile is, we usually get answers around
"adaptative", "easy to change", "small feedback loops", "fit to purpose",
"collaboration", "understand the customer" and some others more passionate
ones. But all of these properties was already there before Agile was born.
So, I was wondering how a scientist would measure whether Agile is been
effective. How to set the boundaries and not fall into ambiguity or in
particular perceptions.
Then I sketched out a particular understanding about what Agile is, and
what makes Agile unique, for me, is the sum of those properties, that is
represented on the manifesto. So, Agile would be to seek the Agile
manifesto values and principles. And that could be measure against actions
toward this goal. What bring us to consider that might also exist levels
of intensity using and seeking Agile.
If Agile is to adapt to customers, we already had that before. If it is to
deliver value or respond to change, also. But if the context is seeking
actively to address all the 4 values of the manifesto, using particular
practices and techniques, that is a different approach that we can call
Agile.
I recognize, though, that is easier to say that someone or some company is
doing Agile, even if they don't follow what I said before. And I have no
problems with that. The Agile movement spread some good practices and made
them popular and took the credit. That is apparently doing good to the
practicioners.
***
Another concern that arises from this rational is whether any context
could be Agile. And the way I see, it couldn't. Applying Agile to some
deterministic nature works might result in waste. The contexts that
benefits from experimentation, that ones, would be eligible to be and use
Agile.
Bests,
Rafael Buzon
Fair enough, Dave. This was not to replace the Manifesto or for training
in any way. This was to explain to professional friends what we are doing,
in simple business terms. It’s my distillation. As a distillation, it’s a
lossy compression algorithm. But I thought it communicated the nature of
the domain in a way that many professionals I know can easily grasp. I’m
not sure, though, that I agree with you that the implications of the
Manifesto are obvious. If that were true, the glaring delta between the
manifesto and what most companies are really doing wrote be a whole lot
more apparent to them. IMO. I like the phrasing you have of “working
software to interact with,” and I may incorporate that. It is still people
collaborating to discover what the product wants to be.

Post by ***@lawpro.ca [SCRUMDEVELOPMENT]
I'm struggling to see value in this definition beyond the content
contained in the two pages on Agile Manifesto website. I had to go back
and look at it, which I recommend that everyone do from time to time,
and it really does seem complete and clear even after all of these
years.
Items that aren't included on the Manifesto site, like "creating
cross-functional teams", aren't really part of Agile, IMHO. This one in
particular seems like a bit of a pipe dream, really. People aren't
fungible resources and shouldn't be organized like they are. And, surely
the principle that, "The best architectures, requirements, and designs
emerge from self-organizing teams.", would win out if the team decided
that it wanted to work in a very siloed manner?
I'm not trying to be hyper-critical, but one of the big issues we have
in the Agile/Scrum world seems be competing definitions about
fundamental concepts. Here we have 4 main clauses in the Manifesto, and
12 underlying principles. It's short, simple and the implications are
fairly obvious.
If there was one explanatory item that I'd ever feel was needed it would
be this: Users never really fully engage in the software design process
until you give them working software to interact with. Requirements,
white-board diagrams, meetings, demos, mock-ups, prototypes or any other
aid you can try will not elicit the input that you need from the
customer to build the right software. The only defense against this is
write a minimal amount of working software and get it into the customers
hands as soon as possible, then listen to what they say.
It's clear to me that the authors of the manifesto completely understood
this. The first 4 principles are all about making that happen.
dave
\