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...

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

Customer Experience Is Usually Very Poor

(I didn't finish this article, and to engage myself in finishing it, I post it as such.... Yes I will finish it soon!)

this article will be translated to English


Uit een onderzoek van Forrester uit 2008, waarin zij aan klanten vroegen naar hun ervaringen met verschillende bedrijven op het gebied van bruikbaarheid, usability en plezier, bleek dat ANWB winkel, Esprit en de Bijenkorf aan de top staan in Nederland.

Forrester stelde uit die gegevens de Customer Experience Index samen. De lijst omvat 57 bedrijven, waarvan er slechts 6 een waardering "excellent" kregen. Daarentegen kregen 30 bedrijven de waardering "slecht" of "zeer slecht"...

Wat valt er op aan deze onderkant van de lijst? De bedrijven uit de lijst waren grofweg ingedeeld in 5 branches: retailers, banken, energiebedrijven, internet service providers en mobiele telefonie bedrijven. Wanneer je gaat kijken wie er aan de onderkant van de lijst staan, valt het wel op dat de energiebedrijven het wel heel slecht doen:

25e plek: Greenchoice
45e plek: Essent
47e plek: Eneco
48e plek: Nuon
52e plek: Energie:direct
55e plek: Oxxio
56e plek: E.ON
57e plek: Nederlandse Energie Maatschappij

Alleen Greenchoice krijgt een waardering "okay". Wanneer je in deze lijst onder nummer 37 staat, is het niet best met je, de waardering is daar ronduit "zeer slecht". Valt het u op dat het 2e energiebedrijf op de lijst Essent op nummer 45 staat? Niet zo best dus.

De energiebranche in Nederland doet het dus het slechtste op het gebied van Customer Experience. Overigens doen de Internet Service Providers het net iets beter, maar worden nog steeds gewaardeerd als "zeer slecht".

Waarom zit het nou in die specifieke branche zo slecht? Ik ben 2 jaar gedetacheerd geweest bij één van de genoemde energiebedrijven, dus op basis daarvan kan een ik kleine analyse doen.


The Experience Economy


Het draait erom in hoeverre het belang van Custromer Experience meespeelt in de bedrijfsprocessen. En dat begint met het erkennen en willen dat het bedrijf zich onderscheidt in Customer Experience. Vanuit de gedachte dat je niet in alles de beste kan zijn, moet je in alles even goed zijn als de concurrent en in één ding uitblinken. En aangezien de economie nu steeds meer draait om Experience (zie: The Experience Economy [Pine & Gillmore, 1999]), laat dat dan dat ene zijn waarin het bedrijf uitblinkt. Uiteindelijk zal het voor energiebedrijven zeker zo zijn dat de tarieven overal net zo scherp zijn, de stroom net zo groen en de energiemeters net zo slim.


Als je de volwassenheid (maturity) van Customer Experience in de organisatie in de volgende niveau's verdeelt:

1. Interesse


2. Er wordt in geinvesteerd


3. Toegewijd


4. In ontwikkeling


5. Opgenomen in de organisatie

Kunnen we met zekerheid zeggen dat energiebedrijven niet veel verder komen dan niveau 1. De interesse is er in die zin, dat er veel over gesproken wordt en dat eigenlijk wel iedereen er het belang van inziet (85% van de bedrijven bevestigen dat zij het belang van een goede Customer Experience inzien). Uit mijn ervaring kan ik zeggen dat die interesse er eigenlijk nu zo'n 2.5 jaar is. In de 2 jaar dat ik bij het bedrijf werkzaam ben geweest is er ook echt wat mee gedaan, maar dat kwam voornamelijk omdat ik daar persoonlijk de focus op legde, maar niet omdat dat door de organisatie gevraagd werd. Dat ze nog niet bij niveau 2 waren, was duidelijk doordat er geen ruimte voor was in planningen en allocaties.

Daarnaast wordt vaak Usability, User Experience en Customer Experience over één kam geschoren. Wat zijn dan die verschillen? Mijn definities zijn deze:

Usability

De gebruiker wordt goed ondersteund doordat de best-practices in het design zijn toegepast. De interactie is consistent, navigatie is duidelijk en indien nodig wordt de gebruiker op weg geholpen. De gebruiker raakt niet in verwarring, vindt wat hij zoekt en begrijpt waar het over gaat doordat het intuitief werkt of goed wordt uitgelegd.

User Experience

De gebruiker krijgt ook een bepaald gevoel tijdens en na het contact met de website of applicatie. Dat gevoel dient prettig en passend te zijn. Hij moet aan zijn vrienden kunnen vertellen dat het gebruik van de website makkelijk en leuk was. Omdat de resultaten naar verwachting waren en het "servicegevoel" in lijn met de norm van het bedrijf.

Customer Experience

Hier verandert de gebruiker in een klant. Op dat moment spelen er subtiele andere gevoelens mee dan in de User Experience. De klant moet overtuigd raken, onderhevig zijn aan bepaalde emoties en vertrouwen hebben (zie: How to Design for Persuation, Emotion, and Trust [Human Factors International]). Een gebruiker moet gewoon de dingen kunnen doen die hij moet doen, een klant moet daar ook zo'n positieve ervaring bij hebben dat hij ook terugkeert en beter nog: het bedrijf aanbeveelt bij zijn vrienden en kenissen op verjaardagen (zie: Net Promoter Score).

Waarom zijn dan de energiebedrijven hier zo slecht in?

...

Yes, you really should do Usability Testing!

You should do Usability Testing. Really. When you create a new website, Usability Testing should be part of your project.

If not, it will cost you more money and less people will use, visit and like you website.

Why?

Simply because you are not the user. It is really impossible for people in the project or even in the company or people in the web development business. You have no idea how the visitors of your website experience the site. An you surely will agree that you want them to like it and use it?

What's the occasion?

At the company I work now, we've done a redesign project of their new website. A Usability test was done (by another company) on the old site. I started to work on the project when it actually was started already. So in fact I was a bit too late. But I tried to make the project work by introducing User Centered Design (UCD) to them. And Usability Testing is part of UCD.

What I've done.

I couldn't do the whole UCD process, but I did some parts to catch up and ensure that the project would be a success. Since you may not know what the UCD process is, I will tell you what I did in this perticular example.

I made personas. Personas are fictional website visitors which fit the main profile of the visitors. This profile was determined by talking to the Business people about who their customers are and on which they target. I made 3 Personas.

The website was graphically designed by a design company who seemingly didn't have too much website design experience. They still designed for print instead of the web. And these are really different!

When we saw the first designs, I knew we had a lot of work to do... I won't get into detail here, but I made quite some remarks on Usability issues. There are a lot of things about the use of colour, contrast of colours, position of elements, what kind of buttons to use, the use of bread crumbs, and so on, you can tell in advance they won't work or confuse the user.

At the end, I've won on a lot of parts, and some parts were left as is. They probably would be exposed in an Usability Test!

Functional testing

Using the Personas, I made some scenarios with the Business people. The scenarios represented the most common and most important scenarios on the website. The developers of the site should consider if the Personas would be able to complete these scenarios. I sent the scenarios to the Business people and asked them to make it part of their test-plan. The company has a low maturity on testing, so it also stimulated them to make testing, in fact, functional testing, more important.

The testing process started a bit uneasily, but after all it was done quite well.

The Usability Test

After the site was developed and functionally tested, the company decided it should go live and then do a Usability test. Well, it would be better to do the Usability test first. But hey, as I told before, I got into the project a bit late, so it was a bit hard to change the planning for this.

And it wasn't too big a problem, since I could do the test right after the site went live.

No or low budget Usability Testing

I've done a cheap Usability Test. This meant that I invited some friends and acquaintances to participate in the Test. They've never done a test like this and they hadn't seen the website yet. I drove to them in my car, so that cut down on expenses.

When I designed the test, I used the Personas to pick the participants and the scenarios to perform the test. I used a demo version of a screen capture software package to record what the participants did.

I told the participants that they were not doing an exam, and that if something didn't work or was difficult, the website was to blame. I asked them to perform the scenarios and cleverly avoid any questions they had. I was an observer and nothing more. This simulated the situation they would be in when they visit the site from home or somewhere else without anyone around from the company itself!

I also had a questionaire about how they liked the site, what they would change etc. And finally, as a bonus, I gave them a sheet with keywords like "nice", "ugly", "easy to use", "family like", "professional", etc. and asked them which keywords fitted the website. The results of this can be used to match them with the ones the Business people would like to represent the company.

All went well and it took me about 24 hours all together to design and take the test with the 5 participants!

Last monday I made the presentation to present the test results to the Business people. And again, it really surprised me! Issues arose about which I haven't thought yet and offcourse also some issues which I predicted when the design company presented their design ;-).

Now what?

Doing a Usability test before you even develop the site, on a paper prototype or prototype, will reveal 85% of the Usability issues inyour design. You should do the test again when you have developed a first version. It will again reveal 85% of the Usability issues. After some iterations, when the site is live, you should continue to do Usability Tests. The science of Usability changes, and the way users behave does.

What will this cost?

Early Usability Testing is much cheaper. The costs of fixing the issues from an Usability Test in an early design stage are at least 5 times lower that when they are fixed after the site has gone into production.