New Paradigm of Issue Workflow

The big rage right now is the Agile development process, which I do like. The thing that I don't like is the inadequacy of issue states. This isn't just an issue within Agile, but one that plagues every workflow. Is an issue done? is it done done? Is it verified? How about deployed? What does it mean to reopen an issue? I face many of these questions on a daily basis, not just from others, but from myself as well.

Some where, in a dungeon at our office is a spreadsheet printed out which has an explanation of each of our 50 different states an issue can be in. I've also been lucky enough to try out the Greenhopper Simplified Workflow which simplifies the number of states dramatically. But it still doesn't capture enough states of an issue.

Basic States

State	Description
Open	Nobody has started working on this issue
Reopened	The issue was done, but was not completed properly
In Progress	Someone is currently working on this issue
Resolved	Coding has been completed and the issue is done
Closed	This issue was not actually an issue and has been closed

And this is fine for a starting point, but I don't believe that this actually encapsulates an entire development groups effort. Let's start with a basic workflow, a developer picks up an issue, works it, then passes it to their QA. QA then tests it, and sets it up for a UAT after which the UAT is approved and the issue is completed. Once the issue is completed, then issue is pushed to staging/pilot/production. Let's think about the possible states here.

Workflow separating QA and Development

State	Description
Developer Todo	A developer needs to pick this issue up to work on it
Developer In Progress	A developer is currently working on this issue
QA Todo	A QA needs to pick this issue up to work on it
QA In Progress	A QA is currently working on this issue
Needs UAT	Code and testing has been completed, this issue now needs a UAT
Completed	The UAT was successful and has been approved by the product owner; at this point this issue is done

Let's think about another workflow that might happen. Let's assume that an developer picks up an issue and works it but gets blocked on some other issue. Let's assume that he gets unblocked and completes the issue sending it over to QA. Now let's assume that QA gets blocked on another problem. After getting unblocked they push it over for a UAT which then gets approved and the issue is pushed.

Separated Workflow with blocked state

State	Description
Developer Todo	A developer needs to pick this issue up to work on it
Developer In Progress	A developer is currently working on this issue
Developer Blocked	This issue is waiting on resolution of another issue
QA Todo	A QA needs to pick this issue up to work on it
QA In Progress	A QA is currently working on this issue
QA Blocked	This issue is waiting on resolution of another issue
Needs UAT	Code and testing has been completed, this issue now needs a UAT
Completed	The UAT was successful and has been approved by the product owner; at this point this issue is done

Adding Closed States

But wait, there are a few different end states and outcomes of a specific issue; let's list a view different outcomes from issues.

• Issue was deployed to production
• Issue was transitive (fixed by a different issue)
• We understand that this is an issue, but there are no plans to fix it
• This is actually how the product works, so it is not an issue

Let's address these issues one at a time.

Issue was deployed into production

This is obviously the state we want all of our issues in. This, to me, is the definition of Completed

Issue was transitive (fixed by a different issue)

This is a special bucket where there was no actual code that fixed this issue that applies to the issue itself. So we should have another state of Closed where we can indicate why we did not actually complete it.

We understand that this is an issue, but there are no plans to fix it

This is one of those states that I hate to admit exist, the "Won't Fix" syndrome. But here is the issue, we shouldn't have a separate state for that, instead we should reuse our Closed state indicating why we didn't complete it. Communication is key, and this forces us to indicate why we aren't fixing it rather than just saying "no, we're not fixing it."

This is actually how the product works, so it is not an issue

This is a state in which we have to say "this is how this feature was designed" and I think that this falls into the previous section as well. Let's reuse our Closed state and indicate why we didn't complete it.

State	Description
Developer Todo	A developer needs to pick this issue up to work on it
Developer In Progress	A developer is currently working on this issue
Developer Blocked	This issue is waiting on resolution of another issue
QA Todo	A QA needs to pick this issue up to work on it
QA In Progress	A QA is currently working on this issue
QA Blocked	This issue is waiting on resolution of another issue
Needs UAT	Code and testing has been completed, this issue now needs a UAT
Completed	The UAT was successful and has been approved by the product owner; at this point this issue is done
Closed	No code was changed in this issue, and no further action will be taken on it.

Transitions

The idea is that an issue can move between any two states at any time except from a closed state. An issue cannot be reopened. But why not? Why shouldn't we be able to reopen the issue that was closed?

Reopening Issues (the bane of our existence)

Let's think about what is means when an issue is reopened. If an issue is being reopened, this means that a user feels that the issue was not actually completed correctly. However, if we look at the stages of the issue and what it means to be Completed, then what the user is saying is "I don't think, QA tested this right and our Product Owner didn't understand the requirements."

If we accept that is what reopening an issue means, then we can see that the issue was not implemented completed, but instead that the underlying people did not do their job appropriately. In this case, we should not say that the issue was incorrectly implemented and should be redone, but instead we should address the issue with the people and create a new issue to rectify the incorrect implementation.

But what does it mean to reopen a Closed issue? It means that the user feels that we've ignored their request and that we really don't care about their issue. But, for the most part, we're saying "I'm sorry, but that's not in the cards." As such, we should do our best to communicate why it's not going to happen. We shouldn't just put a single sentence saying "Not going to happen" but instead, link to another issue or some other piece of documentation which explains why we're saying no.

A New Paradigm

