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!