|
On 02/21/2020 01:37:01 PM, Steve Gordon wrote: Almost all the development metrics that are useful can be mined from
the
repository as long as the developers have the discipline to tag
checkins
with the applicable story (or bug).
(I'm not making a statement about Steve's post here; rather, it inspired a different question) This is related to something I've been slowly coming to believe over the years. One of the widespread misconceptions about XP (and, to a somewhat lesser extent about Agile in general) is that it's a rejection of discipline in favor of simply letting developers do as they please. I view it as substituting self-discipline for externally imposed discipline; this is the meaning to me (or at least one of the meanings) of the phrase "People over process". The notion that discipline _must_ be externally imposed, or it won't exist at all, is built into the mindset of the various MBA/PMP curricula, and into that of many businesses. I suspect this misconception is responsible for the widespread popularity of Scrum and the prevalence of Fake Agile over the real thing. Scrum gives folks with that mindset something which they can latch onto as an externally imposed process, while simultaneously "being agile", at least in name. Thoughts? -John -- John Maxwell KB3VLL jmax@...
|
Under Agile, the team owns their work process instead of the organization or process police.? That means the team has no excuse not to comply with their own process, no excuse not to change that process if it is not working for them, and no excuse for blaming the process for their problems.
On Fri, Feb 21, 2020 at 12:00 PM John Maxwell < jmax@...> wrote: On 02/21/2020 01:37:01 PM, Steve Gordon wrote:
> Almost all the development metrics that are useful can be mined from
> the
> repository as long as the developers have the discipline to tag
> checkins
> with the applicable story (or bug).
>
(I'm not making a statement about Steve's post here; rather, it inspired
a different question)
This is related to something I've been slowly coming to believe over the
years.
One of the widespread misconceptions about XP (and, to a somewhat
lesser extent about Agile in general) is that it's a rejection of
discipline in favor of simply letting developers do as they please.
I view it as substituting self-discipline for externally imposed
discipline; this is the meaning to me (or at least one of the meanings)
of the phrase "People over process".
The notion that discipline _must_ be externally imposed, or it won't
exist at all, is built into the mindset of the various MBA/PMP
curricula, and into that of many businesses.
I suspect this misconception is responsible for the widespread
popularity of Scrum and the prevalence of Fake Agile over the real
thing. Scrum gives folks with that mindset something which they can
latch onto as an externally imposed process, while simultaneously "being
agile", at least in name.
Thoughts?
-John
--
John Maxwell? KB3VLL? jmax@...
|
Interesting! I usually heard it described as ceremony vs discipline!
I always regarded XP (and especially TDD] as *extremely* HIGH discipline. It's not that its somehow low-process (or low discipline) as much as it is low *ceremony* (or even low formality).
Because in the end ... * documentation is not the same as understanding * discipline?is not the same as formality/ceremony * process?is not the same as practice "And miles to go before I sleep" --Robert Frost
On Fri, Feb 21, 2020 at 1:00 PM John Maxwell < jmax@...> wrote: On 02/21/2020 01:37:01 PM, Steve Gordon wrote:
> Almost all the development metrics that are useful can be mined from
> the
> repository as long as the developers have the discipline to tag
> checkins
> with the applicable story (or bug).
>
(I'm not making a statement about Steve's post here; rather, it inspired
a different question)
This is related to something I've been slowly coming to believe over the
years.
One of the widespread misconceptions about XP (and, to a somewhat
lesser extent about Agile in general) is that it's a rejection of
discipline in favor of simply letting developers do as they please.
I view it as substituting self-discipline for externally imposed
discipline; this is the meaning to me (or at least one of the meanings)
of the phrase "People over process".
The notion that discipline _must_ be externally imposed, or it won't
exist at all, is built into the mindset of the various MBA/PMP
curricula, and into that of many businesses.
I suspect this misconception is responsible for the widespread
popularity of Scrum and the prevalence of Fake Agile over the real
thing. Scrum gives folks with that mindset something which they can
latch onto as an externally imposed process, while simultaneously "being
agile", at least in name.
Thoughts?
-John
--
John Maxwell? KB3VLL? jmax@...
|
Yes, I agree. There was a book title a while back that set my teeth on edge: Balancing Agility and Discipline.
Agile, and particularly XP, is a high-discipline process! Anybody who thinks otherwise hasn’t done it. That’s one of the values of pairing/mobbing, in my mind: it helps people maintain their discipline even when individuals aren’t at their best.
Brian Marick had a great talk quite a while ago about the four missing values of the Agile manifesto: Joy, Ease, Discipline, and Skill. I think he was right on.
toggle quoted message
Show quoted text
On Feb 21, 2020, at 11:01 AM, John Maxwell < jmax@...> wrote:
On 02/21/2020 01:37:01 PM, Steve Gordon wrote: Almost all the development metrics that are useful can be mined from
the
repository as long as the developers have the discipline to tag
checkins
with the applicable story (or bug).
(I'm not making a statement about Steve's post here; rather, it inspired a different question) This is related to something I've been slowly coming to believe over the years. One of the widespread misconceptions about XP (and, to a somewhat lesser extent about Agile in general) is that it's a rejection of discipline in favor of simply letting developers do as they please. I view it as substituting self-discipline for externally imposed discipline; this is the meaning to me (or at least one of the meanings) of the phrase "People over process". The notion that discipline _must_ be externally imposed, or it won't exist at all, is built into the mindset of the various MBA/PMP curricula, and into that of many businesses. I suspect this misconception is responsible for the widespread popularity of Scrum and the prevalence of Fake Agile over the real thing. Scrum gives folks with that mindset something which they can latch onto as an externally imposed process, while simultaneously "being agile", at least in name. Thoughts? -John -- John Maxwell ?KB3VLL ? jmax@...
|
The difference is whether the discipline is with respect to a set of practices defined by the team itself or defined from outside the team.?
On Fri, Feb 21, 2020 at 12:10 PM Jim Shore < jshore@...> wrote: Yes, I agree. There was a book title a while back that set my teeth on edge: Balancing Agility and Discipline.
Agile, and particularly XP, is a high-discipline process! Anybody who thinks otherwise hasn’t done it. That’s one of the values of pairing/mobbing, in my mind: it helps people maintain their discipline even when individuals aren’t at their best.
Brian Marick had a great talk quite a while ago about the four missing values of the Agile manifesto: Joy, Ease, Discipline, and Skill. I think he was right on.
James On Feb 21, 2020, at 11:01 AM, John Maxwell < jmax@...> wrote:
On 02/21/2020 01:37:01 PM, Steve Gordon wrote: Almost all the development metrics that are useful can be mined from
the
repository as long as the developers have the discipline to tag
checkins
with the applicable story (or bug).
(I'm not making a statement about Steve's post here; rather, it inspired a different question) This is related to something I've been slowly coming to believe over the years. One of the widespread misconceptions about XP (and, to a somewhat lesser extent about Agile in general) is that it's a rejection of discipline in favor of simply letting developers do as they please. I view it as substituting self-discipline for externally imposed discipline; this is the meaning to me (or at least one of the meanings) of the phrase "People over process". The notion that discipline _must_ be externally imposed, or it won't exist at all, is built into the mindset of the various MBA/PMP curricula, and into that of many businesses. I suspect this misconception is responsible for the widespread popularity of Scrum and the prevalence of Fake Agile over the real thing. Scrum gives folks with that mindset something which they can latch onto as an externally imposed process, while simultaneously "being agile", at least in name. Thoughts? -John -- John Maxwell ?KB3VLL ? jmax@...
|
I found the quote (I had the last part of it wrong). Seems to be from Jim Highsmith back in 2001
"In the past, we have equated discipline with formality, and we've got to unlink those ...? ?- Documentation is not understanding;? ?- formality is not discipline;? ?- process is not skill."
sources: ?--?? ?--??
"And miles to go before I sleep" --Robert Frost
On Fri, Feb 21, 2020 at 1:10 PM Jim Shore < jshore@...> wrote: Yes, I agree. There was a book title a while back that set my teeth on edge: Balancing Agility and Discipline.
Agile, and particularly XP, is a high-discipline process! Anybody who thinks otherwise hasn’t done it. That’s one of the values of pairing/mobbing, in my mind: it helps people maintain their discipline even when individuals aren’t at their best.
Brian Marick had a great talk quite a while ago about the four missing values of the Agile manifesto: Joy, Ease, Discipline, and Skill. I think he was right on.
James On Feb 21, 2020, at 11:01 AM, John Maxwell < jmax@...> wrote:
On 02/21/2020 01:37:01 PM, Steve Gordon wrote: Almost all the development metrics that are useful can be mined from
the
repository as long as the developers have the discipline to tag
checkins
with the applicable story (or bug).
(I'm not making a statement about Steve's post here; rather, it inspired a different question) This is related to something I've been slowly coming to believe over the years. One of the widespread misconceptions about XP (and, to a somewhat lesser extent about Agile in general) is that it's a rejection of discipline in favor of simply letting developers do as they please. I view it as substituting self-discipline for externally imposed discipline; this is the meaning to me (or at least one of the meanings) of the phrase "People over process". The notion that discipline _must_ be externally imposed, or it won't exist at all, is built into the mindset of the various MBA/PMP curricula, and into that of many businesses. I suspect this misconception is responsible for the widespread popularity of Scrum and the prevalence of Fake Agile over the real thing. Scrum gives folks with that mindset something which they can latch onto as an externally imposed process, while simultaneously "being agile", at least in name. Thoughts? -John -- John Maxwell ?KB3VLL ? jmax@...
|
On 02/21/2020 02:13:36 PM, Steve Gordon wrote: The difference is whether the discipline is with respect to a set of
practices defined by the team itself or defined from outside the team.
This is true, but is tangential to the point I'm trying to discuss. What I'm trying to explore is whether the widespread (among organizations in general, not the Agile community) belief that there is no discipline unless it is externally imposed by managers is a key factor in the prevalence of Fake Agile. If my hypothesis is true, does that give us any leverage to drive towards true Agile? Possibly getting managers to understand that self-discipline is better than externally imposed discipline is a key to this? -John -- John Maxwell KB3VLL jmax@...
|
It is simply getting managers to understand that the team owning the process to be disciplined about is better than telling the team what process to be disciplined about.? The manager can certainly communicate the goals and expected outcomes of the team's process, but should not the specify the details of how the team works.? When a problem occurs and root caused to be a process problem, then the team is responsible for fixing their process.
On Fri, Feb 21, 2020 at 12:24 PM John Maxwell < jmax@...> wrote: On 02/21/2020 02:13:36 PM, Steve Gordon wrote:
> The difference is whether the discipline is with respect to a set of
> practices defined by the team itself or defined from outside the team.
>
This is true, but is tangential to the point I'm trying to discuss.
What I'm trying to explore is whether the widespread (among
organizations in general, not the Agile community) belief that there is
no discipline unless it is externally imposed by managers is a key
factor in the prevalence of Fake Agile.
If my hypothesis is true, does that give us any leverage to drive
towards true Agile? Possibly getting managers to understand that
self-discipline is better than externally imposed discipline is a key to
this?
-John
--
John Maxwell? KB3VLL? jmax@...
|
On 02/21/2020 02:30:12 PM, Steve Gordon wrote: It is simply getting managers to understand that the team owning the
process to be disciplined about is better than telling the team what
process to be disciplined about. The manager can certainly
communicate the
goals and expected outcomes of the team's process, but should not the
specify the details of how the team works. When a problem occurs and
root
caused to be a process problem, then the team is responsible for
fixing
their process.
OK, I'm going to give in to annoyance here. The fact that so many workplaces think they're "doing Agile" when in fact they're ruthlessly squashing any move in that direction is a major source of frustration to me, and I'm trying to discuss one potential leverage point for enlightening folks. You are correct in everything you write, but you are also not addressing the topic I'm trying to talk about. There's a reason that I changed the subject line and explicitly stated that I wasn't commenting on your post. By all means, change the subject and talk about whatever you want to, or stick with your original subject and continue your discussion. But please stop trying to explain basic Agile to me. I've been here and doing this longer than you have. I'm not trying to get a primer on how to "do Agile". I'm trying to discuss how to move whatever organization I'm part of at any time towards being Agile, and away from Fake Agile. One of the old XP aphorisms was "Change your workplace. Or change your workplace." I'm trying to discuss how to do the first. </flame off> -John -- John Maxwell KB3VLL jmax@...
|
I think we very often run into a lack of trust and respect between different roles. Some people might call it a lack of empathy. I think the way most organisations are set up, in terms of silos, responsibilities and accountability, is almost certain to result in that lack of empathy.? An on-site customer is not just good for high-bandwidth communication about requirements. They become part of the team, and the empathy that generates does perhaps more in managing scope than anything else.
My early efforts in agile I always tried to first become a dependable partner: the development team that was clear about what they could (and couldn't) do, would deliver to their obvious best abilities. All to build that trust. Nowadays, I'm more often in a position to work on multiple sides of that trust and respect.?
Some organisations benefit?a lot from more clarity about process: people are often mad that their counterparts in the other department isn't doing the work. In both directions. Sometimes pulling them into a cooperating setting is possible and works, other times some clarity can give us the time to breed some trust.
Wouter
On Fri, Feb 21, 2020 at 8:24 PM John Maxwell < jmax@...> wrote: On 02/21/2020 02:13:36 PM, Steve Gordon wrote:
> The difference is whether the discipline is with respect to a set of
> practices defined by the team itself or defined from outside the team.
>
This is true, but is tangential to the point I'm trying to discuss.
What I'm trying to explore is whether the widespread (among
organizations in general, not the Agile community) belief that there is
no discipline unless it is externally imposed by managers is a key
factor in the prevalence of Fake Agile.
If my hypothesis is true, does that give us any leverage to drive
towards true Agile? Possibly getting managers to understand that
self-discipline is better than externally imposed discipline is a key to
this?
-John
--
John Maxwell? KB3VLL? jmax@...
|
On 02/21/2020 02:44:17 PM, Wouter Lagerweij wrote: An on-site customer is not just good for high-bandwidth communication
about
requirements. They become part of the team, and the empathy that
generates
does perhaps more in managing scope than anything else.
Good point; the times when I have been able to move my organization towards more agility, this has been a key. I recall one occasion when, after considerable begging, I got our customer (in the business sense, not the Agile/XP meaning) to come and sit with the team for a day's work. He viewed it as auditing us. At the end of the day, he commented that this was the most disciplined software team he'd ever encountered, and that he was much more comfortable about our ability to meet our commitments. This wasn't actually a case of moving my organization; I had the good fortune of working on a team that had embraced XP; the issue was building trust with the folks who were paying my company to develop software for them, but I can see it applying more broadly. -John -- John Maxwell KB3VLL jmax@...
|
John,
I AM talking about changing your workplace.? Evidently, making the change to have your teams own their own work process and agree on their own discipline within their own process is NOT an appropriate change for some reason.? If you have not built enough trust to ask for that change, then maybe you are really asking for how to build even more trust while still being a slave to somebody else's work process.
Also, I object to "I've been here and doing this longer than you have.". It might not be true, but even if it were, it is inappropriate and irrelevant.??
On Fri, Feb 21, 2020 at 12:44 PM Wouter Lagerweij < wouter@...> wrote: I think we very often run into a lack of trust and respect between different roles. Some people might call it a lack of empathy. I think the way most organisations are set up, in terms of silos, responsibilities and accountability, is almost certain to result in that lack of empathy.? An on-site customer is not just good for high-bandwidth communication about requirements. They become part of the team, and the empathy that generates does perhaps more in managing scope than anything else.
My early efforts in agile I always tried to first become a dependable partner: the development team that was clear about what they could (and couldn't) do, would deliver to their obvious best abilities. All to build that trust. Nowadays, I'm more often in a position to work on multiple sides of that trust and respect.?
Some organisations benefit?a lot from more clarity about process: people are often mad that their counterparts in the other department isn't doing the work. In both directions. Sometimes pulling them into a cooperating setting is possible and works, other times some clarity can give us the time to breed some trust.
Wouter
On Fri, Feb 21, 2020 at 8:24 PM John Maxwell < jmax@...> wrote: On 02/21/2020 02:13:36 PM, Steve Gordon wrote:
> The difference is whether the discipline is with respect to a set of
> practices defined by the team itself or defined from outside the team.
>
This is true, but is tangential to the point I'm trying to discuss.
What I'm trying to explore is whether the widespread (among
organizations in general, not the Agile community) belief that there is
no discipline unless it is externally imposed by managers is a key
factor in the prevalence of Fake Agile.
If my hypothesis is true, does that give us any leverage to drive
towards true Agile? Possibly getting managers to understand that
self-discipline is better than externally imposed discipline is a key to
this?
-John
--
John Maxwell? KB3VLL? jmax@...
--
|
How does this organization manage its accountants, janitors, shippers, lawyers, etc.? Does it only manage their outcomes or micro-manage how the way they do their work complies with some defined process?
On Fri, Feb 21, 2020 at 1:05 PM Steve Gordon via Groups.Io <sgordonphd= [email protected]> wrote: John,
I AM talking about changing your workplace.? Evidently, making the change to have your teams own their own work process and agree on their own discipline within their own process is NOT an appropriate change for some reason.? If you have not built enough trust to ask for that change, then maybe you are really asking for how to build even more trust while still being a slave to somebody else's work process.
Also, I object to "I've been here and doing this longer than you have.". It might not be true, but even if it were, it is inappropriate and irrelevant.??
On Fri, Feb 21, 2020 at 12:44 PM Wouter Lagerweij < wouter@...> wrote: I think we very often run into a lack of trust and respect between different roles. Some people might call it a lack of empathy. I think the way most organisations are set up, in terms of silos, responsibilities and accountability, is almost certain to result in that lack of empathy.? An on-site customer is not just good for high-bandwidth communication about requirements. They become part of the team, and the empathy that generates does perhaps more in managing scope than anything else.
My early efforts in agile I always tried to first become a dependable partner: the development team that was clear about what they could (and couldn't) do, would deliver to their obvious best abilities. All to build that trust. Nowadays, I'm more often in a position to work on multiple sides of that trust and respect.?
Some organisations benefit?a lot from more clarity about process: people are often mad that their counterparts in the other department isn't doing the work. In both directions. Sometimes pulling them into a cooperating setting is possible and works, other times some clarity can give us the time to breed some trust.
Wouter
On Fri, Feb 21, 2020 at 8:24 PM John Maxwell < jmax@...> wrote: On 02/21/2020 02:13:36 PM, Steve Gordon wrote:
> The difference is whether the discipline is with respect to a set of
> practices defined by the team itself or defined from outside the team.
>
This is true, but is tangential to the point I'm trying to discuss.
What I'm trying to explore is whether the widespread (among
organizations in general, not the Agile community) belief that there is
no discipline unless it is externally imposed by managers is a key
factor in the prevalence of Fake Agile.
If my hypothesis is true, does that give us any leverage to drive
towards true Agile? Possibly getting managers to understand that
self-discipline is better than externally imposed discipline is a key to
this?
-John
--
John Maxwell? KB3VLL? jmax@...
--
|
On 02/21/2020 03:05:16 PM, Steve Gordon wrote: [snippets rearranged to put the most important thing first] Also, I object to "I've been here and doing this longer than you
have.". It
might not be true, but even if it were, it is inappropriate and
irrelevant.
Fair. I apologize. I'm trying to learn to hold my temper better, but it's a struggle. I AM talking about changing your workplace. Evidently, making the
change
to have your teams own their own work process and agree on their own
discipline within their own process is NOT an appropriate change for
some
reason. If you have not built enough trust to ask for that change,
then
maybe you are really asking for how to build even more trust while
still
being a slave to somebody else's work process. Good point; "build more trust" is an excellent way to get there. Are there others folks have had success with? (By way of explanation for my annoyance - *not* justification: When I read your initial response - paraphrased as "The team should own the process", I saw it as extremely condescending. Still working on "just because I read it that way doesn't mean that's how the author intended it.) -John -- John Maxwell KB3VLL jmax@...
|
On 02/21/2020 03:41:24 PM, Steve Gordon wrote: How does this organization manage its accountants, janitors, shippers,
lawyers, etc. Does it only manage their outcomes or micro-manage how
the
way they do their work complies with some defined process?
Mmm. So maybe that's a useful way to approach them issue, you're saying? To clarify: I'm not talking about any particular organization. I'm talking about a pattern I've seen repeatedly in multiple organizations, where my attempts to advocate for more agility have been met by "That's not the right way to manage a team." -John -- John Maxwell KB3VLL jmax@...
|
John, On 2/21/20 2:25 PM, John Maxwell wrote: On 02/21/2020 02:13:36 PM, Steve Gordon wrote:
The difference is whether the discipline is with respect to a set of
practices defined by the team itself or defined from outside the team.
This is true, but is tangential to the point I'm trying to discuss.
What I'm trying to explore is whether the widespread (among
organizations in general, not the Agile community) belief that there is
no discipline unless it is externally imposed by managers is a key
factor in the prevalence of Fake Agile. That's an interesting hypothesis, and I think there's much value in that. What many people call "a manager's job" I would classify as "a foreman's job." Pushing people who do the work is not management, to my mind. But it is to many people. There's a book that traces that sort of management back to the control of slaves. I haven't read it, but that's a believable notion. If my hypothesis is true, does that give us any leverage to drive
towards true Agile? Possibly getting managers to understand that
self-discipline is better than externally imposed discipline is a key to
this? Possibly, but it's still tough. When managers think that they are the brains and the developers are the brawn, it's very hard to shift that (or any) viewpoint, in my experience. - George -- ---------------------------------------------------------------------- * George Dinwiddie * Software Development Consultant and Coach ----------------------------------------------------------------------
|
One of the widespread misconceptions about XP (and, to a somewhat
lesser extent about Agile in general) is that it's a rejection of
discipline in favor of simply letting developers do as they please.
Sounds like a misconception form someone that never experienced XP/TDD.
Thoughts?
-John
--
John Maxwell KB3VLL jmax@...
|
For most positions in the company, process is defined by either law or the company. After the process is defined them they measure on outcome, and if the outcome fails, they double check that the process was followed.
I think agile vs fake agile is really a problem with education and resources. Not every software company has profit margins which allows them to hire the best or even just self disciplined workers. And not every company or worker has the knowledge/experience to know the difference between real and fake agile.
The journey to improve is an important step to get there, it can't really be skipped over.? Until these things are taught in society and school I think it's inevitable that they get learned on the job, company by company.
A few of my friends work in construction and they are always concerned about the number of workers who don't take pride in their work, and how they can't find enough people who do.
How does this organization manage its accountants, janitors, shippers, lawyers, etc.? Does it only manage their outcomes or micro-manage how the way they do their work complies with some defined process?
On Fri, Feb 21, 2020 at 1:05 PM Steve Gordon via Groups.Io <sgordonphd= [email protected]> wrote: John,
I AM talking about changing your workplace.? Evidently, making the change to have your teams own their own work process and agree on their own discipline within their own process is NOT an appropriate change for some reason.? If you have not built enough trust to ask for that change, then maybe you are really asking for how to build even more trust while still being a slave to somebody else's work process.
Also, I object to "I've been here and doing this longer than you have.". It might not be true, but even if it were, it is inappropriate and irrelevant.??
On Fri, Feb 21, 2020 at 12:44 PM Wouter Lagerweij < wouter@...> wrote: I think we very often run into a lack of trust and respect between different roles. Some people might call it a lack of empathy. I think the way most organisations are set up, in terms of silos, responsibilities and accountability, is almost certain to result in that lack of empathy.? An on-site customer is not just good for high-bandwidth communication about requirements. They become part of the team, and the empathy that generates does perhaps more in managing scope than anything else.
My early efforts in agile I always tried to first become a dependable partner: the development team that was clear about what they could (and couldn't) do, would deliver to their obvious best abilities. All to build that trust. Nowadays, I'm more often in a position to work on multiple sides of that trust and respect.?
Some organisations benefit?a lot from more clarity about process: people are often mad that their counterparts in the other department isn't doing the work. In both directions. Sometimes pulling them into a cooperating setting is possible and works, other times some clarity can give us the time to breed some trust.
Wouter
On Fri, Feb 21, 2020 at 8:24 PM John Maxwell < jmax@...> wrote: On 02/21/2020 02:13:36 PM, Steve Gordon wrote:
> The difference is whether the discipline is with respect to a set of
> practices defined by the team itself or defined from outside the team.
>
This is true, but is tangential to the point I'm trying to discuss.
What I'm trying to explore is whether the widespread (among
organizations in general, not the Agile community) belief that there is
no discipline unless it is externally imposed by managers is a key
factor in the prevalence of Fake Agile.
If my hypothesis is true, does that give us any leverage to drive
towards true Agile? Possibly getting managers to understand that
self-discipline is better than externally imposed discipline is a key to
this?
-John
--
John Maxwell? KB3VLL? jmax@...
--
|
On 02/22/2020 08:42:00 AM, James Grenning wrote:
One of the widespread misconceptions about XP (and, to a somewhat
lesser extent about Agile in general) is that it's a rejection of
discipline in favor of simply letting developers do as they please.
Sounds like a misconception form someone that never experienced
XP/TDD.
Absolutely. What I'm looking for is ways to break the cycle of "No, I won't try that because it's obviously nonsense -> I've never seen that work -> No, I won't try..." -John -- John Maxwell KB3VLL jmax@...
|
The State of DevOps report was created to help get passed that hurdle.
There should be enough data there for anyone now to see that not only does it work, but it gives the company a competitive advantage in any industry.
On Sat, Feb 22, 2020, 21:31 John Maxwell < jmax@...> wrote: On 02/22/2020 08:42:00 AM, James Grenning wrote:
>
> >
> > One of the widespread misconceptions about XP (and, to a somewhat
> > lesser extent about Agile in general) is that it's a rejection of
> > discipline in favor of simply letting developers do as they please.
>
> Sounds like a misconception form someone that never experienced
> XP/TDD.
>
Absolutely.
What I'm looking for is ways to break the cycle of "No, I won't try that
because it's obviously nonsense -> I've never seen that work -> No, I
won't try..."
-John
--
John Maxwell? KB3VLL? jmax@...
|
James Grenning