Well, it's boastful to say it, but we just received a nice little certificate from Craig Laundy (assistant federal minister for innovation) and Victor Dominello (NSW state minister for innovation). It says "Best Industry Application of AI/Cognitive" for the Automated Estimator of Effort and Duration.
Actually, we were just highly commended, and it was stratejos that won, but what is interesting about all this is: the whole AI/Cognitive category just went to artificial intelligence JIRA plug-ins.
Firstly, Atlassian has won the enterprise. When 100% of the top-tier startups targeting large organisations are developing for your platform exclusively, it's only a matter of time.
Secondly, AI is hot technology in Sydney with political capital. We think of Silicon Valley as being the centre of the universe for this, but I've never seen US Federal and Californian state senators getting together to express their commitment as we saw in this award.
Thirdly, this means you really should try out AEED: http://www.queckt.com/
Showing posts with label AEED. Show all posts
Showing posts with label AEED. Show all posts
Wednesday, 7 December 2016
Thursday, 21 April 2016
HP Service Manager tools @JIRAServiceDesk @github
For customers running HP Service Manager, I have two freebies:
- A free demo of JIRA Service Desk. I'll even show you how you can get big data analysis (somewhat like Smart Analytics and/or IDOL) for a fraction of the cost ( http://blog.ifost.org.au/2015/10/are-you-having-problems-with-estimates.html )
- I'm open-sourcing all the tools I wrote to work with HPSM -- https://github.com/solresol/sm-tools -- the README follows...
sm-tools
Tools for interacting with HP Service Manager
- activitywsdl.unl -- enable WSDL access to the Activity table
- create-or-update-incident.sh -- when NNM detects a node goes down, either update the existing Service Manager incident or create a new one.
- event-handler.sh -- When NNM generates an event (either up or down), dispatch appropriately to Service Manager
- email2ticket.py -- a much easier way of having HP SM receive emails that doesn't involve Connect-IT. Edit email2ticket.conf and you're ready to go
- fastpass-email2ticket.py -- similar to email2ticket but designed to work with FastPass, and report the ticket as closed automatically
- sm2email.py -- a much easer way for HP SM to send emails that doesn't involve Connect-IT. Edit sm2email.conf and that's about it.
- sm2sms.py -- if HP SM tries to send a "pager" notification, send an SMS. Doesn't involve Connect-IT.
- smcli.py -- library and program -- Swiss army knife of interacting with Service Manager on the commandline
- smprocmail.py -- instead of polling an IMAP or POP server, why not deliver your customer interaction emails via procmail through to smprocmail.py which will turn them into interactions instantly (i.e. no polling delay). Amaze your customers.
- valuesms.py -- command-line script for sending emails
Greg Baker (gregb@ifost.org.au) is a consultant, author, developer and start-up advisor. His recent projects include aplug-in for Jira Service Desk which lets helpdesk staff tell their users how long a task will take and a wet-weather information system for school sports.
Thursday, 10 December 2015
Celebratory 100th blog post - what people have actually been reading, and what freebies and junkets are on offer
This is the 100th blog post, and the counter of page views is about to tick over 50,000. Thank you for your readership!
According to Google's infallible stats counters, here's what most people have been reading on this blog:
POEMS At the end of a day of being a computer nerd, you need something that will make you laugh (or at least smile) and also make you look cultured among your friends. Nobody else writes poetry about nuclear physics or time travel, so if you want to get that "I'm so hip" feel, you really should buy a copy of When Medusa went on Chatroulette for $3 (more or less, depending on your country of origin).
NAVIGATOR - If you run Data Protector then you will definitely get some value out of the cloud-hosted Navigator trial. You can get reports like "what virtual machines are not getting backed up?" and "how big will my backups be next year?" -- stuff that makes you look like the storage genius guru (which you probably are anyway, but this just makes it easier to prove it).
HOW LONG WILL IT TAKE - If you are tracking your work in Atlassian's fabulous JIRA task tracking system, then try out my free plug-in (x.ifost.org.au/aeed) which can predict how long tasks will take to complete. And if you are not using JIRA, then convince everyone to throw out whatever you are using and switch to JIRA because it's an order of magnitude cheaper, and also easier to support.
TRAINING COURSES - You can now buy training online from store.data-protector.net -- and it appears that it's 10-20% cheaper than buying from HPE directly in most countries. There are options for instructor-led, self-paced, over-the-internet and e-learning modules.
SUPPORT CONTRACTS - Just email your support contract before its renewal to gregb@ifost.org.au and I'll look at it and figure out a way to make it cheaper for you.
BOOKS - If you are just learning Data Protector, then buy one of my books on Data Protector (available in Kindle, PDF and hardback). They are all under $10; you can hide them in an expense report and no-one will ever know.
According to Google's infallible stats counters, here's what most people have been reading on this blog:
POEMS At the end of a day of being a computer nerd, you need something that will make you laugh (or at least smile) and also make you look cultured among your friends. Nobody else writes poetry about nuclear physics or time travel, so if you want to get that "I'm so hip" feel, you really should buy a copy of When Medusa went on Chatroulette for $3 (more or less, depending on your country of origin).
NAVIGATOR - If you run Data Protector then you will definitely get some value out of the cloud-hosted Navigator trial. You can get reports like "what virtual machines are not getting backed up?" and "how big will my backups be next year?" -- stuff that makes you look like the storage genius guru (which you probably are anyway, but this just makes it easier to prove it).
HOW LONG WILL IT TAKE - If you are tracking your work in Atlassian's fabulous JIRA task tracking system, then try out my free plug-in (x.ifost.org.au/aeed) which can predict how long tasks will take to complete. And if you are not using JIRA, then convince everyone to throw out whatever you are using and switch to JIRA because it's an order of magnitude cheaper, and also easier to support.
TRAINING COURSES - You can now buy training online from store.data-protector.net -- and it appears that it's 10-20% cheaper than buying from HPE directly in most countries. There are options for instructor-led, self-paced, over-the-internet and e-learning modules.
SUPPORT CONTRACTS - Just email your support contract before its renewal to gregb@ifost.org.au and I'll look at it and figure out a way to make it cheaper for you.
BOOKS - If you are just learning Data Protector, then buy one of my books on Data Protector (available in Kindle, PDF and hardback). They are all under $10; you can hide them in an expense report and no-one will ever know.
Friday, 27 November 2015
How to avoid getting lumped with the tickets that take forever to resolve -- Sydney Atlassian Devops Groups
For those that were (and those that weren't) at the Sydney Atlassian Devops Meeting last night, my presentation is here: http://prezi.com/ukofmue_rgf0/
Tuesday, 24 November 2015
Three rules of thumb that say "this job is going to take ages"
As you might know, I've written a robot called AEED which looks at work tickets and predicts how long that job is going to take. I designed it to solve the black-hole problem of service desks: instead of "we'll get back to you", it's "your request will take around 4 days". If you happen to run JIRA in the Atlassian cloud (here's the marketplace link) or HP Service Manager it's definitely worth a look.
As it turns out, it's also giving surprisingly good predictions for software development and other kinds of projects too.
Anyway, some fun: now I've got some comprehensive data across a good number of organisations.
Rule of Thumb #1: Each hand-off adds about a week.
Initially I didn't believe this: whenever I've done any sysadmin work if someone ever assigned a ticket to me and it's not something I could do anything about, I would just pass it on to someone more appropriate as soon as I saw it -- a few minutes at most.
But that's not quite it, is it? The ticket sits in your queue for a while before you get to it. Then you second guess yourself to wonder whether it really might be something you are supposed to handle and waste a bit of time investigating, during which time you will get interrupted by something more high priority, and so on. Then you might need some time to research who it is supposed to go to.
I've seen numbers as low as 4 days per re-assignment in some organisations, stretching up to two weeks for others.
Whenever an organisation gets bigger than Dunbar's Number, the mis-assignment rate starts shooting up (as can get re-assigned absurdly large numbers of times, as in the chart above). Which makes sense: no longer does anyone know what everyone is doing. (I've got a long-ish presentation about this).
Implications:
Rule of Thumb #2: Meetings slow things down.
I didn't expect that just having the word "MEETING" appearing in a JIRA ticket would be a signal for a long duration. But, wow does it ever make a difference: 8-10 standard deviations of difference in how long the ticket will take!
The actual effect is often only a few days extra, but it's a very, very definite effect.
Some people might interpret this as saying "don't have meetings, meetings are bad". I don't think this is what is going on here; if a customer or tech is writing a work ticket and mentions a meeting, it probably means that the issue really can't be resolved without a meeting. If an INTP or INTJ computer geek says that a meeting is required, it's very unlikely that they are having a meeting for the sake of having a meeting.
But, any meeting has to fit into everyone's work schedules, and that can introduce delays.
Implications:
Rule of Thumb #3. Not much gets done on Wednesday
I was digging for data that showed that Friday afternoon is the worst time to raise a helpdesk ticket because everyone would be slacking off. It turns out not to be the case at all: in all the organisations I've got, everyone is more-or-less conscientious. Perhaps they make a Friday afternoon ticket a top priority for Monday, or otherwise make up for lost time.
But Wednesday? It's not true in every organisation, but it was there for quite a few.
I can only guess why. My guess it that people have less time on Wednesdays because they are called into meetings more. Nobody would organise a meeting for a Friday afternoon if they can avoid it; likewise Monday morning is often avoided. But need to call a meeting on a Wednesday? No problem!
Does anyone have any data on this? Maybe Meekan or x.ai might know, or anyone from the Google Calendar team? Or does anyone have any good suggestions of the Wednesday effect?
Implications:
Greg Baker (gregb@ifost.org.au) is a consultant, author, developer and start-up advisor. His recent projects include aplug-in for Jira Service Desk which lets helpdesk staff tell their users how long a task will take and a wet-weather information system for school sports.
As it turns out, it's also giving surprisingly good predictions for software development and other kinds of projects too.
Anyway, some fun: now I've got some comprehensive data across a good number of organisations.
Rule of Thumb #1: Each hand-off adds about a week.
Initially I didn't believe this: whenever I've done any sysadmin work if someone ever assigned a ticket to me and it's not something I could do anything about, I would just pass it on to someone more appropriate as soon as I saw it -- a few minutes at most.
But that's not quite it, is it? The ticket sits in your queue for a while before you get to it. Then you second guess yourself to wonder whether it really might be something you are supposed to handle and waste a bit of time investigating, during which time you will get interrupted by something more high priority, and so on. Then you might need some time to research who it is supposed to go to.
I've seen numbers as low as 4 days per re-assignment in some organisations, stretching up to two weeks for others.
Whenever an organisation gets bigger than Dunbar's Number, the mis-assignment rate starts shooting up (as can get re-assigned absurdly large numbers of times, as in the chart above). Which makes sense: no longer does anyone know what everyone is doing. (I've got a long-ish presentation about this).
Implications:
- Do you know exactly who is going to do this task? If not, add a week at least.
- Is your organisation so large that it takes time just to find the right person? If so, sign-up to the next beta of AEED.
Rule of Thumb #2: Meetings slow things down.
I didn't expect that just having the word "MEETING" appearing in a JIRA ticket would be a signal for a long duration. But, wow does it ever make a difference: 8-10 standard deviations of difference in how long the ticket will take!
The actual effect is often only a few days extra, but it's a very, very definite effect.
Some people might interpret this as saying "don't have meetings, meetings are bad". I don't think this is what is going on here; if a customer or tech is writing a work ticket and mentions a meeting, it probably means that the issue really can't be resolved without a meeting. If an INTP or INTJ computer geek says that a meeting is required, it's very unlikely that they are having a meeting for the sake of having a meeting.
But, any meeting has to fit into everyone's work schedules, and that can introduce delays.
Implications:
- Do you need to meet anyone in order to complete this job? Add a few days.
- This is the kind of thing that AEED tells you. Install it now while we're still in beta and not charging for it.
Rule of Thumb #3. Not much gets done on Wednesday
I was digging for data that showed that Friday afternoon is the worst time to raise a helpdesk ticket because everyone would be slacking off. It turns out not to be the case at all: in all the organisations I've got, everyone is more-or-less conscientious. Perhaps they make a Friday afternoon ticket a top priority for Monday, or otherwise make up for lost time.
But Wednesday? It's not true in every organisation, but it was there for quite a few.
I can only guess why. My guess it that people have less time on Wednesdays because they are called into meetings more. Nobody would organise a meeting for a Friday afternoon if they can avoid it; likewise Monday morning is often avoided. But need to call a meeting on a Wednesday? No problem!
Does anyone have any data on this? Maybe Meekan or x.ai might know, or anyone from the Google Calendar team? Or does anyone have any good suggestions of the Wednesday effect?
Implications:
- Assume you have a 4.5 day week. Pretend that Wednesday is a half day, because that's about all the work you will get done on it.
Greg Baker (gregb@ifost.org.au) is a consultant, author, developer and start-up advisor. His recent projects include aplug-in for Jira Service Desk which lets helpdesk staff tell their users how long a task will take and a wet-weather information system for school sports.
Wednesday, 11 November 2015
An Atlassian story
A little while back I was talking with two Daves.
Neither had any idea of who Atlassian is or what it does, which was no surprise to me. I don't quite understand why an Australian company with $200m+ in revenue and a market cap in the billions which isn't a miner, telco or bank isn't memorable.
Still, the tools Atlassian makes are mostly used by software developers, and my circle of friends and acquaintances doesn't include many coders so "Atlassian makes the software to help people make software" isn't a good way of describing what they do.
Other than a brief stint at Google, I haven't been a full-time employee or even long-term contractor in any normal company this century, so instead I talked about what's unusual and different at Atlassian based on all the other organisations I've worked with. I talked about how the very common assumptions about the technologies to co-ordinate a business are quite different here.
And yeah, my secret superpower is to be able to narrate HTML tables in speakable form. There was a lot of "on the one hand... on the other hand at Atlassian..."
Note that the Atlassian column is all public and searchable (in line with being an open company), and the "default corporate column" is not. Also, in the Atlassian column, you opt-in to the information source; in the "traditional company" column, the sender of the information chooses who to share it with.
Why is this interesting? Because the Atlassian technologies and the Atlassian way of doing things is an immune system against office politics.
In order to get really nasty office politics, you really need an information asymmetry: managers need to be able to withhold information from other managers in order to get pet projects and favourite people promoted, and for others to be dragged down by releasing information at the worst possible moment when the other party can't prepare for it. (Experience and being middle-aged: you see far too much which you wish you hadn't.) When information is shared only with the people you choose to share it with, that's easy to do.
At Atlassian, it's not quite like that. Sure, there are still arguments and disagreements. Sometimes there is jostling for position and disagreements about direction and there are people and projects we want to see happen. And not every bad idea dies as quickly as it should. But because other interested parties can opt-in as required for their needs it's a very level playing field and ---
And that's where Dave #1 cut me off, shook my hand and said, "Wow. Thank you. That's exactly it. That's EXACTLY it."
Dave #2 just nodded sagely. "Yes," he said, and then again more slowly: "yes."
Summary: Atlassian sell office-politics treatments.
Greg Baker (gregb@ifost.org.au) is a consultant, author, developer and start-up advisor. His recent projects include a plug-in for Jira Service Desk which lets helpdesk staff tell their users how long a task will take and a wet-weather information system for school sports.
- Dave #1 is the CIO of a college / micro-university
- Dave #2 is on the board of a small airline.
Neither had any idea of who Atlassian is or what it does, which was no surprise to me. I don't quite understand why an Australian company with $200m+ in revenue and a market cap in the billions which isn't a miner, telco or bank isn't memorable.
Still, the tools Atlassian makes are mostly used by software developers, and my circle of friends and acquaintances doesn't include many coders so "Atlassian makes the software to help people make software" isn't a good way of describing what they do.
Other than a brief stint at Google, I haven't been a full-time employee or even long-term contractor in any normal company this century, so instead I talked about what's unusual and different at Atlassian based on all the other organisations I've worked with. I talked about how the very common assumptions about the technologies to co-ordinate a business are quite different here.
| Type of communication | Corporate default (aka "what most companies do") |
What is generally done at Atlassian |
|---|---|---|
| Individual-to-individual | Email or talk over coffee. | HipChat @ the individual in a room related to the topic |
| Individual-to-group | Teleconference / webinar, for all matters big or small. | A comment in the HipChat room. Or sometimes Google Hangouts and HipChat video conference if it's something long and important. |
| Reporting (project status, financials) | Excel document or similar | Confluence status page or JIRA board |
| Proposal | Word document or Powerpoint presentation | Confluence page |
| Feedback on proposals | Private conversation with the person who proposed it, or maybe on another forum page somewhere else on their sharepoint portal. | The discussion in the comments section of the confluence page. |
And yeah, my secret superpower is to be able to narrate HTML tables in speakable form. There was a lot of "on the one hand... on the other hand at Atlassian..."
Note that the Atlassian column is all public and searchable (in line with being an open company), and the "default corporate column" is not. Also, in the Atlassian column, you opt-in to the information source; in the "traditional company" column, the sender of the information chooses who to share it with.
Why is this interesting? Because the Atlassian technologies and the Atlassian way of doing things is an immune system against office politics.
In order to get really nasty office politics, you really need an information asymmetry: managers need to be able to withhold information from other managers in order to get pet projects and favourite people promoted, and for others to be dragged down by releasing information at the worst possible moment when the other party can't prepare for it. (Experience and being middle-aged: you see far too much which you wish you hadn't.) When information is shared only with the people you choose to share it with, that's easy to do.
At Atlassian, it's not quite like that. Sure, there are still arguments and disagreements. Sometimes there is jostling for position and disagreements about direction and there are people and projects we want to see happen. And not every bad idea dies as quickly as it should. But because other interested parties can opt-in as required for their needs it's a very level playing field and ---
And that's where Dave #1 cut me off, shook my hand and said, "Wow. Thank you. That's exactly it. That's EXACTLY it."
Dave #2 just nodded sagely. "Yes," he said, and then again more slowly: "yes."
Summary: Atlassian sell office-politics treatments.
Greg Baker (gregb@ifost.org.au) is a consultant, author, developer and start-up advisor. His recent projects include a plug-in for Jira Service Desk which lets helpdesk staff tell their users how long a task will take and a wet-weather information system for school sports.
Tuesday, 27 October 2015
Vote for me and the robot overlord party!
Well, actually vote for my estimation robot.
Nobody enjoys figuring out how long it's going to take to program a new feature, or close a customer support ticket, or do a step in a project -- so let's had it over to the robots!
If you run Jira in the cloud, just click here to install it in your instance: https://marketplace.atlassian.com/plugins/au.org.ifost.aae
And if you think that it would be awesome to have better software estimates, and better predictions of how long projects and work will take, then vote!
http://devpost.com/software/automated-estimator-of-effort-and-duration
P.S. Devpost has all sorts of interesting and exciting competitions. It's worth signing up just to get a feel of where the future is headed.
Nobody enjoys figuring out how long it's going to take to program a new feature, or close a customer support ticket, or do a step in a project -- so let's had it over to the robots!
If you run Jira in the cloud, just click here to install it in your instance: https://marketplace.atlassian.com/plugins/au.org.ifost.aae
And if you think that it would be awesome to have better software estimates, and better predictions of how long projects and work will take, then vote!
http://devpost.com/software/automated-estimator-of-effort-and-duration
P.S. Devpost has all sorts of interesting and exciting competitions. It's worth signing up just to get a feel of where the future is headed.
Thursday, 1 October 2015
Are you having problems with estimates for projects and tasks?
I've developed a plug-in for Jira that uses machine learning to predict how long it will take for a ticket to be closed, and how much work effort will be required. Based on my current data, I'm getting 50% of tickets predicted correctly within a factor of 2, which is I think better than most human beings can do.
I'm looking for beta testers to confirm that it is all working as it should. If you are currently using Jira in the Atlassian Cloud (Agile, Service Desk or just vanilla) this will be a one-click add-on.
Contact me (gregb@ifost.org.au) if you are interested in trying it out.
Subscribe to:
Posts (Atom)