TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: Relating PMBOK Practices to Agile Practices--Part 4 of 4


Viewing Item 1 of 473


A StickyMinds.com Original
Article Picture
Relating PMBOK Practices to Agile Practices--Part 4 of 4

By Michele Sliger

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: The Project Management Body of Knowledge (PMBOK) outlines the specific actions required for proper quality management as quality planning, quality assurance, and quality control. In this last installment of Michele Sliger's four-part column series, she looks at the quality management process and determines how compliance with the PMBOK practices correspond to activities that an agile team might perform.


Seapine
Ah, quality--always the last phase in traditional plan-driven projects! So I've left defect detection and prevention as the last topics covered in this article series. Used to being the caboose on the train, QA staff have come to expect shortened time frames for testing, specs that don't match the product delivered, and little interest in their input until the last few weeks of the project. As one of my colleagues used to say, "Well, we must be done testing because today is the release date!"

In a change that pleasantly surprises most quality personnel, agile software development brings QA back into the analysis and design of the product, keeping QA heavily involved in decision making throughout the entire lifecycle. Because incremental code is being developed each iteration, QA is now testing at the very beginning of the project lifecycle instead of waiting for something to be "thrown over the wall" at the end. And because throughput is increased as a result of agile's iterative and incremental development, QA finds itself with a need to become more technical as it must automate testing at all levels, not simply via macros run on the GUI.

Quality Planning
Typically, quality planning includes defining how to perform quality assurance and quality control activities as they relate to standard QA practices, organization policies, and procedures. Agile QA team members should still address this need and work with the project team to determine what tools and technology they will use in writing, running, and reporting tests and results, as well as what metrics will be tracked in each iteration. It is important to engage developers in this definition, as they will be contributing to testing by writing unit tests and helping with the framework for automating regression and acceptance testing. Product owners also must be involved, helping to define and run the acceptance tests. In agile methodologies, everyone contributes to defining, maintaining, reviewing, and enhancing the quality of the product and the process.

Quality Assurance
Quality assurance, with its focus on preventing defects, is translated into the agile practice of having committed QA resources on the development team that participate in daily decision making throughout the lifecycle of the project. Their input during elaboration and design helps developers write better code. As a result, more "what if" scenarios are considered and planned for, as the collaboration between coders and testers gives the coders more insight than if they were to plan the work on their own. Likewise, the testers gain added insight into the expected functionality from the coders and the product owner, and they are able to write more effective test cases for the product.

Another aspect of quality assurance is the idea of continuous improvement, which the agile principles of constant feedback and responding to change support. Stopping points meant for inspection and adaptation are built into all agile methodologies. Continuous improvement is practiced in planning meetings, daily activities, and iteration reviews and retrospectives. A recognized exercise in the iteration retrospective is determining what went well in the iteration, what did not go well, and what changes the team wishes to make in the next iteration.

Quality Control
Quality control places its emphasis on finding defects that have already slipped into the system and working with developers to eliminate those defects. This bug checking is done within the iteration, using techniques such as daily builds and smoke tests, automated regression testing, unit testing, functional and exploratory testing, and acceptance testing. Everyone participates; no one is exempt from the task of ensuring that the coded feature meets the customer's expectations. The goal is to find and fix all the bugs in order to have the feature accepted by the product owner by the end of the iteration.

