There is a difference between doing Agile and being Agile.

What kind of mindset do you need to be Agile?

Effects on a team when you change it

Following up to a discussion I had as an Agile Coach with a team, I painted a simple graph what can be a great food for thought and discussion: what happens if you fiddle with the team size?

In Agile and Scrum utopia teams exists forever and have time and means to improve themselves. They are self-steering so take care of the team as well. In practice, that usually is not the case. Sometimes (in the consultancy project driven world I work in) there are budgets, projects and project managers who guard these. As an Agile coach you’re sometimes caught in the middle when “resources” (they mean: people) are added or removed from teams due to several reasons. To help clarify the effects of this I like to share these thoughts with you.

Startup and sustain periods

When a new team starts (e.g. when a new project starts in the previous mentioned world) a certain “normal” pattern occurs with the team’s velocity. The first 3 or 4 sprints or so, the velocity increases. People get to know each other, the team is getting used to their teammates and the subject matter becomes more known. I call this the startup period. Length may vary depending on the team, the subject matter, the organization, the sprint length, etc.

After that, a period starts I like to call the sustain period. The velocity might go up or down based on the ability to improve, but I like to look at what happens when something is done with the people in the team.

A subject matter change (A)

If the team starts working on something completely different, like a new website, maybe some other technology, a lot of knowledge collected is no longer useful. Maybe another Product Owner gets in place and stakeholders change. This has quite a severe effect on the velocity. Almost like the start of a new team, only the team dynamics stay in place; they know each other and their competences, but a lot of new stuff and new communication lines need to be discovered and installed. This is maybe unavoidable, but one need to realise what the effect is.

A small team change (B)

A small team change can be replacing a team member or adding but not removing a team member (see D and E for that). The good thing here is, that the (usually unwritten) knowledge of the team remains, the new guy learns from the team members and gets introduced into their way of working and communicating. The impact isn’t that big (as long as the team member leaving isn’t the team’s superhero, which a team shouldn’t have, but that’s another subject) but still everything goes down for a bit: velocity, predictability, the average number of stories done, the estimation accuracy and the matter knowledge.

A big team change (C)

A big team change is usually not recommended, you lose the knowledge of the team and it’s like a new team with a few people who know how they did it in the old team. This brings the team back to start and basically back into the startup period. Getting to the sustain period might go a bit more smoothly depending on the knowledge left over in the team.

Up sizing or downsizing (D and E)

When people are added or removed from the team, basics like velocity and number of stories done go up or down accordingly, but predictability, estimation accuracy and matter knowledge go down in both cases. Since there is a new team member or a team member has left, the team needs to restore balance. That influences predictability, because they need to find out how to estimate in the new setting. Maybe a story point devaluates and that does not matter, because a story point in itself has no meaning, but is a means for the team to do their planning. They have to reestablish that.  Of course some knowledge leaves with the leaving team member and a new team member needs to acquire that knowledge, so matter knowledge will suffer.

Conclusion

I realise that this is a quite generic approach, but I hope it helps the discussion and the understanding people have when you change a team or the team changes itself (that would be the best variant). For specific teams in specific situations, this all happens (a bit) different, but I think this is a good starting point. So I hope this helps you and please share your experiences with me!

Why do we have this Sprint Goal?

The idea of a Sprint Goal is to know why you are doing things. In the previous version of the Scrum Guide, it was about completing the sprint, now it’s about meeting the sprint goal. That’s in a lot of aspects the same thing, but for example, when the Sprint Goal becomes absolete, there is no need to complete the sprint, since the Sprint Goal has no value. Using a Sprint Goal helps the Scrum team to focus on the purpose and value of what they’re doing, instead of just finishing the sprint.

It is not mentioned in the Scrum Guide how to document the Sprint Goal, or even if you should do that at all. I would say that the purpose of a Sprint Goal is met when the Scrum team has the Sprint Goal clear for everybody. Tools to help there would be:

