Karmængine

Unfortunately, I am on a mailing list which gets a lot of requests from small businesses to install Google Analytics on their website.

The gist of such requests:

Hi,

I own a website for my little newspaper stall, which sells newspapers and magazines on the corner of 5th and Maine.

I am starting to get some traffic to my site, sometimes up to 50 visitors per day. I have heard that Google Analytics can increase my website traffic and help me to earn more money with my business.

I have a budget of $200 to spend on getting it set up and running for my website http://bobs-newspaper-stall.free-website-community.com/

Please let me know if you are interested.

Bob

My keyboard and desk is literally littered with the hairs I’ve pulled from my head when reading such emails.

So I’m writing a post here, the link to which I can send as a standard response to such emails.

Let me deconstruct what is making me angry about such emails.

1. 50 visitors per day

This is great, good job. Firstly though, how do you measure this amount of visitors? Are you one of those evil nasty website owners who uses a ‘hit counter’ on their site? Do you already have some statistics software installed, or some kind of log analyzer? Why do you need Google Analytics then? Is there additional data you wish to see? Which data?

How many visitors do you expect a traffic analytics software can give you? Do you understand that counting eggs doesn’t increase the number of eggs?

If you are getting 50 real visitors per day, have you given any thought to promoting your website?

2. I hear good things about Google Analytics

I hear good things about the Hubble Telescope, but that doesn’t mean I need one so I can see the sky. Google Analytics is a turbo diesel-powered pneumatic sledgehammer of a piece of software. There are, of course, simple pneumatic sledgehammers, or plain sledgehammers, or even just little hand-held hammers available to you. Do you need the planet-smashing power of Google Analytics, when you just want to tap a nail?

You have to understand that when you ask me to dig a mile-wide hole for you to plant a tiny seed into, I am going to wonder exactly what is going to grow from that seed. State your goals, or you have none.

Understand what you’re asking someone to do. You can learn yourself about Google Analytics, about website promotion, about the internet in general, which you should do, if you ever want to run a successful website. Don’t just throw money somewhere and expect to make a profit.

3. You want to spend $200

Ok good, you have a budget.  That means that somewhere you have calculated your potential revenue and profit and have decided that you should spend $200. On what? On your website? On promoting your website? On promoting your business? On hiring someone to ‘fiddle’ with your website?

Google Analytics is free. Documentation on how to install it is free. What do you expect to gain from hiring some guy to help you see statistics about your visitors? Do you have an action plan, incase you see some trends in the data?

4. My website is on blah-blah-keyword-blah-keyword.free-website-hosting.com

Unless you want to attract the very lowest-budget customers to your site, stop being a cheapskate and get a proper domain name. $10 is all you need.

Also get those damn keywords and damn hyphens outta there…!

And that, folks, ends my rant for today.

Well, being Product Owner is a bit like being a head chef. You can either cook the meal yourself, you can order someone to cook it, or you can convince the diner that they don’t really need a meal.

And which do you choose?

Well. It depends. It depends on who is ordering the meal, and who is standing behind the chef with his notepad and a stern look on his face. It also depends on what ingredients you have in the larder.

So, do you want to be a Product Owner or a Product Pwn3r?

What’s the difference?

Well, here’s a hint. One plays the role, and the other creates the role.

More to come…

Yes this is ’special’. That makes it sound better, doesn’t it?

Bottom line: You can get StatsJunky for $297 for life. (normal price is $500+ per year).

It’s the stats program which helps you keep track of your PPC and affiliate campaigns.

I haven’t used it, I’m just trying to cash in on their ridiculously good offer.

A lot is written about the three main roles (or only roles, as some might have it) in scrum. Here are my definitions:

1. Product Owner – The product owner is the filtration and feeder system for the machine, which inputs ideas and outputs a product.
2. Scrum Master – The safety valve on the machine. Can manage the internal pressure.
3. Developer – a working component in the machine, a processor. One who does the actual development.

But, I’d like to touch on another role, the stakeholder.

