Comments on Better Projects: Are they the right features?

When I used SCRUM, we planned each monthly sprint ...

2008-10-21T11:51:00.000+11:00

When I used SCRUM, we planned each monthly sprint at a high level in the beginning. The monthly stakeholder reviews were to get feedback on the release, we didn't need to ask them what to do next.

I am sure we were not following the textbook SCRUM method, which is fine. All frameworks are methodologies are there as standards and theoretical reference points, not as examples of exactly how to implement them.

Josh Nankivel
pmStudent.com

A couple of days ago I had a discussion about the ...

2008-10-20T20:36:00.000+11:00

A couple of days ago I had a discussion about the subject. From my perspective when a customer or a project sponsor doesn't act agile way you lose most of value brough by agile.

Agile isn't the only technique which allow you to create quality products (doing the thing right), although some agilists would state so. And when you act in very formalized environment with non-agile people on the other side agile methods don't bring you any closer to build a product which fulfills business needs in a better way. You do the same thing no matter if that's "the right one" or not.

Each time I'm a part of discussion about agile I try to virtually map agile methodologies to one of our customers - highly formalized company where people care more about their chairs than about success of their projects. So far no one convinced me it would be better to switch to agile in projects we do for the company.

Of course I don't reject agile fundamentally - we use agile techniques in our other projects.

Craig,

I think one has to be a little caref...

2008-10-20T10:12:00.000+11:00

Craig,

I think one has to be a little careful. Whether agile and scrum type methodologies will work has a lot to do with the environment in which the project exists.

If there is a clear, decisive requirement, sponsor or customer who can define what is needed and offer feedback as development goes along, it is a great approach. (my current little business operates this way.) It will deliver faster, more reliable and defect free products than any other methodology.

However, my previous, professional environments have not been this way. The environments were highly politically charged with sponsors/customers/analysts goals and objectives changing as the political winds changed. To get something completed in these environments, funding had to be allocated, requirements defined and a waterfall type approach followed and payment received for meeting predefined thresholds.

In these environments, many projects were killed. The standard line was that only 1 in 5 projects ever saw the light of day. It was not technical reasons or funding or qualified staff. These were all available. (they were and are wealthy industries)

The business architecture, incentives and economic realities have far more to do with the life or death of projects then the development methodology.

The development methodology answers the question of how the deck chairs will be aligned. Not where the ship will go, whether it hits storms or even icebergs. 4 out of 5 projects hit icebergs and ironically, I generally wished the 1 out of 5 that survived had been killed. (Murphy is cruel)

I'm not saying it's unimportant to the people doing the development, but it's not as important as the overall business environment and what people want.

Opinions and requirements can change very quickly, development goes very slowly. Chalk up a big plus for waterfall approaches, getting a signed off set of requirements and getting paid for developing to meet those requirements.

In an ideal world or in a world of small custom development teams answering to a single customer, I absolutely agree with you. But it took 15 years to collect enough capital and partners to take this approach and we will certainly need some luck to avoid having economic realities or business environments sink our whole endeavor.

In my experience, in the world of global development projects in multinational companies or financial service industries, sign a contract and pay me to waterfall. Agile approaches offer far too many opportunities to be bankrupted by the environment.

Andy

I think there is a difference between agile method...

2008-10-18T14:36:00.000+11:00

I think there is a difference between agile methodologies delivering faster to market (small deliverables of value to the customer delivered iteratively) vs agile methodologies delivering full project scope faster. But interpretation of faster to market is often then translated into faster project completion, which also implies cheaper. However, it is not necessarily the case that agile methodologies will deliver a full project faster or cheaper, but hopefully one that is a better fit for purpose and of higher quality. But all of that aside...

In my experience, the more partners you need to deal with, and the longer the lead times that these partners need to have, the harder it is to run a project in a "pure" agile manner where you only deal with what is in the current iteration, and nothing more.

You cannot suddenly say half way through your project, "for this 2 week iteration we will interface with partner X" when partner X requires 3 months lead time to schedule you into their development stream, and your project development phase is only meant to be 3 months in total.

I am likely to be flamed here, but interpreting agile in its "purest" sense implies that it is best suited for green fields standalone applications, and that it has no need for BA's, architects, or even testers, just the business and developers. There is a lot of debate on the Web in relation to agile vs project size, upfront design in an agile project, and the relevance of roles of different IT professionals in an agile project.

Personally, I believe that the larger the project, the more need there is for some level of upfront modelling, design, scheduling, and orchestration to occur. And for upfront design, there needs to be some upfront requirements gathering on which to base the design. The larger the project, the more important it is to have an overall direction. IMHO, a short sighted purely iterative driven approach with no big picture guidance is a recipe for disaster. At the very least, without having some form of outline of the project scope, how can you prioritise what to do next?

This is where a mature team and good project manager can interweave aspects of different methodologies and processes to fit the need of the task at hand - doing the right thing. An immature team and/or bad project manager will be more prone to slavishly follow a single process regardless of how fit for purpose it is to the task at hand - perhaps doing the thing right, but definitely not doing the right thing.

Hi Craig,

You are right on with doing th...

2008-10-18T07:45:00.000+11:00
Hi Craig,

You are right on with doing the thing right versus doing the right thing.

Lately I keep finding myself involved with efforts mired in lots of activity but getting to places other than where they need to go. What I keep asking the PM is this:
Are you answering the wrong question?