It’s tempting to do things that you shouldn’t. In software development, unrealistic deadlines and changing requirements often lead teams to make counterproductive decisions, such as adding additional staff in order to achieve a deadline. This not only creates more defects on the current project but also takes resources away from other projects.
I recently faced a similar dilemma when deciding whether or not to indulge in the holiday treats in the office breakroom. Should I consume the sugary snacks that taste delicious but have the potential to cause obesity (among other health consequences) or should I eat the banana I brought with me? Perhaps to me, this internal debate became exaggerated after reading Kidd et al.’s (2013) study and watching the accompanying video on environmental stability and satisfaction. However, after some thinking, and more indecision on my snack choice, I came to the conclusion that software is like a marshmallow.
To give a brief summary, the researchers wanted to determine whether environmental stability would affect children’s ability to delay gratification. This study had two parts. In the first part, children were assigned to experimental conditions (a stable environment or an unstable environment) and told that they were going to do a coloring project using an assortment of old crayons. In both conditions the children were told that there were better art supplies in the next room and that if they could wait for the researcher to come back they would get to use those instead. The researcher delivered the art supplies to the children in the stable condition as promised. However, in the unstable condition, the researcher returned to the room empty-handed, apologizing to the child that they could not find the art supplies.
In the second part of the study, the children were then told that it was snack time and given a marshmallow. The researcher told the children that they could eat the marshmallow now, or if they waited for the researcher to come back, they could have two marshmallows. Children in the stable condition waited almost four times longer for the researcher than the children in the unstable condition. This showed that in the stable environment, children were able to trust that delaying gratification had better payoffs. However, in the unstable environment, children learned that resisting temptation does not pay off, thus fostering a preference for instant gratification.
To me, this scenario related nicely to software development, and is quite possibly the reason why Agile exists altogether. With nearly 70% of developers reporting that they’ve worked on a failing project, it’s clear that the environment for software development can be rather unstable. After spending enough time in such an environment, stakeholders may not be able to delay gratification any longer (i.e. wait for the delivery of the fully functional product) because historically, their projects have failed to meet the schedule requirements. Similar to the children who ate the marshmallow before the researcher returned to the room, stakeholders will likely prioritize short-term over long-term gains if they’re uncertain whether the fully functional software will be delivered. As a result, they may come to value software delivery in smaller, more frequent iterations because waiting for the whole product is too risky.
This is exactly what Agile development does: “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” By delivering frequent iterations of the software, developers are able to break the projects into more manageable portions. While integration of interim releases may cause the delivery of total functionality to take slightly longer, the stakeholders are able to use early iterations of the software very quickly.
Projects with multiple iterations, such as Agile projects can be estimated and tracked easily using SLIM-MasterPlan. Rather than toggling between multiple estimation screens for each respective iteration, SLIM-MasterPlan lets you view the project as a whole (see Figure 1).
Figure 1: SLIM-MasterPlan View of Project Lifecycle
You can set the project schedule so that subsequent iterations begin once the previous release reaches a certain milestone (see Figure 2). In this case, Iteration 2 begins when there is a 15% overlap with Iteration 1.
Figure 2: Editing Program Builder Window
Setting up dependencies in this way allows the user to adjust the schedule for the entire project, if for example, one iteration is late. This can be accomplished by sliding the bars either left or right depending on your scheduling needs (see Figure 3). Note how the schedule dates change.
Figure 3: Schedule Adjusted for Late Iteration 002
In the constantly unstable world of software development, it’s completely rational to desire “instant” gratifications, realized with Agile (or marshmallows). By scheduling releases in shorter, more frequent iterations, it’s possible to create a more stable development environment. By doing this, organizations can avoid making short-term decisions that ultimately produce poor outcomes in the long-term, such as adding additional staff to a project in order to compress the schedule. Through Agile, we can see how succumbing to your short-term desires can result in long-term benefits. Now, if only I could figure out a way to make my short-term sugar cravings pay off in the form of long-term health benefits…
References
Kidd, C., Palmeri, H. & Aslin, R. N. (2013). Rational snacking: Young children’s decision-making on the marshmallow task is moderated by beliefs about environmental reliability, Cognition, 126, p. 109-114.