The stakeholder may be the real owner of the product. He is the person the product is created for. He is the person with the ‘vision’ of the product.

And, the stakeholder has responsibilities. He (or she) is not just a boffin at the end of the phone.

The stakeholder should:

• Know what he wants from the product.
• Know when he wants the product to be completed.
• Be able to outline all major features of the product.
• Be available for the Product Owner to discuss the product often.
• Represent or actually be be the user of the product.

The whole development of the project can break when the stakeholder doesn’t meet these requirements.

Let’s examine each point and assume we have broken it:

• The stakeholder doesn’t know what he wants from the product. In this case we end up wasting development time on a product which goes in the wrong direction. We might create something usable and meeting the basic requirements, but was the real requirements become clearer, more and more work will need to be done to pull the project back on track. It may require starting from scratch. It is very unlikely that the team will deliver exactly what’s needed.
• The stakeholder doesn’t know when the product needs to be delivered. Well, the immediate thought is that this is a good thing. That it means the development can proceed at a leisurely pace. This is almost always wrong. What usually happens is that while the stakeholders are mulling over the goals of the project, they have ‘already told you about it’ and expect that work is already proceeding. Then when they come up with a deadline, it will be shorter than expected, due to this mulling and buggering about time. This causes a panic and can put the team under pressure, resulting in a low quality product.
• The stakeholder cannot outline the major features of the product. This is a major problem. What is developed? If it’s left to the PO and the rest of the team to decide, the product will end up satisfying only them. It will not satisfy the stakeholder. In this case it’s much better to put the brakes on and string up the stakeholder until he tells you what he needs from the product.
• The stakeholder is rarely available to discuss the product with the PO. If the stakeholder is the type of ‘hands off’ person who does not keep in touch with the PO or the progress of the product, the product will start heading in the wrong direction. Stakeholders have an ugly habit of changing their minds every time you speak with them. They can be influenced by even the subtle flapping of a butterfly’s wings on a planet millions of light-years away. If they can’t communicate their mind changes to the PO, the product delivered will be not what the stakeholder was expecting, and therefore a disaster.
• The stakeholder doesn’t use the product, nor represent the users of it. Ridiculously, this can happen. And if it does, you’re making a product blindly. The stakeholder will probably accept whatever you churn out, but beware that when the users come back with their tsunami of complaints, it’s the PO who lying on the beach, not the stakeholder. I could put the good ole iron fist down here and say “Don’t ever create a product for a rogue stakeholder!” Tell them to shove it. Outsource it. Bypass him if necessary. Get your own understanding of what the users need by communicating directly with them.

Hopefully this gives some understanding of the ‘role’ of stakeholder in Scrum. There seems to be a lack of information about them on the net so far.

Lastly, I would say that if you’re the PO, you’re probably liable to the stakeholder. Don’t let him put you under his thumb. If he throws you a curveball, catch it, and shove it in his face.

I have already tried to describe a methodology called SCRAM, but now revising it makes sense. Things have been learnt.

Scrum has Sprints, Scram has Scrambles. We scramble and push and do everything we can do deploy new functionality every day.

Humans and animals move fastest when running from something, not when running towards something.

In the case of Scram, developers are running from fear of being booted from the team, losing benefits, and losing respect. They are in an effort to ‘keep up’ with the best of the team.

Scram is like an olympic-level of development.

The purpose is to get the most out of the team, to push them beyond their usual capacity, and to meet their needs as we do so.

Let me start by just getting on with it.

I know ‘deployer’ is not a real word.

Requirements for Scram:

• A team consisting of: A tester, a deployer, 2-4 developers, and a product manager.
• Company-provided lunches of salad or pasta and varied meats (chicken, beef, pork, seafood, fish – 5 days, 5 different meats).
• Company-provided refreshments available whenever the team needs them (water, tea, milk).
• Company-provided fruit/berry snacks.
• A product to create.

Abnormal focuses:

• Nutrition of the team
• Pressure-cooker mentality
• ‘Natural selection’ evolution of team – the chaff gets booted out quickly.
• Team-members control who is in the team.
• Paired/quartet-programming encouraged.
• No documentation (unless documenter is added as a separate entity to team)

Normal focuses:

• Working towards a common goal.
• Test-driven development.

Roles:

• Tester – Works between developers and deployer. The tester is responsible for testing ‘completed’ work, and giving the go-ahead to the deployer. Developers must inform tester when work is ready for him to test. The tester is responsible for deployed, not-working functionality.
• Deployer – Works between the tester and the product manager. The deployer is responsible for deploying work which the tester approves for deployment. The deployer is responsible for broken deployments. The deployer maintains a deployment record for the product manager.
• Developers – are responsible for creating the product. Developers must understand what functionality needs to be made, and then make it. Developers must inform the tester of work which is ready for testing. Developers are responsible for work which fails testing.
• Product manager – is responsible for itemizing and detailing the functionality to be created. Is responsible for providing goals. Is responsible for released product.
• Documenter (not obligatory) – observes tester and story description from manager, and documents functionality.

Iterations:

Daily routine:

• 15 mins preparation – manager explains what tasks are ready. Developers recap what tasks are in progress.
• 120 minutes development – Major effort. Coding, testing, deploying can all take place.
• 15 minutes recap and preparation – developers explain what has been done, what is yet to do. Tester explains what’s tested. Deployer explains what is deployed and/or will be deployed. Manager observes.
• 60 minutes development – Medium effort. Coding, testing, deploying can all take place.
• 120 minutes lunch – extended lunch. Team should eat together, discussing work and patting themselves on the backs. Stragglers have time to catch up. Impediments and problems are explained to the manager.
• 15 minutes recap and preparation – next phase is planned, deployer recaps, tester recaps, developers recap, manager encourages.
• 120 minutes development – Major effort. Push to get something deployed if nothing new is deployed yet.
• 15 minutes cooldown – Patting-on-the-back, recap, discussing problems. Each team member confidentially writes two names: team member they were most impressed with, and team member they were least impressed with, for the manager’s review.

The manager’s daily routine is somewhat different:

• 15 minutes preparation – manager confirms with team what will be achieved today.
• 120 minutes development – manager reviews yesterday’s work and communicates with stakeholders.
• 15 minutes recap – manager learns the current state of development.
• 60 minutes development – manager plans and predicts outcome for the end of the day.
• 120 minutes lunch – manager joins in, discusses with team, jokes, keeps the atmosphere positive. Glares at slower team members.
• 15 minutes recap – manager explains progress and expectations.
• 120 minutes development – manager starts to plan next day’s work, based on projections for current day.
• 15 minutes cooldown – manager goes berserk if nothing was delivered. Manager praises team is goals were met. Manager collects feedback from the team.

Guidelines:

• Deployment can be made at any time.
• Something must be deployed every day.
• Extended lunch break. Always.
• Team members can be booted out of the team at any moment, at the manager’s discretion (based on team feedback).
• Team members should be the ‘elite’ and be paid and treated that way.
• Unique hats or t-shirts or mouse or monitor should be given to team members to distinguish them from others.
• Team members can break and snack at their leisure.
• Friday evenings of every fortnight should be a major wind-down, possibly with a trip to sauna, gym, massage, or yoga.
• Strong focus on nutrition; physical and mental well-being of the team members. Team members should start to increase their capacity for output the longer they stay a part of the group. Should also result in less sick-leave, which can collapse Scram.

Business-level notes:

The fact is, running with such a team is going to be expensive. The lunches, the benefits, the ‘elitism’ of their salaries, etc.

However, the potential output, and the fact that new features are delivered every day, gives such an approach a high value – a value which in broad terms can be translated into higher revenue for the business.

Being constantly pushed, reviewed, and judged by their peers can result only in the overal improvement of the team members, and a well-oiled team of intelligent and highly-skilled people should result in a high-speed development process, provided that the product functionality can be divided into components small enough to develop in a day.

