Staying agile in the midst of adversity.

[Steve Toalson]

First post ever.....  Been 'coaching' for 2 years. Spent all of 2013 with a GREAT team.  So Great, it was time for me to move on to work with other not so great teams. :-)

Anyway - I'm still connected to this team.  Just prior to my departure, they learned of a significant deadline - 4/1.   They needed to have all of Release 5 features delivered by that time.   Team has kept working and making good progress.  However, our Product owner, and her Business partners continue to uncover new stories.  (#2 - we welcome changing requirements).  At this point, their metrics tell the story that they will NOT make their deadline.   As an agile evangelist, the answer seems straight forward - 1) Cut stories/features (scope) and deliver what they can on 4/1, or  2) extend the deadline. The business has responded vehemently - No and No.   So much for them being partners with us. :-(

The worst part now, with my absence, the Project Manager is Commanding the team to do whatever is necessary to deliver all stories by 4/1.   I am a very sad coach. I want Agile to succeed.  What I see is that, given dire circumstances, management is content to revert to our old ways. So much for being agile.

Would really appreciate any perspectives folks have to assist.

[Mike Bowler]

If the numbers say you can’t hit that goal then you can’t hit that goal. One of the things about agile is that it makes problems visible early enough to be able to fix them. Would they rather know that the team can’t hit that deadline now or on the day it’s supposed to be delivered? 

Most likely, there are things being requested that are not actually critical for the 4/1 deadline.  If you can split your stories to be granular enough then the PO will likely be able to defer some parts. That might make enough of a difference to get a useful release out by that date.

If the dev team has an adversarial relationship with the business (and it sounds like you do), then the options are really limited.

--
You received this message because you are subscribed to the Google Groups "Agile Coaching Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-coaching-su...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mike Bowler

Agile & Technical Coach, Gargoyle Software Inc.

Cell: 905 409-7052

Find me at LinkedIn, Google+, Facebook, Twitter, or Flickr

[Alan Dayley]

There a myth about Agile somewhat implied in your text. A principle of the Agile Manifesto states:

"Welcome changing requirements, even late in development."

This is different than what some people think it means. Some think it means "Welcome additional requirements..." Changing is different than adding. 

If the stakeholders and business people are willing to ignore empirical data on what can fit in the given time frame, they will get low quality. Not because the team will sabotage the work but because over stressed and over worked people make mistakes, take shortcuts and are less creative. 

I'm sad to hear the story. Sadder to hear that the people around the team don't see the reality of what they are forcing. 

Alan

[Mark Levison]

Steve - please excuse my brevity. Since its a weekend I'm focused mostly on family needs especially since I travel on Sunday.

I wrote blog post you might want to share with the business people about just this issue last week: http://agilepainrelief.com/notesfromatooluser/2014/03/scrummaster-tales-overtime-on-a-scrum-team-is-an-unhealthy-sign.html

Good Luck

Mark

--
You received this message because you are subscribed to the Google Groups "Agile Coaching Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-coaching-su...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Mark Levison | 1 (877) 248-8277 | Twitter | LinkedIn | Facebook Certified ScrumMaster Training: Vancouver | Edmonton | Ottawa | Montreal | Toronto Agile Pain Relief Consulting | Notes from a Tool User Proud Sponsor of Agile Tour Gatineau Ottawa and Agile Coach Camp Canada

[Jean-Charles Meyrignac]

I'd like to point to another direction: your inner self.

>I am a very sad coach.

My question is: why are you sad or angry ?

You did the best you could do, but you cannot save people (or companies) against themselves.

My advice: don't take the results of your coaching personally ! (except if all your projects fail, perhaps you are not integrating the feedback correctly).

If the clients want to sabotage their project, then let them sabotage it !

But if they want to discredit your coaching, don't let them !

