As we become faster, more agile, and better organised thanks to Scrum, one can only try to imagine where we’ll be in another 20 years, in terms of software development.
I think we’ll be seeing more web-based applications, games, and Java developments, and less of the standalone desktop type software being created. This seems to be the trend, anyway.
What this trend (whether it exists or not) means is that the move will be towards much more agile development – but what kind?
More on this after I’ve given it some proper thought…
Well, we just finished sprint 18. There’s been some good success, but unfortunately I feel this should technically be called a failed sprint, for the simple fact that three tasks were not completed.
The first of these tasks was an ongoing piece of software custom-written for a single user. It has been completed long ago, but we had a task about possible changes needed to be made, and indeed, on the final day of sprint, the user provided the requirements. To me, this goes against Scrum principles, and as such not only makes me angry, but makes me wonder how well we’ve actually implemented scrum.
The second incomplete task was never started, it required a deployment to be made first. I had personally planned the deployment for the final day of sprint, and even informed users, but this was canceled by our director, who essentially was in a panicky mood, and I feel there was no real reason not to deploy.
That leads to the final unfinished task. Deployment. We set aside eight sprint hours for the deployment of the product onto the production environment, and today, the retrospective and demonstration day, is when we’ll have to do it.
Nevertheless, this sprint went well. A word of warning I could give as a result of my experiences is – if you have an easily startled director overseeing what you do, sit him/her down with a cup of hot chocolate and let them experience a comfy sofa while you go behind their back create mad product downtime. Or get approval beforehand.
Today our pack of thirty planning poker card decks arrived from Mountain Goat Software.
They were ordered by our senior engineer, who is also a partner in the company, and their arrival was a surprise to me. Unfortunately he went a bit overboard when ordering.. considering that there’s enough cards in a deck for four developers to use, he’s ordered us enough for a hundred and twenty people.
I put it down to sheer old-fashioned optimism. If pressed we could line up about twenty people with a ‘developer’ label on them, if we scoured every office in our company and stuck a few mannequins between them.
So I am illegally going to give a few packets away to readers of the blog. Contact me on Skype (jacob.ozolins) if you are interested (I’ll edit this post to remove this sentence when there’s none left).
You can order your own too, if you want: http://store.mountaingoatsoftware.com/products/planning-poker-cards
Each deck contains enough cards for four estimators to each hold cards with the following values: ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and ∞. The cards are printed on the finest quality card stock available. Each deck comes in a box to help keep the cards from being damaged.
We’ve been using laser printed pieces of paper in the past, which are now frayed and yellowing. These cards make the developer feel at least a little more ’serious’…
I am writing this hopefully to educate some of the people I work with, who seem to be astonished by the fact that sometimes usually there’’s discrepancies between these two entirely different methods of tracking traffic.
The main point is this. One tracks before the visitor lands on the website, and the other tracks during page load.
77Tool is capable of both methods.
On-click tracking
On-site tracking
Problems with on-site tracking
With on-site tracking, the entry is only recorded after the script has loaded on the page. A number of things can prevent this.
Browser has scripts blocked. – In this case, a ””noscript”” version of the tracking needs to be in place. This is usually an image tag, and it”’’s highly likely that the browser is not set to ignore images.
Visitor clicks something on the website and moves away from the page before the script has time to load. Nothing can be done about this. Try to get the script placed at the top of the page code, so it loads before anything clickable.
Script is not implemented correctly – Typos or incorrectly copy+pastes can lead to complete malfunction of the script. Make sure to test after implementation. Luckily, 77Tool has only a 3 minute wait between entry and reporting of entry in the 77Tool interface. This makes testing easy.
Script does not have all required information. Our script generally requires a 77tadunit to be available in the source URL. An alternative is to have this value set on the website itself, but without either of these, the entry will land in natural traffic. Website tag is generally implemented in the site code, but is something else which can be stuffed into the source URL.
Cookies blocked – if the browser does not accept our cookie, entry will be created, but the visitor might not be linked to the conversion, and the conversion will end up in natural traffic. In general, our cookie is able to write to browsers set to ””high”” security and anything below (assuming a higher level exists).
Problems with on-click or redirect tracking
Mostly, on-click tracking is more effective at reporting entries. User clicks on the advert, entry is registered, and only then do they get to the website. Problems still exist..:
If website is down, entry is still reported, even though visitor never got to the website.
If the redirect server fails, user never reaches the website.
Parameters must be correct in the redirect URL, or visitor can end up on the wrong landing page.
A script or pixel must be called during conversion anyway.
The main issue with on-click tracking is the second point. A strong system needs to be in place in the event of redirect server failure. In 77Agency we have a backup system in place, and a five minute TTL on our DNS records, so we can change redirect servers rapidly.
Why the different methods create discrepancies
Basically, the on-click method will always report higher entries, simply because it has none of the limitations of browser problems loading the on-site script.
This is not just the difference between our own two methods, it should be expected when comparing our on-site tracking with third party on-click systems also.
Well, here’s my opinion on the majority of the Google Analytics Authorized Consultants.
Put it this way: If Google stuck a needle and thread up their bum, a GAAC would be the first person walking around with freshly darned socks.
My gripes go further than that.
Why does every new GAAC feel they have to introduce themselves on the mailing list? Nobody gives two hoots about you – and you know, you’re just one more gilled creature flapping around in the sludge. You’re another competitor.
One of these people even started an email about GAAC ‘etiquette’ – the gist of which is essentially ‘let’s share clients’. Well I’m sorry, pal, but that’s not the way it works, and that sure as hell isn’t the way the client should conduct their business. The client should end up with the best possible consultant. If you are not as good as the next guy – then get better. Don’t expect any grace, the GAACs are vultures (generally they wear pink fluff and prance around like flamingos if Google is watching, though).
Oh the GAACs sure do crinkle my collar.
Look at this, which some GAAC made during a ’summit’ (I’d rather call it the ‘world-class brown-nosing championships’): Warning: this is utterly disgusting.
If you can get past the first few moments, then I fear you’ve lost all humanity.
Another thing: They write emails with subjects like ‘News from Caleb’ – as though everyone is sure as hell to know who he is. What a bigshot. Well done Caleb, we all really needed your ‘update’ full of links to your company website.
Before I forget to mention, there’s a GAAC Jesus. His name is Avinash or something, and if you ever want to survive in that world, you better creak your knees a bit and place your moistened lips against his gnarled and hairy feet.
Disclaimer: I am sure that there’s one or two of these Google consultants which is actually a thoroughly decent human being. Probability is with me on this. I just haven’t met any. Well there is one Irish girl who keeps her mouth shut. That counts.
After I began maintaining a manual burndown chart for the sprint, I noticed that in reality the burndown chart was not telling us what we needed to know. It was based on completed tasks – and completed means coded and dev-tested.
Towards the end of almost every sprint, we were seeing that our burndown chart suddenly drops down as tasks are put through testing.
Due to this, we don’t really get an idea of where we are, in terms of development. An eight hour task could be coded but not tested, and that means eight hours still in the backlog. Spending twenty minutes testing it essentially ‘leaps’ the task from zero to completion. Not correct at all.
One solution is to report hours spent on all tasks, rather than just completed tasks. This might be even further from reality – essentially it would just show effort, which is generally not going to change from day-to-day and reporting it doesn’t show anybody anything.
This was causing me to have a minor meltdown, and thus this rather colourful chart evolved in my Excel spreadsheet:
The sprint meltdown chart.
Forgive me for the lack of labels here. Y-axis is number of hours (points) remaining in the sprint. X-axis is the nth day of the sprint.
The meltdown chart is always displayed as an ‘X’, with expected effort starting at zero and moving up to the planned hours limit, and expected burndown moving in the opposite direction.
Additionally, there is a central ‘window’ in the chart, and using this window I can spot mid-sprint what the outcome of the sprint will be if we maintain current progress.
There are four sections of the window, and briefly, if the real effort and burndown intersect in pane:
1. Effort needs to be reevaluated. Developers are sprinting and can probably cool off a bit, depending on whether burn is above or below average. If above, then tasks estimations are askew. In this case I would spend time to reevaluate with the team. If burn is below average, the sprint might have room for additional tasks. I would ask the developers if they would accept extra work added mid-sprint. Keep in mind that doing this might break the sprint later on.
2. Sprint is in serious trouble. If actual effort is below expected effort, it’s time to take the cane to the developers. In reality this can take the form of discussing the problems after a stand-up meeting, or scheduling a brief meeting. It’s likely the developers will state that they incorrectly estimated the tasks, and will complain that external factors are changing the scope. It could be time to alter the backlog, removing items if necessary.
3. Sprint estimated poorly, or horrible code quality. If the burn is in this window pane, then the second half of the sprint will be a walk in the park. You can decide if you want developers to stroll or pick up additional tasks. It might be worth paying closer attention to the quality of code – unless estimations were completely off, one or more developers could be writing rubbish code. I would spend time investigating the overall quality of the work done on the tasks.
4. Increase effort, depending on the burn, if it is above expected. If it’s below, effort can remain the same. Sprint is more or less on target.
These points depend mainly on how close the intersection is to the center of the chart. The closer to the center, the less attention you as a product owner need to pay.
In the image example, you can see our intersection landed in pane 2. From there, we turned up the effort of the developers, pumped them full of coffee, and managed to drag the sprint back on target.
I have no reservations when it comes to encouraging developers to work harder, but I see such effort boosts in terms of karma. More coffee mid sprint can more-or-less be translated into more beer at the end of it.
“This hands-on, interactive two-day course will teach you:
How to be an effective Product Owner
Write User-Stories (Agile requirements)
How to manage an Agile product throughout the Software Development Life Cycle
Agile Release planning and Tracking
Upon successful completion of this course, each participant will be enrolled as a Certified Product Owner, which includes a one-year Scrum Alliance membership, where additional ScrumMaster and Product Owner material and information is available.”
Gabrielle seems to have a good track record with scrum and even with implementing it in a new environment. This leads me to believe she’ll be the better teacher (there’s another course I could attend, hosted by a German guy who wrote a book about scrum).
If anyone has some feedback on these courses, I’d love to hear them.
I’ve signed up, but am yet to receive my confirmation. But I can say this – It’s Google. It’s going to be good (not talking about morality here, of course…).
