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

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

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

How you come about introducing (the idea of) change depends a lot on your relationship with your manager (and peers) as well as the organisation culture. Here are some suggestions to go about it: Start with an informal discussion: when you say you have to "break things" to your manager it just sounds like you're going to give him/her bad news, and no-one ...


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

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

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

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

I would strongly resist the urge to manufacture a crisis, but equally strongly advocate using a real crisis to drive change. My belief is that you need to start by articulating in simple terms why the status quo is not an option, and then explain in equally simple terms a clear and compelling vision of where you need to be (and this should include the ...


3

Start small so you can demonstrate success. Look for the biggest pain point and see what you can do to address it. The more success you have, the more momentum you'll build behind your campaign and the less you'll look like a cowboy yourself. Ask Questions rather than making statements. "What if we were to try this?" "Why don't we do it this way for a ...


3

I would say it all depends on people. Personally I would adjust the way I act in general with specific focus on bring all these problems out to the specific decision maker I would be talking to. If your manager is a guy who is willing to improve but for whatever reason failed to do so up to this point bring it all to the table: current failings, areas worth ...


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