I suggest a "cruel" plan:
1) tell them that they are going to fail, and explain why (the sooner the better), preferably in a written way (try to have a maximum of witnesses)
2) let them fail (I would suggest to allow them to fail small, by proposing a short deadline, and let them realize that they won't reach it)
3) the next time you meet them, remind them that they wouldn't have fail with your assistance. I'm pretty sure they'll agree.

Do you have any other mean of action ?

A few other ideas:

1) I believe that the client decided on the 1/4 deadline to "encourage" their team to deliver fast (in fact, they are destroying all motivation). I'm pretty sure it's an arbitrary decision and it will disappear after 1/4.

2) I believe that the PO doesn't defend the team's point-of-view. In France, we have a term for somebody who always agrees: "béni-oui-oui". These people believe that agreeing is the best solution, but this is wrong, because they are never respected.

Good luck !

JC

[George Dinwiddie]

Hi, Steve,

On 3/8/14, 9:45 AM, Steve Toalson wrote:
> First post ever..... Been 'coaching' for 2 years. Spent all of 2013
> with a GREAT team. So Great, it was time for me to move on to work with
> other not so great teams. :-)
>
> Anyway - I'm still connected to this team. Just prior to my departure,
> they learned of a significant deadline - 4/1. They needed to have all
> of Release 5 features delivered by that time. Team has kept working
> and making good progress. However, our Product owner, and her Business
> partners continue to uncover new stories. (#2 - we welcome changing
> requirements). At this point, their metrics tell the story that they
> will NOT make their deadline. As an agile evangelist, the answer seems
> straight forward - 1) Cut stories/features (scope) and deliver what they
> can on 4/1, or 2) extend the deadline. The business has responded
> vehemently - No and No. So much for them being partners with us. :-(

First, I like to make the data tell the story clearly, rather than
giving an interpretation. My favorite for this is the burnup chart, as
it shows the additional scope as well as the consistency of progress. I
think it help people realize that suddenly going faster. I find the
chart communicates more strongly than do numbers.

I don't know your relationship with the Product Owner and her business
partners. It sounds as if you identify more strongly with the team. Do
they, or can they, accept you as a trusted adviser? What does the
situation look like from their perspective?

One thing I've learned from sailing is that wishes don't have much power
over reality. When the wind strengthens from the wrong direction, I have
to do the work to sail around it. The additional time it takes is not
negotiable, and being unhappy about it doesn't help me at all. In
addition, I have to prepare for the consequences of such a situation. I
don't want to get stuck on a lee shore with no way out, perhaps putting
the entire vessel in jeopardy. But choices made early sometimes limit
the range of choices available later. I could entertain you with some
sailing stories, but the point is...

What contingency plans have they made for the situation where they don't
get what they wish?

>
> The worst part now, with my absence, the Project Manager is Commanding
> the team to do whatever is necessary to deliver all stories by 4/1. I
> am a very sad coach. I want Agile to succeed. What I see is that, given
> dire circumstances, management is content to revert to our old ways. So
> much for being agile.

Who owns the code base? Do they care about it's longevity?

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Dale Emery]

Hi Steve,

> Just prior to my departure, they learned of a significant deadline - 4/1. They needed to have all of Release 5 features delivered by that time.

What does “need” mean here? Whose need? What is the nature of the need? What makes that specific date so important?

In my view, any “deadline” that doesn’t include that information is suspect.

> As an agile evangelist, the answer seems straight forward - 1) Cut stories/features (scope) and deliver what they can on 4/1, or 2) extend the deadline. The business has responded vehemently - No and No.

Extending a “deadline” seriously impacts the power relationships in an organization. If you can extend a deadline, that says it wasn’t really a deadline. It communicates that you didn’t really mean it.

For me, that’s a good reason not to declare a deadline. For people who like to declare deadlines, it’s a good reason not to extend them.

So now you know which kind of person you’re dealing with.

> The worst part now, with my absence, the Project Manager is Commanding the team to do whatever is necessary to deliver all stories by 4/1.

