Latest Tweets:
Sorry for the delay, it’s been a long month and rather busy for me. Hopefully the last few postings left you hungry enough that you’re not to upset.
As it’s been a long while it’s probably best to write about something quite general again, today’s topic will be based on what you need to build a website.
At the beginning of this week we built a shop, from scratch, 90% of which was achieved within two working days. The original project took almost a month to complete and was existing before we came along and essentially cloned it. Granted originally it was an ASP website and we were working in ruby on rails, that somewhat speeds things up. I’ll go into that in further blog posts though as it is something I really should talk about and don’t enough.
The reason for the 2 day build though instead of the 20 day build is quite simply that we knew what we were dealing with. We had content ready, a design signed of and complete product list. The product list was coming from a xml feed and not being populated by a client.
Essentially the three parts of the site had no impediments! Myself (the developer) knew the business logic, merchant IDs all upfront, the designer had nothing too do and the sweeper knew the content and layouts required to build.
Now surprisingly enough this is a real project that actually happened, not a made up example to demonstrate a point ;) however there is a lot to be learned by this example, it’s somewhere that agile can often help with things and rarely does. Most people use agile to point out impediments but not actually resolve them. Having a morning meeting to discuss what you are doing or taking on that day is designed with the purpose of being informing. Not just to everybody else looking blank as to why they are doing it but to project managers, copy writings, account managers etc. If you are working on a new page and will need text for this, an image for that then it’s somebody’s job to aid you in that.
If somebody needs an image or piece of text to complete that work and it’s your role to provide it, then all you have done is waste a day. The great thing about agile is you work in two week chunks typically. So you can for the most part just-in-time deliver, most of the time the sweeper will have the most knowledge of required assets as they are dealing with both front and back ends of the website. They have a great understanding of how the design works with the data and are the best go-to-guy (or gal) when it comes to the “what can i do to make everybody’s life easier?” moment.
Anyway, deviating again, the morning isn’t a place to tell somebody what you need for the day, everybody meets the customer and touches base with them, the reason for the customer being sat there in a meeting is two-fold. Firstly they can feed back to you what they want and what matters too them. Secondly you can have a conversation and start a relationship. Trust me, customers love it when a team member calls them and asks what they want the thank you message on the contact page to say. The customer knows you are working on this project, that you care and value there input in the development process. You get it right first time and everybody walks away happy.
Bigger obstacles such as an entire page of copy or a design for a page not being done, you should be flagging up before you start the sprint anyway. I find the best way to get round all these problems is apply common sense. If you are working as a team of three, and you really shouldn’t be any bigger than that, you are naturally staggered anyway. Your developer will be writing tests and models, your sweeper will be fixing in IE and your designer gets a head-start. If the developer or sweeper runs out of work then they can use the time to either start on something they don’t need more input to do or they can research something they will need for the sprint. A plugin or mockup a piece of functionality.
When you see the customer tell them if they want to test it what they need to test in, there’s nothing wrong with being completely open with somebody and saying that you build to work in safari and fix it for IE afterwards, its just a process. They don’t build websites so will accept it as long as when the project is said and done you really are fixing problems in IE.
Nobody is perfect and bugs and problems will happen, but an open and honest relationship with your client means they will trust you, and trust you fill fix any issues. It’s all part of a wonderful orb of customer support. Your more likely to be nicer to somebody you know. Especially if you know they worked hard for you.
If you want to know more you can always email me or send me a tweet I haven’t had time to put comments on however I will for the next post.
As a heads-up, next post will be about the new google features and what it means to us, the importance of working the social engine. Have fun at work!
