We are having an internal debate regarding Waterfall and Scrum. Our development team has transitioned to Scrum in order to iteratively develop and release software better and faster. Our QA team insists that Waterfall must be used and that specific SDLC documents must be sent to them for QA review and signoff as part of their QA process. The PMO is seeking to document all PM best practices and is caught between the growing difference of opinions between the development team and QA team on this issue. Does anyone have any insight or similar experiences to share? Saving Changes...
Shawn BellingChief Technology Officer and Adjunct Faculty| Geno.Me/University of WisconsinFitchburg, Wi, United States
Too cynical, Joshua. I too had some initial issues with SCRUM and Agile, but have generally accepted them. My project team adopted many Agile tactics a year ago on our current project. Even though this particular project is not necessarily ideal for the Agile approach, we certainly have not suffered for lack of following waterfall. The development team has generally appreciated the change in approach, and certainly in the first 3/4 of the project it was the right approach.
As professional project managers, we need to be open to assessing and adopting methodologies that may add value to our project management. When applied properly and in the right situations, SCRUM and Agile can make strong contributions. The ROI is found in getting solutions to users as soon as possible and stopping when "good enough" is acheived.
It is important to ensure that the methodologies are being followed properly and selected for use for the right reasons. It is unacceptable for a team to refuse to develop plans or be held accountable to an organized approach and defend this as "SCRUM." Saving Changes...
Wayne MackRetired| RetiredSouth Riding, Va, United States
Back to the initial point. Standard QA departments often have a difficult time adjusting to agile as it changes the nature of the work. There are short term adaptations that can be made, but long term it becomes prohibitively expensive to perform a full, independent QA for each sprint or iteration.
Here are some short term things to try:
1) Invite the QA team to the Sprint Planning Meetings and Sprint Review Meetings. These are the Scrum "Quality Gates".
2) Provide the QA team with access to the Product Backlog and Sprint Backlog.
3) If the team is using story cards to track progress, give the deck of finished cards to the QA team at the end of the sprint (or give them a copy if you like to hang on to such things).
At this point, the QA team has access to all of the information available to the development team. The question now is one of format. It is now a higher level call as to how to proceed. If management says the QA team needs to work with the naturally produced Scrum artifacts, fine. If not, the team needs to add one full time resource to format information into the desired format. I have usually found this entails 10% - 20% of the effort of the team. Unless directed otherwise, include this effort as tasks in the Product and Sprint Backlogs.
Saving Changes...
Paul ParkerScrumMaster (CSM)| PricewaterhouseCoopers (formally BearingPoint)Tampa, Fl, United States
The whole concept of a Scrum team means that all the skills to facilitate software development are represented on the team. Members of QA should be on that cross functional team and provide input into the development process and testing is a part of the process. The silo approach that most Waterfall organizations tend to foster does not work in an Agile or Scrum environment. Having helped organizations into Scrum this is one of the "pain" points I've seen.
Paul Saving Changes...
Anonymous
I have to completely agree working in the financial industry and automobile manufacturing we didn't use SCRUM. However, in my new environment they went from nothing to one person instituting SCRUM to help bring some order to our current company. The problem with SCRUM and sprint it takes all the power away from the project manager and puts it into the technical resources hands on dictating what tasks they are going to commit to doing this moth. It really doesn't help forecast resource needs in the future or give the ability to the project manager to manage those resources. We want to phase out SCRUM since it was only here for a few years and its not working well.
I'm looking for any information anyone can provide on how to delicate bring out this culture of change and slowly phase out this horrible methodology since our company does very few inhouse software development its the wrong methodology for our organization. Saving Changes...
Shawn BellingChief Technology Officer and Adjunct Faculty| Geno.Me/University of WisconsinFitchburg, Wi, United States
It sounds as though SCRUM was improperly implemented at your current firm. The key item I am concerned with is the phrase "takes all of the power away from the project manager." SCRUM does not empower the technical team at the expense of the PM's "power" nor does it absolve anyone on the team of the accountability to provide the business with resource and schedule planning data. It simply means that a different process and set of tools and thinking is used for this. In any case, sounds like SCRUM is not right for your current situation. As with all change, the place to start to make the case to deprecate SCRUM is with the business reasons why it should go. Emotional arguments won't help this - there need to be sound business reasons. Good luck. Saving Changes...
I don't think of Agile as a methodology. I was surprised that it was mentioned as a SLDC by the IIBA. It's a simple mindset. My quick summary is that People and working solutions are more important than a bunch of useless processes and documentation. This is not to say that processes and documentation aren't important, but to remember what is most important.
I don't see any conflict with documented requirements in Agile and Scrum. Quite frankly, if the customer wants a requirement, the requirement IS a deliverable. I've added requirements as deliverables to sprints that may precede a later development sprint for that same requirement. It's a deliverable that's testable (I hope you're testing your requirements).
There is a nasty perception out there that Agile is a requirementless SLDC. I think folks need to read the Agile Manifesto a bit more carefully before they jump to this conclusion. If a business needs a document to satisfy legal requirements, why is that any different than any other deliverable that the business needs? I think we get the idea that the only deliverables that belong in a sprint are those that the developers can create. In this case we're allowing a process to become more important than the solution.
It's the business that drives the backlog, not the development team. We are focusing on the business needs if we deliver what they are asking for. Saving Changes...
Anonymous
If you're truly using Agile methodology - then why isn't QA involved in the development process? The whole point of Agile is that everyone responsible for deliverables whether it be the product, the documentation, or the quality - is involved in the development process. One group doesn't just complete "their" part and then throw it over the wall to the next group. All aspects of deliverable development are interative and interactive. Saving Changes...
Djalma GomesProgram Manager| Data PineSao Paulo, Sp, Brazil
Dear friend,
The best approach to use depends on many aspects (like users availability, company culture and how stable your requirments are). since quality is a must, you have 3 major variables in a project context: Time, Cost and Budget. You may define up to 2 variables, but the third one should vary. Therefore:
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 through EVM or buffer (if using a critical chain project management approach)
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 “Funccionality Backlog”)
Aligning expectations can be done in both approaches. In an AGILE approach however, you depend on much higher user´s availability to allign scope expectation (if compared to waterfall approaches)
About documentation, you have documentation used ONLY for project purposes and documentation to be used AFTER the project completion (like a trainning material to be used as reference by the users or technical material to be used to maintain the system). The documentation to be used AFTER the project completion should be done despiste the apporach you use (Waterfall or Agile) if you want to have a good IT governance in your company.
However, documentation to be used only for PROJECT purposes depends on the organizational structure you have and should be defined based on your communication needs. For instance, if analysis and programming are done by 2 different parts (analysis is done by your team and programming is done by a vendor located in a software factory), you DO need to have documents to inform what are the requiremements that the vendor should build.
On the other hand, if analysis, design, construction and testing are done by the same person, you have no need for those documents (used only during the project), since you have no information need.
As you can see, using an AGILE approach can be faster (since you have no need for documentation to be used only in the projects), but you loose escalability (you cannot address code to be programmed to outside vendor)
