19

If you reduce a team from 7 to 4, especially if the reason is something outside the team, the best course of action is probably to treat this as a completely new team. People will need to change into new roles, find a new way of working together, cover fresh weaknesses caused by those leaving, find out who is in charge of what, and all the other problems ...


8

Keep in mind that different stories can have different users. If you are building you UI off of your own SDK, it isn't uncommon to have these two use stories: As an SDK user, I would like to be able to grant permissions to a user so that I can manage what different users can do. and As an interface user, I would like to be able to grant permissions ...


8

Everything in your question suggests that you are exploring a new problem, not simply creating something you already know exactly how to build. Because waterfall asks you to create your design completely before you start building it, using waterfall would be inherently problematic. In Agile, and Scrum specifically, the goal of making a product increment and ...


7

I'm a manager of a software development team who was a designer. I started with almost no prior knowledge of writing code, other than simple html and CSS. My initial view was that they are the experts in their field and I am an expert in mine. I am just using my PM expertise to help them become more efficient and better organised, so that their skills can ...


7

While it's not uncommon at all to involve reverse engineering as part of the requirements gathering process, having it be the only step (or, one of the only two steps with the other being 'let the developers guess') is almost certainly doomed to failure. Your responsibility in such a situation is not to be a hero, miraculously learn accounting in a week, ...


5

Remember that very few patterns we consider to be Agile are scientific rules. They are art applied scientifically. So, while Use Stories are supposed to be split vertically offering a complete slice of production-ready code, that is not always the case. Mike Cohn himself has demonstrated a number of case studies from industries that have adapted patterns ...


5

First, I must say that my experience does not match the statement nor am I aware of any study that shows that. When SAFe or "pure" Agile are adopted well, they both have great throughput and quality. When looking at the differences, I'd first look at what makes them hard to adopt well. With SAFe, there are many positions to be filled and it feels a lot ...


5

Validated Learning Agile approaches involve validated learning. Wikipedia defines the steps of validated learning as: Specify a goal Specify a metric that represents the goal Act to achieve the goal Analyze the metric – did you get closer to the goal? Improve and try again This actually maps extremely well to an iterative development model such as Scrum, ...


5

TL;DR While quality can be measured objectively, defining the domain-specific elements of quality for your organization isn’t something where you can rely on a standard dictionary definition. In fact, most of the issues you’ve identified aren’t intriniscally quality issues at all. They seem more like organizational issues. We’ll look at some of them in ...


4

Scrum Master as Coach & Process Referee: Teachable Moments Is it the responsibility of the Scrum master to intervene and interrupt a team member when he/she starts telling about points beyond those 3 that I mentioned? Yes, it is. The Scrum Master is a servant-leader whose primary responsibilities are to act as both a coach and a process referee. The ...


4

Define Your Terms Before you analyze any problem, you need to define your terms. What do you mean by "respect?" What do you believe is your actual role on the team as a "project manager?" What do you think you're "managing?" Validate Your Beliefs Once you've defined all the things you believe, you need to perform some sort of external validation. Do each ...


4

You have no choice but to get the estimates and planning values--and risks thereof--from the vendors you are planning on using. Then you need to load those external commitments into your master schedule and read the resulting overall duration. Better yet, you would have a worst case duration value, best case, and most likely so you can fully understand ...


4

You can adopt agile with any size of team as it is an approach to doing software development. As you mention in your question, one of the key aspects is to favour responding to change over following a plan. It gets a bit more complicated if you are talking about using agile frameworks. The Scrum Guide suggests a minimum team size of 3. This is because with ...


4

Neither Project Manager nor Scrum Master is normally a line-manager function. I don't know who came up with the idea of doing that in the first place, but it seems that mistake has been corrected. So as you are no longer the boss by hierarchy, you need to ask and answer yourself the following question: how does the team profit from my work. How does my work ...


3

Bottomline: go for the approach that'll help you solve the end user needs (features or bugfixes) faster. A task should reflect the issue from end users view. You can do a triage, but I'd avoid rephrasing what the user has complained about. There are three main reasons to stick to user wording: it's a waste of time to rewrite what's already written ...


