33
As a Product Owner or product manager, you shouldn't be too concerned with the details of how the development teams are working on a day-to-day basis. If you believe that certain aspects of the way of working are leading to risks in the ability to build and maintain the product, you should be able to raise those concerns, but you shouldn't attempt to direct ...
12
If a requirement is discovered in the middle of a project or even later, then the cost of implementation of this requirement can be very high.
In this statement you are saying that the cost of change is high (particularly late on in a project).
The agile approach recognises that change happens and so endeavours to reduce the cost of change.
This is the ...
12
Just don't call it agile.
Often the resistance to agile ways of working is associated with the terminology. It is not uncommon for teams to 'hate agile' when in the past they worked in a flawed agile implementation and learned to dislike it. They now associate the terminology with bad things.
As a Product Owner you can't dictate the way the development team ...
7
In order to be cared about, standards must be understood.
You say that
a checklist[...]/checkboxes [are not] ideal
because
On previous teams, the coding standards were like an ethos that was upheld by the Application Development Manager, believed in by the team, and taught to new Devs when onboarded.
What I take from this is that your primary concern is ...
7
It is hard to say anything without more details. You just mention there is a potential problem with the level of specialisation, but you don't make clear whether that is a real problem or whether it is just a concern that you have.
It is also not clear what the typical size of a project/assignment is for the organisation, which can make a dramatic difference ...
6
You say:
If a requirement is discovered in the middle of a project or even later, then the cost of implementation of this requirement can be very high.
This can be true or can be false. It depends of the type of change you are referring to. I'm assuming a big change, or something lacking in an important way, or something that deviates in some way from what ...
6
Prioritisation, continuous delivery and review is the way to control delivery risk for any software development, not just when using Scrum. I can't agree with the first sentence of your question however. If work is ordered wisely then the most important and most risky or expensive work usually comes first, so the cost of unexpected work should tend to reduce ...
5
In my experience the most effective coding standards are those that are driven directly by the developers.
An approach I have seen work well is to have a developer community of practice that discusses coding standards and agrees them by consensus.
By introducing standards in this way the developers have a buy-in to them being successful. If they feel a ...
5
Successful Retrospectives are for Communication and Collaboration
Setting aside the fact that at least some of your agenda items seem like they are intrinsically Scrum anti-patterns (please ask why in a separate-but-linked question if you really want to know), you and the team are approaching the Sprint Retrospective event incorrectly by treating it ...
5
You have said a few things which are legitimate concerns for the development team. Agile teams are supposed to be self-managing but your team apparently is not because developers are having work allocated to them individually. You say that the product team are intervening and apparently your developers don't feel in control. These all seem like symptoms of ...
5
This is a weird test.
You have a fixed time, fixed goal and fixed resources. Nothing there is flexible. There is no decisions to be made here. You are not a project manager, you are a project statistician.
You can make the boards and graphs showing progress, but in the end, it's like a movie. It will play. It will either have a happy end or not. But none of ...
5
This scenario feels Waterfall because of the fixed scope of 8 epics and fixed schedule of 10/21/2021 so I wouldn’t say your feeling is off on that point. However, this is very much reality in many contexts therefore I can see some utility in this as an exercise in laying out a strategy or approach.
With that said, you may start with working backwards from ...
4
Between
Why do you need to track 'Features'?
Never said I did. The problem is historic to this team.
and
Why do devs need to track their time
Primarily because some activities qualify for R & D tax refunds and some don't.
My suggestion would be to reduce everything down to just two 'Features':
R&D Tax Refundable
Non-R&D
It simplifies ...
4
From a sequential perspective, the idea that a requirement that is discovered later in the project is likely to be more expensive to address. Similarly, a defect found late after origination is also likely to be more expensive. This is because of how much work is done. Consider that in efforts run using sequential methods, you try to elicit all of the ...
3
They're pretty much whatever the company defines them as.
To the best of my knowledge, 'Release Manager' and 'Delivery Manager' don't come from any published frameworks, the way 'Scrum Master' comes from the Scrum Guide.
So, the answer to all three of your questions is 'it depends how your company defines them'. There may be common interpretations, but there'...
3
The situation you are describing reminds me of a something Sir Ken Robinson said in a TED talk:
I saw a well-meaning policy statement that said 'College begins in Kindergarten'. No it doesn't, Kindergarten begins in Kindergarten. A friend of mine once said 'A Three-Year old is not half a Six-Year old'.
Seems the company has a vision of increasing their ...
3
As a Product Owner maybe a goal oriented approach could lead to change in behavior.
Example goal Reducing time to market:
To be able to compete with competitor X we aim for a time to market of less than a week. Delivering a couple of end-to-end features in a week might be a real challenge for a group of hero-coders. The group could now self-manage and adopt ...
3
You have two separate problems here.
You are not on the same page as your VP on what 'agile' means.
You think it's the VP's place to decide whether or not a timeline is realistic.
I'll tackle these in reverse order.
Realistic vs. Acceptable Estimates
First, the only one who can decide if an estimate is realistic is the team doing the work. The only one who ...
3
You say you can get audited and that you do some R&D activities too. Does the company you work for need to comply with specific regulations or standards? If yes, that would be the where I would start.
If your auditors or tax people require certain information to be available then try to identify the work that falls in these categories and split them from ...
2
Welcome to the real world - I have seen what you are describing to a higher or lesser degree in all agile or not-so-agile teams I have ever come in contact with.
The thing is - and devs can be awfully short-sighted about this - that with good people, this will just work splendidly. Too splendidly, in fact.
All is well until one of your key persons (and ...
2
In this case, the easiest solution would be to use some linters for the code you produce, be it SQL or something else. See also:
Lint (software)
List of tools for static code analysis
These tools will automate some of the rules, but they only cover syntax. You still need people to agree together on a standard of quality and then stick to it because it's ...
2
An effective way to define product ownership is to use customer journeys.
Each product owner is assigned one or more journey. Examples might be:
Registration journey
Onboarding journey
Subscription journey
Purchasing journey
By thinking in terms of journeys we give the product owner the chance to influence the experience of the customer. For example, a ...
2
As you wrote, it's likely a combination of education and process task.
The coding standard needs to be understood, digested and practiced before it becomes a habit and part of the professional ethos.
I find that Definitions of Done are very useful to educate the teams and get these habits embedded in the normal way of working.
You could add a dedicated ...
2
As you mention, I would question if any specialization is really necessary. Every situation is different, but in most cases, a product being maintained by less than 10 people probably isn't so diverse that you need teams that specialize in one part of it or another. Ideally, they would all be able to pull whatever work is most important.
2
Based on the context you have shared, I agree that having separate teams for B2C and B2B might not be the most effective configuration. On the other hand, I would also not recommend "feature-agnostic" teams, as you put it, because they'd effectively function like project teams, and that's now recognized as bad for knowledge retention, architectural ...
1
TLDR: B2B/B2C split won't work for you. You'll need to work closely with the other PO.
So, let me just see if I've grasped the situation correctly:
Your company has both B2B and B2C business.
The B2B and B2C are not always anywhere approaching balanced
Your department has 10 developers and 2 Product Owners (and 0 QA?).
Someone (upper management? the team?) ...
1
Here's what I would do next: "take your concerns back to them." Alert them to the fact that you perceive that the standards are not being "properly" adhered to, and "ask them why." Listen very carefully to what they say.
The technical issues and concerns, particularly with SQL, have already been brought forward in this thread ...
1
In the last sprint, there were some standards that were missed by the
Developer, and also missed by the Reviewer.
Why it was missed? Was it due to lack of time or lack of intention?
If it is due to lack of time, then when you plan next sprint, the development team should keep aside estimates to make sure they check that the code they develop is adhering to ...
1
By all means, the very first thing that I would do is to "talk to them." They are developers with a not-insignificant amount of experience working with the very thing that you are now going to be managing. If they are objecting, why are they objecting, and exactly what are they actually objecting to?
Using a minimum of "Agile terminology,&...
1
Beware of falling into the "We are doing Agile and we are doing Scrum" trap! Far too many people think that rigidly following a set of procedures is (1) the only allowable form and (2) means they are achieving the intent and goal of Agile. I recommend reading all of "Joel on Software" end-to-end, and also thecodelesscode .
Now, ...
Only top voted, non community-wiki answers of a minimum length are eligible
