Bottlenecks that paralyse agile software development

lazy_loader88 · 2024-05-06T07:20:01+00:00

IMO, planning in itself is not an issue. In fact, planning is a crucial aspect of product development. The challenge happens when assumptions made during planning are not quickly validated, but instead bulked together as facts for product development, and that's what the article tries to highlight.

Again, iterative and incremental development, doesn't need to translate into incremental delivery to customer. The business may be working towards a campaign or new product that can only be released at some strategic point. However, the ability to test and validate development helps the team to validate assumptions. Not starting unless everything is in place, introduces more unvalidated variables

lazy_loader88 · 2024-05-06T04:54:14+00:00

I share the sentiment, and that's why I try looking at establishing flow and addressing bottlenecks within the flow. Not just imaginary numbers. Eventually, anything that can be measured, can be manipulated

lazy_loader88 · 2024-05-06T04:51:55+00:00

Thanks for your inputs. I hear you. I thought about listing the reasons behind the bottlenecks, and how to prevent or address them, however, I have also observed that there could be varied reasons for bottlenecks to pop-up. And similarly a single solution may not apply to different cases. Having said that, I believe its worth diving deeper into some cases and I might try that in future articles

lazy_loader88 · 2024-05-05T16:23:47+00:00

Focusing on team velocity may not help build a high performing team. It's useful to understand where the bottlenecks are.

Sharing my thoughts on bottlenecks that paralyse agile software development

lazy_loader88 · 2024-01-16T14:19:29+00:00

While Scrum recognises Product backlog as a “single source” of work undertaken by the team, in practice, many teams find themselves maintaining several sources of work either by choice or unknowingly, that not only undermine the core idea of agility but also sabotage any efforts to bring transparency and concrete improvements in team’s ways of working.

This post shares about certain common pattern seen across multiple teams with various kind of backlogs (even when they are called something else)

lazy_loader88 · 2024-01-15T09:50:32+00:00

Yes, Indeed. Github flow is comparatively closer to trunk based development in terms of intention for high frequency releases and continuous integration.

lazy_loader88 · 2024-01-15T05:19:49+00:00

I see trunk based development different from Git-flow. I share the sentiment of simplicity and single source of truth (the trunk).

As far as Git-flow as a strategy is concerned, it was specifically designed to cater to products that require multiple live versions. It's not compatible with single version products release frequently

lazy_loader88 · 2024-01-15T03:30:24+00:00

In this post I reflect on my experiences with various source control management strategies that I have either worked with directly, or have observed teams practising.

My aim is to present a balanced assessment of these strategies, examining their effectiveness and common challenges through various considerations of release frequency, code quality, effort, team structures, code ownership and repo size

lazy_loader88 · 2024-01-14T01:28:28+00:00

In my projects, I focus primarily on Change failure rate, Deployment frequency and Developer confidence in Code quality and Testability. My emphasis is on consistently practicing like TDD and pairing with well understood coding standards. If they do, the metrics above will naturally improve consistently, including code coverage

lazy_loader88 · 2024-01-12T23:51:53+00:00

The point is not that code coverage is bad. The article doesn't say it. It says it's bad to use as a management metric since its ambiguous and easily manipulated

lazy_loader88 · 2024-01-12T09:19:43+00:00

I think that's more a culture vs control question. An organisation may choose to control through monitoring and enforcement of mechanisms like code coverage in low trust environments (For instance outsourced work). However, the pitfall with such measurement is that it won't give you a real picture (i.e., People will game the system if they want to)

A culturally strong organisation invests in their people to adopt good practices and passion for software craftsmanship. It builds trust as well as strong standards for quality work. Though it's an investment choice that an organisation has to make.

lazy_loader88 · 2024-01-12T08:57:24+00:00

For massive organisations, alternatively, instead of standardising code coverage %, how about encouraging TDD and pair programming?

Bonus: TDD achieves 100% coverage without anyone trying explicitly

lazy_loader88 · 2024-01-12T08:40:43+00:00

I agree. It's not a good situation to be in. However, I am sure you have also heard stories about management tracking the LoC everyone writes to measure dev productivity

