robjam.es

I know there is a lot of developers kicking and screaming when they see this, but hear me out, as it is important for the success of your project/product and your sanity and the business being happy with you as a developer.

Lets get one thing straight; REQUIREMENTS WILL CHANGE! I cannot stress this enough. What project (beyond the most simplistic) have not had requirements change? If they changed because someone didn’t provide enough details in the first place, or the business forgot something, or the market environment has changed, or a plethora of other reasons; it doesn’t matter. The business isn’t changing requirements to piss you off, they are doing it because one of the above reasons happened and they need to make the change.

Now that you are all angry at the above paragraph, it is time for the good news; a system to make it work!

Firstly, I would hope by now that you are using an Agile process to develop software, and my solution only works if you are doing Agile development. And when I say “my” solution, its not mine at all, but just my way of implementing what Agile tells us to do.

Since you are doing Agile you are using an iterative approach. My personal preference is to take the fixed timeboxed approach versus what Scrum tells us to do which is a variable timeboxed. In a typical fixed timeboxed approach, I generally like my iterations to run for 2 weeks. This is because in the 10 working days we have, this is usually enough to have 1 day at the start to plan the iteration, and get all the story details out, the last day to get the iteration build out (although this should not take the day at all) and 8 days to drill out the dozen or so stories you have prioritised for this iteration.

This iteration release is locked. So when the business says we need to change the requirement, tell them it is not going to happen in this iteration. Whatever the new requirement is, write up the stories, and add it to the backlog and then get the business to re-priorise the backlog for the next release.

There is only 2 times that you should effect what you are delivering for this iteration, and that is when the requirement is not a requirement change at all, but further details about a story you are currently working on that won’t effect the estimate. Ie/ “When creating the login screen, we want the word ‘account’ to be replaced by ‘username’”. But if the requirement is, “We no longer want the user to login with a username, instead they are to use an email address”, this is a “We’ll have to add a new story and prioritise for the next iteration.” In this second scenario, although as a developer, you may write some redundant code to implement a username, don’t worry, all the other stuff is valid (password checks & validation etc), that it would actually be more disruptive to drop this story altogether to start something else.

The other time that a change to requirements can effect a current iteration is when the change is actually making an existing story totally redundant. ie “We no longer want to have a username/password for login, but want to just use Open ID”. In this case, if you are currently half way through the login story which is going to be a total waste of time, its time to drop it and roll back the code that you wrote. BUT, and very big BUT. This doesn’t mean that the new requirement becomes a story for this iteration, it goes into the backlog to be prioritised for the next iteration, or at best, goes in the “unplanned stories” bucket for the current release but is the lowest priority. This is slightly controversial, and that is because you may have planned to deliver 28 points in the current iteration that has a capacity of 30 points, and by dropping the login story, you have saved 5 points and consequently are down to 23 points. That is fine, if we really do save ourselves the points, we’ll get to it at the end. There is a conscious reason for doing this; mainly it is to avoid the knee-jerk reaction to adding new stories. It buys some time for the business to really think through why they are adding this requirement, and secondly, it is a way to apply a “cost” to the business for changing a requirement. I know you are all thinking that we are punishing the business, and although this is not entirely true, it is partially true, because the reality is that changing requirements is extremely disruptive to the current iteration, and its always best to continue with what has been planned.

By applying these rules, you continue to set an expectation of what I called the “heartbeat for the project”. If you are running fortnightly iterations, then everyone expects to lock in the stories during the planning meeting, and they also know that the stories will be delivered in 2 weeks, and this will be consistent. Routine is not only good for babies. It is good for all of us!!

If you have a business that is really unsure that of what they are doing (and this happens, and is quite fair, if they are still brainstorming some of the requirements), you may want to shorten the feedback loop. The feedback loop is the time you have to get working code from an iteration out for QA or the business to test and validate. So you may want to run 1 week iterations. The only thing to take into account, is that you will not be half as productive when you half your iteration cycle. This is because you still need to go through the planning cycle. Although you may be delivering 30 points in 10 days, you will probably only be able to deliver 10 points in 5 days.

But this is a sure fire way to keep yourself and the business sane and happy, by putting in a process that allows changes to occur immediately, and to be implemented in no longer than 2 weeks (or the length of your iteration).

Often we find the challenge of turning an idea into reality quite daunting. And rightly so, its not easy. But the fact is, if you apply a) a process, and b) the discipline, you can get this done.

