12

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?

  • 4
    "Fast, good, cheap: pick any two". – alephzero Mar 4 '17 at 12:43
  • 4
    Voting to leave this question open. Although answers may contain strong opinions, the question asks for scenarios from experience. Experience here is not an opinion, they are facts that happened in real life. Like most questions with Agile and testing you can answer it with "it depends" which lead to interesting answers. – Niels van Reijmersdal Mar 4 '17 at 13:01
  • "Will implementing Agile generally improve code quality?" - No. Agile has nothing to do with code quality. I see some companies using Agile that have high quality and some with poor quality. I see some companies using other methodologies that have high quality and some with poor quality. – Joe Strazzere Mar 5 '17 at 18:26
13

Tl;DR: Yes, it should if you practise 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 as Scrum focusses 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 practises under time pressure is a dream that is just not true.

Therefor other Agile frameworks often mention quality practises. 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 practising 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.

http://agilemanifesto.org/principles.html

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 in 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 practises. 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.

  • 2
    I was going to write an answer myself but you already said everything I would have and more. Agile by itself won't increase code quality, and can possibly make it worse because of its short turn-around time! Unit tests and TDD/BDD are needed as well, although this is no guarantee either. Another good book to read is Working Effectively with Legacy Code by Michael Feathers. It describes how to gradually change terrible code into better code but the whole team must do it for it to work. – CJ Dennis Mar 4 '17 at 12:51
  • The best comparison I've ever seen was to dieting. If you lower your caloric intake and increase exercise, you absolutely will lose weight. But if you take the time to measure your calories and don't actually lower intake, or if you don't exercise, you won't lose weight. You might feel better because you can say you're on a diet, but you won't get results. So if you have a scrum three times a week but don't do retrospectives or you let things creep into a sprint or you use your scrum time as a way to single out poor performers instead of identifying roadblocks, you're gonna have a bad time. – corsiKa Mar 4 '17 at 18:29
4

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.

  • 2
    The Agile manifesto links code quality in one of the 12 principles, namely this one: "Continuous attention to technical excellence and good design enhances agility.", most Agile frameworks define what this means. – Niels van Reijmersdal Mar 4 '17 at 11:34
  • 1
    Your opening line is a bold statement. Do you have a citation for the claim? – corsiKa Mar 4 '17 at 21:40
  • dl.acm.org/citation.cfm?id=2635922 this study shows the dominant factors are team size and static typing – Ewan Mar 4 '17 at 21:52
  • 1
    Shame the article is not free, but the abstract states it is about "What is the effect of programming languages on software quality?" and not "What is the effect of (Agile) process on software quality?". I think the results would be significantly different. Static typing for example seems irrelevant. Team size will have effect ofcourse. – Niels van Reijmersdal Mar 6 '17 at 16:16
  • well. what we can derive from the study result is that the effect of methodology on code quality is insignificant when compared to use of strongly typed languages. If the converse were true you would not see the link to typing without factoring out methodology – Ewan Mar 6 '17 at 16:20
4

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 that will result in being agile (adjective), in a business objectives or being more responsive to customers/users needs and issues. Avoid issues in the first place with TDD and automated testing. Code quality could be improved with static analysis, peer-review or pair-programming, so include those 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.

3

I have had a few interesting stories to tell:

  • For a company I was working for, the team leader (also the scrum master) would ask for an extremely detailed report during a morning standup. Our stand-up normally took 1 hour to complete. When it was my turn, I would normally give a very brief description of what I have done, what I am planning to do. The whole point of having a morning stand-up is not to learn every single detail of others' work; most people would lose attention when a one-sided conversation drags on too long, especially when you are not interested (let us be honest, who wants to know all the details of others' work, every day?). In conclusion, having a morning stand-up is to have a short session that everyone is aware of the big picture, it needs to be short and succinct. IMO, having a long morning stand-up really defeats its purpose.
  • A robotic scrum master. There was a dedicated scrum master that was hosting morning stand-ups. This guy got a nickname "robotic scrum master" soon after he joined us as all he did was saying "OK, now it is your turn to talk." Whenever a decision was to be made, he would say "I am only the scrum master, it is not my job." In conclusion, if we take roles out of an Agile textbook and strictly role-play them as they are described in a book, it will not work so well either.
  • A company I was working for had a kickback culture, people were nice to each other; but it would cost this company a lot. During retrospective, problems were identified, but no action was taken to correct or prevent them in the future.
1

I believe it will depend because the definition of quality comes from the business

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?

  • There are three types of quality: process, structural and functional. The quality that comes from the business are process and functional, but the question is about code quality which is structural quality. Which should be defined by the development team and not the business if you ask me. davidchappell.com/writing/white_papers/… – Niels van Reijmersdal Mar 4 '17 at 17:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.