7

I'm not looking for advice how agile process should work. I know that part. I'm curious what the best way to adapt the process to a typical large, well-established corporation who loves its "processes" and gate/passport reviews.

For those lucky enough not to know what they are, gates/passport things are essentially waterfall milestones presented by development teams to executives: Gate 0 - kick off, identifying positive npv projects; Gate 1 - planning work for the release, coding begins, Gate 2 - code complete/testing phase, Gate 3....

While within our team we've tried to embrace agile as much as we could (peer reviews, iterations, constant communication, doing what makes sense, continuous improvement...), these gates come from way up and there's nothing we can do about them.

Of many things that bug me, one of them is that the corporate environment we are in, imposes some constraints which seem to have adverse effects on how we work. One example is that during development we only focus on new features and ignore existing bugs and even introduce new bugs. This is unfortunate and goes against agile, but we have no choice since code complete could be in 2 months, but "testing/bug fixing" phase can last 6 months after that. We are under constant pressure to "finish work" but emphasis is on completing features, not getting a stable product. This part we sorta learned to live with.

My question is what strategy (successful mode of operation) other teams/companies have found for the "testing" phase that follows a "code complete" milestone?

During "new development" we have iterations and each one gets filled in with stories and tasks. However, currently once development is "done", there's no more iterations and no more planning. Instead, we solely use bug tracking database to monitor how many new bugs are being found and how fast the bugs are being resolved.

Personally, I don't see the difference between adding new UI feature and making existing UI feature work. To me work is work. I proposed that we continue having iterations as normal and continue to schedule work as before, but neither management nor other team members seemed to be on board with that. So 1) am I way off and is bug track database the best we can do? and 2) if there's a better approach, I'd like to explore it and maybe acquire enough ammunition to take back to my boss. At the same time I somewhat agree that a lot of times when reacting to bugs we don't have the luxury of waiting till next iteration.

--- Slight clarification based on first few responses ---

We just entered the testing phase. At the moment, there's no more stories, no more iterations. Only bug tracking database. That doesn't sit right with me, that's why I'm curious what other teams would do in this situation. Also some bugs are definitely the size of a medium size story, while other bugs would take 5 min to fix. Should 5-min bugs also become stories if we were to continue with iterations? The other argument we've been having is that during "new development" we only interact with Agile tracking tool (Rally) but in "testing" if we continue with iterations, we'd have to maintain paper trail in Rally as well as in bug tracking software.

Improve this question

7 Answers 7

Reset to default
5

I don't think you'll really get anywhere without reworking the way things are done right now.

One example is that during development we only focus on new features and ignore existing bugs and even introduce new bugs.

I am fairly certain that this is a grave mistake. Try to explain that bug fixing becomes more difficult and more expensive the longer it is postponed. I don't think there is any excuse for postponing bug fixes for so long.

All agile methods I know emphasize that the software should be technically ready to ship at the end of each cycle/iteration (or even continuously). That means any bug that you wouldn't want to ship must be fixed before any new features is started.

Try to work with people, and explain your concerns.

Finally, if you cannot get any kind of agreement on such basics, it may be best to move on.

Edit

Based on your amended question: I agree that bug fixing should be handled just like new features. I'd normally have single tasks for "small" bugs (up to a few hours) and stories with subtasks for "big" bugs (multiple days, possible to split into tasks). If your colleagues do not agree, point out that the advantages of agile methods apply to bug fixing just like to new features.

As to wheter to use an agile tracking tool or a bug database: Ideally, the two are integrated. If they are not, then yes, you'll have to track work in both. It's annoying, but I've done it myself, and didn't find it a big problem. You track bugs as usual, and just copy&paste the bug id into the title of a task/story when you schedule a bug to be worked on. The task is just a link to the bugtracker (eays if both are web-based), and all discussion is in the bug db. If you link consistenly, you could probably even run reports across both systems.

Finally, it you believe you cannot change the way development is organized, you'll have to work within these constraints. Things like introducing some agile methods into the bug fixing phase will probably help.

Still, I am convinced that splitting development into a "feature phase" and a "bugfixing phase" is a grave, possibly fatal mistake. It may not be so serious for your company (every situation is different), but if it is, and if your organization is unable to change this, then your organization may be so dysfunctional that you'd be better off elsewhere. But that is your call to make... good luck!

Edit 2

Finally, if company policies dictate "features first, bug fixing later", maybe you can sidestep them, e.g. by redefining bug fixes as new features (the difference is often a matter of opinion anyway). To some extent, you can try to introduce new ideas "from below" that way. You know, "if you can't beat them, join them".

