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. ...
11
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 ...
11
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
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
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 ...
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
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
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
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
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
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
tl;dr
"Independence" isn't the issue; the issue is accountability and your integrity.
Dispense with the distractions
Independence is a road to project failure. You are interdependent; your success is tightly coupled with that of your project team, and theirs with yours. Any other viewpoint will lead you to disaster. I would argue that none of the ...
2
Refer to senior management only if it is a policy issue
As @CodeGnome pointed out you should not try to run your project as an independent fiefdom.
On the other hand, you should not refer every decision up the chain either.
"In broad terms, delegating up means pushing responsibility and decision-making up one level, with the intent of the employee to ...
2
I am Dana and I work as a project manager in a digital studio. I have 3 years experience in the field, in which I've helped build several web and mobile apps.
Here are my answers, I hope this helps:
What situations have you been in when you've fallen into the trap of becoming a micro-manager?
Especially when working with beginner/medium level designers ...
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-...
2
The project manager should have a good understanding of the technologies involved in the project. Not that they can code, but understand how the pieces fit together from a high level. Leadership and communication are more important qualities.
Depending on the process, there may be procedures built in that help verify task estimates. For example, agile’s ...
2
This is an interesting question, worded well (thanks @CodeGnome for editing) and highly relevant.
Unfortunately the answer is, like many questions regarding ideal practices, a firm "it depends".
It would depend on the
Nature of the Development Team
Existing Practices
Organisation Culture
Exact type of Agile implementation
Individual personalities
...
Only top voted, non community-wiki answers of a minimum length are eligible