In some of the more extreme agile methodologies, quality drives the entire software development process in something called "test-driven development" (TDD). (For more on test-driven development, check out the FAQs on http://www.testdriven.com/modules/news.) In this approach, tests are written and automated first, before the functional code is written. As stated in one of the FAQ responses at Testdriven.com’s Web site, "Write a small test, write enough code to make the test succeed, clean up the code. Repeat."

Whether you choose to embrace typical agile activities or something more extreme, quality is guaranteed to improve when implemented in the spirit of the Agile Manifesto and its guiding principles. And as this last article in the series draws to a close, I hope that you've seen how agile practices are in sync with most, if not all, of the tenets outlined in the Project Management Body of Knowledge. I invite you now to learn more about agile by visiting the following sites and to look for more of my articles next year on how to make the transition to agile.

Further Reading
www.agilemanifesto.org
www.agilealliance.com
www.apln.org


Click Here to Read Relating PMBOK Practices to Agile Practices Part 1 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 2 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 3 of 4


About the Author
Michele Sliger has worked in software development for over fifteen years. She currently works as an agile coach for Rally Software Development, where she trains software development teams in agile methodologies. Sliger has served as a project manager at Qwest Communications, a consultant for Fortune 500 companies, and was a founding member of the engineering teams at two biotech start-ups. She is a certified Project Management Professional (PMP) and a certified Scrum Master. In addition to her service at Rally, Sliger is also an adjunct faculty member of the University of Colorado, where she teaches software project management to graduate engineering students.

Back to Top
 

StickyMinds.com Weekly Column From 11/6/2006 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Sanjay Srinivas 11/6/2006

I agree that QA in Agile tests at the beginning and with Unit Tests it is "End to End" quality. However I have observed that after the first few iterations or releases, the QA is always playing catch up, because Developers do not like to own any part of functional testing. Secondly the number of testers to developers is often low so the QA starts getting multiple priorities.

Is this something that's seen by everyone or is it just my team ?

Author's Response:
11/8/2006    
I see this quite a bit. If this is allowed to continue, you end up right back at the waterfall, with testing being done late/last. Agile is a team commitment, and that means that everyone chips in to help produce an increment of working (tested) code each iteration. Even if the developers don't like to help with testing, the problem would go away sooner if they did work to help the testers build the framework for automated testing and get the existing regression suite automated.

 
 
Comment:    
by Wayne Mack 11/6/2006

I find that one of the stumbling blocks hindering acceptance of agile development by many people is due to the formal definition of a "project." PMI defines a project as having fixed scope and schedule. For software development efforts, I feel a better definition is that of a program.







Software development efforts are usually ongoing things. The...Read On

 
 
Comment:    
by Bill Rinko-Gay 11/6/2006

In the book "Agile Project Management", Highsmith points out that many traditional projects are starting to use Agile methodologies. In fact, IIRC much of what we now have as Agile methodologies comes from Toyota. Traditional manufacturing projects can implement agile by using software modeling to replace building prototypes which drastically reduces cycle-time and allows the fast-fail paradigm without wasting materials.



I believe Boeing used many of these concepts in the development of the...Read On

Author's Response:
11/8/2006    
That's right, Bill. Another great book that directly addresses this is Mary and Tom Poppendieck's "Lean Software Development," and their new book "Implementing Lean Software Development."

 
 
Comment:    
by suba bse 11/3/2006

It's encouraging to see these days a search for a common ground between PMBOK practices (or CMMI, for that matter) and agile.

However, from whatever little I know about these all, agile is a paradigm change in software development, particularly in industrialized software dev.

PMBOK, when developed, was intended to be generic to all kinds of projects, not only for IT. On the otherhand, agile is very software specific. I find it hard to imagine how building a bridge can be agile. Thus,...Read On

Author's Response:
11/3/2006    
The PMBOK does not specify the type of methodology to be used, but I do agree that many people associate it with waterfall and plan-driven projects. The PMBOK actually states that “there is no single best way to define a project life cycle” and indeed, “The project manager in collaboration with the project team is always responsible for determining what processes are appropriate, and the appropriate degree of rigor for each process, for any given project.” I believe that this is part of that common ground that both Agile and PMI can stand firm on. And I think it's important to remind folks of that common ground as Agile continues its expansion into more and more large organizations.



I’ve found that the basic intent of many of the PMBOK’s best practices can be mapped to agile practices, which is what I’ve tried to do in this series of articles. For me, it doesn’t feel like a round peg into a square hole – more like learning a new language and culture. I try to help other PMPs make this change by sharing some of the translation that I went through as I made the transition to Agile. And yes, this is a paradigm shift, and I think it’s one well worth making!



 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2009 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


Seapine





ADP2009