The discipline is difficult and really up to you, but the process can certainly be challenging, and this is something I can hopefully help with. Before we get into a process (which I am going to keep simple for this first post), there are some principles that you should also keep in mind. If you have ever heard me speak, these are the principles that I always go on about, and here they are in an abridged version;

• Keep the idea simple, you may have grand plans for it, but what is the simplest thing you can do to get into the wild. I call this your Minimal Success Set. Which is the minimum amount of features that you can apply to your product for it to be called “a product”
• Don’t worry about problems you don’t have. You will start thinking into the depths of the different challenges you might have, but if they are not holding you up now, don’t worry about them. In fact, this is the best time you don’t have to worry, and you can start building, because you are starting from a fresh slate.
• Can you operate or support the application when you go live? Think through the details of what happens once you get it into the wild, will there be human processing that will need to occur, even emails that will need to be processed. You need to consider what the impact of this would be. I once worked on a project that required human intervention to process every subscriber’s content on-line. Seemed like a great idea, and the impact was 30 minutes for each account. But when we analysed this, I could only process 16 subscribers per day, but that meant I was just processing subscribers, and the costs were not significant enough to hire someone. So I had to re-engineer this concept real damn quick!

There are many other important principles, but these three are the good ones to consider when starting out. The next step is to have a process; and by the way, the process will help you with your discipline, because you will see a solution to deliver a product.

The below process is based on a more detailed 9 step process (which I am going to publish in the next few days). This subset is a great start. The first 6 stages focus on the areas that a product manager would be concerned about. The last three are more technically driven. All-in-all, this is what I call a top-down or user centric process, which not only works really well, but is also accepted as best practice these days.

Here are the 6 user centric steps in the process, with some detail;

1. Brainstorm to firm up the concept.

You have an idea, now you have to make sure that it is valid. I am assuming that your idea has a commercial benefit, so you therefore need to make sure that it is commercially viable. This is also the time that you want to try and take the steps where you minimise what you are going to deliver, and start doing some thinking about how the customer will interact with your application. Start to answer the questions like; what will this thing do (and NOT do) in the first release? How will it make money? How much of my time will it need after it is launched? What kind of customers do I want, and therefore, what is my product’s personality? Minimise, minimise and minimise again, until you get down to what the absolute basics of the application are.

2. Write a scenario

Earlier this week, I wrote a post on how to write scenarios, they are extremely useful at this stage. They describe your users and the process they would go through on your site in plain English. It is essentially a creative writing piece. You come up with a model for your user, you then describe in a step-by-step format on how the user will accomplish their goal. A scenario models only one path, usually the most common path a user will take. And often can include the intention of multiple users. Don’t omit this step. Scenarios are fun to write, and because they are usually not constrained by technology are generally going to be the best experience that a user can have in the application. When doing the next steps, you always come back and compare it against your scenario.

3. Sketches

Use paper, whiteboards or software tools if you are comfortable with them. Start to sketch out how the screens will work. Try and put as much detail as you can, but also try and minimise as much as you can. Don’t skimp out! It is so easy to say “and after the user clicks the submit, they see a confirmation screen. We don’t need to sketch that – its straight forward!” No its not!!! You are a) leaving yourself open to interpretation and b) not apply consistent behaviour. If you assume that the confirmation screen is just another screen, what purpose is it really providing? Just another screen? What can the user do here? How do they get back? Can we just show the same form with a confirmation message? Can we show a details page with a confirmation message? Could we simplify with Ajax? until you actually do it, you don’t know. Remember, it is easier to screw up a piece of paper than to refactor code, and change application behaviour. This is also a good time to take a friend (you trust) through your application, and get a second opinion.

4. Design

I find the design really important. This is where you start to get a feel for your application, particularly its personality (Something I think is very important). Work on a template design, something that you are going to apply to all your screens, then start working on a couple of screens. Try to use the correct copy instead of Lorem Ipsum. You will start to get a feel for the application. Think about the personality of the application based on who your potential customer will be. If you are targeting a youth market, then is your app look-and-feel ‘youth’ like? Does it come across as a 18-35 year old? Do you envisage the customer and the application having a relationship with each other? Work on the design until you think you have nailed this. Although with style sheets, you can always change the design, getting it as close as possible at first, means that you make lighter work later.

One thing that I will also add here that I like doing, is that I like to make sure that I leave some flexibility in my design. Things like size of titles, colours etc. The reason I do this is twofold; firstly, you just don’t need this detail, and secondly is for psychological reasons. As you go ahead to build and test your application, you are looking at your screens day in and day out. You quickly get bored of them, and start asking yourself the inevitable questions of “did I get this design right? Seems stale now, what can I do to improve it?” By adding the missing design elements, you tend to find that you keep it fresh and stop second guessing yourself. Again, just something I like doing.

