So um, as eloquent as a lot of these explanations are (they are good rationalizations!) I still stand by my first recommendation.

Don't do it.

But then again that is a choice I make and I will not work under those conditions. Of course I do work with many teams in cleaning up crap like this so feel free to call me to kill this project now or to clean up later.

Still, good luck.

Mike Vizdos

Marco,

On 11/8/12 7:00 PM, marcodorantes wrote:
> Hi all,
>
> I am looking for articles or papers that talk about the details of
> how to successfully execute a development project with a waterfall
> façade to the upper-management layer and an agile approach for the
> development team. All is new in the project: the team, the users, the
> application, the technology. Note that with «waterfall» I mean strict
> sequential stages of requirements, analysis, design, coding, testing,
> deployment to production, and three months of maintenance; along with
> a fixed-price/fixed-scope contract, and a single Gantt chart as part
> of the signed contract. This Gantt chart will work as the criteria
> for payments at the end of each stage against stated deliverables in
> the contract.
>
> I have heard, from time to time, that some teams have done precisely
> that and very well done. Yet, I have not checked the evidence to
> believe it.
>
> Could you point to those articles or papers, or experiences?

I've seen a number of teams who think they're doing Agile development,
but are, instead, trying to burn through a fixed backlog by using
iterative processes. Theoretically, that could work. It would even give
you a better indicator of progress (or lack of it). I've never seen it
go well, however. It has all the fragility of waterfall plus the
frustration of not being allowed to use what you learn as you go.

If you can't change the backlog, it's not, by any means, Agile under the
covers. It's still waterfall, even if you use some practices that are
commonly associated with Agile.

   - George

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

If the company implementing this does everything classical (as you wrote), perhaps have a conversation with them about how they would like to see the input from their client.

Raises other questions that others will probably hit but ummm... What does your friend really want out of the erp implementation?

Start with a conversation. Just because there is this cool agile tool called scrum in your toolbox does not make it right for the job.

What is it they really need out of the erp implementation?

Mike Vizdos

Thanks, Mark. In my experience, though, there's room to be flexible even when
told you have to do it a certain way. Senior managers don't have time to
micromanage what is going on. The role of the PM is to figure out how to make
the space so that the team can be successful. Don't call it a Map Day, but a
Planning Day. You'll come out with a very good plan out of the first day.
Subsequent meetings will be to assess where we are and "refine the plan." Senior
managers will be OK with that.

It may be still, as you say, a train wreck. But that's no reason to run away.
Still, we may agree to disagree.

All the best,

Jose

