ISE Blog

What we have to say, what you want us to hear.

That’s how our blog works. It’s interactive. Let’s learn together.

Analysis vs. Doing Something

Oct 18, 2018 | by Andrew Smith, Principal Architect | Tags: Agile

How long should a team spend analyzing something before doing something?

A team I work with recently used a "spike" to investigate how to implement a new system capability. The spike was open for two sprints, although I am not sure how much effort was expended over the course of those two sprints. The fact of this spike being open for two sprints made me curious about the trade-offs made… given the agile value of Working Software over Comprehensive Documentation, was the team leaning too far in the direction of comprehensive documentation? And if so, how would they know? 

In thinking about this trade-off, I like the following thought experiment… what would each extreme look like?


Feature Teams and Component Teams

Sep 20, 2018 | by Andrew Smith, Principal Architect | Tags: Agile

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:


Uncertainty and Improvement: Harnessing the Desire to Improve

Aug 16, 2018 | by Andrew Smith, Principal Architect | Tags: Agile

"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?


Agile Training, Revisited

Jul 12, 2018 | by Andrew Smith, Principal Architect | Tags: Agile


“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