Being Iterative Is Not Enough: Being Focused Is a Must

DZone 's Guide to

Being Iterative Is Not Enough: Being Focused Is a Must

Read on to see why one developer says simply using the iterative-incremental model isn't enough, and how it can cause teams to loose focus.

· Agile Zone ·
Free Resource

Although it is a bit hard to state precisely where and when the iterative-incremental model started, we can say with some confidence that it is reaching, as of this writing, almost 50 years (see "Iterative and Incremental Development: A Brief History" by Larman and Basili for more on this). However, and despite its wide adoption, there is a big quantity of projects that have not seen the promised benefits of using this development model.

It seems iterative and incremental is the de facto model for any modern software development project. But the reality is that problems always arise and many developers begin to doubt the real benefits of working in an iterative and incremental manner (much of the time, developers feel they have to go back to a more classic waterfall model which, to be honest, for some software projects is not so bad). Moreover, some people start to believe that the iterative incremental model began because of the work being done by a bunch of non-experienced theorists that ended up writing books on this topic.

So, what's the problem?

In my experience, most of the time the main problem is not being focused. To succeed using iterative and incremental development, you must be focused. If you work in a team, you and all of your peers must be focused.

Being Focused

In this context, being focused means working towards an objective set for the iteration. Of course, depending on your actual situation, you can also call it an iteration goal. And working here means doing implementation activities that, when finished, eventually would lead to the achievement of the objective or the goal established for the iteration.

In Scrum, it is recommended that the Scrum team craft a goal soon after determining how many Product Backlog items can be worked on the Sprint. But being focused is not limited to Scrum.

Being focused is a must in any development process that is modeled after following the iterative and incremental model. The main reason is that you and your team must work together in a cohesive and organized manner and the objective or goal will act as a guide for you and your team to be focused. It is common to find teams with some members working towards what they think is important and others working towards what they view as required. What these teams have not done is to sit, before implementation begins, and discuss if they all understand what the customer/user expects at the end of the iteration, which is the main source to define a goal or objective. Usually, a goal or objective will be oriented toward some functionality. For example, "provide the user a useable interface for analyzing social data gathered from two defined sources" (of course, analyzing social data is something you have to refine). 

Before starting implementation, be sure you and your team understand, at the same level, what you have to accomplish, that is, the iteration goal or objective. Taking the above example, if one or more members feel the objective is to test the integration of APIs to the sources that provide social data, then your team will not be focused on the same objective because some of them will be working towards API integration (which will probably end in a technical prototype that is only interesting for technical people) and others working towards implementing functionality (which will give you early feedback from your customer/user).

Sometimes, Being Focused Is Hard

There are some cases in which being focused is very hard to attain.

Although there could be many examples, I can tell you that R&D environments are typically so complex that most of the time your goal or objective risks becoming obsolete in less than two weeks! Thus, be especially careful in these environments. Try to shorten the iteration. Not so short to not being able to build at least one piece of working functionality, but not so long to allow the risk of obsoleting the goal or objective increase. In practical terms, one or two weeks for these environments is OK. Note that if you select one week as the length for the iteration, your iteration goal must be consistent with what you and your team can accomplish in one week. 

Having Too Many Goals or Objectives Is Not So Good

Finally, be careful with being flooded with goals or objectives. No matter how long you set your iteration for, having more than 3 to 4 goals will probably affect you and your team's focus. So, having several goals will not be a guarantee of being focused.

agile, iterations, sprint goals, sprint planning

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}