• Writing it on a big piece of paper and put it on the wall of the team’s location, next to / on the Scrum Board;
• Share it in a visible way digitally (helpful when not all team members are on the same location);
• Talk about it (at least in the Daily Scrum)

·        …

These are the most important parts in the Scrum Guide (2013) about the Sprint Goal:

Topic One: What can be done this Sprint?

…

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Daily Scrum

…

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

Wil ik mijn Product Owner wel in de Retrospective? (NL)

We hebben inmiddels 13 Sprints erop zitten, en eigenlijk is alles in onze Scrum inrichting wel op zijn plaats. In een van de laatste Retrospectives kwam de vraag ter sprake of het handig zou zijn om de Product Owner (PO) deel te laten nemen in die Retrospectives?

Allereerst kun je kijken wat Scrum daar zelf over zegt. Volgens scrumalliance.org (1) moet de PO hier niet aan deelnemen. Ze zeggen dat het een meeting is tussen het Team en de Scrum Master.

 

Voors en tegens

Scrum Master Jack Mulunsky pleit op blog.agilebuddy.com (2) ervoor om de PO wél te laten deelnemen. Hij vindt het belangrijk dat deze betrokken is gedurende de gehele development life cycle en daarmee ook invloed heeft op het succes van het team. Hij vindt het belangrijk dat het team “leert leven” met de PO. Dit is voor mij een argument wat ook zwaar meetelt, onze PO geeft uit die motivatie onze demo’s met het team.

Scrum Master Bartek Kobilecki vraagt op pm.stackexchange.com (3) of de PO bij álle Retrospectives aanwezig moet zijn. Zijn PO staat daar zelfs op. De Scrum Master vreest dat door de aanwezigheid van de PO mensen bevooroordeeld of op zijn minst met een voorbehoud zich zullen gedragen in de Retrospective. Dat punt zie ik ook wel, op zijn minst vanuit het onderbewustzijn, aangezien de PO toch de organisatie van de opdrachtgever vertegenwoordigt en daarmee een gevoel van een hiërarchische verhouding ontstaat. Daarentegen vind ik transparantie een groot goed, en zou je moeten werken aan het wegnemen van het genoemde voorbehoud door altijd open en eerlijk te communiceren. Opmerkelijk is wel dat Kobilecki de PO “de baas van de teamleden” noemt. Ik denk dat hij zich daarmee wat beter in Scrum moet verdiepen.

Radu Davidescu reageert op de vraag van Kobilecki dat het belangrijk is dat, wanneer de PO aan de Retrospective deelneemt, er de kans bestaat dat deze een groot deel van de meeting aan het woord is (en dat het team gaat zitten luisteren, red.). Hij vindt dat de PO dan ook alleen op uitnodiging van het team aan de Retrospective mag deelnemen.

Het team

Goed, meerdere argumenten dus. Overigens ook veel discussie over of de PO deel uitmaakt van het team. Ik snap de verwarring wel, maar als je kijkt naar de 3 rollen die Scrum kent: PO, Scrum Master en Teamlid, dan zou je kunnen stellen dat vanuit de rollen dat niet zo is. Vanuit de groep mensen die bezig zijn met het product en proces, zou je kunnen zeggen dat deze 3 rollen het team vormen.

Conclusie

Mijn benadering is eigenlijk heel eenvoudig, en helemaal Agile: we gaan het proberen en kijken of het werkt. Dan komen we te weten of de voordelen opwegen tegen de nadelen. En hier raken we dan ook wel de kern: de daadwerkelijke implementatie van Scrum is altijd anders dan de droge theorie, omdat alle organisaties en mensen anders zijn en denken. Zaak is dat je trouw blijft aan het principe van Inspect and Adapt en dat je het proces continue verbetert.

Referenties

• Glossary of Scrum terms:
  http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1113
• Should the Product Owner be an active member of the Scrum team:
  http://blog.agilebuddy.com/2009/04/should-the-product-owner-be-an-active-member-of-the-scrum-team.html