Improve this answer
4
  • As I tried to explain originally, this waterfall gate thing is pushed down from way high up. Even our VP of engineering is not in control of this. So who can I possibly explain it to? To me agile is a toolbox and a methodology that says do what makes sense and work with people. So given our corporate environment myself and my team are doing the best we can. And if I have a short-term deadline of passing gate 2 while I have another half a year to fix bugs, unfortunately for our team that is a very valid excuse. I am attacking this issue on several different fronts, one of them being...
    – DXM
    Dec 13, 2011 at 17:36
  • ... lobbying other technology leaders so they could help influence management. But this will take time. In the meantime, what I'm looking for is advice specifically on mode of operation for our team given our environment. Obviously ditching the team and finding a different job is an option for me personally, but that still doesn't answer the question.
    – DXM
    Dec 13, 2011 at 17:41
  • @DXM: If you're adding facts, please update the question. If you're repeating parts of the question, that's silly. If you're changing emphasis, please update the question.
    – S.Lott
    Dec 13, 2011 at 18:13
  • 3
    "as I tried to explain originally" usually means I'm repeating part of the question. I did that because this answer suggested I change the way my company operates and sadly that's not one of my options at the moment. Someday, maybe, not now though. I rephrased and repeated myself because the person who tried to help me clearly did not understand this part when he read my original question. So I attempted to clarify it for him. In my experience saying the same thing in different words helps people better understand what you are trying to say but putting this in original question would be silly.
    – DXM
    Dec 13, 2011 at 18:28
4

One example is that during development we only focus on new features and ignore existing bugs and even introduce new bugs.

This is a bad thing. A very bad thing.

You're not "Semi-Agile" if you're introducing bugs during an iteration. You should have gotten stuff to work and moved things back to the backlog because they weren't getting done.

If you take 6 more months to build stuff well, then you don't spend 6 months testing and fixing bugs.

It's supposed to be simple. Stop rushing and called bad code "done".

If management insists on rushing bad code into a "done" state, they're blind to the waste of time that 6 months of bug fix called "testing" is. Inform them.

Also some bugs are definitely the size of a medium size story, while other bugs would take 5 min to fix. Should 5-min bugs also become stories if we were to continue with iterations?

You really have no choice but to put the bugs into the backlog and try to iterate correctly. Stuff isn't "done" until it's bug-free.

If you can't get it bug free, it goes back into the backlog for the next iteration. Then, you'll be able to make it bug free.

Improve this answer
3

Try this: Shrink your iterations to a size that you can get done and tested in the Coding Phase. Your testing phase will be finished early (IE: however long it takes your unit tests to run.)

Alternately: Ignore the gates. Your company's definition of Code Complete is meaningless anyway. If you haven't written any code for a feature by the testing phase, then declare that feature "done" and file a bug for the fact that it does not work yet.

Improve this answer
2
  • +1000 - for ignore the gates. You have been hired to do a job in a professional manner. Claiming to be done when you aren't just to meet a gateway is unprofessional and highly unethical. If you can't meet the gates then a professional admits to the fact, they don't lie.
    – Dunk
    Dec 13, 2011 at 21:44
  • I dislike the idea of lying to management, as a general rule, but if management refuses to do business with reality, some creative reinterpretation can help everybody.
    – Matthew Scouten
    Dec 14, 2011 at 15:13
2

How do you know that your code is complete without any test ? How do you validate that you can cross Gate 2 ?

My way of doing Agile in a Waterfall process as a developer is to do TDD hidden behind a debugging curtain.

Doing so, I know when my code is complete and I am confident about its stability.

Of course coding takes a more than 2 months but coding+testing takes less than 8 months.

About new features/fixing bugs, I am sure that you can arge that the new feature cannot be introduced if that bug is not fixed before.

Improve this answer
8
  • Gate 2 is scheduled 6-9 months after Gate 1. We are code complete when the date comes and doesn't get pushed. Management 4-8 levels up the chain discusses a bunch of semi-fiction in a 4 hour meeting. Then we get congratulations and a team lunch. Any code that wasn't completed becomes a bug. Notice my use of quotes around the "code complete". We also have something called "code freeze" which is really a chill that can last for months. It's a silly system, but for now we are stuck playing in their sandbox
    – DXM
    Dec 13, 2011 at 10:23
  • 1
    @DXM: Please don't call it "semi-Agile", then. It sounds more like ordinary waterfall.
    – S.Lott
    Dec 13, 2011 at 18:14
  • 1
    @S.Lott-From your several comments, I feel like I need to defend myself. We have continuous integration, nightly builds, stories with complexity values determined by the team, every line of code written gets reviewed by at least one person, we have daily stand-ups and every developer/tester knows what the team is working on, design/architecture is done as a team, we have velocity estimates that help with projections, we use evolutionary design and actively refactor. If you can't give me 50% agile, how about 40% or maybe at least 25%?
    – DXM
    Dec 13, 2011 at 18:34
  • 1
    ... and we do our best to deliver each story bug-free but some times we have to let some things slip because of the environment constraints. When we do it, we know perfectly well that this goes against the very practices we are trying to embrace. And yes, my team is not agile, but we are certainly trying to work towards that the best we can.
    – DXM
    Dec 13, 2011 at 18:36
  • @DXM Those are all great practices that you have listed, however you are still not Agile. All that means is that you are a very well run development team in a strict Waterfall environment. To be honest, I don't think there is anything you can do as developers to make the situation any better than you already made it. Given the obvious contractual and political constraints of your organization, your team is doing everything in its power to run as smoothly as possible.
    – maple_shaft ♦
    Dec 14, 2011 at 12:23
1