--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
>
>
> That's a nice write-up, Jose, but I don't see how it's going to help the
original poster. The OP describes a by-the-book (serial) waterfall approach
involving a completely new team in a new domain. This is classical crash and
burn territory.
>
> It doesn't sound like they have the option to have multiple planning sessions
every 6 to 8 weeks (i.e. Map Days). As described, they have to have *one* plan
at the beginning, and they'll be held against it.
>
> On top of that, they won't deliver *any* working software until the very end
of the process, but somehow it will have to work exactly as the customer wants
it. Hmmm. Yea, right.
>
> This is a train wreck waiting to happen. The only way they're going to make
money on the project is if they sell tickets to the crash.
>
> Mark
>
>
> --- In scrumdevelopment@yahoogroups.com, Jose Solera <JOSE.SOLERA@> wrote:
> >
> > I beg to disagree with those who say not to do it. If you have to, you have
> > to. I had to do it once (no choice, believe me!)
> >
> > What I did: I layered an approach developed at Intel for their
> > semiconductor design projects and now known as "Commitment Based Project
> > Management" or CBPM for short. It is a domain-agnostic (it's been used not
> > only in semiconductor design and software development, but also
> > construction, defense projects, medical device development, education,
> > event-planning, and numerous other domains).
> >
> > It starts with what we call "map days". These are planning days through
> > which the entire team develops a rolling plan. Details are planned as far
> > out as the team is comfortable with, typically 6-8 weeks. Owners make
> > commitments as to when they'll deliver an item. They work with the
> > consumers or users of these deliverables to ensure agreement on what is
> > being delivered. Subsequent map days are scheduled, one at a time, at the
> > end of the previous map day.
> >
> > Regularly (at least three times a week some times daily) progress is
> > reviewed and adjustments made to the plans. Issues are encouraged to be
> > brought to light as soon as possible.
> >
> > Deliverables and status are tracked through an automated Excel spreadsheet.
> >
> > More details are available in Timm Esque's book describing its development:
> > *No Surprises Project Management*, at the LinkedIn group Project
> > Acceleration thru Commitment Based Project Management (
> > http://www.linkedin.com/groups?gid=1944064&trk=hb_side_g), in workshops
> > that Timm and I deliver, in a white paper I published (let me know if you
> > are interested), in Timm's company website (http://ensemblemc.com/) and in
> > a white paper he's published (
> >
http://ensemblemc.com/wp-content/uploads/2011/10/2010-Ensemble-paper_Commitment-\
Based-Project-Management.pdf
> > ).
> >
> > To get back to my story: I had to use a home-grown waterfall methodology.
> > We planned the effort using CBPM, avoided saying yes to the unrealistic
> > date requested by the customer by demonstrating its impossibility in the
> > first map day, made a commitments early on (second map day since we needed
> > to see if we could deliver portions of the software -- Agile!) and hit each
> > and everyone of our commitments on the nose. "There were no fires!" was the
> > best comment I heard.
> >
> > Would I use this instead of Scrum or XP? No! Those approaches are designed
> > for software development. But if I have to use waterfall, yes. Or for some
> > other less-SW-development time of IT projects such as migrating
> > applications to a new security system, deploying servers, etc.
> >
> > Contact me or Timm (through his website) if you want more details.
> >
> > All the best,
> >
> > Jose Solera, MBA, PMP®, CSM, CSPO, CSP
> >
>

Hi folks

Iran Agile 2013
Practical Agile and Nothing Else
19 Feb 2013 – Tehran- Iran

Iran Agile 2013 is the first specialized agile conference in Iran. It focuses on
agile values and principles in software development and management, on
innovation and on entrepreneurship, which are topics well interconnected
together.

Get inspired by others and share your experiences.

Call for papers

Topics:  Organization, Teams and Customers.

You can find More info in bellow doc
http://scrum.ir/wp-content/uploads/2012/11/Iran-Agile-2013.pdf

Regards

Asad Safari

Hi,

I am quite new to this and and have been lurking for some time.
I have one question to this comment since I am in a bit similar
situation: we have a huge backlog of things which all
are wanted by some customers, prioritized by the customer importance,
and usually we can go through quite a few sprint before something new gets into
the backlog on top of it, having a higher priority.

I also understand that Agile emerged in places where the customer did not know
what he/she wanted, and main impact of "learn and adapt" principle on project
success was by enabling the result of one iteration/sprint to influence the
remaining product backlog.

We don't have much of that, but sprint reviews allow us adapt our ways of
working on a team level: how we plan, estimate, test... what we document and so
on... I think it's another aspect of "agility":
we do not adapt the backlog, but adapt our ways of working.
Not "fully agile" then, but still a bit.

I am pretty sure that out POs could use the reviews more to our benefit, but
anyway...

//Jerzy

--- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
>
> Marco,
>
> On 11/8/12 7:00 PM, marcodorantes wrote:
> > Hi all,
> >
> > I am looking for articles or papers that talk about the details of
> > how to successfully execute a development project with a waterfall
> > façade to the upper-management layer and an agile approach for the
> > development team. All is new in the project: the team, the users, the
> > application, the technology. Note that with «waterfall» I mean strict
> > sequential stages of requirements, analysis, design, coding, testing,
> > deployment to production, and three months of maintenance; along with
> > a fixed-price/fixed-scope contract, and a single Gantt chart as part
> > of the signed contract. This Gantt chart will work as the criteria
> > for payments at the end of each stage against stated deliverables in
> > the contract.
> >
> > I have heard, from time to time, that some teams have done precisely
> > that and very well done. Yet, I have not checked the evidence to
> > believe it.
> >
> > Could you point to those articles or papers, or experiences?
>
> I've seen a number of teams who think they're doing Agile development,
> but are, instead, trying to burn through a fixed backlog by using
> iterative processes. Theoretically, that could work. It would even give
> you a better indicator of progress (or lack of it). I've never seen it
> go well, however. It has all the fragility of waterfall plus the
> frustration of not being allowed to use what you learn as you go.
>
> If you can't change the backlog, it's not, by any means, Agile under the
> covers. It's still waterfall, even if you use some practices that are
> commonly associated with Agile.
>
>   - George
>
> --
>   ----------------------------------------------------------------------
>    * George Dinwiddie *                      http://blog.gdinwiddie.com
>    Software Development                    http://www.idiacomputing.com
>    Consultant and Coach                    http://www.agilemaryland.org
>   ----------------------------------------------------------------------
>

Jerzy,

On 11/16/12 10:51 AM, jerzyklek wrote:
> Hi,
>
> I am quite new to this and and have been lurking for some time.
> I have one question to this comment since I am in a bit similar
> situation: we have a huge backlog of things which all
> are wanted by some customers, prioritized by the customer importance,
> and usually we can go through quite a few sprint before something new
> gets into the backlog on top of it, having a higher priority.
>
> I also understand that Agile emerged in places where the customer did
> not know what he/she wanted,

I suggest that your understanding is not quite correct. Perhaps
sometimes, but that's not the general case. More commonly, the customer
DID know what they wanted, but were able to take advantage of things
learned during development to achieve something better or sooner.

> and main impact of "learn and adapt"
> principle on project success was by enabling the result of one
> iteration/sprint to influence the remaining product backlog.
>
> We don't have much of that, but sprint reviews allow us adapt our
> ways of working on a team level: how we plan, estimate, test... what
> we document and so on... I think it's another aspect of "agility": we
> do not adapt the backlog, but adapt our ways of working. Not "fully
> agile" then, but still a bit.
>
> I am pretty sure that out POs could use the reviews more to our
> benefit, but anyway...
>
> //Jerzy
>
> --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
>>
>> Marco,
>>
>> On 11/8/12 7:00 PM, marcodorantes wrote:
>>> Hi all,
>>>
>>> I am looking for articles or papers that talk about the details of
>>> how to successfully execute a development project with a waterfall
>>> façade to the upper-management layer and an agile approach for the
>>> development team. All is new in the project: the team, the users, the
>>> application, the technology. Note that with «waterfall» I mean strict
>>> sequential stages of requirements, analysis, design, coding, testing,
>>> deployment to production, and three months of maintenance; along with
>>> a fixed-price/fixed-scope contract, and a single Gantt chart as part
>>> of the signed contract. This Gantt chart will work as the criteria
>>> for payments at the end of each stage against stated deliverables in
>>> the contract.
>>>
>>> I have heard, from time to time, that some teams have done precisely
>>> that and very well done. Yet, I have not checked the evidence to
>>> believe it.
>>>
>>> Could you point to those articles or papers, or experiences?
>>
>> I've seen a number of teams who think they're doing Agile development,
>> but are, instead, trying to burn through a fixed backlog by using
>> iterative processes. Theoretically, that could work. It would even give
>> you a better indicator of progress (or lack of it). I've never seen it
>> go well, however. It has all the fragility of waterfall plus the
>> frustration of not being allowed to use what you learn as you go.
>>
>> If you can't change the backlog, it's not, by any means, Agile under the
>> covers. It's still waterfall, even if you use some practices that are
>> commonly associated with Agile.
>>
>>    - George

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

Hi,

I think you mean that even when they know what they want,
this is not what they need :-)
Very true!
We do embedded stuff, where some thick spec mandated by law
can take many sprints, so it's more difficult to be in this situation...

