Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
21

When taking over a troubled project, one of the very first things you need to do is to slow or stop the train. If you let it continue to move, you will most likely continue on the same path and unable to introduce any meaningful intervention. You need to get the sponsor at the table to redefine the project as if it is a new project. This means the ...


9

Change Control Isn't an Agile Scoping Tool If he/she wishes to change the scope by adding in/taking out/re-prioritizing the Backlog the PO must submit a Formal Change Request/IOCA before taking an approved Change to the Scrum Master for Planning consideration. This is the antithesis of agility. While Scrum works just fine in environments that require ...


9

Retrospectives are a meeting for the Scrum Team and are internally focused. Sharing information from a retrospective with a wider audience has to be done very carefully. A couple of reasons for this are: People will tend to speak less freely if they know information is going to be shared outside of the retrospective meeting People outside of the Scrum Team ...


9

As Barnaby Golden has stated, it is not a good idea to share the content of a retro. It is very important for teams to know that the retro is a "safe place". What happens there, stays there - unless the team wants you to volunteer information about. But I wouldn't push them. Also note that not all teams are talking about impediments during their retros. Most ...


8

After I have received some of them, I have found out that the sponsor wants more than what we have been programming for. How do I handle a situation like this? Part of what you need to do is triage the project: what can be finished, what can be finished only by scaling back and what cannot be finished in the time allowed (and needs to be dropped in "this ...


8

Agile Manifesto says that you should value Responding to Change over Following a Plan, however it doesn't mean that you should include every Change Request demanded by Client ASAP. Look at Scrum - you have Iterations and when you decide upon stories that would be acomplished during the Iteration the scope is frozen and you can prioritize tasks for the next ...


8

When projects and project managers are out of sync, this is an issue at the organizational level. The organization needs to resolve this problem if it chooses to advance in its project management maturity level. That said, it is quite common. Usually, you see this question from the PM point of view, who is trying to ensure its matrixed resources are ...


7

While not being a trained expert on the Agile ways, I would try to not bother the customer with uncertainty in the way of "you might not get what you asked for", but rather give him certainty that something (and be it just confirmation of the viability of a solution) can be done. I think agile methodologies can help here. Take Scrum. Your team should commit ...


7

The problem with using crisis as a change management tool is that people only focus on the crisis, and not the change. So whatever changes are made to deal with the crisis most likely won't hold over time. The team will regress to the old pattern once the crisis is gone. Real (sustained) change comes from addressing the root cause of the problem, not simply ...


7

You should not reopen an old story. You should create a new one and if it is in any way connected to the old one, you could put a link to the old one in the new one. New requirements are completely new work and add new value to the Product, so definitely go with the new Story.


6

Issue Log & Risk Registry. (hat tip to @David Espina, without whose answer I would have missed this). You're responsible for your project(s). Anything that you can solve relative to those projects, you're obliged to solve. These are examples of things you cannot solve, because they are artifacts of dysfunctional organizational process assets. Things ...


6

The following is pulled from a few different sources (including my own experience as a solo freelancer with multiple clients); however, you mentioned Agile and Scrum - so my terminology will be similar. Shorter development efforts, with extended silence: What I found worked for me was to have, essentially, a one week sprint. On Monday, you meet the ...


5

Yes, you do because otherwise nobody will be able to track the changes of the system, and know how your system is supposed to work. Make sure that you mark the change section in the history of the document.


5

A common issue. There are a few approaches, but this is the one I use: Each change, or set of changes is captured in a new Change Request document. The CR document must capture the new requirements in as much detail as is required to a) approve them b) perform the functional requirements analysis c) do a reasonable estimate of the effort required to deploy ...


5

From Agile Manifesto - "Responding to change" over sticking to a plan. It is a good practice to respond to a change so that your product/project evolve in right direction. It will lead to client's satisfaction. But there are some precautions you can take. 1. Please start writing the requirements in the form of Stories (As a user<>.. etc) and also with ...


5

I am assuming that this question is describing a "change" that is implemented bypassing a controlled change process. If true, then I would agree there is no such thing as a small, quick change. The issues of adopting the alternate point of view are many: Many small, quick changes equal a few large slow changes. The lengthy negotiations of what constitutes ...