It sounds as if the business and the project manager are feeling some need to reassert their power in the organization. It’s illusory, but they don’t know that.

A troubling fact: The project manager gets to make demands like that.

A potentially interesting fact: The people on the team get to decide how to respond to demands.

> I am a very sad coach. I want Agile to succeed.

It sounds as if you worked with the team. Often the trouble is outside the team, which puts it (to some extent) outside of your help.

They may be suffering from The Law of Conservation of Frustration: http://cwd.dhemery.com/2004/08/locof/

> What I see is that, given dire circumstances, management is content to revert to our old ways. So much for being agile.

When people are stressed, they often revert to doing things that (appear to have) helped them survive in the past.

Where is PM and business folks’ stress coming from? Could you help them respond more effectively to it? Do you want to?

Dale

[George Paci]

Steve,

I'm pretty sure I have nothing to say that will actually solve your
problem, for which I apologize in advance. I do have some questions,
mostly in rant form, which you may or may not feel like reading; it
largely depends on whether you find Eeyore funny, or depressing.

On 3/8/14 9:45 AM, Steve Toalson wrote:
> First post ever..... Been 'coaching' for 2 years. Spent all of 2013
> with a GREAT team. So Great, it was time for me to move on to work
> with other not so great teams. :-)
>

If it were me, I'd probably try to reflect for a bit that whatever crap
happens this year, 2013 was still great. You may not be as prone to
pessimism and catastrophizing as I am, so you probably already notice this.

> Anyway - I'm still connected to this team. Just prior to my
> departure, they learned of a significant deadline - 4/1. They needed
> to have all of Release 5 features delivered by that time. Team has
> kept working and making good progress. However, our Product owner, and
> her Business partners continue to uncover new stories. (#2 - we
> welcome changing requirements). At this point, their metrics tell the
> story that they will NOT make their deadline. As an agile
> evangelist, the answer seems straight forward - 1) Cut
> stories/features (scope) and deliver what they can on 4/1, or 2)
> extend the deadline. The business has responded vehemently - No and
> No. So much for them being partners with us. :-(
>

So the business side put a lot of stock in the developers' estimates
when those estimates showed the team making the deadline, but refuses to
accept them now that they show the team missing the deadline (because of
newly-discovered additional work). Why did they accept the estimates at
the beginning? Why not now? Do they think (after working with this
team for at least a year) that the developers were
sandbagging—deliberately inflating their estimates? My guess is no,
because if the business did think that, they would have either directly
accused the developers of sandbagging, or indirectly showed they think
so by trying to cram more into the Release 5 (or moving the deadline
earlier).

I think the business side thinks two things:
1) Bad things will happen (to them, to the organization) if they
don't have everything in the backlog done on April 1st.
2) There's no way to get everything in the backlog done on April 1st.
The problem comes when they think the two thoughts together, because the
conclusion is unavoidable:
3) Bad things will happen (QED).

This conclusion is intolerable. They reject it (for emotional reasons,
not rational ones), which means (if they want to appear rational to
themselves or others) they have to either reject (1) or reject (2).
Rejecting (1) means bucking their bosses or customers or whoever it is
that helps them make their mortgage payment and feed their kids, so
that's out. So they reject (2), since it's much easier to fantasize
their way around: hey, it's software: anything could happen, right?
Didn't a college kid write the first graphical web browser in under a year?

The problem, of course, is that (2) is true, so they're willfully
believing something important that's false, which is literally insane.

Is there some way to inoculate people against this particular brand of
insanity? Are there Aesop's fables of software development that we
could tell that would do the trick? (I like the one where Aesop
volunteers to carry the food and water on a march: it's very heavy in
the morning when he's fresh, and very light in the evening, when he's
tired. The link to test automation seems obvious to me.)

