It baffles me how easy some people are to dismiss techniques and perspectives that are advocated by developers as "something for developers" and thus not for business or product management:
These are all concepts meant to improve delivering the right product and delivering the product right. Thinking it's merely developers doing their thing outside the realm or concern of product management is so detrimental to both.
@kerfuffle Most modern product management advice has rapid prototyping, experimentation and all that stuff. So it's very much agile, but since it operates at different speeds than development, it's not called 'scrum'. But the wheels totally should interlock somewhere, and I think most PMs understand this.
@heinragas What brought this post on was the umpteenth product manager I come across, this time on LinkedIn, who dismissed these things as "for the devs" / "a tech thing".
This whole movement of breaking down dev & ops silos, embracing change and fighting waterfall big up front design is a thing that exists in a realm where product management does its business.
I think "the wheels should interlock somewhere" is a nice way of putting it - though do wheels interlock, or should that be cogs? ( :
@kerfuffle Bah. Product Management exists to maximise the effectiveness of development. Not sure why this person thought it was smart to showcase their ignorance in that way.
I guess cogs are indeed the things that interlock, but there must be some kind of transmission in between, because they move at varying speed differentials.
@kerfuffle though, devil's advocate, I don't want "the business" or "project management" telling me how to do my job. I'll work TDD because that's how I work. Management has no say over how I work or what tools I use. They don't have a say in whether I use an RCS or what IDE or she'll I'm using either. So why would it be up to them to say I can do TDD?
The others, DDD, agile, scrum do need cooperation because they are a way to cooperate. But TDD?
@alan@berkes I definitely think they have a say for the sake of continuity, homogenous skill pool, training cost and material requirements, but "tell me how to do my job" has the ring of top-down authoritarian management to it, which is a much bigger problem that I'd probably address with Stop Drop and Run ( ;
@berkes Test Driven Development starts with "what should it do when it works". Somewhere along the way it got turned into "developers start with writing unit tests for pieces of code", but the underlying principle is much more an aspect of shift left, which simply means to anticipate all concerns - including business. My point wasn't about management telling a dev how to do their job, but about them dismissing concerns as dev-only when it concerns them as well.
@kerfuffle certainly. A part of TDD will require buy in and effort from other stakeholders. Indeed to "define the outcome that allows us to check this is 'done'". Especially when TDD is what some call BDD, where we test outside in.
But there will always be modules, classes, functions, boundaries, that have hardly impact on "the higher ups", for which I'll always write tests, rather than clumsily and manually testing their workings by clicking around.
Add comment