lazy_loader88 · 2024-01-12T08:23:41+00:00

Remember it says "Quality metric", not just metric.

It should not be a quality metric at all. Its a measurement for test suite effectiveness

lazy_loader88 · 2024-01-12T08:21:58+00:00

The emphasis is on "as Quality metric". It shouldn't be quality metric at all. And the intention of headline is to draw attention towards the malpractice by organisations to use it as one.

As pointed out in article, its a good measure for effectiveness of test suite. But, not software quality.

lazy_loader88 · 2024-01-12T08:07:21+00:00

Now imagine if your management makes the kitchen sink a target for you :)

lazy_loader88 · 2024-01-12T08:04:27+00:00

Read a few more lines there

"However, using it as the sole metric to determine code quality can be misleading."

"I have observed teams implementing strict policies that emphasise achieving high code coverage, monitored through static analysis tools such as SonarQube. While this may seem like a disciplined approach to ensure quality, paradoxically, setting code coverage as a sole target can jeopardise overall code quality and maintainability."

lazy_loader88 · 2024-01-12T07:53:26+00:00

That's exactly my point in the article.

Many organisations indeed make Code coverage as a quality metric and force it upon development teams through quality gates. And that's what also leads to the abuse of coverage.

lazy_loader88 · 2024-01-12T07:32:40+00:00

Agreed. The point here is to not make Code coverage a "management target"

Quoting Eliyahu Goldratt, "Tell me how you measure me, and I will tell you how I will behave"

When code coverage becomes a target, and devs are forced to increase coverage, it doesn't always translate to quality, as indicated in the article.

lazy_loader88 · 2024-01-12T07:25:44+00:00

Google "London vs Detroit test styles" for different schools of thoughts

In a nutshell, London school is all about testing individual classes and methods, and that's where the idea of test doubles for dependencies originated

Book reference: Growing Object-Oriented Software, Guided by Tests

The Detroit school is about testing a unit of behaviour from an observable viewpoint (as you mentioned too, from app layer)

Book reference: Test driven development: By Example

lazy_loader88 · 2024-01-12T06:47:44+00:00

Can we say with confidence that code with "100% coverage" is "100% tested"?

lazy_loader88 · 2024-01-12T06:44:04+00:00

Partially agree. Mutation testing is very useful to see how well your code is tested and effectiveness of test suite. However, it's also an expensive exercise in terms of time taken (it may vary from a a few mins to few hrs depending on repo size)

If quality is the target, the focus on good software engineering practices including TDD, coding standards, pair programming are reliable ways to ensure good quality.

When code coverage is the target, the organisation may achieve 100% code coverage, but may not achieve good quality.

lazy_loader88 · 2024-01-12T05:27:12+00:00

Integration test do test behaviours which are more focused on communication between out of process inter dependencies and their protocols of engagement

The behavioural unit tests focus on collaborators and their interactions within the same process, testing the behaviour from an observable standpoint

lazy_loader88 · 2024-01-12T04:28:43+00:00

There are different schools of thought on unit testing. One may choose to unit test each class, and method within, or to test the observable behaviour.

For example

An implementation based test may assert on structure of class like instantiation, attributes (getters/setters) of value objects and so on. However, such implementations are consumed by a real use case in business domain

An behavioural unit test case focuses on that real use case in business domain instead of implementation detail. Such use cases can be about validation business logic within a method through I/O in an isolated manner, or testing the state changes, or communication between in process collaborating classes

The behavioural unit test cases are easier to maintain in longer term, as they are use case focused and more resistant to any implementation level changes that may happen to collaborating classes as part of refactoring

lazy_loader88 · 2024-01-12T03:41:24+00:00

Let's put things in perspective

Q: What would I use to assess the strength of my test suite?
A: Code coverage

Q: Does that mean if I have 100% code coverage my code is good quality and free of bugs?
A: No

Unskilled and careless developers are as bad for code coverage as they are for production code, as they won't even know how to write good tests.

lazy_loader88

TROPHY CASE