I wish I could take the business side to a track, have them run a
quarter-mile, then make them run it twice as fast. Unless they walk the
first time, my guess is they'd discover it's impossible. After they
failed, I'd offer them big bonuses for succeeding. When that didn't
work, I'd threaten their jobs if they fail again. When that didn't
work, I'd explain how vitally important it is to the business that they
at least stop running it more slowly each time. For some reason, many
people on the business side always think they can get more out of
developers, no matter how productive the developers are. Maybe, deep in
their subconscious, they really *do* believe that programming is just
typing, in which case a programmer's only real physical limit is four or
six characters per second, or 112 - 168 KB of code per day, or about
5,000 - 9,000 lines per day. (Unless you make the slackers work
overtime, of course, and isn't dictation software getting better every
year?)

I don't know a guaranteed way to make people face reality; I suspect if
I did, I'd be rich, like Oprah. Or at least maybe powerful, like
Oprah. Life-or-death situations sometimes clarify things, but sometimes
just make people cling harder to their illusions. Same for
employed-or-unemployed situations. Yelling, threatening, crying, going
on Dr. Phil, even mockery: sometimes these approaches work, sometimes not.

The best suggestion I have, therefore, is to talk to them a lot. Ask
them a lot of rational questions. Can they demonstrate how they can get
all of what they're demanding in the time frame they're demanding it?
Why are they certain that the estimates in their plan are better than
the estimates from the developers (who know the work and how it's done
in much more intricate and intimate detail)? Can they (or you) can get
another group of developers to estimate the work? Maybe you should
encourage them to put the work out for bid to an outsourcing firm, and
listen to their reasons against doing so.

How is it that their estimate for the work coincides so wonderfully with
the arbitrary due date (and, I'm guessing, has continued to do so as
each new story was added)? Why don't they think it can be done a week
before that? Or a week after that? Or next week? Clearly, their
estimates are changing; why do they think they're getting better at
estimating and not (as is obvious to anyone outside the situation) worse?

How would they adjust their estimates if they lost one of the
developers? How would they adjust their estimates if they lost all but
one of the developers? How do they think barking unrealistic orders at
the developers affects the chances of those scenarios actually
happening? How do they think it affects morale, and how do they think
that affects productivity? Do they observe Google going broke by
listening to their developers and being nice to them?

Are they paying attention to how quickly the work is actually being
completed? April 1 is 24 days away. Does progress match their
estimates better than it matches the developers' estimates? The other
way around? Or are *both* estimates too optimistic? Is it worse to
give advance notice that not everything will be done before the
deadline, or better? (Not that customers and bosses ever love negative
surprises, but maybe the business side needs the time to line up job
interviews or something.)

Did they make a commitment to someone higher up in the organization? To
someone outside the organization? Did the commitment include
(implicitly or explicitly) all the newly-discovered stories? What are
the actual consequences of not having everything done April 1st? What
are the actual consequences of having everything done when the team
thinks it will be?

Another good question is, "Has what you're doing right now *ever* worked
for you?" Especially if you already know the answer is "No."

You'll have to repeat yourself. Get resigned to it. Think how much
repetition it takes to teach someone a foreign language, and count
yourself lucky by comparison.

> The worst part now, with my absence, the Project Manager is Commanding
> the team to do whatever is necessary to deliver all stories by 4/1.

I'd put a poster of King Canute up on the wall. Heck, I'd tell the
story at the start of every meeting. The developers on the team may
have more interest in job security than I do, true. Though they should
really ask themselves why: is there really no job out there that's
better than the one they're in? Do they think things will go back to
being sane after 4/1 (a GREAT day for an arbitrary deadline, by the
way)? Wouldn't they rather go into job interviews talking about how
they just wrapped up a successful year, rather than explain how they
were on a team that missed an April Fool's Day deadline and got
fired/quit/sacrificed the month of April fixing critical bugs in the
field for pissed-off customers?

(We talk derisively about rats leaving a sinking ship, but from the
rat's point of view, it's a no-brainer: he can be a live rat, or a
drowned rat; those are his only options, and one is clearly better.)