thanks for the insight!

/Jerzy

--- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
>
> Hi ...
>
> On Nov 16, 2012, at 2:06 PM, George Dinwiddie <lists@...> wrote:
>
> >> I also understand that Agile emerged in places where the customer did
> >> not know what he/she wanted,
> >
> > I suggest that your understanding is not quite correct. Perhaps
> > sometimes, but that's not the general case. More commonly, the customer
> > DID know what they wanted, but were able to take advantage of things
> > learned during development to achieve something better or sooner.
>
>
> The first XP project, still one of the best, was payroll. The customer knew
EXACTLY what they wanted.
>
> Ron Jeffries
> www.XProgramming.com
> You never know what is enough unless you know what is more than enough. --
William Blake
>

Thanks, Mitch, Charles, Michael and everyone for the feedback.

Your insights are always helpful.  :-)

Cheers.

This feels like its own question.  You should repost as a new question to the group

Chang,

On 11/19/12 3:35 AM, changjiang1124@... wrote:
>
>
> Hi guys:
>
> I am new to this group, should have much to learn from you guys.
>
> I see here we always talk about "customer", does Scrum only fit kinda
> outsourcing development? What about doing your own products? That means,
> you will always get feedbacks from your customers, like bugs or wanted
> features, sometimes you need to reply them within several hours. And you
> still need to keep pace on your own milestones.

There is always a customer (or several) even when they're within your
own organization.

   - George

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

Hi guys:

changjiang1124@...

19 November, 2012 10:08 PM

 

Hi guys:

As I've been reminded, I repost the following to a new thread.

--------------

I am new to this group, should have much to learn from you guys.

I see here we always talk about "customer", does Scrum only fit kinda outsourcing development? What about doing your own products? That means, you will always get feedbacks from your customers, like bugs or wanted features, sometimes you need to reply them within several hours. And you still need to keep pace on your own milestones. 

--------------

@George, thanks for your reply. 

I can understand you should see your product owner as your customers. But when your customers are in your company, means they can always bring some "emergency" to you, from your business partners, or VIP customers, and if you don't want to slow down the business, you should pause what you are doing and support the "emergency", sometimes it may last several weeks, some or all of your devs may be occupied during this period. This would mess your whole plan.

Best regards

Chang, Jiang

Best regards

Chang, Jiang

Excellent. Requests and feedback is still coming in so I hope this helps. Let me know.

Happy Thanksgiving

Mike

Chang,

On 11/19/12 10:08 PM, changjiang1124@... wrote:
>
>
> Hi guys:
>
> As I've been reminded, I repost the following to a new thread.
>
> --------------
> I am new to this group, should have much to learn from you guys.
>
> I see here we always talk about "customer", does Scrum only fit kinda
> outsourcing development? What about doing your own products? That means,
> you will always get feedbacks from your customers, like bugs or wanted
> features, sometimes you need to reply them within several hours. And you
> still need to keep pace on your own milestones.
> --------------
>
> @George, thanks for your reply.
> I can understand you should see your product owner as your customers.
> But when your customers are in your company, means they can always bring
> some "emergency" to you, from your business partners, or VIP customers,
> and if you don't want to slow down the business, you should pause what
> you are doing and support the "emergency", sometimes it may last several
> weeks, some or all of your devs may be occupied during this period. This
> would mess your whole plan.

How often does your company have "emergencies?"

If they are very infrequent, you can either put your plans on hold and
deal with them, of split some people off to deal with them. It slows
down the planned work, of course, but that's the nature of emergencies.

If emergencies are common, then they're not so much emergencies as they
are poor ways of operating. I've seen this many times. Sometimes it's a
lack of planning. Sometimes it's too much power invested in a sales
person who wants to impress a customer or potential customer at the
expense of the long-term health of the company. Sometimes it's a way of
getting around a formal process of allocating time and money to
projects. Sometimes the organizational culture rewards "heroes" and
"firefighting" and ignores competent day-to-day work.

   - George

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