Agile User Experience

Editor's Notes

• #3: If we check our agenda;At the first part of my presentation, I will try to expose the need for Agility, starting with some statics. Then we will move on to the expectations from software projects from different views points and at the end of that section I will be talking about the Agile Manifesto.After defining the manifesto, I will be explaining the user experience, the very broad term, from risk management perspective which requires agility.Then finally I will be talking about the UX professionals inside the agile teams and a little bit culture issues.And after all, the questions..
• #4: Standish group is an IT research and consultancy company that prepared a report called Chaos Report about the success of It projects over the globe. This is their 2009 results. We can define a successful project as; it’s finished on the date planned within the planned budget and with the functionality promised. As seen here only %32(thirty two percent) of the project are successful due to our definition.%44 of the are either late, off budget or delivered with less features. And finally %24 of them are unfortunately cancelled. If we consider the big picture, we see that about %70 of the projects are not successful because of some reasons. Or %70 of them has poor quality, or lost time to market advantage or expensive.By the way, 95 reports are much worse than that. I think we are learning how to do that.
• #5: There is also the Gartner’s reports which are very similar to, actually worse than, Standish groups statics. We see here that half of the project’s exceed their budget by %200, which means that those projects are probably late..There is something wrong with this picture. So let’s put our selves into the position of our customer’s. Customer’s do want something and they can not get it. So, there are expectations from the software projects. So the question is; what do we expect from software projects both in terms of the process and the product itself. Please tell me what would you expect?
• #8: Now let’s compare two approaches, waterfall and agile from different perspectives. The first one is time-to-market. Let’s assume that we are developing a software project with conventional methods, waterfall. That is the level of value that we want to achieve. We started with the analysis, let’s say it took 3 months, than design and coding and testing. And we delivered the project at the end. There are 2 main problems that may arise here. The first one, the market needs are changing while the project is being built and it’s nearly impossible to produce a product with such a strong prediction to see the needs after a year.Second, since the customer was not present during the project, there may be many misunderstandings which may result in a lower value than the expected, even if we predicted the future.Then the customer needs some change to catch the target value. Then we again make some analysis and design and coding and testing, but now we have a bigger system and it’s really hard to respond quickly towards the need of change. Also our process and software is not flexible enough to catch that. This is the scenario of legacy systems. We all have them in enterprises. They have low quality stuff in it and total cost of owner ship is really high.So, as we work, we see that, we have no impact on the market until the delivery of the whole system. We can make some phases as a work around but it still is a masterplan that should not change. This is just a work around.What we did here was, we tried to get all the requirements at the beginning for the perfect design. So we go to the customer and say “tell me everything that you want so that I can make a good design. But beware of changes because you can not change any thing during the development”. So, what customer does is easy, he writes every thing down that has a possibility of creating value. That is one of the points where the problem arises. So, standish group has another statistics, it says, %45 of the functionality delivered never and %19 of the functionality is rarely used.So, let’s take it the other way and try to see. We have a set of prioritized requirements and we deliver them. The customer is also working for the others while we are developing. Then they give feedback and another set of prioritized requirements. And we develop them. Since we are going small and getting feedback earlier, we get less risk and we always deliver high business value. We do not deliver useless functionality at the end. All the pieces of the software we delivered is working and customer can make money with it. This how you achieve a better time to market advantage. We can see the impact of time to market in Kodac insights report 2009. If you push your product to market earlier, you get a higher cash flow.
• #9: Let’s look at the situation from cost of change and quality perspectives. This the exponential curve of Bohem. The later you realize, the more you pay. When we consider the conventional methods, you see the need for change at the end which is most costly region. So, we need to optimize this point. With an agile approach of delivering working increments of software, you reduce the costs by catching the errors earlier. This result in a more linear graph because we test earlier and through the whole process.
• #11: So, seventeen software gurus came toger in Utah in 2001 for a 3 day event for better software products and they had a conclusion. This is the result, the Agile Manifesto. Go through each of them.
• #13: Nowadays, many of the companies around the world are using Agile methods to deliver software. Nokia, Yahoo, Google, Microsoft and many others..When we look at the succes rates, which is published by Version one in 2008, %55 of the respondents says to %90 to %100 of the cases were resulted in success.Katilimcilarin %55 I projelerinin %90 ile %100 ununbasarilioldugunusoylemis.
• #14: Now, let’s talk about usability and usability from the perpective of Agile.
• #15: When we check the user experience from a web perspective(it can be an application, too), with Jesse James Garrett’s five levels of user experience, he defines the user experience with 5 planes which I also think makes sense. By the way, this is a very popular and an easy structure to apply, actually he defines this as a framework for designing the user experience. The the first leg is the strategy layer. This is the idea and the place where we ask the question of what users want from this pageSecond level is the requirements. We know the vision and the need, so we can create some scope that can satisfy the need. This is where the functionality and the features takes placeThird level is the structure of the site. How you are going to organize the interaction of user with the functionality. Then we have the skeleton of the site. This is where we have the placement of buttons, controls, images and etc. All of these are placed in a skeleton for better user experienceFinally we have the visual design at the surface plane. These are the colors, images, text fonts an etc.Each level depends to the levels underneath. So, when we look at a web site or an application, what we are going to see will be all of this planes that are creating the user experience.At this point we are considering the requirements as at the very lower levels of this structure, which means, requirements are an important part of the use experience.
• #16: Let’s get back to what I have said about requirements before. It’s hard to define everything upfront and as the requirements change, it may drive change in structure, scope and the surface. Conversely, if there is a user experience problem at some point, it may require a change at the requirements too.UX design degismeyecekdesen, requirement degisiyor. Bu da zaten UX design in onemlibirparcasi, bu da sistemicinbir requirement oluyor.
• #17: When we look at the Winston Royce’s model, you again have to think about the user experience up front. But the requirements will change and we have to manage that change in terms of user experience too. If we do the user experience testing at the end, then we have to be ready for serious changes which is very risky and costly. We can have user experience testing through an agile process which will reduce the risks.Burada da requirement ve design arasinda en iyi user experience I tasarlamangerekiyor. Eger takimindaboylebiriyoksa, boylebirprojedeki en buyukriskin, is ciktiktansonrafarkedilenuxhatalariolacak.
• #18: Inspecting over working software will create better results in terms of user experience testing. Here is how user experience is achieved more easily.First we create the working software increment, which is a prototype. Then the user experience testing of this prototype is made at the end of the first iteration by the users of this product. Then create the other increment. While we are creating the increments, the user experience designer can collect some data from the users, or he can create some low or high fidelity wireframes or he can use wizard of oz testing for future increments. So, the tests will come up with more requirements including the UX This will bring the user experience design to an agile team. This does not mean that the whole process is based upon user experience but we can add some spices.Buradaiseiceridebirux designer in olmasadaha, prototype uzerinden test yptirdiginicin, ux de ototmatikolarakherhangibir waterfall design a gore cokdahaiyiolacak.
• #19: Since the nature of agile is based upon frequent inspection and adaptation over working software, we are going to have a better user experience which is being built naturally with the real users testing the application much earlier then expected.
• #21: So, now, the question is, can we have any ux people in our teams? The basic structure of an agile team is listed here. With the basic definition there is no evidence that agile teams can not have ux professionals. They can have more than that.Tell each of the sentences seperately:Self-org: self managing, micromanagementCross-functional: no taylorism, no roles, only skillsHighly productive: autonomy, mastery, purpose + communicationCreative: They have space for it. They have to find their solutuions for the problems.
• #22: You can do the following to add some ux design skills into teams.