I recently found myself in a conversation with a colleague regarding feature teams vs. component teams. The colleague was expressing his frustration with feature teams. In his environment, there are a number of shared infrastructure systems on top of which are built a variety of products and features. His frustrations included:

"I'm implementing a user story and I see a way to improve/refactor the existing code while I am at it. Should I do that?"

"I've completed implementing a user story and want to clean up the code I've written. Should I do that?"

"I have an idea for a better way to solve this problem. Should I implement it?"

"This piece of legacy code is complex and painful. I want to rewrite it. Should I do that?" 

 

Do any of the above questions sound familiar? I've heard them on many projects and on many teams. The questions reflect both a desire to "make things better", as well as an uncertainty as to the boundary of "what's ok to change". I wish there was a simple answer. Sometimes there is, but often there is not. How do we decide if, when and how to implement improvements?

 

“No man ever steps in the same river twice, for it's not the same river and he's not the same man.”

- attributed to Heraclitus

 

One of the staple technical practices of agile software development is Continuous Integration (CI). A continuous integration environment provides fast feedback on the state of your code. In a typical configuration, the CI tool is configured with a "job" that monitors the source code repository for commits. When a commit is made, the job: