Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
I am writing up a white paper to introduce Agile. As my role is a QA engineer working for a consultancy company.
We want customers to hire us to train them in implementing Agile and we DO want our customers to be aware of various traps when implementing Agile as well as false expectations.
I am thinking of adding some scenarios that show if Agile is not properly implemented, it may backfire on you.
Have you experienced any scenarios where Agile does not improve efficiency or even hurdle coding?
Tl;DR: Yes, it should if you practice technical excellence. Sadly often it doesn't.
The current most popular Agile framework Scrum mainly focuses on process quality and project communication. If you get yourself a project manager transitioning to Scrum Master you will be in trouble, because they have no clue about internal or structural quality and why this is so very important in Agile product life-cycles.
According to Scrum it is up to the team to increase product quality:
During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate.
This sounds pretty good on paper, but Scrum focuses mainly on the process. The technical product quality could become an oversight. Going faster and faster, while making the code worse and worse. Trusting blindly on developers to improve code quality and having the skills for this, fighting quality, or executing quality practices under time pressure is a dream that is just not true.
Therefore other Agile frameworks often mention quality practices. The best known are the rules from ExtremeProgramming: Pair-programming, TDD, Refactoring, etc.
I like how the LESS (Large Scale Scrum) team puts it:
Organizational Agility is constrained by Technical Agility
Most companies starting with Agile forget about the technical part. Therefor practicing technical excellence as described in the Agile manifesto is a must. Your organisation can be o so flexible, but if your product resists change on a code level, was it worth it?
Continuous attention to technical excellence and good design enhances agility.
One of the manifesto signees, namely Robert C. Martin is fighting to improve the code quality skills of developers, with his books Clean Code: A Handbook of Agile Software Craftsmanship, The Clean Coder and Agile Software Development, Principles, Patterns, and Practices. I truly believe it is necessary that an Agile coach teaches the skills described in these books to the development team, but in the real world I only have met a few who do and who really understand the impact of these practises. To often they trust the developers to know, experience shows they don't, even if they think they do.
Be sure to find an Agile teacher, coach, Scrum Master that has been either an ex-Developer, ex-Tester or worked in a team that practiced technical excellence. ex-Project managers are probably the worst candidates, although they might be better at resolving organisational impediments. Which might be the biggest hurdle in getting started with Agile in some bigger companies in the first place. But for small teams starting with Agile, focus on technical quality will benefit them greatly!
Why am I writing this, because I have seen multiple successful products developed non-waterfall at different companies. Where the end result was that the teams came to a grinding halt when it comes to adding new feature to the product. Fixing one thing would mean breaking something else. The nature of the Agile process does not by default deliver a good structural maintainable and extendable product, certainly not Scrum. This is the biggest trap if you ask me.
The second biggest trap is deadlines. Even if the team does all the estimates taking into account good quality practices. Most product managers will commit features to clients. Putting a team under time pressure does not help with delivering high quality code. Still most companies do this even if they are very aware they shouldn't. This is because clients also need to pitch internally to get budget, leading to roadmaps and deadlines. I think we should revisit Agile sales pitches.
I have had a few interesting stories to tell:
There really is no link between 'agile' and code quality.
At the end of the day, you have the same programmers writing the same code.
Scrum or (Lean or Kanban) is to do with how they spilt it up, what order they do it in and reporting progress.
I think what you should write about is the challenge of adding processes which add to code quality. (unit tests, code review, or whatever). into an agile methodology, While maintaining a focus on delivering features to deadlines.
You can big up the difficulty of balancing technical debt vs feature delivery, continual development vs scheduled manually tested releases etc.
The kind of thing that doesnt come in a book, the kind of thing only the hard won experience of your big time consultants can tell you.
we DO want our customers to be aware of various traps when implementing Agile as well as false expectations.
Rather than pitching Agile (noun) as a product, sell best practices and continuous improvement as services that will result in the customer being more agile (adjective). Use business objectives or being more responsive to customers/users needs and issues.
Avoid issues in the first place by using TDD and automated testing. Code quality could be improved with static analysis, peer-review or pair-programming, include those practices as appropriate in the over-all offering, but they are only one aspect of CI, which is only one aspect of being agile.
YAGNI reduces costs by avoiding wasted effort. The BDD promotes a focus on valuable features; Pitch the range of improvements with tangible benefits, notices which interest them and follow up with those.
Let me try and give three examples where the answers might be "No", "Yes" and "Maybe".
NASA - Will the agile discovery be appropriate for planning ahead and writing high quality code with very strict and fixed requirements? Probably No.
Uber - Will constantly iterating over the design and implementing feedback from customers improve code quality? Possibly yes.
Healthcare.gov - will iterating over the design improve code quality given a large number of regulatory requirements and the need to consider data exchange standard from the start. Maybe? Not?
