Wednesday, 14 January 2015

The First Is A Lie

Lately, I've been hyper aware of the first choice in web drop down lists. Yes, yes, I need a hobby.

When unsubscribing from a bunch of mailing lists, I've found I lazily choose the first option for "Reason" when I'm asked. This goes back to me wanting a one-click subscribe but beyond that, I will also choose the first option.

If you are thinking about asking a question and not putting yourself out of business then think about what your first choice in a list is. Don't let it be your worst option, even if it is alphabetical.

Sunday, 11 January 2015

Spam a Lot

If I attempt to unsubscribe from a email distribution and it is more difficult than two clicks, I will mark their email as spam. If you're implementing an unsubscribe mechanism for mass mailing then keep this in mind. Systems like gmail and other mail servers will start quarantining or marking all your mail as spam. This means that your valid subscribers may also miss your mail now.

One thing I've learnt about usability is that if I'm doing it then there are millions doing the same thing. Especially when it comes to exerting too much effort.

Monday, 17 November 2014

Oakton DVS Agile


When I complete a project delivery, I like to make sure that I list the agile practices that were used to achieve this goal.

No matter what people tell you about agile, there is no one way to do it. I have delivered and managed many agile teams over the years and even the same team across multiple projects and I have never once seen exactly the same agile practices set used twice.

Just as fingerprints are different between individuals, so are agile practice sets for teams. The variables are so vast that no two will be the same, beit the product being built, the team and parts of its sum or the baggage we all carry from job to job.

This is normal and this is why I keep track of all the combinations as I go along.

In the case of the Document Verification Service that we built for the Commonwealth Government's Attorney General's Department, the picture above shows the practices and some of the tools we used.

It is grouped in to development, management and analysis (BA and QA together) practices. Some of course, overlap.

Always keep track of what worked and what didn't. Try them in your next project but don't force them. Sometimes the best practice on one team will die brutally on another and vice versa.

Just as agile allows projects to adjust with changing requirements, agile itself changes for its team requirements.

Rigour over rigidity, always.

Thursday, 6 November 2014

Resume + Character is what I want



A resume does a good job of describing specific skills. Today I had lunch with a group from my last contract and then an evening of pampering with the women I work with in my current role.

Reference checks and resumes don't tell me how awesome you are as a person or why your ex-colleagues still love being around you. How do we judge a person's character when all we have is a list of jobs?

I think it's a combination of what is on paper and what you see in an interview. Let people reveal themselves face to face. Talk to people who know them. Look for character as well as a checklist of skills.

Wednesday, 27 August 2014

Why Organisational Culture Comes From the Top



When you are a doer, you want people to let you do your job and to help you improve at it. You need senior people who enable you.

When you are senior or a lead, you want people to let you do your job and to help people around you. At this point, you know how to improve yourself but you need to be allowed the space to grow and move.

When you are a team, group or organisational leader, you want people to let you do your job and to enable those around you to do their jobs. You want to aid in individual and organisational growth.

If one of these points in the hierarchy doesn't want to enable others and instead focuses on themselves with little to no regard towards those around them then organisational culture changes. In my opinion, it changes for the worse.

Too many places I have worked see leaders who see their career journey and their need to climb a corporate or financial ladder as more important than the people around them. When they finally achieve the power required to drive their own careers, they declare it "every man for themselves!" and start kissing up and kicking down. Or worse, they simply neglect their teams.

I asked a recent manager in a past job if he cared about his team at all and the dysfunction that was tearing his team apart. He said to me "I don't have time to care." At that point, I reached out to my network and found myself a new job.

You shouldn't work for a manager or leader or boss who doesn't have time to care about his or her team. Nothing good comes from that.

If you look above you in an organisation and don't see anyone caring about the people who work for them then leave. If you look around you and can find no allies who will fight for your team over themselves then leave. If you don't want to enable the people you work with or aren't allowed to then leave.

I once had a manager who told me to stop enabling people because it was getting in the way of them working. He also thought bums on seats was more important than productivity which ultimately drove his subordinates to avoid his desk to take coffee and toilet breaks so he wouldn't see them. He didn't want anyone to be allowed to grow and achieve in their roles. Instead, he wanted them to clock in and clock out and show him the appropriate amount of fear inspired respect. As you can imagine, his team ended up as toxic and broken as he was.

Organisational growth comes from its leaders. So does organisational rot.

If you can respect the leaders around you then you will like your job and where you work. If you can't get near them, don't know what they represent or purely dislike their ethos then you need to go somewhere else.