I sincerely wish I'd sent my resume out immediately the couple of times
in my career that I've seen regression like this in an organization.
It's a big hole below the waterline, with nobody patching it and nobody
pumping. You'd be doing the individual developers on the team a service
by pointing this out to them.

> I am a very sad coach. I want Agile to succeed.

I'm guessing you also want world peace. You may have to adjust your
time frame for the widespread adoption of either if you don't want to be
sad.

There's a regressed Agile team in my past (this probably fails to
surprise you). I can't help thinking about them. I'm still mad about
what happened to them, but in the future that will probably dull to
sadness like yours. Something wonderful happened, and then it was
mindlessly killed. It's like a children's cancer ward writ small. Some
members of the team were stuck in that organization, and couldn't even
quit. Some of them did quit. (Their departure didn't affect the
schedule, which is interesting.)

Are you still in the same organization?

Can you go over the heads of the crazy people? Do they have a boss
inside the organization? Was she or he supportive of the team's Agile
performance? Can you get them to see how unrealistic the current plan
is? Can you do an anonymous survey of the team to demonstrate that none
of them believe in the schedule? Can you get the higher-up to admit to
some flexibility that either the developers or the business side are
unaware of? Can you express to them the plain facts that they have a
time budget, the stories have pretty well-known time costs (especially
in the aggregate), they thus can't realistically get all of them, and
they're going to have to prioritize?

> What I see is that, given dire circumstances, management is content
> to revert to our old ways. So much for being agile.
>

"Content" is probably an overstatement; I'm sure their Maalox
consumption is going up. The old ways are just less awful-feeling to
them than the new ways (or than they think the new ways will be). I see
this irrationality in myself occasionally, so I think I understand it a
little. But, as coaches, we know about stress-induced regression. We
know it's a little late to deal with it after the regression has
happened. What can we do about it beforehand?

Is there some way to rule such crazy behavior out of bounds, like a type
violation? Is it enough for the developers to just keep repeating,
"These are our estimates, this is when we think you can have each of
these items if we do them in the order you gave us"? (One of the things
that angers me most about this type of situation is not just that the
business side rejects the developers' estimates, but that they want the
devs to *accept* and even *endorse* theirs.)

> Would really appreciate any perspectives folks have to assist.

I'd understand if, after reading this, you add an exception to the above
statement.

--George

[Steve Toalson]

Wow!   Let me first say I will work hard to become a regular here!  The quick and informative feedback since my original post on a Saturday morning - impressive!  I was thinking maybe one person would reply (given its a weekend).

Thanks everyone for your thoughts and suggestions and questions.   I will keep everyone posted as the rest of March transpires and 4/1 approaches.

Having had more time to think, and absorbing these various posts/thoughts/questions,  I truly believe our issue is with the engagement of the business.   We actually do have a great Product Owner.  Sadly, however, she is also at the mercy of those above her that are not engaged in the conversation. They are not trying to help figure out how WE will all win.   George - your suggestion of taking them all out to the track at the local high school is perfect.  Rather than examine the results (our metrics) and develop a better plan (ie. something realistic), they opt for the hammer.      It     Must    Be    Done!  (hammer harder,   hammer harder, hammer harder).   (Definition of insanity? Anyone?)

Including George's track analogy  - it's priceless:

"I wish I could take the business side to a track, have them run a
quarter-mile, then make them run it twice as fast.  Unless they walk the
first time, my guess is they'd discover it's impossible.  After they
failed, I'd offer them big bonuses for succeeding.  When that didn't
work, I'd threaten their jobs if they fail again.  When that didn't
work, I'd explain how vitally important it is to the business that they
at least stop running it more slowly each time.  For some reason, many
people on the business side always think they can get more out of
developers, no matter how productive the developers are."

