6

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:

  1. 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".

  2. 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 ?

Improve this question
12
  • 2
    Question still stands: What problem are they trying to solve? Predictability? Quality? Turn-around time? Relationship between tech and business?
    – pdr
    Sep 25, 2012 at 16:28
  • @pdr Well that's the confusion actually. The only fact is that the most valuable of the company's asserts (the product) is rotting so fast. They just want to save the product and make the customers happy and make it cheap to evolve the product in the future.
    – Ashkan Kh. Nazary
    Sep 25, 2012 at 16:32
  • 3
    Neither XP nor Scrum are silver bullets. In my experiences, a tailored process improvement program utilizing a number of appropriate tools works far better than expecting a single tool to drastically change your company. What is your end goal?
    – Thomas Owens ♦
    Sep 25, 2012 at 16:33
  • 5
    @ashy_32bit Their problem is that they did a poor job of architecting a maintainable and scalable product from the start and a worse job of managing technical debt over the years. Now they lack the financial will to invest in major refactoring and lack the political will to admit that their poor management decisions in the past led them to this unfortunate situation. The little control they do have is implementing useless process changes like Moscow throwing meaningless military parades during the collapse of the Soviet Union. I have seen it so many times that I tire of it.
    – maple_shaft ♦
    Sep 25, 2012 at 16:49
  • 1
    @ThomasOwens One of the reasons it's often a good idea to use an industry methodology to start improving things rather than tailoring an improvement program from scratch is that companies who need improvement programs are the way they are from the imnplementation of their own designs. Further designs of their own making aren't usually going to cause improvement, so it can be best for them to take a timeout from their own ideas and adopt someone elses for a while. I agree it won't be a silver bullet, but unlikely to be without improvement.
    – Jimmy Hoffa
    Sep 25, 2012 at 17:09

5 Answers 5

Reset to default
11

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.

Improve this answer
10
  • 1
    I would say XP is not project management and so his question isn't about which big M Methodology to use, so much as whether to look into a methodology for project management, or a methodology for software development. I agree however that it's worth his time to consider other project management methodologies aside from Scrum. Also to your No Silver Bullet point I'd also add joelonsoftware.com/articles/fog0000000024.html though I would temper "No Silver Bullet" with "A bullet that has some silver is better than one with none at all" :)
    – Jimmy Hoffa
    Sep 25, 2012 at 16:52
  • 1
    Also a fair point. Perhaps the best person they could spend money on is a decent manager who can analyse the business, consider all the options, guide them to continual improvement, while explaining to the business why they're in the position they're in and what THEIR options are.
    – pdr
    Sep 25, 2012 at 16:52
  • @JimmyHoffa Of the things I named, Scrum is the only management-oriented methodology. But yes, you do need to consider which tools in the toolbox would best be applied.
    – Thomas Owens ♦
    Sep 25, 2012 at 16:56
  • 1
    @ThomasOwens: I suspect they'd have no choice but to manage at first. See Roy Osherove's writings about the 3 maturity stages of a software team: 5whys.com/blog/…
    – pdr
    Sep 25, 2012 at 17:02
  • 2
    @ashy_32bit Don't differentiate. They often go hand-in-hand. It doesn't matter how well you manage a project, if you don't have the technical competence to carry it out, it won't succeed. On the other hand, it doesn't matter if you have the best tools money can buy and all the skills to use them, if you have poor management, the project is going to fail.
    – Thomas Owens ♦
    Sep 25, 2012 at 17:12
8

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.

Improve this answer
6

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.

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.