Spending a good fortune on a certificate holding Scrum Master or a Veteran XP coach?

There is a very prestigious company that delivers a well-sold software about financial systems. It has more that 20 years of history, and is staffed with about 20 programmers and much larger number of managerial staff.
Dissatisfied customers have reported strange bugs and no one has a clue what is wrong, hard to read code, and customization is prohibitively expensive. In a word, the software is rotten.

The company decided to spend a fortune and found the Agile thing as the remedy but they are stuck about what it is they need most urgently. Is it about the process or the developers or both? The challenge breaks down to the following options:

They can hire a certificate holding Scrum Master to teach them
Scrum. When asked about the value of doing it, the SM responded: “I
will prepare them to embrace Agile and only then they can go Agile
and save the product”.
They can as well hire a veteran XP coach. When posed with the
same question he responded : “The most urgent problem is with the
programmers and not the management, XP will save the product from
rot and only then Scrum will make sense”

Developers are far from capable of doing agile programming practices at the moment. No unit tests, no pair programmings, no CI (huh? what is it?) … you get the idea.

Some say they would be far better trying to improve their programming first (hire option 2) and then go with the process. Many say quite the opposite. Any insights ?

I’m a firm believer in the idea of No Silver Bullet. The two people that you are describing – the Scrum master and the XP coach – appear (based on your description) to be pushing their favored methodology as the solution to your organization’s problem.

No one idea is going to improve your time to delivery, quality, predictability, or any other aspect of your development environment significantly over night. Process improvement and quality programs take a long time (not weeks, probably not months, but years) to design, implement, and institutionalize.

There are a lot of tools out there to help improve an organization’s ability to deliver software, each with their own advantages and disadvantages. The correct solution would be to bring in someone who is familiar with a number of methodologies, techniques, and tools to assess your current status and culture and develop a process that addresses key problems facing the business.

Right now, you’re only considering someone advocating Scrum and someone else advocating XP. What about CMMI? Lean Software Development? Six Sigma? PSP/TSP? Crystal? RUP? Some other tailored process that takes advantage of a collection of traditional product/process quality techniques and modern software engineering methods?

Don’t look toward these snake oil salesmen. I believe that both XP and Scrum offer good ideas, but they aren’t right for everyone. I’d look elsewhere to people who understand that and can help you build what’s right for you.

This is a biased answer as I believe in quality above all else.

I would say go with the XP coach hands down. It sounds like the team doesn’t know how to refactor or really implement well organized code, the XP coach will help them start holding themselves to a higher standard on these points.

I’m inclined to think that scrum is great at organizing the productivity machine to have them start churning things out at a consistent velocity. However if they haven’t learned to refactor and follow good coding practices and write readable maintainable code, then most of the sprints will be spent consistently churning out either buggy software or bug fixes for what they did last sprint. And that velocity will be very low due to the time it takes to work in such software as you described.

Some may say Scrum can solve these problems, and it’s true, but here’s how: Scrum will magnify the inefficiences in the process, that is, make them visible problems, not larger problems. When scrum makes these visible long enough management may be inclined to start pushing engineers out the door and looking for replacements that do not show the same issues.

This is not (always) the best solution. A bit of coaching on better implementation practices may resolve these issues where Scrum processes will just make them apparent.

That said, if they can spring for it, have them go for both, but I would definitely start down the XP hole first.

Developers are far from capable of doing agile programming practices at the moment. No unit tests, no pair programmings, no CI (huh? what is it?) … you get the idea.

The problem isn’t your developers. With a twenty year old product, your don’t have developers. You have maintenance programmers. As much as I loathe maintenance programmers (the havoc they wreak on what was a beautifully architected system is a crime), they do have a place in this world. Most development programmers don’t like that place. They would love to be cast into the development world. Give them the chance!

Your problem is almost certainly management, not your developers. Prima facie evidence: about 20 programmers and much larger number of managerial staff behind the company. What has happened to your product is that customer X asked for feature A, customer Y asked for feature B, customer Z asked for feature C. All ASAP, all at minimal cost, and all with zero concern for how feature A conflicts with feature C. Your maintenance programmers have become quite agile at wedging that garbage into the product. The result, after twenty years of such maintenance wedging, is a product that is 99.44% pure garbage.

You will not turn this around overnight. Someone who says you can is just peddling a different kind of garbage.

The first thing that needs to happen is that your management has to see that they are the ultimate problem. If this doesn’t happen, let us know the name of the company so we can sell them short before you go bankrupt. If this does happen and you do have management buy-in, turn your maintenance programmers free. This will take a mindset change, and some will not be able to make it. Whether it’s agile programming, extreme programming, or something else, most of them will jump at that chance. It’s a once in a lifetime opportunity that will last at least a few years.

The important thing is not the approach you take but how you assure yourself that you have a perpetually high quality product. You need to maintain (improve!) that quality rather than let it degrade. Otherwise you will face exactly the same problems a few years down the line after the beautiful rewrite once again becomes 99.44% pure garbage.

This is opinionated, but based on personal experience.

I think the XP coach is more likely to provide value than the scrum master. He is far more likely to create good programming than the scrum master is likely to create good management.

If that doesn’t persuade you, use your common sense. He says he will turn around your management and he calls himself a “scrum master”. Does that sound like B.S. to you?

If the “XP coach” called himself a “home run czar” then that wouldn’t be confidence-inspiring either.

O.K., that was a joke, partly, (plus XP coach isn’t a B.S.-free term itself) but there is a better chance for programmers to implement changes without management really being behind it than there is if management is behind it but the programmers don’t know how to do it.

Also, once management has shelled out for the XP coach you can probably justify, you know, doing some of the stuff you were coached about. So you get some of the benefit of the scrum master. The converse would not be true – the scrum master won’t teach you how to do this agile programming stuff, even if your stand-up meetings make onlookers weep at their beauty.

Neither option will come close to being enough to solve the problem, but the XP coach is better if you must stick within the choices presented in the question.

I don’t think this is an “XP or Scrum?” question. The question might be best phrased as “How do I improve the quality of this existing product?”

Secondly, As another poster pointed out, your product appears to be in “maintenance mode” rather than new product development. I would rarely advise Scrum for purely maintenance tasks.

So, I’m thinking a two-prong approach may serve you best.

With regard to quality, I’d say that helping the team to implement things like unit testing, Test Driven Development, Behaviour Driven Development and Refactoring would be a great starting point. Education first, then practice.

Next, to help with managing the way in which the product gets fixed, try something like Kanban.

Filed under: softwareengineering - @ 04:16

Thẻ: agile, extreme-programming, scrum

Thiết kế website giá rẻ

Danh mục

Spending a good fortune on a certificate holding Scrum Master or a Veteran XP coach?