• Should Product Owner be present on all retrospectives:
  http://pm.stackexchange.com/questions/5681/should-product-owner-be-present-on-all-retrospectives

De zwijgende SCRUM master (NL)

Een bekend dillema, vooral voor SCRUM masters die een technische achtergrond hebben (bijvoorbeeld als ontwikkelaar): het team staat voor een uitdaging, en jij hebt ideeen over de oplossing...

Een lastige. Ik ken het gevoel. Maar als SCRUM master is je doel om je team te ondersteunen en stimuleren vele malen belangrijker. Wanneer je meegaat in de materie, verlaat je het proces. En ik ben van mening dat je daar altijd 100% bovenop moet zitten. Het kan wel zijn dat je een inhoudelijke bijdrage kán leveren, maar wanneer het team niet meer functioneert als team, verlies je veel meer. Een opmerking als "hoe zouden we dit kunnen aanpakken?" heeft zoveel meer waarde. Je team wordt dan gestimuleert om ideeen te spuien, te delen en als team na te denken, binnen de context die zij het beste kennen.

De manier en de oplossingen waar het team mee komt, bepaalt ook de kwaliteit en uiteindelijk de velocity van dat team. Als je daar, afhankelijk van jouw incidentele kennis, input aan levert en dit tevens ten koste gaat van het proces, gaat dit ten koste van de glorie van het team.

Wanneer je als SCRUM master en coach het proces zo optimaal mogelijk weet te krijgen, investeer je daarmee in de komende 100 sprints. En als je je overal mee wilt bemoeien, had je projectmanager moeten worden...

Frequent Agile Questions #1: Kan ik Agile zijn als de rest van mijn organisatie dat niet is? (NL)

Ik ben enthousiast geworden over Agile nu ik er over gelezen heb. Collega's die ik spreek zijn onverdeeld enthousiast. Ik heb de knoop doorgehakt en werk nu Agile en dat willen mijn klanten ook. Waarom werkt het nou toch niet?

Wanneer je besluit om Agile te gaan werken, begin je niet alleen aan een nieuwe manier van werken, maar ook aan een nieuwe manier van denken. De redenen waarom je de dingen doet die je doet, veranderen. Je verandert vaak van efficient gedreven werken naar effectief werken. Het is goed om er meteen mee te beginnen, maar tegelijkertijd gaat je organisatie een transitie in.

Van Waterfall via WAgile naar Agile

Je zult veel energie moeten steken in het promoten van de "Agile mindset" bij iedereen waar je mee te maken krijgt. Je hebt bij je development process te maken met Business stakeholders, grafische vormgevers, testers, functioneel ontwerpers, projectleiders (!), developers voor front- en back-end, etc. Hoe meer partijen de Agile mindset delen, des te beter werkt het. Sterker nog, in je eigen clubje kun je maar beperkt successen boeken. Want na enige tijd loop je tegen deze problemen aan:

• De business maakt zich druk over het feit dat je ze niet kan vertellen wat een project gaat kosten;
• De projectleider wil toch eigenlijk wel graag de scope vastgelegd zien, en graag in het begin van het project. Hij wil meer informatie vooraf, er moet tenslotte een PID gemaakt worden;
• De grafische vormgevers vragen zich van tevoren af wat ze allemaal moeten ontwerpen en achteraf waarom men zich niet aan hun design gehouden heeft;
• Developers zullen constant geneigd zijn om iets "helemaal af" te maken en passeren het incrementele principe.

Dat zijn dan enkele voorbeelden, ik denk dat ik er nog vele kan noemen. Maar als je aan de wieg hebt gestaan van het Agile werken in je bedrijf, zul je mijn voorbeelden zeker herkennen. 

Investeer dus tijd en moeite om dergelijke problemen te addresseren, en blijf iedereen vertellen waarom je het allemaal doet: stick to your principles. Ook en misschien juist bij tegenslagen. Vier je successen en deel ze met de anderen. Werk aan het besef dat je het allemaal doet om waarde aan de onderneming toe te voegen en niet om wilde ideeen te laat, met een overrun en verspilde energie uit te voeren.

