Nikolay SpasibenkoMSc Student| Heriot-Watt University, MIP Politecnico di Milano, USBE Umea UniversityUmea, Sweden
Hi,
We are two students conducting research for Umea University in Sweden. Our research is looking into which projects types are appropriate for Agile methodologies.
The idea comes from Brooks who has mentioned that there is no Silver Bullet. There is no single methodology, which would suit every project in the best posible way. Not all projects require Agile, some will benefit more from traditional waterfall-like methodologies. There has been very little research done into this topic. Therefore it represent a very interesting area for the research.
We are looking for project managers who have experience with both methodologies, who would like to volunteer for a telephone interview on the topic mentioned above.
We are going to post the results of our research onto ganthead once it is finalized.
Please PM me if you are interested.
We would appreciate any comments on the topic as well.
I am interested in the results. I see a place for both Agile and Waterfall together for most software projects. You need Agile to bond the development and test teams and you also need waterfall as a backdrop to communicate at milestones to the sponsors. Saving Changes...
Nikolay SpasibenkoMSc Student| Heriot-Watt University, MIP Politecnico di Milano, USBE Umea UniversityUmea, Sweden
Hi,
I have posted a survey online which asks to rate performance of different families of methodologies against different criteria’s.
I am calling out for everybody who has experience with agile, traditional or RUP methodologies to participate in my survey. I hope the results it will yield would benefit software development community.
The survey is available at http://agile.surveyconsole.com/ I would really appreciate your input on this issue. If you have any questions regarding the survey please feel free to PM me.
I agree most projects can be taken up in agile, RUP, waterfall or any of the mryaid methodologies.
Some cases like Time and material projects driven heavily by Business analysts/team and a clear direction for the project is not known (like all features of a product not fleshed out at the start) are good candidates for Agile.
On the other hand for software development house taking up Agile on fixed cost would be a nightmare :) Saving Changes...
Gabrielle MaherPMO Consultant| IndependentLondon, London, United Kingdom
Hi Nikolay - I have worked with both Agile and Waterfall.
Waterfall recognises 6 distinct stages within the project lifecycle – where the beginning of each stage is dependent on the completion of the previous stage. The UAT and deployment of the full system functionality happens at the end of the lifecycle. Strict change control is required for user requirements after the user requirements are signed off at the end of the business analysis stage. As Waterfall is commonly used in large complex developments - the risk here is that by the time the production version is released - the business requirements and processes will have changed - and the project will face endless change requests - which extends the time and therefore cost to deliver. It also makes the predicability element of the project more risky. The most complex and lengthy the development time - the more likely it is that the business requirements have changed.
Agile recognises the development lifeycle stages but fused or overlaps project stages - where 2 stages (or part thereof) can run in parallel. The analysis and design stages are intense and fused which enables the acceleration of the buid and test stages. User participation is intense. This methodology is used to enable accelerated build / development of software where the full functionality of the system is built iteratively. The execution process is crafted through a series of analysis, design and build iterations to develop prototypes or ‘spike’ solutions which can be demonstrated to the business. The development of reports and screen as part of this process also ensures business acceptance. The methodology requires the business and IT teams to ‘act as one team’ and involves the intense involvement of the business throughout the project. It allows for a flexible approach to system development enabling the business to direct the system development by functional priorities.
Once business signoff of user requirements is achieved the system build and test phases in the development cycle will commence for the 1st iteration / production release. The iterative process is an effective way of rapidly developing areas / segments of functionality in short timeframes whilst ensuring the business assurance process is enhanced. The iterative delivery approach – of which many will occur before the ‘full’ system will be deployed - allows segments of the functionality of the system to be gainfully employed before the ‘full’ system functionality is ready for rollout – thus enabling the business to take early advantage of their investment in parts of the system’s functionality. The focus of this method is to deliver early customer / business value.
Agile methods — these methods, including Extreme Programming and Scrum, they maximize flexibility and deliver working software faster and more often. Agile is about increasing predictability - getting the business requirements rights, incrementally buildings the system within tight timeboxes to maintain focus and promote simplicity, its about reducing waste (simple design, lightweight models), and accelerating business value.
Agile also has an aggressive approach to managing risk - the prioritisation of work is driven significantly by risk - therefore hard problems are tackled first - it involves building the most complex / high risk and architecturally significant part of the system first.
The method also requires active stakeholder engagement - a one room co-location for rapid communication - users / testers are an integral part of the team. The focus is on value driven prioritisation - top business requirements / functionality are delivered first. Pre-requisites require a dedicated 'War Room' where a meeting room is assigned to the team exclusively for the duration of the programme.
The time to deliver an iteration in Agile is very tight - I have worked on a programme where the window for each iterative release was 4 weeks. The first release was an Executable Architectural release. Its best used when the user requirements are unknown, there is significant user interface elements, a contained scale and basic functionality is needed quickly.
Waterfall is more suited to developing systems where the user interface elements are not significant, and full functionality is needed before deployment. It is more suited to large scale - multiple site -development. Saving Changes...
I like Gabrielle Maher's posting. It is spot on with what I know. I would like to add that in my experience with eXtreme, a key component is having highly experienced developers coupled with junior developers--to help the juniors develop their skillsets.
The idea is that you work more in a software factory model where product is assembled on-the-fly by developers and business folks, allowing the team to make their own decisions without due-process justification. Thus, the project management becomes 'process-industry' project management, where time-slicing production (like line-of-blalnce) is the techinuqe.
This is different from the well-documented waterfall approach, where every decision regarding the product is documented and scrutinzed by higher authority.
david alvarado Saving Changes...
Joelle GodfreySr Project Manager| DuracellNaperville, Il, United States
I read the article mentioned by Joelle and have some comments about it;
"The project manager puts together the project plan. They may or may not draw upon others to help"
This was a statement in the article. I suggest you read the discussion on GH at http://www.gantthead.com/discussions/discu...er.cfm?ID=14257 about who should develop the work plan. Because unless the PM is a subject metter expert in all aspects of the project it is highly unlikely that they can produce the plan without drawing on others to help.
The original article also mentions traditional project planning but only goes as far as the "Schedule" not the total planning process. There is no mention of risk, quality, stateholders, communications etc etc which are also key parts of the plan. I think this is a common mis-understanding that the plan is not the schedule and the schedule is not the plan. The schedule is a sub-set of the plan.
I would be interested in some comments about the rest of the planning process in the Agile world.
Saving Changes...
Andrew BrownProject Manager| eTelligent GroupSpringfield, Va, United States
I agree with the emerging consensus that there may be a place for both Agile and Waterfall in many projects, particularly in software development (which is, of course, the environment par excellence for Agile methodologies).
However, I'm willing to push it a bit further and predict that in the more or less foreseeable future, Project Management for all areas of product and software development, as well as factory-driven industry, will be defined by a completely new standard that is more than just a hybrid or tailored approach comprised of a bit of waterfall here, and a flavor of Agile there.
My conclusion is based on the push in recent years to include a PM role in Agile where there really has not been one before, as well as the occasional, but not too-infrequent presentation, lecture or paper on how to "reconcile" the perceived control and discipline of traditional PM techniques with the efficiency and flexibility of Agile.
Remember rolling-wave planning in waterfall?
Add to this the acknowledgement that Lean (an evolution of line management productivity methods applied within a traditional waterfall environment) is an essential part of Agile principles - and I begin to see the development of a completely new and wholly unique approach to Project Management that will be more than the sum of its parts; effectively supplanting and transcending the PMBOK as we now know it.
I have often combined the best of all practices known to me, without necessarily citing the pedigree of the practices to the team I am working with, and have had success combining six sigma, cmmi, OPM3, PMI PMBOK, ITIL, ISO, and other practices and standards.
That said, I will also say that I believe there are hard limits. Especially regarding the transition or organic growth of a project begun in, say, Agile (low risk, low complexity, little integration standards) to, say, PMI PMBOK under a full blown PMO with fairly rigorous standards. I say this because of several aspects, like development team culture, risk management practices, communications practices, and locus of control or level of decision making authority.
It seems to me that many projects begun in Agile or other informal methodologies which are highly successful and rise to importance usually fail unless reworked in more rigorous methodologies so that risk and decision making and quality control and documentation and communication and other critical factors are handled successfully. Often by an entirely different team.
While I love Agile and the free-wheeling creative spirit that it so effectively embraces, I have observed that integrating that style into high importance, high risk, high complexity and high cost efforts can be self defeating.
Thanks
Larry Saving Changes...
Shoaib AhmedProgram Manager| Eagle Technology GroupWellington, New Zealand