4

Do not manufacture crises. This will backfire on you as badly as in the parable of The Boy Who Cried Wolf. I've worked for bosses who thought that their workers performed better under a crisis than when one planned ahead. Some of these are bosses who cannot distinguish between "urgent" and "important". To them, quadrants 2 and 3 don't exist (quadrant 3 is ...


4

A sense of urgency is one of the nine or 10 critical success factors to a successful change. It is aligned with a compelling reason to change, i.e, they go hand in hand. To use the words, 'create a sense of urgency or crisis,' is odd to me, however. That implies an almost artificial scenario, smoke and mirrors through which your targeted group under ...


4

It depends. If it's a change that affects the requirements, then yes, the document needs to be updated and versioned. But there are changes that don't affect the requirements. In that case, it might mean that the document has a hole and it should be added. Or it might mean that the change really doesn't affect the requirements and the document is fine. ...


4

TL;DR You are missing processes, not tools. Specifically, you are missing a formal change-management process that handles your bugs, content updates, and other important tasks in a controlled fashion. Change Management At a basic level, change management can be thought of as a process for identifying, controlling, and tracking changes within a system. ...


4

Let them be emotional. You do risk losing your client because there are many in this game that give away stuff all the time but there are a ton of downstream threats caused by that that negatively impact both the client and the ones giving free stuff away. That said, if they find your work valuable, then likely it's just a tantrum to try to get their way....


4

My first step would be to ask how you are doing Kanban? Kanban is the go-to tool for rapidly changing requirements. The basic principle of "Have a board, have a WIP, prioritize daily", is incredibly simple. However, Kanban is really hard to do well. It's why I almost always start new teams with Scrum first, just so they can start to get the fundamentals of ...


4

I think the simple statement of your problem is that to plan you need to at least be able to count the number of things you need to do. However you have no base number right now besides the 800K & 50%. I also think you may be trying to apply project management to what sounds like process management. Maybe it's a little of both. I'm guessing. If you ...


4

TL;DR You have both a political problem and a process problem. There is no silver bullet, and you can't fix these problems solely within the team. Instead, you must rely on the agile concepts of transparency and visibility to ensure that the costs associated with bypassing the process are charged to the project budget. Make Costs Visible In agile ...


4

I agree with Todd about it being a political and process problem. I want to add that apart from showing them the impact on morale and quality -which I believe that they are quite important for your team- I would recommend having a discussion with them to understand why they believe it is useful to have this way of working and also prepare for them a "...


4

There are two views that may be helpful here. The first is that it is much easier to create change in a place where it is wanted than to try to force it. When I coach I rarely try to coach a team who isn't ready for it. Now, let's say you don't have a choice. There are a number of models for resistance to change you can look at. I personally like ...


3

TL; DR The Sprint Goal must not be changed during an iteration. Changes that would prevent the Scrum Team from reaching the Sprint Goal must terminate the sprint. The rest is just an accounting exercise that helps the organization understand the cost to the project for scope changes made mid-iteration. When Scope Changes Mid-Sprint Scope changes really ...


3

Strictly speaking, the PO shouldn't be changing stories in the current sprint. For Scrum, best practice would be to abandon the entire sprint and start over with a new sprint planning session, new burndown etc. Other stories currently in progress can still be brought into the new sprint of course. As for timesheets - you should probably ask whoever ...


3

Defects are signals. Something is going on, which needs to be changed. Most probably you have some quality issues, and it is urgent to handle them as soon as possible. On the other hand, I suggest to talk to the Product Owner. She should be able to prioritise the user stories and bugs (you can handle bugs as user stories, but they don't hold any value). ...


3

I used to use a commuting analogy. You know it normally takes between about 40/45 minutes to get to work, so there's a basic level of uncertainty there: 40 to 45 minutes, but you don't know whether it'll be 40 minutes, 45 minutes, or somewhere in between. So you allow 45 minutes. But on a bad day (e.g. when the traffic is unusually heavy, or a train is ...


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