Do the right things and do things right...

Implementing Agile: Quite a transition

A few days ago I talked to a (dear) colleague about his experience while implementing and starting up an Agile way of working at a large company. Yesterday again, I spoke to a dear colleague, and we basically all came to the same conclusion: implementing Agile certainly has quite a transition phase.

In my experience, people get very enthusiastic about Agile and they start working Agile. Then the frustration comes: Why don't the other guys understand that Agile is the perfect way of working? This is often the case when a small group starts adapting Agile, and they still have to do with "the other guys"... For example: the Business. The Business heard that Agile is fantastic and that you really should be Agile and that it will create value for them. Only; why won't anybody tell me how much things cost? Where is my estimation? When will it be ready? What's this thing about flexible scope?

In my opinion, this illustrates how important it is to guide a company when implementing Agile. Not only it gives the developers a chance to do the right things and get used to it (get velocity) but it makes clear to the business it's not just some methodology, but a mindset, the Agile Mindset. And it will save both parties, and others from quite some frustration.

The Agile process: A fast running train?

Came up with this title during a meeting I had today with some colleagues. It was a meeting which I dialed in remote, so I had a disadvantage from the beginning, but that's not my point.

If you put a lot of people into a room, all of them will probably have something to say about 80% of the issues you're talking about. That's what we're experiencing in our Agile process, and a lot of that is good. Everyone knows what it's all about and everyone can have his say, so no-one is left behind or in the dark.

The problem is, that meetings like these are usually more of a brain storm session. We are doing Agile with SCRUM, so you need to take care of the fact that the actual work should be done in the Sprint itself. In that Sprint you should do people in what they are best.

In my case, I'm looking from a Usability perspective to a project and the team is really brainstorming on a lot. And making decisions while pokering. In Agile, that usually is not a big problem, if you have ideas on improvement, make a new story and if that delivers business value, develop it. But in a lot of cases, certainly in ours, we've experienced that those improvements are not often developed because the project has no budget. So if I want to make Usability improvements I need to fight for that and try to get my point through in the discussion. Well, that's life for a Usability Analyst, I know.

How would we improve that and be more (mature) Agile?

• Recognize the right disciplines in your Agile team, like Usability, Testing, Front End Development, Back End Development, Content Design, Business Process Analysis, etc.;
• Don't design too much in the poker sessions, make sure that the idea of the required functionality is clear so the team is able to poker it;
• Recognize that design (not only visual but also functional, navigational and content design) is part of the development process;
• Choose some form to be clear and unambiguous about function, form and interaction. I prefer making a clickable wire frame or prototype, with detail in those areas where needed;
• From a budget perspective, be clear that your entire budget shouldn't be gone when the stories are finished. That's more like a form of waterfall where you just use the budget and then development is ready. Maybe there's is Business Value in there, but in Agile you should be both iterative and incremental. Do do this properly, you need releasable versions you can make improvements on;

If you do this, you will deliver more Business Value. If you don't do increments, you are still trying to do everything in one shot; and that's not Agile. For the same reasons I make wire frames to let my stakeholders see what the effect of decisions is and what value it delivers, you should do that with the releasable product as well. 

I've been experiencing the implementation of Agile / SCRUM in a large company for quite some time now, and I realized quite awhile ago that the change from Waterfall to Agile is not only learning a new methodology. It's not only changing your mindset, but also recognizing that the current situation is not Utopia, but it should be the road to it. You should always think about these things:

1. How are we going to do things best in our current environment and situation?
2. What is the ideal way of doing things?
3. Who do we want to be and what do we want to achieve?
4. How do we get there?

There's no mistake: going to be Agile needs change management. In the spirit of SCRUM: use retrospectives  to consider how we've done and what we need to do, because doing that is often forgotten in the delusion of the current day.

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.

Twitvertising?

This week, I realised that Twitter is in danger of SPAM. Or will it be an enrichment? How Twitter can be used for targeted advertisement.