Hm. Not that I really done this, but it seems to me that one of the most ideal models for this situation would be based on agile technique of "play and then throw away experiment". Treat all the code you created during two months of not having opportunity to create good code as a long experiment - now you are clear what do you want to achieve and also more or less how. Toss it out and begin to do things right. Every time you successfully finish a feature, report it as "bug fixed". After all, doing everything right from the scratch is the best way to fix bugs of inherently flawed legacy code. Treat the two-month effort as bad legacy code that needs to be completely refactored, just report it as bug fixing.

Improve this answer
6
  • 2
    "doing everything right from the scratch" is actually a good way to introduce interesting new bugs...
    – Michael Borgwardt
    Dec 13, 2011 at 10:19
  • Not sure Joel Spolsky would agree that is a good idea joelonsoftware.com/articles/fog0000000069.html. Doesn't make it gospel but surely just tossing away code isn't good? Just chance to add new interesting bugs.
    – GraemeMiller
    Dec 13, 2011 at 10:20
  • 1
    2 months was just an example. Actually we've been coding for about 8 months now. Somehow, I don't think I can sell it to my boss that "new development" phase will be for throw away code, something needs to be delivered, but to a degree that's what we end up doing. We close stories even though there are known bugs because of the knowledge that we'll have more time to fix them later, whereas we don't have time to deliver new code.
    – DXM
    Dec 13, 2011 at 10:35
  • Ok, not from scratch, but by treating old code as legacy and poisoned and instead of "fixing bugs" simply refactor and nothing more, using all methods that are used to work with legacy code, making it right in the process. The bosses can hear about "big fixing" if they need to, though it will be really just "development done right at last".
    – herby
    Dec 13, 2011 at 10:50
  • 1
    @DXM: IOW, your team are a bunch of liars. You claim being done when you aren't. And because you are able to be done in 2 months, the next team that gets a project will have to be done in 6 weeks. And if that team also lies, then the next team will have to be done in 5 weeks. It seems like your company culture of lying is what got you into this mess to begin with. Otherwise, you would have had adequate time to complete the project and remove bugs to begin with.
    – Dunk
    Dec 13, 2011 at 21:41
1

There are problems mapping purely agile processes (like SCRUM) onto a project setting. Biggest issue is that in the agile approach, there is a constant negotiation and re-evaluation of the scope for each iteration. In a project, however, you will have a fixed deadline, a fixed budget and an expectation of what should be delivered ON THAT DATE. For me, SCRUM is about software maintenance more than a project methodology.

My suggestion (that I've employed myself) is to shrink your gates. If you're trying to maintain, for instance, 4 week iterations then your gates should be 4 weeks. Establish deliverables and "definitions of done" for each gate. If you, at the end of an iteration/gate still have bugs in your code then the gate is not complete and should be flagged as overdue. This is the mindset that both you and your business stakeholders should try to get into. At the end of each iteration there should be a completed set of goals and no half-finished or non-working features.

Improve this answer
1
  • As I mentioned elsewhere our corporation is really, really big and even our VP doesn't have control of when the gates are set. You've given some good advice, but this advice is for people who won't ever read these posts. I'm kinda curious what could be done at our level given the corporate constraints that are beyond our control
    – DXM
    Dec 13, 2011 at 17:48
1

Did you used to work for my old company? The similarities are frightening...

Some words of advice... nothing you say or do will change the process in any meaningful way whatsoever. You are not a PM, you prolly do not have PM cerficiations or any political importance to effect change on such a large operation. Exposing how they are doing things wrong will inevitably equate to you pointing the finger at somebody of greater political importance than yourself and will get you fired. I have seen this happen too.

Your options are clear, live with it and accept it, because the project likely has an enormous budget and clients suffering from vendor lock-in or government contracts so there are quite literally dis-incentives for completing work in less time. Further why focus on quality if it doesn't affect your bottom line?

If the above situation doesn't describe your companies market position then it is just a matter of time before a lean agile startup will eat their lunch and put them out of business. If it does then you can decide to live with it and continue or leave for a company that is actually focused on producing software, and not a company that finds ways to justify a massive budget by consuming it.

Improve this answer
3
  • Although I still don't have any practical takeaways, yours is the first answer that actually understood the situation my team is in. And that's the thing, I'm not trying to change the world or our company or to point fingers (which certainly have places to point at). I'm just trying to figure out what we as a team of pawns can do at our level given the environment we are in.
    – DXM
    Dec 13, 2011 at 17:55
  • 2
    @DXM I'm just trying to figure out what we as a team of pawns can do at our level given the environment we are in The same thing that all pawns can do. You can move forward one space, possibly moving one diaganol space to take an opposing piece, sacrifice yourself for the organizations strategic position, or trade yourself in for a Queen by reaching the end of the board :)
    – maple_shaft ♦
    Dec 14, 2011 at 12:15
  • never realized how much distance that analogy could go, that alone deserves a +1 :) But when I come to work in the morning (or close to noon), it's nice to know that at least I'm not limited to an 8x8 square and 2 dimensions.
    – DXM
    Dec 14, 2011 at 19:01

Your Answer

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

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