Getting Green Light
for Technical Agile master class
Do you need approval from your supervisor to join? No worries—we’ve got you covered! Here’s our suggestion for convincing your boss why you and your teammates should be allowed to participate in the Technical Agile master class. We’ve gathered a bulleted list of arguments. Feel free you rewrite them to better suit your company culture or use them as they are.
Looking forward to seeing you at the master class!
Aki, Sami & Sami
Unit tests, testing, coverage:
We do not have a lot of time for testing before any release, and it generates bugs that we have to spend a lot of time fixing. Learning efficient testing methods to incorporate into our coding work would help with this a lot, which would in turn result in our team being faster with new stuff, since there would be less time spent on maintenance.
Our unit testing coverage is lacking, and what we do have, intermittently fail. This means that we cannot trust our tests to tell us the state of our product, and it breaks up concentration, having to manually rerun CI jobs because of flaky tests. I truly believe that this course could help us learn how to write stable, fast and independent test cases, eliminating the intermittent failing problem quickly, and over time fixing our test coverage as well.
Refactoring:
Our teams often bring up "refactoring", and it always gets pushed to a later point in time. It's actually starting to generate some friction, possibly resentment, in our dev teams, because we do not feel heard with how impactful that work would be. This class apparently teaches some refactoring techniques that are applicable in daily work, so it might be a good middle-ground, where we can refactor a bit while also producing new value.
I’ve noticed that a lot of our codebase is very hard to test. This results in development taking a longer time, because developers take a longer time to write tests, or they skip on writing them altogether. After talking with others and taking a look at the codebase, I’d say it’s because of the way our code is structured. This class claims to have some ways to take such a codebase and refactor it into a more easily testable shape, while also improving the overall design of the code. This is something we need to improve in.
We’re losing the chance to do refactoring, because every refactoring task we take, it’ll be weeks before it’s ready, and that’s a long time for a developer not to be producing any new value. It makes our people quite nervous to approve any such tasks in our backlog. It's essential that we can take care of our codebase when needed, and this master class promises to deliver techniques and methods for refactoring and evaluating that work quicker. That benefits us a lot.
Technical Agile as a methodology:
I'm interested in hearing why, with such a focus on testing code, is this Technical Agile methodology so efficient in also pushing new code to production so often. Some of us do not see much benefit in writing tests for the code we write. I feel like learning techniques for efficient and easy testing, and being able to pass them to the rest of our team, would greatly increase our product's dependability in the long term.
We've talked a lot about getting feedback earlier from our business about what we're developing. However, we can't seem to be able to have demos as often as we'd like, and when we do, there's not much to show. One of the key points of technical agile is to enable rapid feedback loops. That would mean more productive demos, people would see what we're building earlier, and getting comments would probably help us and our Product Owners to steer us in the right direction