5. HTML Screens

OK, once you are happy with the fundamental design, it is time to start building screens. This is where, if you didn’t cut any corners on Step 2, that you will find this to be an easier process. Mainly because you start to identify similar screens. Again, do your best to not cut corners though. Build every screen that you need, as it will make your coding experience much more pleasurable. If you can walk through your scenario using HTML screens, you are doing quite well. And you are half way there.

The interesting thing here is, how far do you take your Ajax at this point? With frameworks such as Rails and Grails, many of the Ajax functions are available out of the box, so you may not want to hand build everything in the HTML. I use grails a lot and what I like to do at times, is when I have taken my HTML screens to the point that I am writing Ajax code, I now start writing the HTML within the Grails framework, which means that I start building the actual Ajax around the framework tools, and also start putting real links without any real logic behind the scenes. This should be pretty straight forward, and again, make lighter work for you in the future.

6. Write the code

This is where you start finishing the project. Notice I say finishing, and in some ways you feel like you have just started? That is because we often get caught in the trap of writing apps from the bottom up; design the database, work out functional code and then the design. But that is wrong. DB admins aren’t the users of your application, its people that are interacting with the UI, so you should take the top down approach. And that is exactly what we did with this process.

Now that we are writing the code, we work out what the actual stories are from our scenario and start writing the code by writing the tests first etc. I am not going to go into what a purist Agile, Test Driven development tirade is, but I think most coders know what best practice is these days, and should strive to get as close as possible to that (even though it is not realistic to do so at times).

So there it is, a process that you can clearly follow. I haven’t gone through the details of how to launch in the market, but that post will come soon. There are so many ways that you could run this process, and find a more optimal way for you to work, but this is what works for me that means I can get a running product much quicker than fumbling over myself.

Don’t you hate that? When you are working on something, and people start raising problems that we don’t actually have. In traditional projects, this is disguised under the term “risk”.

Raise it, acknowledge it, maybe have one person spend 5 minutes thinking about it, then shelve it.

My mother is a sucker for this when she knows I am coming over for dinner. With my family, there is only a total of 6 of us. But my mother has a tendency to cook for twice as many people. So what is the problem she is trying to solve? Firstly, being of European background, she would be embarrassed if her own son walked out hungry. Secondly, she wants to be prepared if someone else knocks on the door unexpectedly.

But wait a minute! She’s my mum, so she has a pretty good gauge of how much we’ll eat, and in my entire life, I think people have unexpectedly knocked on the door less than half a dozen times. And it would have pretty easy just to whip something up to feed them.

The net effect, is she creates more problems than she actually solves EVERY time she cooks. What to do with the extra food? We are carrying the stuff home in droves, some gets thrown outetc etc.

I have waffled on, but I think you get my point. How many times do I sit in meetings and roll my eyes when you get people start debating about scaling issues, and we haven’t written one line of code or have one customer. WHO CARES!!!

Work on the problems you have, not the ones you don’t have. Why think about scaling issues, when you are only expecting to have less than a hundred customers for the next 6 months? Why think about a licensing server when you haven’t even launched a Beta?

In an engagement with a client some years back, the customer was so hung up on how the product would scale, that they sent a small team to go off and prototype a scalability solution. This piece of work took 3 people 2 weeks. Consequently their findings were implemented into the product and added at least 10% of complexity to writing the product. Here was a product that was yet to have any functionality developed. Ultimately, the product was launched, never succeeded, and never got beyond a handful of customers. The scaling was useless. Instead of using the resources and reducing the complexity to implement richer features that could have led to a more successful product, the time was wasted on code that was redundant.

I am not suggesting that if the team had not done this work and concentrated on the features that it would have been a success, but at least there would be a better chance of success.

Contrast this with another product that I worked on last year, where I debated whether scalability was a problem, and forced the team to just ignore it in the short term. When we finally DID have that problem (which was 12 months later), we basically used an off the shelf product, and 1 week of 2 developers times to implement, andWhoila! We were scaling!!!

So how do you do this? How do you avoid solving problems you don’t have?

Firstly, accept that people are going to raise non-existent problems. Then agree that if it doesn’t matter, the item will be acknowledged and logged. In a meeting, if someone raises a potential issue, first thing you do is ask the question “Is this a problem today?”, if it isn’t, don’t spend more than 5 minutes discussing it, and make sure a scribe logs it. That’s it! let it go!