It remains a fact that this development approach is not suitable nor required for many common projects. Users of systems rarely require new features available every day. Regardless, this approach can be maintained with releases to pre-production environments, which are then passed on to a Q.A. department for monthly deployments into the real world. The goal remains the same – to create the product as quickly as possible.

A note on documentation:

All products should be documented, and the documentation should be written for users. With Scram, an option is to have an additional team member – a documentation writer.

Flaws:

• Quality of work is never checked.
• Automated tests of functionality are not created.
• Unless the team knows each other well, it can be a free-for-all battle to get the ‘easy’ tasks to work on.
• Scope of stories to be completed is only broadly estimated, on-the-fly.
• Bug fixing has to be slotted-in randomly.
• It’s difficult to find team members suitable for such a high-level of output.
• The manager is somewhat hidden with his collection of feature requests and stories for the developers. For the developers, these may seem to come from nowhere.
• Team members have no chance to make suggestions for features.

http://www.karmaengine.com/_img/daily-routinejpg.jpg

I’ve just added a document written by Ternary Software, Inc. to the documents category – you can see it on the right side of the blog.

What You Need to Know About Agile

Thanks,

Jacob

Unfortunately, a bit of controversy has stirred up about the trademark ‘Scrum User Group’ which as been registered (or attempted to be registered) by the Scrum Aliance.

They are trying to crack-down on it’s usage.

Recently the Orlando Scrum User Group has had to close up shop, due to infringing on the trademarked ‘Scrum User Group’ term, and certainly this is mostly a trend.

Bah. I can’t be bothered writing anything more on this. I am ashamed for the entire western world when I read about things like this. Ridiculous.

Story points.

We recently made the switch to using the story point system and the most difficult thing to explain to the developer was the point of the whole thing. They were used to estimating tasks in terms of hours – a system which was never accurate and lead to utter disarray in terms of unfinished, half-finished, and poorly-finished tasks.

What goes through a developer’s mind when he tries to estimate how many hours a task will take? This:

1. How many stored procedures will I need to write? How long does it take me to write one?
2. How long to create the new page for it?
3. How long to implement data filters and sorting?
4. How much time do I need to make new tables?
5. How much time for putting it all together?

And, in the end, they’d come up with some relatively random number like 13 hours or 8 hours. “What about testing?” I’d say.

“Oh and two or three hours for testing.” They all claimed.

Bill and Bob would estimate 13 hours for the task. Alice and Alicia would estimate 8. Fred would say 20.

And you know what we’d do? We’d take an average and say that’s how much work the ticket needed. It’s shameful, but that’s what we’d do. And would have continued to do, if we hadn’t woken up one day and said “this just isn’t working.”

Incoming – story points.

We understood eventually that this was some way of comparing scope of tasks, and not an actual measurement of anything. We understood that by understanding the scope in this way we could get a ‘feeling’ about how much work could be completed. We didn’t understand why Fibonacci sequence is used, nor what we could use as a medium-scope task to compare others too. But, we gave it a try.

First, to help developers understand what story points were, the S.M. ran an exercise, where animals in a zoo had to be assigned story points. The exercise broke down under relentless questioning about small details, but the general concept was understood.

Now we’re using story points to estimate stories for addition to the sprint backlog. This is what goes through the developer’s mind now:

1. Is it smaller or larger than the 8-point task we all agreed on?
2. How much larger is it? Is it less than twice the size?
3. How many of the 2-point tasks could I complete in the same amount of time it would take me to complete this task?
4. Where’s my beer?

You can clearly see that the process requires less thought, and more ‘feeling’.

One of the ways to keep a developer happy is to remove his need to think independently, and story points take one more step towards achieving this.

So. Recently we’ve tried to make some changes to the way in which our team implements scrum. They came out as a result of a) me learning from the yahoo group and reading plenty of documentation on scrum, and primarily due to b) the scrum master getting certified by attending some CSM training.

We were managing quite well with our interpretation of Scrum, but as it turns out, if we weren’t following all the principals, we weren’t doing Scrum.

Here’s what we changed, and why:

