The importance of time boxing in SCRUM

In an Agile environment, in my experience people get enthusiastic. I think that is one of the good things of an Agile way of working. In my work experience I've seen that starting with an Agile way of working, in this case SCRUM, especially developers get happy.

This has several reasons, but the main things is: they can do their work. And the method respects the dynamics of IT development.

But every methodology has some anchor points, which should guide you in the right direction. Important in SCRUM are these meetings:

• The daily SCRUM (stand up)
• The SCRUM of SCRUMs
• The Sprint Planning
• The Sprint Demo or Review
• The Retrospective

There are several variants of the SCRUM implementation in an organization. Probably the company will not start entirely Agile, but start a transition from Waterfall methodology onto pure Agile. Each company has to handle the touch points with other parts of the organization which still practices Waterfall methodology and how to translate that to the part that is Agile.

It is important to keep evaluating things and see how they can be improved. 

I think an important thing is to look at how much time you need for those meetings, and time box them properly. This takes care of the fact that meetings are going to take to much time, and that the meetings will be used for what they're are meant for. Sometimes people tend to use those meetings to talk about a lot of things, maybe also about how to improve the process.

A good moment to look at how you do things, would be the retrospective. But keep in mind that that meeting is time boxed too. Although I do think that during the process of making your organisation more Agile, you might need some more time for the retrospective. On a different level, this goes for the SCRUM of SCRUMS as well.

The positive effect of sticking to this, that is a) time boxing and b) stay to the purpose of the meetings -although it sounds a bit bureaucratic- is that you will have a clear view on how much time it takes to do those meetings and how much time there''s left to do the actual development during sprint. I still believe there's enough dynamics outside these time boxes to keep the process lean - and mean.

The Distributed SCRUM Team: agile teams anywhere on the globe

"We are looking for a location where we can all be, regardless of where we all are."

After 48 weeks of doing SCRUM, with the number of teams growing from 1 to 6 and trying out different implementations, we now face a new, interesting challenge. Our 5th and 6th SCRUM teams have started in... Chine and India.


So, here it is: "One of the biggest mantras for Agile teams is that you have to be co-located.  If you are not co-located, you are not going to be highly performant." (Julie LeMoine, the Fidelity Center for Applied Technology) That's the thing. Everybody, at least in our situation, beleives that one of the biggest benefits is that all team members and teams are at walking distance. Most of them even at pebble throwing distance. And they also agree that most of the problems we face are communication problems with people who are further away then the earlier mentioned.


So how are we going to handle two teams in another part of the world, are we going to share the backlog? Do we instate another product owner? Are they actually working on another product? How do we do shared meetings when we are in different time zones, e.g. for our daily stand up?


Of course there are theories and people who have thought about issues like these, but like always, one also needs to regard the issues of the specific company. And what the possibilities we have to change things. So I'll be probably reading the books below, but also start a discussion, maybe just a theoretic one, with some people and see how we get all advantages there are out of it.


I would be very interested in your opinion and experiences on this, and maybe communicate with the collegues in China and India on a more regular basis, to see what happens from your perspective.


These might be interesting to read:

• A Practical Guide to Distributed Scrum
• The Black Book of Agile Project Delivery with Distributed Teams
• Distributed Agile: DH2A - The Proven Agile Software Development Approach and Toolkit for Geographically Dispersed Teams

Optimization has no Business Value

Or: The future – who cares?

By Sid B. Dane, July 1st, 2011

What is best to do: optimize your IT project to be prepared for the future or don’t care, we’ll see what happens then? In a SCRUM environment you have a strong preference for focusing on Business Value, i.e. effectiveness and not efficiency. The way to reason if you should be prepared for the future is first put it in the two extreme opposites:

• Only solve the problem at hand; use the simplest possible solution ("Effective Java (2nd Edition)" / Joshua Bloch, 2008);
• Always implement the principles of scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security

The thing is: we cannot predict the future. Well, we can expect things, but it is not a prediction. This is like a weather forecast: it’s reasonably accurate for the next day, but after 3 days it’s more like a guess. So does it take more effort to be prepared for the future than just act on it like it comes? In an Agile environment, the rule is: choose respond to change over following a plan ("Manifesto for Agile Software Development" / Kent Beck, Mike Beedle, Arie van Bennekum, and others, 2001).

Also, taking care of things that might happen or might be handy in the future can introduce concessions to speed and performance and other things ("Premature optimization is the root of all evil - not only in the Agile world" / Przemysław Bielicki, 2008). Should you be willing to do those concessions just for the sake of being prepared for the future?

A mental model

Let’s take a look at these two scenarios:

In scenario 1 and 2 the same functionality is developed, which takes 100 units of work. In scenario 1 though, also 20 units of work are spent extra to do optimization. In scenario 2 just the simplest solution is applied and no extra optimization is done.

In this example, we assume that an extra of 10 work units need to be done to change that particular part needed for the new requirement. We can see that if the extra requirement needs 15 units of work, the total sum of work units spent is 135 in scenario 1 and 125 in scenario 2. If another extra requirement comes along, and we add those numbers again, we result in 150 units in scenario 1 and also 150 units in scenario 2.

We can assume this is quite a retentive model, and even then the early optimization pays back only when the 3rd extra requirement is added. So the question is: how likely is it that there will be at least 3 added requirements?

Well, in my opinion this is as likely as forecasting the weather for the next 7 days. I could even argue about the number of work units chosen for the early optimization in scenario 1. How likely is it if you spend 1/5th of the development time extra to optimize the system, that this will cover all possible or all likely future changes?

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” ("The C++ Programming Language, 11.3.7: Efficiency" / Donald E. Knuth, 1988)

