XP versus traditional good project management

Question

I have been working in the IT industry for 10 years, but I worked in "traditionally" managed project teams (both well-managed and poorly managed).

I heard about a “new” scrum or project management such as XP and wanted to be part of one (like people with s / w, we always love something new, I think), but did not get the opportunity.

My question is, what is your experience of transitioning to the “new” method - was it much better or worse or not different? Has there been any improvement in project efficiency using the XP development method, or is it similar to any well-managed traditional projects?

This should not be a political issue, but only your experience, as you have moved into a new world or experienced at least once and back again.

Thank you in advance

Answer 1

Before I found out about XP, I had a really good manager (Mike) at an early job. It was used to manage engineers and move to software management. After several bad working impressions, I again looked at his style and the typical project management that I had before and after working with him.

• I met with everyone at least once a day, but gave us space to work.
• Used a two-column board, people working, and what they are working on, can look at this board and see if something has been done or has been done.
• If someone crossed. I learned rcs and then cvs and how to use make files.
• There used to be a productive "post-moment" when the task was completed. He would ask: "Would it help if X?" or "next time we can try ..."
• Skillfully everyone who worked on short tasks and managed our time, so we always worked on something, but we did not have a bunch of things.

Mike did everything on paper. He will keep notebooks and file cabinets with him. He insisted that everything that management asked him to turn into manageable tasks, often written on note cards. He refused to work on anyone that cannot be clearly explained or has a clear purpose. He asked the vice presidents: "What do you want to say faster?" "What metrics are the reports to serve?" "Why should this be a priority?" He seemed to have almost endless patience to write what needs to be done and what was meant by "done."

When I first read the XP book, I was amazed at how well-known how "Mike worked"

Agile seems to be just introducing a set of best practices and evaluating how they work in your environment. When they do not work, change them. When they work, stick to them.

I think the real problem with traditional project management is that more often than not it does not exist. I am amazed at how many stores claim to use RUP or Code Complete or even Agile and actually have nothing recognizable as project management. Of course they do. And people called project managers. But ask a simple question like “what has been done for project X” or “what needs to be done for project Y” and no one has an answer. They should dig, although letters or indicate a comically inaccurate MS project file.

If a person claimed to be on a diet and cannot answer questions about what they eat or how they exercise; Do you agree that they really were on a diet?

Answer 2

You take your old luggage with you when you go. This means that any incorrect project management methods that you had before, will still be delayed.

However, I will say that the situation improved significantly when we began to close the cycle between us and the client. Larger and more frequent feedback and prototyping with the client means far fewer moments when the client says, “This is not what I wanted.”

Answer 3

I used (slightly modified) Scrum before at work, and here are my thoughts:

• Daily meetings and burnout provided motivation for making progress in solving problems.
• Our manager could talk with colleagues across the pond and show them: "this is what we are working on this month."
• You knew exactly what tasks you needed to complete, and already estimated the time needed to complete.
• When the priorities changed (new tasks, important errors were added), there was a clearly defined process for processing them in the sprint or simply pushing them to the backlog.

Answer 4

These are excellent answers, but I think everyone confuses project management with development / design methodologies.

Answer 5

I am on the team that started Scrum a few months ago, and we seem to be doing faster and with much less “waste” (projects that are uploaded). Just my observations from our small team (4 developers).

Answer 6

I found that the general transition to Agile / XP methods is very positive, in many ways this improves the quality of the download during the development / development process. You will need a buy-in from management and team to really see success ... a few suggestions:

• fix any changes with a small project (2-3 people)
• understand what areas your current team can influence (quality? performance? time to market?) and include several Agile / XP / Scrum processes (what ever) in ... do not include them all at the same time and understand what processes are addressing, what problems are before any changes.
• if possible - track the areas that you want to change and compare with another project launched at the same time (a simple focus on improving something is often enough to improve it, there is research / deadline for this, but I forget what it is)
• sometimes you will see a drop in productivity when starting a new process, this is part of the learning curve
• never assume that good changes today will remain good changes tomorrow, always look through your project areas and be prepared to change any process at any time.
• No changes will remain forever, just like code refactoring, reorganizing your processes.
• make sure you get the purchase from the team and management, you can’t force success.

Answer 7

I like some things that suit agility, but I also appreciate some of the things that traditional approaches do.

Both can work, like a mixture of the two, and this is what I consider the best for my team. I have introduced gradual development, and it really helps us; iterative development is a bit more complicated and we are still working on it. However, we do have many participants, and many of our stakeholders (and PMs) prefer traditional artifacts and steps. Therefore, we must constantly find the right balance.

I also found that people who implement it are even more important than the methodology. Good people find a way to do a good job and do everything regardless of the methodology, although, of course, the methodology can affect efficiency (and morale :)). However, poorly oriented resources can use the finest methodology and find ways to achieve poor results.

Answer 8

For developers, the big lessons of XP and Co - shorter release periods and a more evolutionary approach - in the sense that changing requirements are accepted as a natural part of any project. Customers also offer solutions, but designers and developers need to understand the problems.

Lessons for managers: Developers are not interchangeable specifiers, their individual strengths and weaknesses can divide productivity by 10 or more for a given topic. Knowledge and experience are the most valuable skills in your team, and developers can train every game. Managers do not need to understand what developers are doing to provide the desired results.

---

XP and Co. usually mixed with them solutions to the problem of changing the company. The heroic XP consultant, who successfully preserves a doomed, deferred, and demolished project, plays a big role as a buffer between development and management. But if you are looking at what to learn, you need to separate these aspects.

What I learned in recent years is that errors are not the fault of the individual, and that the sky does not fall when the specifications change. I found out that although design errors are still the most expensive, there is not a single “perfect” design. Instead of correctly understanding one thing, we need to implement guarantees that out of all the many details no one will go wrong - and I learned to use the freedom between the “right” and “not mistaken” in our interests.

Answer 9

My experience is that I prefer to use Scrum over traditional approaches, as this often happened with the fact that the requirements did not remain unchanged for the duration of the project, where projects usually seem to work at least 6 months before my current one year .

There may also be times when there is no project management and everyone just scrambles to “make it work,” so having a formal structure means nothing. There is something to the question of how well the team got together, and the ego rarely appears, because this is not a code, but rather a team code, and there is some group that thinks where, when each person has an opinion, no one trying to get everyone else to see something like that.

Sometimes it seems to me that some of the Scrum and Agile approaches that I used end up looking like rapids instead of a big waterfall. I mean, the collection requirements cycle - Analysis and design - Implementation - Testing - Deploying and receiving updated requirements seems to be repeated many times, so what appears at the end would be extremely difficult to formulate at the beginning if the project sponsor cannot provide very detailed requirements that will never change.