Karmængine

Mr. Ronald E Jeffries is trying to drum up support for a certification process for agile developers, because, “Ken Schwaber, co-creator of Scrum, says publicly that perhaps only 25% of Scrum teams get the full benefit of Scrum.”

Now, the real point he’s trying to make here is that his bank balance is could do with a top-up.  That’s my initial view. But that’s highly cynical.

1. Ron (and others) believe that Scrum and other Agile practices only get their real value if the practitioners are fully trained and ‘know how to do it properly’.
2. Those believers in certificates think that the only way to use a tool properly is to get a certificate saying so.
3. Certification process will not be free.
4. Developers mostly don’t care about whatever methodology is followed to give them things to do.
5. Ron and his mates will be the certified teachers of the course, and therefore be certifiably lining their own pockets.

With these points in mind I cannot help feeling that this is just a growing trend from the Scrum Alliance to earn money from people who want to ‘do Scrum’.

We already know about their claims to the words ‘Scrum Group’ and the financial implications that has.

I suggest we break the bonds and free Scrum from the evil clutches of these money-oriented swindlers.

I mean, what’s next, Scrum Certification for Testers? Trademark on the word ‘Scrum’?

As Tobias Mayer says: I believe the idea of a “certified developer” has nothing to do with Scrum. Scrum is not a software methodology, not a prescribed way of working. It is broader than that. Scrum is a framework for “transforming the the world of work”. It is “…an iterative, incremental framework for developing any product or managing any work”. Creating a certified software developer certificate will push Scrum into a tight corner where it will not be able to grow to be all the things it is capable of being. I find that to be very sad.

Yes, let’s break the bonds. Someone start the ‘Free Scrum’ club please.l

Dramatic title, I know.

The point I wanted to make is that in more traditional software development, you would have a scenario like the human body. There would be the eyes which send signals to the brain, the brain which interprets these signals and controls the arm, which controls the hand, which makes the product.

Now, though, we have Scrum. There is no central lump controlling everything.

There are still eyes, arms, and hands. But, the hands are not told what to do. They decide for themselves what to do, based on what the arm says is possible to do. And so on up the chain.

Scrum has no brain.

And yet, the very point I’m making is that scrum practicioners are blessed with the opportunity and requirement to think for themselves.

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.