Agile Project Management: You Cannot Lower the Quality
“The schedule is primarily managed by manipulating scope.”
This article is one of the “IT Interview” series.
In 2005, after a successful implementation of Agile in my project, the two agile coaches (one business coach and one technical coach; these two were real agile coaches, different from fakes one as we often see nowadays) gave a talk to all IT staff in the division on request. I remember the business coach started the presentation with this question:
He asked: “If there is pressure on meeting the deadline, which adjustment (turning the knobs) will you make?”
The audience (most are project managers or business analysts) shouted out the answer, and from my memory, all said, “lowering down the quality”.
The business agile coach paused for a few seconds, making sure no more answers, then said: “No, you shall never lower the quality. If the deadline (date) cannot be moved, you can only reduce the scope, i.e., the feature knob”.
His answer shocked the audience. Remind you, it was in 2005. Frankly, I would be in disbelief if I had not been involved in the project myself, seeing how powerful automated testing was and the benefits of high quality (achieved by executing automated end-to-end tests as regression testing).
Table of Contents:
· Quality = Good Regression Testing in Software
· High Quality = High Efficiency
· Why many software managers do not care about the quality?
· FAQ
· AdviceQuality = Good Regression Testing in Software
Definition of Quality: fitness for purpose
No matter which development methodology, Agile or WaterFall, the software quality is decided by software testing, to verify the implementation feature actually fits what customers want.
The nature of software determines that code is interconnected. In other words, a change in A will affect B, C, … and/or Z. That’s why regression testing is so important.
Regression testing needs to be automated, obviously. However, most software teams conduct regression testing manually. The reason is simple: they don’t know how and a few attempts on test automation all failed (usually fooled by fake automated testers, or worse, an internal senior software engineer overestimated his ability on automated testing)
Besides the obvious benefits of quick regression testing such as finding regression errors early, another important benefit is to programmers dare to do major refactoring. The team could finally clear some big tech debts that severely impacted the team’s productivity and morale. I have witnessed this a number of times.
High Quality = High Efficiency
I did the following experiment in a few of my conference talks (read from a book, can’t remember which one now).
I asked: “Which country’s culture do you think is associated with top quality?”
The audience answered “Japan” or “Germany”. (Americans & Chinese usually say Japan, and Australians usually say Germany)
I asked: “Which country's culture do you think is associated with top efficiency or highest productivity?”
The audience's answer was the same as the first question: either “Japan” or “Germany”.
The “High Quality = High Efficiency” applies to mechanical/electronic engineering, It will be more (a lot more) so to software engineering.
On a personal note, I became a much more productive (100X) programmer after mastering real Test Automation and Continuous Testing, I created (and have been maintaining) several highly claimed software production, in my spare time.
Why many software managers do not care about quality?
Back in the old days, programmers often joked about the poor quality of Oracle and Microsoft’s software, such as “Don’t use Microsoft products unless it hits version 3”. However, managers usually did not mind that, they thought: “releasing early to occupy the market, issues can always be patched later”. I met many software managers with that mindset.
To a typical software manager’s mind, the NO.1 priority is the deadline and the deliverable is code.
Deadline: A boundary line in a prison that prisoners can cross only at the risk of being shot. — YourDictionary
Let me elaborate on that mindset. Testing (including test scripts, and test data) is often the lowest value proposition in SDLC, which is very wrong. If these programmers are doing a good job, coding was well based on the specification, testing might not even be needed. In the Waterfall model, the testing is just a final check, an assurance. That’s why “software testing is also called Quality Assurance”.
With Agile (even doing fakely), there is a lot more testing effort. Software testing becomes more and more the bottleneck of software development. Over the last two years, based on my observation, the number of manual software testers is typically ~1.5 times of software developers.
The solution is, of course, Automated End-to-End regression testing, however, few have real knowledge and experience. That’s why we see many software teams doing Fake End-to-End Test Automation. Sigh!!!
FAQ
1. Manager: “I have to deliver all the features by X Date”.
No, you don’t. Your actual fear is that certain features (not all) won’t be in production, after missing the deployment date. Still, remember the Microsoft Windows Vista disaster? The worse was actually meeting the deadline with badly implemented features!
How to get over the fear and anxiety? What I tell you, I deploy to production every day (if there are changes made), would that change the opinion? The reason I could do that: Automated End-to-End Regression Testing multiple times a day (if there are changes made).
Think about a real-life scenario that we all have experienced. If there is a bus/train that only comes once a day, you will worry about missing that for sure. But if there is one every 10 minutes, your anxiety about this would totally disappear.
Selenium enables ‘releases twice a day’ at Facebook
“Facebook is released twice a day, and keeping up this pace is at the heart of our culture. With this release pace, automated testing with Selenium is crucial to making sure everything works before being released.” — DAMIEN SERENI, Engineering Director at Facebook, at Selenium 2013 conference.
Clearly, Selenium WebDriver (a free, open-source, End-to-End Web Test Library) helped Facebook achieve that. If you are a CIO or a senior manager, shouldn’t you be starting to question: why my principal software engineer, agile coach, and test lead always recommend failed (and often expensive) test automation framework/tools?!
Check out my other articles:
Recommend a Great CI/DevOps Presentation: “Continuous Integration at Facebook”
Why Do Most UI Test Automation Fail?: Wrong choice of automation framework, Wrong test scripting language
Test Automation Camel, a metaphor that explains why most test automation attempts failed?
Benefits of Test Automation and Continuous Testing series: Executives, Managers, Business Analysts, Developers, Testers and Customers.
2. Manager/Software Engineer: “I have to how to do automated End-to-End testing?”.
Learn it. As a matter of fact, engineering means a repeatable and highly-reliable process, isn’t it?
Once, I was rehearsing my presentation in flight for an international conference. The sitting-next passenger saw it (my presentation has a lot of demos, including live ones) and chatted with me. He was an electronic engineer and was also quite familiar with software development. He told me: “In his work, he needs to provide test reports of passing every electronic gate (which I don’t quite understand, or I remembered that term wrongly). That’s the common practice to ensure quality, every engineer does that. However, you are the first software engineer I met who do have a repeatable quality-checking process to verify your work”.
Imagine your software team somehow was sent to build a bridge. The software project manager only cares about made-up velocity charts based on estimated story points; architects spent the most time in meetings; engineers care little about quality (‘it compiled’); there was virtually no repeatable quality control process. Will you dare to drive your family car on the bridge? I doubt that!
Advice
Make this (knob-turning) an interview question for software managers, agile coaches and ScrumMasters. You will be surprised how many candidates do not understand proper software development.
Related reading: