Harlan BridgesConsultant, Coach, Trainer, Speaker, Program Manager, Project Manager| EntrepreneurSeguin, Tx, United States
As a veteran PM, I am glad to learn more and acquire new skills. I have been studying and doing all that I can to keep up with new processes and techniques. So I have certainly been paying close attention to all the Agile methodologies. Certainly, I can see the advantages to Agile development. Of course, it will only work in the IT world. This is not surprising because it is after all an IT methodology. However, there are more PM's in other industries than there are the IT world. In fact compared to other industries, IT is a newcomer to PM methodologies. So, as methodologies like Agile become more prevalent in the IT world, we run the danger of losing sight of the fact that project management has a much larger world than IT. I am aware that Gantthead is focused on the IT world, but we can still learn from other industries that have been doing PM far longer than the IT world. Many of the projects I work on have other business components that must align with the IT development.
I get concerned that many business organizations do not recognize how much of their work outside of the IT department are really projects or how many IT projects have dependencies on the business projects. These projects need the PM process we all seem to be ready to chuck in favor the new methodologies. We must take care that our PM methodologies align with entire project.
It is also seems to me that Agile development requires a level of committment from the business (users, SME's) to which few organizations are willing to commit. That is a weakness of the methodology with which functional based organizatizations are reluctant to address. It may be less an an issue in a projectized based organization, but most organizations still ascribe to the former. Saving Changes...
Ed GeeSenior Program Manager| Smart Technologies Inc.Chandler, Az, United States
I have scanned this blog on Agile PM and have a few thoughts that I would like to share. First, there is contention between the traditional role of the PM (or Software PM) and Scrum Master. You don't just change titles and move along your merry way. There are actually modes of conduct that PMI has not yet fully reconciled and so the jury is out.
While SCRUM is traditionally a Software Development Methodolody which has shown to produce better results (better meaning better adherence to cost, schedule, and requirements) we are using it to develop our hardware/software SSD products and today we are able to bring products to market with more success and that success is not only measured by the traditional "Triple Constraint" but also by team morale and satisfaction.
I can say introducing a new methodology 'du joir' was not received well initially by the hybrid team or even the software design team and so we had to take baby steps and implement the methods and practices slowly.
The best part is that we are deliverying and testing code as part of a 2 week sprint and so we are not delaying surprises or stacking up risk to the end.
Six months later we still have not fully impemented Agile or Scrum but the very application of daily, 15 minute stand-up meetings to synch the teams, control of requirements and scope creep by use of a back-log and product owner, containment of resourse diversion until at least the completion of a sprint each have netted very favorable results in this company which I believe is at about a CMM Level 2.5.
So, I am optimistic in that we are seeing the benefits of the Agile/Scrum methodology and as applied into a hardware/software hybrid application. I still drive the hardware development part using tradtional waterfall techniques but marry that up with milestone end dates for software and the daily interchange between software engineers, VHDL/FPGA Designers, and Hardware Designers has netted very favorable results such that the Agile/Scrum model is here to stay-at least for now. Saving Changes...
Eric LandesProject Lead| Large Global CompanySouth Bend, In, United States
Harlan, I do believe you are wrong that Agile PM can only be done in IT world. Here is a link where Allistar Cockburn used Agile to build a house (he was the PM on the house) http://www.agileadvice.com/archives/2006/06/interview_with.html. For me, as Jim Benson mentioned, the huge takeaway with Agile is interaction.
I am not advocating agile for all projects, but it should be a tool in your belt. Especially for projects where requirements are not easily defined (new product development springs to mind). Saving Changes...
Djalma GomesProgram Manager| Data PineSao Paulo, Sp, Brazil
I believe there´s a confusion between “Project Management Lifecycle” and “Project Lifecycle”. Project Management has INITIATION, PLANNING, EXECUTING. CONTROLLING and CLOSING (that´s why we use the PDCA approach). And so far, they have not addressed a better approach than this traditional one.
Project Lifecycle depends on the product we are building (civil construction, IT, marketing caimpaing, etc…). Agile and SCRUM cannot be used for all types of “Project Lifecycle” (So far, I have only seen it used in product development and IT projects).
About the “Project Lifecycle”, we have 2 alternatives:
1) WATERFALL: We define the scope and plan cost and time. Since cost and time are our variables, we need to control their variance towards the baseline
2) AGILE: We define cost and time (a.k.a Time Bucket Approach) and plan the scope. Since scope is our variable, we need to control its variance towards the baseline (using tools like the a “Feature Backlog”)
Therefore, if the scope is the variable and scope definition is an information we get from users, of course we need much higher users availability in AGILE approach if compared to Waterfall approach. If user´s availability is a restriction in your context, AGILE is not such a good option.
I believe I am adding to another point above, Not only do I run large projects I have also focused on manufacturing for many years - repetitive/continuous and job shop, etc. The repetitive line (and job shop) builds a bit, tests a bit, builds a bit, tests a bit, all the way down the line and - that's the operation - in engineering it is similar - so Agile does have application outside of IT - it's just not called that. In fact dare I say Agile had its genesis in manufacturing TQM/JIT... excuse the TLA's Saving Changes...
Djalma GomesProgram Manager| Data PineSao Paulo, Sp, Brazil
Dear friend, I guess you are making a much bigger confusion. Projects start and finish. Operations however do not have a due date to finish (unless company goes bankrupt)
Project wise, manufatucting usually uses a waterfall approach in terms of determining the scope up front. The main reason for that is that engineering projects (like adding a new production line) usually requires machine acquisitions which costs a lot and it takes some time to deliver. It does not make much sense to buy an expensive machine if the scope is not defined.
What could eventually happen is to define the scope up front, but leave a few details to be discussed later on in the project. In such case we use “Control Points” (that´s the terminology used) to break down the details.
But that´s still a waterfall approach, since you define SCOPE and plan time and cost. In an engineering project, you cannot leave a machine behind because you ran out of time of budget. Therefore, you cannot use a “Time-box” approach. Engineering is also where Critical Chain came from (it started with TOC) and in order to use CCPM (Critical Chain Project management), you MUST use waterfall approach. It does not make sense to talk about time buffer in a time-box project.
By the way, like you, I am also an industrial engineering Saving Changes...