Another item to consider......  The people in the business - they actually do accept the overtime, and have for a long time. Seventy hours is not uncommon. For years they have been pushed and pushed.   The application we are creating should have a positive impact on this unfortunate behavior.  But just because others have been forced into these working conditions, does that make it right?  (No need to reply to that question.  I know the answer).   The answer is no - but even so, it does add pressure for the team to 'also contribute'.   If the business were jumping off a cliff, maybe that would make it more clear to others - we don't want to do what they are doing.   It kinda boils down to the David and Goliath story.  Or Bullying.  

[Tim Ottinger]

You've gotten a lot of responses so far.

Anyway - I'm still connected to this team.  Just prior to my departure, they learned of a significant deadline - 4/1.   They needed to have all of Release 5 features delivered by that time.  

How often do they release? Is this a release or a launch? It sounds a lot like they're not doing continual release from this.

The less often you release, the more stress hits the release planners (sales, product, marketing, etc). Not releasing often enough causes panic. Releasing all the time creates calm.

How long before they can release something that doesn't get in this time?

 

Team has kept working and making good progress.  However, our Product owner, and her Business partners continue to uncover new stories.  (#2 - we welcome changing requirements). 

"Uncover" sounds like it wasn't a choice.
It sounds like someone isn't taking responsibility here.
More stories are a choice, a decision.

Others have mentioned that you're at a certain capacity. They can only add N-sized stories by removing other stories of the same or less importance and size. It's not your decision to have a given velocity. It is their decision to do more than they had agreed.

Do they know they're breaking an agreement without negotiation or advance discussion?

See this: http://agileotter.blogspot.com/2009/08/platitudes-of-doom.html

 

At this point, their metrics tell the story that they will NOT make their deadline.

Good. That's what metrics are for. Did the metrics *just* *now* start to tell them that? Or have they ignored the signs until now?

 

The worst part now, with my absence, the Project Manager is Commanding the team to do whatever is necessary to deliver all stories by 4/1.   I am a very sad coach.

Ex-coach for them.

But have them start tracking bug injection. As they fix a bug, have them find the date of the prior edit(s) to that source. This will provide a shield for next time ("remember when you had us work overtime, and we quintupled our defect rate for a month?")

 

I want Agile to succeed.  What I see is that, given dire circumstances, management is content to revert to our old ways. So much for being agile.

One product manager once said to me, "I miss the days when I could go home at five knowing that the developers would stay up all night to give me the features I want."

He ACTUALLY said that.

Yeah, I know. Unbelievable.

If you're not working with them, there is little you can do. If you walk away, you walk away.

This is a challenge for the team. If they can weather the storm, they will be great. If they forget everything they learned "just this time" then they'll fail.

You are the wrong person to be asking for advice. Where are the team members right now, and who are they asking?

--
Tim Ottinger, Sr. Consultant, Industrial Logic
-------------------------------------
http://www.industriallogic.com/
http://agileinaflash.com/
http://agileotter.blogspot.com/

[Jean-Charles Meyrignac]

On Mon, Mar 10, 2014 at 11:57 PM, Tim Ottinger <tott...@gmail.com> wrote:

 

The less often you release, the more stress hits the release planners (sales, product, marketing, etc). Not releasing often enough causes panic. Releasing all the time creates calm.

I'm sorry, but that's not true.

I agree that if there is no release at a regular pace, nobody really knows if the product progresses or stagnates, but I can assure you that releasing frequently creates chaos, especially when you have to maintain older releases.

In my case, we have a new release every 2 weeks, but we only upgrade our clients with a stable release (>1 month of no patch) every 3 months.

In fact, we upgrade our clients with the latest release only when the client has a problem.

In general, frequent releases are a PITA for IT, because IT needs stability, while development needs reactivity.

Of course, if no IT is involved, releasing faster is nice.

I agree with your other comments.

JC

[Tim Ottinger]

We release several times a day. It takes about an hour from the time we commit, which we've decided is too long. It used to be faster, and needs to be again.

It shocked me the first time John told me "when you release constantly, it takes all the stress out of developing software." My experiences were more like yours. But I have changed my mind.

To release all the time, you have to have a lot of automated support. Being hands-off and automated is a lot less stress for you. That means you have to have good tests, and constant integration. But those are learned quickly enough.

You also lean to do all your work incrementally. Do a piece, ship it, do the next, ship it. It's a learning process, but it's pretty darned cool.

But the biggest difference is what it does to planning stress. Planning stress is about:

• What happens if you're wrong about priorities?
  
• How long do you have to be right?
• How long before you find out if you're right?
  
• When can you correct if you're not right?

If you release once a year, you'd have to know all the things you're going to want next year, and you'd damned sure better be right because it's a year before you can ask again. You have to load up the maximum number of features "just in case" and there will be a panic when you get around to 'integration phase' when everything has to really work for the first time.

With constant releases, the answers are:

• Nothing much, you pick another and go on.
• For hours.
  
• Hours, maybe days (we use analytics).
• Right away.

You lean to release a week's worth of work in a week or a day's worth in a day. Tiny releases are easier than big ones.

One of the more stressful places I've been had 6-year "projects" which really ratcheted up the stress. I don't know how people manage products if they have to be right for a period which includes several generations of technological advancement (each of which modifies customer expectations -- think "iPhone").

--
You received this message because you are subscribed to the Google Groups "Agile Coaching Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-coaching-su...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jean-Charles Meyrignac]

I understand all your points, but I still disagree, because I'm working in the IT part.

Before doing "professional" programming, I worked in the console's game industry (you know, the cartridges !), where you could only deliver once.

I let you imagine the stress at the end of the project: only bug fixes during the last months !

Releasing frequently removes the stress of delivering, because the development team gets accustomed to delivering (they don't fear about "finishing", which is a very common fear in programmers who want to have a perfect product).

It also allows to "fail small", instead of "fail big" at the end.

Of course, you listed all the benefits of frequent deliveries, as long as it's not on the production servers.

But there are a few drawbacks:

1) it gives a false sense of reactivity. The customers may believe that everything can be released quickly. In fact, it seems to be Steve's case. The more they'll believe that, the more they'll try to pack features (and of course not listen to their own developers). "We started in agile, so we can now work without method since the project is almost done".

2) when you release frequently, quality may drop, because writing tests takes time, and the team gets more confident on their code. You really need to have a self-disciplined team (it's quite rare from my experience). Writing excellent tests may take 50% of the time, so for customers, it is a loss of time and money. They don't care about technical debt, it's too far.

3) as an IT member, I need a "stable" release. By "stable", I mean a release that has been validated by the human beings during a certain amount of time (typically one iteration). If you come to me and tell me that I can deploy the last build, I'm sorry, but I won't trust you and I'll be right.

For me, a daily build is "beta", even though we have pretty extensive automated tests.

Telling the customer that it's good enough is also why the customer wants even more features.

I'm curious to know how you mitigate the "beta" effect.

JC

[Mark Levison]

Quick check gentleman - is this conversation on the subject of release frequency furthering the needs of the OP?

I'm having a hard time seeing that.

Thanks

Mark

--
You received this message because you are subscribed to the Google Groups "Agile Coaching Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-coaching-su...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

[Alan Dayley]

JC,

I fully sympathize with the difficulties you describe. I also agree with Tim, that such difficulties can and should be eliminated. 

Currently the ideas on how to deliver to the customer, not just code to operations, are called DevOps. The book "The Phoenix Project" is a great and recent encapsulation of many of the DevOps ideas. 

I have been on teams that made hardware and firmware for military use. And could release new code on the platform every week, if required. It can be done. No beta effect, whatever that means.

It's not easy and takes time and effort to build the capability to go from long test periods and manual testing to mostly trusted automation and targeted testing by humans. But it is so worth it!

Alan