Please login or join to subscribe to this thread
Dear Anonymous, we are seeing more and more organizations going through both 1) setting up or revitalizing their project management best practices and 2) ensuring that the project processes are easy to access and use, provide flexibility within structure for differing project types and sizes, and meet the needs of the project team, management and sponsors, as well as those involved with periodic audit (Sarbanes-Oxley) and validation (QA). For example, an organization might have a PMBOK aligned process for general EPM projects, an SDLC process for development projects, and a Change Management process for projects eminating from change requests. And within a given project process type, more and more PMOs are seeking to provide best practice workflows streamlined to project type and size such as PMBOK large and small, SDLC Waterfall and Agile, etc. The idea is that no single project methodology will be best for every project effort. Where one process, say Scrum, may be ideal for the development team's iterative oriented software development projects, it would be highly unlikely that the infrastructure team would want to use an iterative project process for a project to upgrade the servers! I would guess that any Waterfall v. Scrum issues that your development team and quality team are having are most likely centered around documentation as from your post it sounds like your quality team is doing QA on SDLC documents not the actually product of the project, the software. And depending upon your organization structure and dynamics, there may be differing views between the development and quality teams on whether QA is a support function to the development team or whether the quality team has the mission and ability to dictate how the development team should do development. Though it can be contentious, it would be good for the development team to work closely with the quality team to educate them on the value of Scrum and to ensure that the implementation of Scrum is understood and supportable by QA. You might also consider using a project management process tool like Processes On Demand that helps setup, use, and maintain your best practice portfolio. Listed below is a brief summary of Scrum and links for further information:
What is Scrum?
Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development. Scrum is easy, but causes difficult change within an organization.
Great post and good luck! I hope we hear and learn from others on this subject.
I am a Certified Project Manager and PMO specialists that assists organizations in building best practices and methodologies utilizing automated methods, process and procedures for various organizations.
As this article states, Agile development is on the move and is being adapted by a number of organizations. Last year, I moved a organization from the traditional SDLC model to Agile life cycle. As the CIO stated, Agile is a state of mind. In building the methodology, the basic deliverables necessary to deliver quality and on-time projects is not violated. However, time to market was improved using the Agile state of mind.
Background on this organization: The PMO and IT organization spent several years defining methodology and had a large number of deliverables. Of course nobody used the methodology because of the bulky nature of the methodology. In building the new methodlogy, the Agile mindset was installed in 8 weeks using a purchased methodology and tailoring the project and support delivery process to utilize a streamlined Agile methodology.
Results from this effort are as follows: IT adapted the Agile methodology and loved the process. In fact, the PMO sales job to the organizations was easy. I have stayed in touch with this organization and one year into the process they added additional project deliverables, but did not change the mindset of delivering projects. In fact, the company merged other departmental PMO's into a single PMO because of it's effectiveness.
I have a Master's in Project Management practices and a thesis on effective project teams. The Agile methodology support effective teams and delivers projects saving my clients money, time and effectively utilizing scare resources.
I can be reached at firstname.lastname@example.org for further information on integrating this effective way of running business and IT projects.
One point of interest is the separation that you are indicating between development and QA. In the agile methodologies, a very key issue is integration of "developers" and "testers" along with the customer. The stress that you are seeing could be alleviated if the QA team was integrated rather than separate. This means that they would have to buy into the concepts of the agile methodology at the same time. Changing a culture from waterfall to agile requires a complete cultural change throughout the entire organization, not just one group.
Been there, done that - handling a Scrum process with a Waterfall tail... it just takes some time, believe me! So my advice would be "ask politely, provide what they're asking for and give them time to adjust".
I'm assuming that you can't just change the organisation, so what I'd do is first is to find out more about what/who QA needs those SDLC documents for. From what you're writing, they are keen on CYA traceability, which is not a problem for Scrum - just put the required documents in the Sprint Backlog and they will be written. Once the first change requests have gone through nicely & the QA people are sufficiently confident that the project won't backlash because of the weird new methodology, you can discuss whether these docs are still needed...
Francois (sorry, no business plug here ;)
This is a great post, but can I ask its whether Scrum, UML, RUP, CMMI, Six sigma etc. You name the methodologies, if you present this to the business or deparments that are not in IT its all buzz words to them.
Their preceptions are "This is all good touchy feely ways of doing this". Its all good that some companies & SME's are working to best practice, but when you go to "large" corporates, do they really care?.All they would care about is meeting company's or departments objectives. Each group/department have their own agenda's, resources and money is tight. So for those companies that are doing best practice and have the money to spend, good on you!!, but don't go asking for staff with so and so X years of experience in Agile,Scrum,UML etc, when heads of companies; CEO's,CIO's trickling down to managers don't want to spend money on training staff or give people opportunities/experience.
Great post..! Too often, we take for granted or assume our "buzzwords" resonate with others, rather than "continually" relating the importance and value of a particular approach to things in terms of the business result being achieved. I have heard it said, "knowledge may be the tree, but application of knowledge is the fruit of the tree."
Re your comment: "if you present this to the business or deparments that are not in IT, it's all buzz words to them?"
Re your comment: "Their preceptions are 'This is all good touchy feely ways of doing this'. Its all good that some companies & SME's are working to best practice, but when you go to 'large' corporates, do they really care?"
Re your comment: "managers don't want to spend money on training staff or to give people opportunities/experience."
Great post, I hope we hear and learned from others..!
Great post and you've got great thoughts and contructive feedback.
Re your comment: "talk to the line of business executive about "reducing inventory costs" or "increasing inventory turns" not "we are going to do a Six Sigma project for your department".
It is all to often that we talk to a heads of department(s) explaining the benefits of doing things program/project 'on their terms'. However from my practical experience, it is all too often they turn a blind eye into this. Stating the obvious, thanks this is all good but not of value and relevant to us (we have own objectives to achieve), thanks its all good in nature.
However the problem/issue still exists and the department/business trots on doing their own stuff, but the underlying issues pervades - band aid approach. Usually what happens is this band aid breaks, water leaks and the ship is going to sink. Only when lets say 'the sh*t' hits the fan,(excuse my french) do they recognise that something's wrong.
My main question lies: How do we prevent this from occuring?
Surely we can present a 'lesson's learnt' from previous occasions. However what happens if there is no 'lesson learnt' document or lack of one, or its a mess and resides somewhere. Do companies/business still continue on this awful loop?.
I hope to get someones feedbacks and thoughts on this
Excellent feedback on this article! Although it would appear we veered off the path and got a bit into the politics and culture regarding senior and executive managers. As a senior PM that has implemented several PMO’s and managed projects that used Scrum, Agile, and Waterfall processes, I say that like anything else Scrum and Agile are new and take time getting use to. On the original question regarding QA test team and your development team having issues, make sure the QA team knows exactly how the Scrum process works relative to a traditional waterfall project. Let’s face it, there are only a few basic processes and artifacts that are in play here: (for generalization) business requirements, functional specifications, use cases, prototypes/mock ups, etc. As long as your developers can adequately illustrate “requirement traceability” you should have better success with the QA team. The QA team is looking for a package that provides a trace back to the original business requirement for the software developed. All projects are supposed to have the artifacts I mentioned above and on that premise if you are developing an iteration of business functionality using a Scrum process, then make sure the requirement documents get developed the same way – that is, if you are delivering 3 function points rather that 12 in this iteration, then make sure the business analysts and QA team are in synch and the documents are developed as such. As all the rest have weighed in on, provide Scrum overview and/or training to the QA team AND Business or Functional Analysts as well. Good luck!
In my opinion it is best to look at different areas of the PMLC as requiring different methodologies. Simply explained the Project initiation and requirements gathering phases are best managed with a waterfall approach. This allows the development of NPV and ROI so the right projects are chosen. The design, build and system level testing is best handled using an agile approach like SCRUM. This allows the business, development and QA to collaborate in building the optimal solution. The final pahse of Regression testing, UAT, and deployment is best handled in a more structured iterative approach. This allows good decision points when releasing solutions to users.
I believe the Development team likes to call their new approach as 'Scrum' to add a nice name to their methodology or approach to say that they are keeping up with best practice. Or probably a vested interest in someone advocating the type of methodolgy.However coming from over 15 years of experience in PM/ BA work
I believe agile, scrum, uml etc are all hyped up names.
I would challenge anyone in the IT financial services industry to let me know if there methodology agile, scrum or uml have lived up with the ROI or NPV ,With real life case examples - I would highly doubt.
Though different industries may prove a ROI for scrum, agile, uml etc such as advertising/publishing/ IT vendored development companies.
So to answer your question why can't the development team just re-name their scrum methodology and integrate them in on their existing SDLC, then the problem is solved. Its just really the name isn't it?
Appreciate anyone feedbacks and thoughts on this.
Please login or join to reply