If anyone objects to this, it is their responsibility to demonstrate why the problem is an issue today. If they fail to do that, move on!

I hope that helps with you non-problem solving. I have talked about the problem of scaling in this article, but there are many examples of this non-existent problem solving, and I would love to hear stories of problems that you may have solved that you never even had!

Does your application have a personality? Does it portray a character or charisma when people use it? What is its charm? And why does this matter?

Personality is the “feel” component of “look & feel”. It is often overlooked, or at the very least, misunderstood. Your application will have a personality, with or without your input. It’s like a child. If you nurture it correctly, being conscious of the personality you are trying to instil into the application, then you may have some control on how it will end up, and how others will perceive it. But if you neglect it, work on simply writing the code, and getting screens out, you will either end up with a) an application with the personality you didn’t intend for (aggressive instead of passive for example), b) have absolutely no personality at all (dry, like black text on white screen) or worst of all c) a split personality, where sometimes your application is forgiving and at other times stringent and demanding. This just confuses your end user.

But before going any further, let’s look at a few examples. An application’s personality usually really presents itself when you attempt to login. Starting with Sales Force, the login screen is a large burly blacked suited personality, arms crossed, dark sunglasses and earpiece, very Secret Service like. Google’s login is a casual dress down affair, jeans, runners and a clipboard. Google greets me with a smile, but has a couple of big ex-footballers blocking my way unless I give the correct answer. Twitter on the other hand, is a tall lanky personality, a little overawed by its responsibility, giving me the impression that if twitter looks the other way, I may be able to sneak in.

Now your perception may not be the same as mine, but I think at the very least you can see where I am coming from (much like if I was to tell you that I think my sisters new boyfriend is a little too self-confident, you may not have experienced it yourself, but you could probably understand my view). Some of these organisations intentionally went for this persona; such as SalesForce that wants you to feel extremely safe with the information you are putting in, or Google that wants you to be welcomed, but at the same time keep the place secure. Others may not be intentionally portraying their persona, but just can’t help it because of where they are at in their maturity; Twitter is a good example of this, they have had a couple of breaches of security and seem to be toying with ideas of how to improve security, which makes them feel slightly vulnerable, but yet I am not overly concerned with that based on the information I am providing.

So whose responsibility is Personality?

Firstly, Product Managers overlook this trait too often. Product Managers need to provide the vision for the personality, they need to guide the designers and developers with the personality. The designers and developers are where the influencing actually occurs. The designer is the mother, and the developer is the father. The father (developer) is the stern, opinionated influence in the child’s life, teaching discipline, morals and rules. The mother (designer) is the more emotional one, making sure the child is polite, well dressed, and wipes its face with a wet hanky when appropriate. Between the two of them, you are moulding the personality.

Sticking with our login page example, when building your application, you need to think; do I want this page to look inviting, arms wide open presenting a hug and bring the customer in, or do I need this page to look like it is being policed by the secret service. Both are valid. If you are building the next twitter, then you are likely to want to be inviting, but if it is an online banking application, then you are going to want to have a sense of security, and the dark suit may come out. But be creative. For example, I am now seeing some banking applications using a personality of a mature female bank manager in a bright suit, giving me the sense of security my parents or grandparents give me, but also portraying their warmth and concern. This is as much marketing as it is product development, but it’s the way you make sure you target the right type of customer.

Designers do this through using colour, layout and whitespace, Producers use content and language (language being one of the most prevalent ways to portray personality), and developers use error messages, workflow, business rules and validation (allowing a user to enter “next week” for a date, versus “28/5/09″if you want to be friendlier).

Where to begin?

First thing to remember is that your new baby (product) will have a personality anyway, but you need to try and influence it as best as you can. As a product manager, start envisaging a personality for the whole application; friendly and inviting, or strict and unforgiving. Then drill into the details and start working with the designers. Describe the personality the login screen should have; how should it be portrayed, and how should the customer react to it.

A final thought

Finally, you need to consider your typical target customer when creating a personality. If you target market are corporate suits that are focussed on numbers and details, you are setting yourself up for failure if your application portrays a personality of an adolescent in torn jeans and sneakers talking street.

And look around you. See what is happening in the real world. Look at shops that seem to be targeting similar customers, what is their personality? And this is actually quite easy, as they usually do this through the type of people they employ and what they wear, you get to “feel” their personality almost instantly!

So what are your experiences with application personality? What other personalities or split personalities have you come across in applications?