Tag Archives: iterations

Guest Post – 5 Guiding Principles To Using Agile In Research-Intensive Software Environments

Estimated Reading Time: 5 minutes

Agile Meets Research / Data Scientists

As agile spreads wider and wider I often get to work with researchers (a.k.a Data Scientists) working closely with product development. When going agile these people struggle to figure out how it fits their unique style of work. One of those researchers I encountered on an Advanced Analytics group in Intel was Shahar. We had a chat recently and I asked him if he would be so kind to write a guest post describing his perspective. And he delivered! If you’re a researcher trying to make agile work or you’re implementing agile and you’re trying to help your researchers figure it out, this should be interesting!

Continue reading

The cost of iterations applied to Kanban as well…

Estimated Reading Time: 1 minute

My latest blog post was about the costs and challenges of iterations, as well as what to do to overcome them.

One of the other things I’m working on is Kanban. I believe Kanban is a great fit to many teams and situations. Specifically doing Scrumban is a great way to get the benefits of Agile project management together with the Lean Flow Kanban provides. If you strive to achieve a stream/flow of value, you face the same challenges of getting to the minimal batch of work you can live with, and the challenges are quite similar to what I described above.

One difference is that if you DO have bigger features/stories from time to time, with Kanban you do them as fast as you can, but you don’t have the challenge of fitting them into iterations.

This is an advantage and a problem. The advantage is that it feels more natural.

The problem is that teams can fall into the “comfort zone” of keeping the features big, and doing mini-waterfalls on them.

Both with Agile as well as with Lean/Kanban the best solution is on the business/product owner side. If HE breaks the requirements/features into smaller stories/Minimally-marketable-Features(MMFs), the team will execute and deliver faster.

I haven’t thought this through, but my gut tells me that on the engineering practices side, Kanban requires about the same approach as Agile/Scrum in order to reach a high ROI.

What are your thoughts?


Iterate / Inspect and Adapt – nice in theory…

Estimated Reading Time: 2 minutes

On paper, it all makes sense. You iterate in order to deliver business value as early and frequent as possible, and to learn as early as possible about mistakes or opportunities, both in what you build as well as how you build. So far so good.

Now, there are several things you hear from teams starting to work in fast iterations:

  • We cannot really accomplish any meaningful amount of work in this short time. Look at the features we’re asked to work on, no chance we can finish that so fast…
  • Wait – you mean we actually want to have this potentially shippable every iteration? That means we need to have it stable. In order to reach stability we need to do a test cycle. We need some time to do that. The term “Feature/Code Freeze” usually comes up at that point. See my earlier post about this.
  • Can we do design in one iteration, coding in another, testing in yet another?

All in all, if what you are looking for is a way to surface the heavy large batch stuff in your engineering organization, look no further than to raise the idea of fast iterations, not to mention to actually start doing them… 😉 Lucky for us, when we implement Agile/Scrum/Lean, that is exactly what we are looking for.

At this stage fast iterations trade some lost productivity for the gain of early ROI and better visibility of project progress, requirements changes. In Agilesparks, we call teams at this level “Scrum Level 1”. In some cases, at this level the cost and benefits are not that far from each other…

Its crucial at this point that the team/organization transition to a place where the lost productivity is negligible, while the early ROI grows. This requires both reducing the cost of the small batches as well as pushing the product to its customers more frequently. Without these two actions, it will be hard to justify continuing to pay the price of fast iterations, and some regression to long iterations or lower chance of shippable product will ensue.

How do you reduce the cost of small batches?

One of the keys is to introduce Continuous Integration with a fully automation regression suite reduces the price of testing.

Tomorrow I’m talking in a Test Automation Open day about this and related concepts. You are welcome to check out my slides .

I’ll continue to write about this subject in the future. I believe its key to making Agile work in real life.