Although I'm not saying that Agile doesn't work, I think that we, especially as organizations, become to involved with how many states there are to hold different people accountable. And in the end, only a very few people understand what all of the individual states actually mean. That being said, we should also be able to give more information to our users in order to make them feel better about the actions we take on an issue.

My paradigm is to take more time to update issues and flush out reasoning behind the outcome of the issue so that things like Reopened can go away. That coupled with the 10 states listed in our table below will provide developers and QA a simple process of moving issues between states with more freedom and fewer questions like "is this a Won't Fix or Invalid?"

State	Description
Developer Todo	A developer needs to pick this issue up to work on it
Developer In Progress	A developer is currently working on this issue
Developer Blocked	This issue is waiting on resolution of another issue
QA Todo	A QA needs to pick this issue up to work on it
QA In Progress	A QA is currently working on this issue
QA Blocked	This issue is waiting on resolution of another issue
Needs UAT	Code and testing has been completed, this issue now needs a UAT
Completed	The UAT was successful and has been approved by the product owner; at this point this issue is done
Closed	No code was changed in this issue, and no further action will be taken on it.

Previous success is not tomorrows

One of the questions that continuously comes up by people I meet. It's a question that has come up every time I attend No Fluff Just Stuff, as for a shameless plug of Jay Zimmerman's symposium it's an amazing experience with some amazing developers in attendance, "what is going to be the next big language?" NFJS usually revolves around the Java programming language but almost always includes at least one seminar on an alternative language that lives on the JVM. The question is an interesting one, I'm sure that people who were originally working in C had the same questions. Will C++ become the future; or maybe this thing called Smalltalk or what about this thing HTML? Or how about this new thing called the JVM with the Java language?

Today has been a very eye opening experience for me; I've learned quite a bit about what makes "thought leaders." I'm really not one of those employees that drinks the Kool-Aid with the whole "employees are the most important thing" and "employees drive the business." Mainly because this simply isn't true. Yes, employees have an impact to perform their job and do their best to move the company in the direction that the company is already moving. But let's be realistic, customers drive the business; but employees do provide another level of "driving the business" which is being "thought leaders."

No, this is not going to be an anti-enterprise rant; it's a self reflection of how far I've come as an employee. I've begun to understand that I am a "thought leader" in our organization. Before you tune this out and say "oh how you've changed" let me explain how I've come to this conclusion. When we hear about "thought leaders" normally we think about someone who has done something outstanding in a specific business area, at least I did. But I've come to a more realistic understanding that these are actually "innovators." Instead, "thought leaders" are people who attempt to move an entire business area forward with specific concepts that "innovators" created. So for us, this is tantamount to using new technologies to solve our problems or design new solutions to our problems. This, of course, applies to almost everyone in the software development world; so what sets a regular software developer apart from a "thought leader?"

Myself, I'm beginning to stretch out and write a book on Functional Programming. I've been teaching people at my organization how to do functional programming for the better part of a year or more. People look to me not just for help on learning and implementing Functional concepts, but also for general design advice. And instead of just giving them the answer that I might see, I try to help them arrive at the decisions so that they can understand how to actually solve similar problems in the future. Being a central hub for people to seek advice of is a very important part of being a thought leader. When you are able to put the knowledge that you have and the ability to push this to hundreds, maybe even thousands, of other people you become a larger thought leader not just within your organization but within the community.

I talked briefly before about force multipliers. Now this is exactly the kind of thing that assists you in becoming a larger "thought leader" as well. I think about all of the decisions that I make on a daily basis. Then I think about how many people I influence based on my decisions, how many of them might say "you know what, that guy was right we should be doing it that way!" If I, or you, influence many people over the course of your career you should think about how many of them went to other companies or jobs and said "hey, we did XXX at my previous position and it worked out amazingly." This is what being a thought leader is all about. Influencing people in such a way that they will take decisions that you made with them and implement them later with the knowledge that it is a better decision. The important thing is, if they arrive at the same decision then they will inherently believe in the decision beyond just your convictions.

So what does all of this have to do with programming languages and which ones are the next greatest? Easy, think about all those people programming in C. Someone had to walk in and say "we're going to try and use Java." And most likely that happened at a couple of larger companies; as such, they would then get others interested in the Java language over things like C, C++, or Erlang and begin using that language. Those others would then take that knowledge to the next company that they worked for. Remember, larger companies usually churn more people through, and so the more people that get exposure are more likely to spread that knowledge in their future positions. What we can take from this is that the thing that made previous success is NOT going to be the thing that makes tomorrows success. Most likely at those larger companies someone made the statement, probably quite a few times, that "no we're not using Java, C has worked perfectly fine for years and we should stick with it." Eventually the lapse of time causes previous success to stagnate. Instead, we need thought leaders. We need people to push the boundaries and say "yea, that previous thing got us here; but it won't get us to where we want to go." It's important to understand that listening too much to thought leaders can cause a very large distraction; but when used in an appropriate manner, such as replacing an older existing technology, listen to your thought leaders to determine what the best new idea is not just something based on a previous success.

For those paying attention, you'll notice about half way through this blog I stopped quoting thought leaders. The reason being, much like I started out with this mentality of dealing with the enterprise organizational structure I thought it was ridiculous that we had things called "thought leaders." But as I've grown both as an employee and a software development professional, I've come to the realization that thought leaders are a vital part of the ecosystem making up the software development community. They are not the innovators, but instead are the influencers who can take that innovation and get people to understand and use it not just within the business they are at but at the businesses they will eventually move on to.