20
Any tips on how to 'sell' the necessity of dealing with technical debt to nontechnical stakeholders?
You might tackle it by highlighting increases in development costs caused by technical debt. That is a problem we are facing right now, too. Business is requesting more and more features they need when my team really wants to remove technical debt.
We underlined that with less technical debt new features can be shipped way faster- and faster means cheaper. ...
10
You can have a technical leader. You can have him do work off the charts. You can hide this work from others that don't "need to know". You can reduce that person's capacity to make planning more accurate.
But you cannot call that Scrum.
One of the key features of agile (and, by extension, Scrum) is transparency.
Transparency: This means presenting the ...
10
TL;DR
If the work matters, make it visible. If it doesn't, then treat it as muda and trim it as non-essential waste. You truly cannot have it both ways.
No Invisible Work, Ever!™️
CodeGnome's Law of Transparency says "No invisible work, ever!" Any work that is off the books violates that law, as well as generally-accepted agile principles and practices. ...
9
Don't do this.
Speaking as a developer, this sounds great. We get to rewrite that horrible old spaghetti code from scratch! We get to paid to learn a new language! There's a mandate for quality, so we can actually get the time needed to write good code!
...Oh, and there's the fact that this project will take a year or five. Speaking from a business ...
7
One of the best ways to avoid micro-managing is to first realize that by micro managing you are turning yourself into a human bottleneck. Nothing will happen without you, and your productive time will be sucked away doing things and solving problems for others which they should have learned to solve on their own a long while ago.
Once you realize this, the ...
7
Firstly, you could use different methods/frameworks to run projects. Scrum wouldn't necessarily be the solution here as your prime concern is around the line in responsibilities between these two, both different and both required, roles. As well as getting the right level of communication set up.
I have grasped something from the tone of your question that ...
7
Any tips on how to 'sell' the necessity of dealing with technical debt to nontechnical stakeholders?
Take a more proactive approach to dealing with technical debt
In one of my previous projects, we had a major part of a site run on annual data put together by the business. Unfortunatley, the database had been architected in such a way that each year's data will go into a separate database. When it came time to launch the current year's data, it needed a ...
7
Product Owner and the Development Team collaborate
The Scrum Guide is very clear on these aspects:
Product Owner and the Development Team collaborate on Backlog refinement:
Product Backlog refinement is the act of adding detail, estimates, and
order to items in the Product Backlog. This is an ongoing process in
which the Product Owner and the ...
6
Any tips on how to 'sell' the necessity of dealing with technical debt to nontechnical stakeholders?
By analogy, you are asking people to replace a car that works perfectly well because you know that at some point in time the cost to maintain the existing car won't be worth the effort. You need to provide them with thoughtful estimates of when that point in time will be. In other words, the only way to convince them is to come up with a clear, justifiable ...
6
Asking your Product Managers to also perform the Project Management role is probably not the wisest course. There is usually a tension between the two roles. And it is extremely difficult for a single individual to pull off both roles at the same time. Generally, if one person is trying to do both, one of the two sides will get less attention than it should. ...
6
This is a great question! It inspired me to take action and do some research of my own. I interviewed one of my techie colleagues, and I wrote this blog post titled Monday’s interview – Tech Talk with Ciprian. I asked some more questions related to the same issue: "how much tech is too much tech in PM" :). I hope this helps!
Here's a snippet from ...
5
I'm an advocate of not having people reporting into other members of their immediate team. Having a line manager in the room can affect the honesty of things like retrospectives and it avoids some awkward situations (would you want to pair program with someone who just put you/you just put on performance review?).
At my place, we have a lead developers who ...
5
It does not matter. What you are missing is a strong PM capability. You need to designate in a legitimate way the role of PM, give that role the necessary accountability, responsibilities, and authority, put a person in that role who has the requisite knowledge, skills, and abilities to execute, and then press GO.
4
TL;DR
Projects exist within the context of an existing organizational structure, are managed through delegated authority, and should not be run like independent fiefdoms. All of your sub-questions boil down to an organizational failure to properly charter the project and define the project manager's scope of authority (if any).
In addition to the process ...
4
Experience is necessary for capability and competency growth; however, the weight we tend to put on experience, I believe, is grossly overrated. The velocity and degree of capability and competency growth over a period of time practicing an activity can range from decay to something very extreme over a short period of time. So, in the aggregate, when you ...
4
From a technical standpoint, code metrics should be baked into your test-driven development (TDD) or acceptance testing, preferably in an a fully-automated way. However, from a Scrum perspective, the framework is not prescriptive.
The correct framework perspective is that gathering and checking your current code quality metrics should be part of your ...
4
TL;DR You will end up with a product that does not meet your business need, unhappy employees, and self-organising teams that are dead on arrial. Innovation will also suffer.
Impact on Product
Since the PO has responsibility not just for making a domain decision. They are responsable and accountable for the contents of the backlog.
That has to include not ...
4
You don't try to handle everything up front or predict the future. It's a waste of time and effort. As you build out the software and get stakeholder feedback, you will learn more about the true needs of the stakeholders.
I'd recommend looking at the techniques of Agile Data and Agile Modeling. These two sets of practices can help you apply and integrate ...
3
To be blatantly honest, if your project has a non-technical project manager who is not very strong on the business logic or functional aspects of the project and is also involved with other projects, his involvement in the project should be no larger than that of managerial tasks – which is a nicer way of saying – "Getting the crap out of your team’s way and ...
3
I understand that the situation are:
You are a technical lead (TL),
You report to a PM that has no or almost no domain knowledge, technical knowledge.
The PM does not understand you.
"A non-technical PM cannot identify certain dependencies because they have no idea that they exist.": He doesn't have to. I think it is your main responsibility to explain the ...
3
Consideration should be given to the nature and size of the organisation, and the number of projects / initiatives being run. If the team is likely to flex significantly in terms of the people working within it, and if there are several (or many) teams all working on different projects, then it may be necessary to consider the reality of having people moving ...
3
I completely second David (as usual). Having experience MAY increase the likeliness of a professional being a good manager, but it's not mandatory. I believe this "increase" might come pretty much from the past experiences this professional might have been through in the past. Also, it seems you're over evaluating the study degrees... they give you ...
3
Team Leaders and Line Managers are different depending on your organisation structure.
A Line Manager is generally used in a vertical structure with responsibility for direct supervision of line workers, in this case, developers. They duties such as scheduling, training, hiring, firing and writing performance evaluations.
A Team Leader works a lot closer ...
3
As they say in the Washington Post's Worst Week in Washington column, "Congrats - or something..." Set aside the UML, you have more pressing concerns. As is so often the case, your multi-part question can be decomposed into individual questions, many of which have already been addressed on SE.
Project Charter
Stakeholder analysis and management. How do ...
3
Check their CVs and look for experience and other talents that will add value to the team. Also, keep in mind which skill sets are key to your project
Get feedback from previous project managers and tech leads because mastery in technical subjects not always translates to a good team member. Important to check timely delivery and if possible, code quality/...
3
If you're going to base it on code, then why not take code they've written already? That would save the 3 days. ;-)
Assuming your company (like all companies) hires only the best people, the quickest would be to have the team decide. Put them all in a room, outline the project (and skills needed and milestones/deadlines) and tell them you want a team of 3. ...
3
It sounds like there's a whole lot going wrong with your Scrum process.
It's important to realize that a product backlog is not prioritized. It is ordered. There is no reference to a prioritized or priority-ordered Product Backlog anywhere in the Scrum Guide. In the section of the Scrum Guide about a Product Owner, it's implied that individual Product ...
3
My answer would be:
I facilitate technical answers. I trust the team to provide technical answers; I make sure that there is nothing that stands in the way of their understanding the problem and providing the answer.
Sometimes that means making sure that the boundaries of the problem are clear (scope management). Frequently it is my job to facilitate ...
2
The requirements for a project manager always go out from a project profile.
Check DPCI for instance. You can use risk profiles as well.
More technical experience:
Small - you just won't have enough administrative tasks to do, so you better write code with others. You can always back your guys in case sick leaves. And sometimes it's just simpler to fix ...
2
While I have seen projects completed successfully with non-technical PMs, I've also seen a lot of disasters. (That's one of the pushes I had to move from programming to PM.)
One point I have not seen mentioned in the other answers, is the Big Picture aspect of the project.
While we hope we have people we can rely on to give us accurate information (or best-...
Only top voted, non community-wiki answers of a minimum length are eligible