1. Retrospectives. They had essentially halted for the last few sprints, and in any case were not conducted correctly. In the past, we would gather around on Friday, feeling either angry with the P.O. (me) because developers were working into the AM to finish the sprint, or, developers would turn up full of jokes, laziness, and pats-on-backs for getting all the work done on time.

We would sit and chat. The SM tried to instill a sense of order into the meeting, he would ask specific questions and take notes. But in the end, it was really just a relaxing little unwind session and we didn’t get a lot out of it. It did give the developers a chance to throttle the P.O., however, and they did so, shouting abuse about changing requirements and unplanned tasks being added to the sprint.

Two things were wrong with this scenario. Firslty, it is the team itself who should be committing to delivering a certain bunch of stories, not the P.O. ‘telling’ the team what to do. A BIG difference.

Secondly, there’s a purpose to these meetings, and it’s not just to discuss where to go for beer after work.

So, we’ve prepared ourselves for proper retrospective meetings, following guidelines generally accepted by the Scrum world, and expect a result from the meeting. We’ve also altered the mindset of the team to put them in the driving seat, in terms of selecting how much work can be achieved during the sprint.

As for unplanned tasks – well, there are no unplanned tasks. They should be discussed if neccessary and something should be kicked out of sprint if required. The team should be deciding this, based on the P.O. providing updated information of priority.

2. Empowering the developer during preparation meetings. The main point here is – the developers, together with the tester, enter into a kind of ‘contract’ with the P.O., to declare which stories will be delivered at the end of the sprint. This is the way it should work. We were doing it the other way, with the P.O. forcing the developers to commit to a number of tasks, and it should be said, it was usually a long list of tasks.

3. Estimating using story points. Story points – what are they? Why do we need them? The developers were eager to try something new but had a difficult time wrapping their heads around the idea of not estimating in terms of hours but in terms of story points. I used to calculate the amount of hours the team can work during the sprint, get the team to estimate the hours to complete each task, and then say ‘right, this is how much work you’ll get done’, and the sprint backlog was born.

Now, I am just creating stories with user test cases in the backlog and giving them importance factors. The Team is estimating story points based on average stories, and then giving an overall, but confident ‘feel’ (after a lot of technical discussion) about which stories can be in a shippable state by the end of the sprint. Then the stories are added.

4. Adding an ‘Is done when’ field to Trac. We use Trac, or, since new changes were implemented, Agilo, which is built on Trac. The only real acceptance tests we used to have is a ‘How to demo’ field, which would give instruction on how the work done in the ticket can be shown to other people. This was not right at all. Development without testing is like tossing seeds off a cliff and hoping your grandkids will have a fruit tree. No testing = no result.

I’ve added the ‘Is done when’ concept which I’m sure some of you probably use. It’s an english language description of acceptance tests for example, a value of this field could be “An adminstrator can log in, navigate to the accounts page, select a user account, and delete it by clicking on the ‘delete account’ button.” So far this field has had a big impact, as the introduction of any user-level test descriptions should.

5. Visualizing the sprint with a pinboard. We used to be entirely Trac based, meaning developers had to log in, and swim around in Trac to understand clearly what was going on during the sprint. Stand-up meetings didn’t help.

To combat this I have introduced a pinboard into the meeting room, where stories and tasks are pinned on, and moved between statuses before ending up in the ‘closed’ column. This lets the developers see very quickly how much work is left, how much needs to be tested, and generally how on-target the sprint is.

I’ve also put a ‘bug board’ up, which should be empty but never is. Here, developers see bugs which I want fixed immediately. They can discuss them after the stand-up meeting, and come back to me if they think they won’t manage to complete them as well as the sprint stories.

6. Devoted time specifically for bug fixing. We have also given developers a day each to spend on fixing bugs. Roughly thirty hours for the sprint. By setting aside this time, I hope that broken tickets and new bugs will not survive in the backlog long.

With all these changes I feel we’re more ‘Scrumlike’ and I’m hoping this means a better product delivery.