This week, my car needed a checkup. Since I do things digital as much as possible, I made the appointment with the garage by internet. That went quite well. Because I needed to transport quite a lot of stuff, I asked for a bigger car. I have a Volvo V50 myself, and they gave me a Volvo XC70 AWD T5. That's quite a car! I was very happy, 'cause the stuff I needed to transport was so much, that it hadn't fit in my own car. It just fitted in the XC70. I was happy with the car, because it still was very fast and had no problem with the weight.


After I returned the car, I tweeted this message:

"Today I was happy: car was serviced and the temp car was a brand new Volvo XC70 - happy me!"

...Image my surprise - yes, I really was surprised! -  When I got this reply:

That means Dealer24x7 is running an engine to search tweets about car brands, and then replying to it! How brilliant is that!

Of course it can mean, that if more -and also sleezy- companies and advertisers start to do this, Twitter might get flooded with advertisements. I wonder what happens. What I know for sure: Twitter will live on for some time...

The Secret Powers Of Time

E-mail is dead...

Site specific browsers

As defined in Wikipedia: "A site-specific browser (SSB) is a software application that is dedicated to accessing pages from a single source (site) on a computer network such as the Internet or a private intranet. SSBs typically simplify the more complex functions of a web browser by excluding the menus, toolbars and browser chrome associated with functions that are external to the workings of a single site."

So, basically, this is a browser, disguised as an application? We already knew that browsers now act as new layer between the Operating System of a computer and an application, and is not just for browsing through pages of content. A simple step like this might be a step forward to better integration between your desktop PC and the internet, and thus the differences between applications and web (applications) will fade even more.

In his recent article "Exciting web browser trends in 2010" Devindra Hardawar describes that currently only Google Chrome supports this (just use the "create shortcut" option on the upper right). And in fact, it is quite handy! Devindra says in 2010 more browser will support this, and I agree on that. It isn't a too big thing to implement, I guess.

The most importent thing is if the users will start using it. I did. I use Google's Wave for some weeks now, start Chrome every day to check my mail and found out it is very convenient.

This, in combination with products like Adobe's AIR will bring the internet closer to your desktop and perhaps will bring even Microsoft Windows, Apple OS and Linux closer together.

References: http://royal.pingdom.com/2009/12/21/exciting-web-browser-trends-in-2010/

Don't take your random() for granted...

In my current project, we use a functionality which chooses a random colour for a machine. To do this, we need to select a colour from a set of 8 colours. In our Flex application we use a function called randomInt, which generates a random integer between a and b:

public static function randomInt(a:int, b:int):int {
return Math.round(Math.random()*(b-a))+a;
}

Usually we look for functions like these on the internet, but I’d like to emphasize that you also should unit-test functions which are made by others.

So I’ve generated 5000 integers between 0 and 20 in a test application, and put that in a graph:

Note that the numbers on the boundaries, 0 and 20, are significantly chosen less times than the others (1-19). This would mean, that if this function is used for picking a random machine colour, the colours 0 and 7 have only a 7% chance to be selected, while others have a 14% chance!

I’ve talked about this to someone who knows a lot of these mathematical things. The problem is the rounding. Since Math.round() returns a pseudo-random number n, where 0 <= n <>

We need to include the boundaries to produce a evenly distributed random integer. This is the new function:

private function randomInt(a:int, c:int):int {
var b:int = c + 1;
return Math.floor(Math.random()*(b-a))+a;
}

Doing the same test, produces this graph:

As you can see, each integer is chosen about the same number of times. Now we know for sure that colours 0 and 7 won’t stay in storage, but are also sold!

Nomads in IT...

Yesterday I was present at a job interview at IT.

I represented the technical guys, though I'm more a User Experience Consultant with technical background, but my job is mostly technical right now.

The guy who had the interview was somewhat the same, only a bit more with a designer's background.

It was suprising how difficult it is to find the right position for a User Experience Consultants, especially in the technical department!

They belong nowhere...