3

Experiment. No answer presented here will fit your specific product, team or customer. Agile promotes continuous improvement, so go for it. With that in mind, we can review some key items to consider while experimenting: Why changing? Have clear the problems the team is intended to address by applying these changes. Changing for the sake of change "to ...


3

Knowledge Socialisation Sessions. Each project uses a different name for this, but the bottomline is that projects with more than a a handful of people requires a process where people can have a summary of the latest changes or decisions. In our case, I set a bi-weekly meeting where all latest decisions that could impact project performance in the mid to ...


3

I could say something about each of your points, but will address one. If you address this one, then you will figure it all out (eventually). “Software developers started leaving project” Ask why? Ask them why? Ask the people that are remaining why? Hold regular retrospectives, find out why, have the developers find and fix the problems. Give them as much ...


3

TL;DR Level of effort and complexity are much better metrics for estimating work than lines of code (LOC). Furthermore, they can only be effectively estimated by the people who will be doing the actual work. Using proxy metrics that don't map to actual costs is not a good way to plan a project or forecast a budget. Unless your company is actually paid for ...


3

Before Agile was taught in school, people were doing Agile. There just wasn't a single name for it. The start to what we call Agile was in February 2001, when seventeen people met in Utah to talk about the things that they found were working well in software development in a world where there were a lot of projects that were behind schedule, over budget, ...


2

It's important to understand that a change in team dynamic should result in lost productivity, whether that change is a reduction or increase in team size. Requirements, knowledge share, and artifacts of each sprint are dependencies that need to be accounted for when a team change is made. The team should forecast their own sprint based on what they know ...


2

In theory, estimates for support activities are easier to provide for a single reason: historic evidences. Working myself with PROD support for years, I know that some tasks are unpredictable, and that's part of the game. But it's also true that some support activities are similar to already solved issues. The key is to identify these patterns. So, back to ...


2

This seems to be a long-awaited for missing feature in Slack: Read Receipts. In WhatsApp, you would be able to tell who read the messages and who hasn't seen them yet. that would solve your problem at some level. You have various choices, short of using WhatsApp: Keep a list of the non-readers and send them personal reminders Have a shared sheet that ...


2

If this is a single channel where only the final decisions are posted (without the discussions) then that should be fine. There is not much more you can do. As you say it's a software project, you could have a readme file as part of your source where all decisions are put. That way, anybody pulling the latest source would notice it changed. But even then, ...


2

TL;DR Regardless of your role, this is a project management site. I will therefore answer from the project management viewpoint, rather than the (perhaps expected) engineering perspective. Your role as a project manager isn't to justify anything. Your obligation is to raise issues that impact scope, budget, time, or quality in a way that senior management ...


2

First, there is no management theory, Japanese or otherwise, that suggests that you should not give people the tools they need to do their job. And this leads to the real problem with your situation. Yes, you can make a financial argument for the use of IDE's. For the whole JetBrains pack, it would have to save you around 15 - 20 hours per year depending on ...


2

I think that there are many reasons why you should buy the license such as an increase in productivity, it makes your job more enjoyable, it is just the right thing to do! However, most "business people" are interested in money, so, I can suggest you to try to "speak their language". Perhaps you can put together a case of how much time you are saving and ...


2

I would divide it into 4 parts - each one month long, with a milestone at the end of each month: Definitions - ending with a milestone of agreed upon feature spec Create initial sites - ending with a milestone of beta sites Testing beta sites - ending with a milestone of list of fixes for launch Finalizing sites - ending with a milestone of launch live ...


2

Group the requirements up into Epics (or Feature Groups or however you want to call them...) Developers estimate for the individual requirements, and then those are aggregated into the Epics - the Epics are then used to build the schedule.


2

Welcome, Jelle! In my experience, expecting that decisions are read in slack is just ineffective, because they get lost/confusing eventually, especially if it is an update from a previous decision. I think that you could put them in a structured place where everyone can see it when they need to. This place can be either a document, a wiki page, a trello ...


Only top voted, non community-wiki answers of a minimum length are eligible