Organisations can not be healed from the bottom. They are shaped and scented from the top.

Tuesday, 26 August 2014

I was humble once and I was awesome at it or 5 Rules to Being a Great Team Lead


I often mock humility with my favourite saying "I was humble once and I was awesome at it."

The truth is that I think humility is a virtue. It is a moral excellence and one that many claim to possess but then fail miserably at.

The reason I bring it up in this context is because you can not enable and serve a team unless you possess the ability to put yourself last and not aspire to take the credit.

In the last few years, I have worked with egos that would sink the Titanic. Most have been brilliant individuals that for some reason craved the acknowledgement of their brilliance to sustain them.

There is one thing that I do well and it is building teams. That doesn't mean I am awesome at hiring geniuses. It doesn't mean I am great at finding combinations of people that work together. That doesn't mean my teams exist because of me. The one thing I do well is serve my teams. I exist to build a safe and sustaining environment that allows people to do their jobs.

People want to do good work. They want the 8 hours they spend every day to mean something. Most people don't want to run the world. In fact, they want that kind of rubbish to be kept out of their way so they can contribute to the best of their abilities.

I have five rules that I believe make a great team lead:

  1. Lead from behind - enable your team to do what they do best. Don't pull them along by a collar;
  2. Share the fame and share the blame - don't single anyone out as a hero or a villain. Teams produce great results, not individuals;
  3. Celebrate all the wins, no matter the size - don't wait for external validation to celebrate your team. Make the little moments big moments and the big moments, amazing;
  4. Lead the charge and die trying - always be part of delivery and contribute to success. No one will follow you if they don't think you truly understand what it is like to be them; and 
  5. Have fun - life is too short to be serious all the time. There is a time for seriousness and that is usually with your clients. With your team, you should be a person who laughs or cries or falls flat on your face. Being real will allow people to be themselves and when they are themselves, they will be great.
Humility involves succeeding and failing. Both are valid. Failing is ok as long as you learn from it. Success is ok as long is it doesn't go to your head.

Monday, 23 June 2014

User Story with Technical Use Case Template

Every single time I join a new agile team, I am asked the same thing - How do you write a user story?

There are many ways to achieve this. Here is mine template of choice. It is a User Story with Technical Use Case template. The hardest part everyone has when writing a story is defining Business Value. If your users wouldn't say it then it isn't business value. Keep that in mind.

User Story: @id


User Story: [One line description of the story. Keep it short as this is how the team will refer to the story. e.g. Eligible User logs in]

As a/an [persona/user/role/consuming-system e.g. Eligible User]
I want to [do a function of the system e.g. Log in]
So that [business value e.g. Access my information]

Main Flow

Preconditions/Entry Criteria

  • This is an unordered set of conditions that must be met before the first step can begin.
  • E.g. The user is on the login page
  • E.g. The user has already been added as a valid user with a username and password


Steps
1.      This is an ordered numbered list of steps that represents the happy path through the workflow.
2.      E.g. User enteres username and password.
3.      E.g. User clicks the “Login” button.
4.      E.g. User is authenticated and authorised and shown the Successfully Logged In page.
5.      …

Post Conditions/Acceptance Criteria/Exit Criteria

  • This is an unordered list of conditions that must be satisfied in order for the flow to be considered completed.
  • E.g. User sees the Successfully Logged In page.  

Alternate Flow 1

Preconditions/Entry Criteria

  • This is an unordered set of conditions that must be met before the next step can begin.
  • E.g. User login was unsuccessful


Steps
4.1   This is an ordered numbered list of steps that represents the happy path through the workflow.
4.2   This included all error flow but not exception flow.
4.3   E.g. User sees the Login page with an unsuccessful message .
4.4   E.g. User is able to retry logging in.
4.5   …

Post Conditions/Acceptance Criteria/Exit Criteria

  • This is an unordered list of conditions that must be met for the story to be complete.

Alternate Flow 2

 … 

Alternate Flow 3

… 

Exception Flow

Preconditions/Entry Criteria

  • This is an unordered set of conditions that must be met before the next step can begin.
  • E.g. A system exception has been thrown.

Steps

  • This is an ordered numbered list of steps that represents what happens every time there is an exception in the flow that can’t be anticipated. 
  • E.g. User sees the Error page with an filtered error message

Post Conditions/Acceptance Criteria/Exit Criteria


  • This is an unordered list of conditions that must be met for the story to be complete.