It would be nice to measure the following for all stories:

•  How much time is spent on early optimization?
• How much time is spent on developing the new requirement?
• How much time is spent because early optimization was not done?
• How much time is spent because early optimization was not done?

If you measure these parameters on 500 stories on your backlog, it would be interesting to see what scenario works best. Using the law of large numbers, you should consequently use the same scenario to make it work.

Project Managers will complain if negative signals reach them from the project. Spending time because early optimization is not done would be a negative signal. If it exists multiple times in 1 project, it appears to be a bad thing. Depending on how well the Project Manager is heard, views on early optimization will change. The overall gain usually is not visible because the early optimization that is done is often interwoven in the regular development work.

In non-agile environments, there usually is not much time to spend on early optimization. It is focused on meeting the deadline. In an agile environment, the team can decide for themselves. They will be eager to do early optimization because they never had the chance and it always was a developer’s utopia. And it’s the best thing to do… theoretically.

On the other hand, we are working in a SCRUM environment, so the actual questions that should be asked is:

• How much Business Value is generated by early optimization?

“More computing sins are committed in the name of efficiency (not necessarily achieving it) than for any other single reason - including blind stupidity.” ("A Case Against the GOTO, Proceedings of the 25th National ACM Conference" / William A. Wulf, 1972)

How to handle this theory?

To avoid discussion on semantics, we should clearly identify premature or early optimization. The word premature indicates by itself that it’s not a good thing. Early sounds a bit better. But it’s not the words here that matter.

I won’t say that one should never optimize or early optimize. Thing is, in what level are we committed to creating Business Value? If no early optimization is done, the time-to-market will be optimal. The first few changes we can do quickly and it will not cost too much. Changes will take a little more time because we will have to make adjustments to the system to make it fit, but the overall time spent is less, at least for those few first changes.

To make things even a bit better, you could create a rule of thumb about optimization. Some specific aspects of … made us learn that it would be good to invest in those on a certain level. But those optimizations should always be minor and one should always be aware of the motivations and if those motivations are valid and not just because you should optimize or something could maybe happen.

“We follow two rules in the matter of optimization: Rule 1. Don't do it. Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfecly clear and un-optimized solution.” ("Two rules in the matter of optimization" / M.A. Jackson, 1975)

If an optimization is of a larger size, it could be considered a new requirement to the story and the Product Owner and/or Business should be asked if there is any Business Value in it. If not, first make the un-optimized solution and after that reevaluate the necessity of the optimization.

=== END ===

special thanks to Korjan van Wieringen, friend and sparring partner

Bibliography

• "A Case Against the GOTO, Proceedings of the 25th National ACM Conference" / William A. Wulf. (1972, August).
• "Effective Java (2nd Edition)" / Joshua Bloch. (2008, May 28).
• "Manifesto for Agile Software Development" / Kent Beck, Mike Beedle, Arie van Bennekum, and others. (2001).
• "Premature optimization is the root of all evil - not only in the Agile world" / Przemysław Bielicki. (2008, oktober 9).
• "The C++ Programming Language, 11.3.7: Efficiency" / Donald E. Knuth. (1988).
• "Two rules in the matter of optimization" / M.A. Jackson. (1975).

Firefox HTML 5 demonstration

When in Firefox, Chrome or any other HTML5/CSS3 capable browser, take a look at this nice Planetarium demo at http://mozillademos.org/demos/planetarium/demo.html

Flex 4 / AIR: copyToAsync does not fire the ProgressEvent

Problem:

While working on an desktop AIR application, I came across the problem that the copyToAsync method of the flash.filesystem.File class does not fire a ProgressEvent.

I would love to use the Async method, because this does not hold up the rest of the application, but I wanted to display some progress indication in e.g. a ProgressBar.

Solution:

Open 2 streams, one to read from and one to write to. Read and write chunks of bytes and calculate the progress according to the bytesAvailable attribute of the read stream.

Sample code:

// This is an object which has a public attribute which contains the source of the file to copy and 
// a public function with a File parameter to copy it to


public var fileObject:File;


public function copyTo(destination:File):void {
     inStream = new FileStream();
     outStream = new FileStream();


     inStream.addEventListener(ProgressEvent.PROGRESS, onProgress );
     inStream.addEventListener(Event.COMPLETE, onReady );


     inStream.openAsync(fileObject, FileMode.READ);
     outStream.openAsync(destination, FileMode.WRITE);
}


private function onProgress(e:ProgressEvent):void {
     // calculate the percentage
     pct = Math.round(e.bytesLoaded/e.bytesTotal*100);


     // if you want to update the progress bar:
     bar.setProgress(pct, 100);

     // if the ProgressEvent is fired, we have data available in the inStream, so we can start writing data

     var bytes:ByteArray = new ByteArray();
     inStream.readBytes(bytes, 0, inStream.bytesAvailable);
     outStream.writeBytes(bytes, 0, bytes.length);
}


private function onReady(e:Event):void {
     // the whole stream is read, so close the files
     inStream.close();
     outStream.close();


     // dispatch a COMPLETE event to let listeners to this object know the copy is done
     fileObject.dispatchEvent(new Event(Event.COMPLETE));
}

And somewhere in the application, associated with the copying process, there's a progress bar like this:

<mx:progressbar id="bar" mode="manual" width="100%"/>

I'm sorry this code's not entirely complete, but I had to use fragments of my existing code to illustrate this principle. Feel free to experiment with it.