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.

Customer Experience and User Experience

"The customer is always right"

"Know thy user, for he is not thee"

A marketeer looks differently at an online customer than a web designer. A Usability Analyst looks differently at an online user than a web designer. So do marketeers and Usability Analists look the same way at an online user?

In the real world: they don't. But I think they should. We all know that a website is not a pure technical thing, neither a pure marketing and sales thing and neither a pure user thing. These three forces work together and since the beginning of the internet, the technical forces always been stronger than the others and in the last few years the marketing and sales force has become one of the strongest forces: we need return on investment!

Lately, organisations start to realize that Usability of a website is very important. If your website is not usable they will leave. And even worse: if your competitor's website is more usable, they'll use that one because the User Experience is better!

And a good user experience is the basis for a good customer experience. For a good customer experience you need to look at the whole customer life-cycle. Huub Esten, my collegue at Capgemini says: "You need to be the best in one part and at least as good as the others for the other parts of the process". Especially when your company does online business, awareness of Usability and User Centered Design is key.

In his latest "Alertbox", the Usability guru Jakob Nielsen told about a research where they found that if your webpage has about 111 words on it, about 50% will be read. With more words that percentage drops fast. So tell that to the marketing people: your customers will read only half (or less!) of what you need to say to them.

References:

• "Wat doet de Customer Experience Methodiek?" (dutch), Telecommerce Magazine, Jaap van Sandijk
• "How little do users read?", useit.com Alertbox, Jakob Nielsen

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.

Rich Internet Applications in your company: Things to consider

Why should you use Rich Internet Applications in your company?

The answer is quite simple: because it's better. It solves a lot of usability issues and technical shortcomings, especially on your webpages. It is even so much better that applications can be created for a web browser which earlier would be developed as a desktop application because of the limitations of the web.

I am not going to tell you what the advantages of RIA's, you can read all that everywhere, for example on Wikipedia.

Here are the things you should consider when making the step:

How service oriented is your company?

This is a technical thing. Maybe you've heard of SOA (Service Oriented Architecture) or SOE (Service Oriented Enterprise). It basically means that you will take the front-end (the interface) apart from the calculations, rules and processes (business logic). These are going to be seperate applications: services.

This means that any application can use a specific service to get it's data. For example a service to give pricing information on you products. An application can use this service to get product information without doing any database stuff or permission stuff or anything. It doesn't have to look if the product is in stock or anything, the service does that.

The services can be introduced step by step and old applications can be rebuild to use these services and so remove their own business logic. So your legacy can stay or fade away in time.

How can we develop RIA's?

Currently a growing number of developers are learning how to create RIA's. The leading technologies are Adobe Flex (based on Flash) and Microsoft Silverlight. Research of The Butler Group in June 2007 state that also Nexaweb and Sun Microsystems are major players on the 2008-2009 market. You should also consider Backbase, edge IPK, OutSystems and TIBCO.

Your developers will be more front-end or back-end oriented and they should speak eachothers languages to be able to communicate.

The way a RIA project should be run differs from a standard ICT project. It should be user oriented, business oriented and technology oriented. In "classic" ICT projects the user usually is forgotten. To improve the user's experience this is neccessary to make the project to a success.

This takes care of problems you usually experience after the product is launched. Redesigns, remakes and fixes then usually cost 80% more and doing a user centered design takes care of these things in an earlier stage, when changes are much cheaper.

Will my users understand this new stuff?

Yes! Ofcourse currently there are not a lot of RIA's online, but the number is growing. Because of the user centered design, the learning curve for the user is short and the benefits are instantanious. Maybe your users won't notice that they are working with a RIA, but they will be happy about how everything works.

Don't do too much!

Don't make your website one big RIA. You will run into big problems (Google-ability, print issues, etc.). Take the "application like" things, like the order and checkout process, searching and selecting things or processes with a lot of forms or form-elements in it. Make a hybrid website (part HTML and part RIA applications).

Okay, nice. But where should I start?

Start with your most important website or the site a lot of people complain about. Make an inventory of the problems. Let a Usability Analist (like me ;-)) do a Usability test and let him/her make recommendations. Then you can start considering technology things to work on those recommendations.

And do not forget: Define what your goals are! State how much more products you want to sell, by what percentage you want to decrease the number of helpdesk calls, etc. Quantify them!

Do testing in early stages. The sooner you discover problems the better (and the cheaper to change). Also test afterwards and monitor if your goals are met and why or why not.

Don't start with too large projects. I can tell you a hundred things about how to do things, but each company has it's own politics and ways of doing things. You can get accustomed with that in the first smaller projects.