Mark Layton, President of Platinum Edge, spoke on Agile QA’s Game Changing Impact on Project Management. Platinum Edge does training in Agile development. Mark Layton is a certified Scrum trainer and a PMP and PMI-ACP instructor.
Quick overview of Agile: There is no “Agile methodology,” but rather an Agile umbrella of methodologies. Most people use Scrum, eXtreme Programming, or Lean. This talk focused on Scrum.
Teams work in iterations, generally 1-4 weeks long, to do design, development, testing, and documentation. They deliver small groups of usable functionality on a regular basis. The teams are self-organizing and cross-functional. There is close collaboration with business analysts, and an effort to inspect and adapt.
The key to success is failing. See what works and what doesn’t work and adapt from that.
People don’t know what they want until they see and interact with it. Traditional waterfall makes QA the last stage before deployment and loads risk. Sunk costs are high, bugs are found long after development is complete, and fixes are costly and can jeopardize the release date.
The Agile Revolution: Of the 12 principles of Agile, 8 are about raising quality. Get rid of silos (business, development), and increase face to face communication.
What about remote offices? Cisco Telepresence and tech bridges help remote communication, but time shifts are a challenge to face to face communication.
Working software is the primary measure of success. Keep a sustainable pace. Nothing is more expensive than bugs. Too much overtime introduces bugs. Finding defects quickly and early in QA is the cornerstone to Agile’s power. A lot of things that make for better quality also make for better agility, e.g. automation, coding standards. Agile iterations of 1-4 weeks mean constant feedback. The harsh reality of the marketplace doesn’t wait until the very end.
78% of customers were more satisfied after transition to Agile. Quality is client specific, and it is hard to engage clients, but Agile does.
64% done vs. 64% in progress.
Agile front loads rather than rear loads risk. Project management is spread to those doing the work. Teams can leverage the value of automated tools.
Agile QA Techniques include test-driven development, pair programming and peer reviews, and continuous integration through automated testing.
Test-driven development: Sometimes you find that you pass the test and don’t need to code.
Pair programming: One works tactically and one strategically. Compare shadowing, in which someone is constantly asking questions. In a business school study of survival teams composed of British SAF and people who knew nothing, people who didn’t know how to survive asked the silly questions that helped. So even shadowing, not actual pair programming, improves quality.
Automated testing, daily builds, and automated tests: You can use automated testing for unit testing, system testing, integration testing, regression testing, etc. Automated tests can run overnight and daily, providing robust testing. You can use Cucumber for user acceptance testing.
Static testing: Do you align with the coding standards of the organization? Use best practices in coding. Cowboy coding is not an Agile approach.
Fortune 100 companies’ concern about Agile is cowboy coding; once they explain what Agile isn’t, it is more accepted. The larger and more complicated your project, the more appropriate an Agile approach is. If you put in 10 million hours, you have a 0% chance of avoiding errors.
Raising quality = raising level of confidence = raising being in control.
What they’re going to be able to do next is exactly what we’re doing today.
Waterfall provides very little control, requirements gathering is not the same as testing. Agile is best for risk averse control freaks. In Agile, you fail early and you fail cheaply. The Agile approach eliminates the separation between development and QA, and gets rid of bottlenecks.
Gathering requirements = gathering acceptance criteria.
Agile = contemporary. Waterfall = 1940s approach, applied to object-oriented web programming.
From a project management standpoint: Better estimation, reduced downstream risk in the schedule and cost, increased quality.
The last part of the traditional approach is the hardest. In Agile, the risk is the lowest at the end, because the highest priority features have been developed first.
Microsoft: Myth of managed multitasking. You lose when you context switch, and wind up thrashing.
Agile is needed due to acceleration of product development ant the dynamic nature of the market. The world will be completely different in 6 months.
In Agile we start earlier, and evaluate requirements for the product. We can be continually rebuilding the teams.
“You’re very lucky. You’re very thin.”
“I also cycle 120 miles a week.”
“You’re very lucky.”
You need to use Agile to get the benefits.
You don’t have a massive amount of sunk costs on things happening well into the future, so change is easier. Taking a working product and making a small change is better than a change added to a possibly never working product. It’s the difference of knowing vs. not knowing.
Agile Project Management for Dummies.
The role of project manager doesn’t exist in Scrum. Instead, project managers become either product owners or Scrum masters, depending on their best skills.
Scrum lets you quantify your impact.