Who knew I had a blog?

I unexpectedly found this blog when I was cleaning up my Linkedin profile for the first time in 3 years, and noticed the URL hanging off my profile.

A lots happened in 3 years, and my focus has switched from hands on coaching of teams to Enterprise transformations. I spend most of my time coaching and mentoring other coaches and leaders in the organisation. There are lots of learnings there but few that have been captured and documented.

I'll try to rectify that over the next few months...

We keep forgetting to have the conversation

One of the common anti-patterns I see with new agile teams is that they try and do the requirements

analysis in a linear fashion. Something along the lines of PO -> Business BA-> Tech BA ->Architect ->Dev.

By the time it reaches the dev, it’s been several weeks and the requirement is so far abstracted from the original intent that it’s incorrect.

This can be exacerbated with a team that may be under pressure as they’ll default to previous waterfall behaviours and look to deflect the pressure onto someone else.

In nearly every scenario where I’ve walked into a project and they’ve told me they have an issue with the requirements and building stories in time, I witness the above scenario.

Get a room. Grab a whiteboard. Have a chat.

Shane Hastie did a session at Agile Australia 2015 on Product Ownership being a team sport which is a good read: 

“It’s not usually a problem with the tool, but the tools using the tool”

A wise agile coach once told me that.

All of the Agile ALM tools do similar things. Each have pro’s and con’s, but they’re all pretty similar.

If the solution to your problem is the tool – you’re doing it wrong and you may want to re-visit the agile manifesto.

On my most recent assignment, I have a PM that hates Jira. Can’t stand it.

Can’t tell me why.

Having mostly used Rally and Version-one, I was surprised by how simple the filter querying is in Jira and my ability to generate reports to find gaps in our delivery process.

So 2 days after all the Jira complaints – I gave the PM  a few dashboards and reports that gave them better visibility into their actual status.

And that’s when I found out they’d never logged into Jira before.

Thus ends this story - Please return to title.

Leadership communication.

It’s really important.

How you do it is also important. At my current workplace, I usually get a daily email from one of the senior Execs that is blasted out to the company. They’re not personal, but they’re generally pretty good.

At a previous company, the Leadership emails didn’t even come from people. They came from the furniture.

All the emails would come pre-fixed with “From the desk of xxx – CEO”.

Please don’t do that. It’s hard for someone to believe you care about them when you’ve delegated your communication to your desk. Unless your desk has a dream...

The Agile ceremonies are not for you

Well, they might be. But not always.

Working in a collaborative fashion is difficult when more and more often our teams are not co-located.

In an era of activity based working and off-shoring, it’s increasingly rare that the basic scrum model is adhered to.

The daily stand-up (Team Scrum, Scrum of Scrums) is the one daily opportunity on our projects when you know everyone is going to be there just in case you need to have a conversation straight after. 

It’s not about you. It’s about the people that might need your help.

Otherwise we resort to email. And we all hate email.

Whilst I’m waiting for that kettle to boil….

Context switching. We’re all guilty of it. Even those of us that lecture others not to do it.

An example occurred recently when I was in the middle of answering several emails, whilst also talking to someone on the phone. (Cue Male multi-tasking jokes.)

Anyway, instead of sending a document on to my team for review, I inadvertently sent it to the wrong distribution list and sent it to 450 staff instead. You all know how well the Outlook “recall email” feature works right?

So instead of saving me time by working on multiple things at once, my multi-tasking cost me 2 days. For the next 48 hours, I received and responded to emails form confused people asking me why they had to review a project charter template.

This same scenario plays itself out in many other work facets. Do you have team members working on more than 1 project? Or more than 1 feature at a time? Is your organisation working on numerous initiatives at once instead of prioritising and completing one at a time?

There’s an often circulated graph from Weinberg that represents the loss in productivity to context switching.

Sometimes you're better off staying at home and not coming into the office...

Another one I like to use is this one from Rally. When they look at the underlying data from their hosted product, they noticed a significant increase in bugs when team members were working on more than 1 project. So whilst it seems faster, It’s actually costing you more in the long run. 

Excuse me – I have to go re-boil the kettle.

What’s good?

I was contracting on a pretty tough project at the time, and got a request for a meeting with one of the consultants in the firm that was sub-contracting me out to the client. In hind-sight, I think he was on the bench and they just wanted to keep him busy, but his supposed aim was to get a pulse on the consultants and what was/wasn’t working.

I still clearly remember when he asked me how happy I was in the role on a scale of 1 to 10 and I replied with “7”. “Oh, that’s great” he said.

No it’s not.

7 is meh.

Having previously experienced awesome, I knew how un-awesome the current role was.

I quite like the simplicity of the net-promoter scoring system.

Essentially there is only 1 question  - How likely would you be to recommend the service/product to someone else. The ranking is out of 10 and the scoring gives you an indication of who is a detractor, a passive or a promoter. You want promoters.  You want your team out there talking to friends about what an awesome place it is to work.

So based on my scoring, I was passive about the company (which was true - I wasn't exactly running around raving about it to my friends). 

If you’re an employer or a leader at a company and your staff are ranking your workplace a 7, You’re better than that.

Finding Awesome Product Owners

We were having particular trouble with the product ownership on a project and I wanted to create some training on what you want in a good product owner. Henrik Knibergs video is brilliant and I use it regularly, but then I came up with the 5 A’s to an awesome product owner below:

Ability - Is able to be the voice of the customer.

Authority - Empowered to make decisions on a day to day basis

Autonomous - One single "owner". Not a committee.

Available - There on a day to day basis to work with the team

Adaptable -  Flexible to changing situations and environments

Whilst there’s only 5 traits – finding them in the one person at a large organisation can be ridiculously hard. The person with authority usually isn’t available. The person with the ability may not be adaptable enough to work in an agile way. In a large business, it may be hard to find someone with sufficient autonomy.

No one said this would be easy…

Take your hand off it

Can’t get people off their mobile phones?

Use them as part of your meetings.

Live online surveys are awesome, as it forces them to interact using their devices and they can’t check Instagram at the same time. Well, they can, but they’d be context switching and you all know that’s  a no-no now right? 

There’s a bunch out there, but Directpoll is free and seems to work well.

I sometimes also use planning poker apps instead of cards – There are some free ones out there – Scrum Poker cards has worked for me.

Ask your staff

We had an IT Exec call us up once and ask us what they should do to help their team. Over the previous 2 years, they’d gotten good at iterative delivery and we’re pushing features into production on a weekly basis. The nature of the systems meant that those deployments usually occurred on a weekend and he was worried about burning out his teams. (Which is a good thing that he cared).

Our response?

“Why are you asking us? Ask your team.”

And once you've worked out if it is/isn't a problem, then ask them what you can do to help.

We continually run into the management trap of trying to make decisions and solve problems in isolation, when we’re too far removed from the coal face where the problems are occurring.

Caution: Be careful that you actually action and are willing to solve the teams issues. It only takes 1 or 2 instances of “My door is open – please tell me your problems” that never lead to any solutions before they will stop coming to you. And that breakdown in trust may be even more detrimental.

Hire only Fully Formed Adults

Sometimes an article or blog post resonates with you deeply. 

The Netflix HR slides did for me.

One of my first roles was as a Program Manager at a start-up that built enterprise network and systems management software. 

I was employee #11 in the Sydney office, and I somehow ended up doing most of the hiring over those formative years. In hind-sight, it was ridiculous to have a 22 year old kid doing the interviewing for all the dev and test roles, but we didn’t know better, and hey – that’s why start-ups sometimes succeed when you don’t expect them to. They don’t listen when you tell them it shouldn’t be done.

Looking back – I was purely hiring on “cultural fit”.

Essentially; Was the person someone that you would be excited to work with. That was the test.

We certainly made mistakes and we probably had a few too many “brilliant jerks”, but they were still some of the best years of my career.

Because when you surround your staff with awesome people - it's a great place to work.

Being a scrum-master isn’t difficult

That phrase is probably considered blasphemy, but I guess it’s a case of perspective. My wife tells me  “brain surgery isn’t rocket science” J.

Over the last few years I’ve seen a lot of people (testers and BA's in particular) move into scrum master and iteration manager roles.

When you look at the criteria , it’s really not that difficult. A CSM certification is essentially bought. You spend a few thousand dollars on a 2 day course, and BAM – you’re a Certified Scrum Master.

When I was at Pillar, we were anti-certification for that reason. You also wouldn’t have seen scrum-master or agile coach on any job description either. From a mercenary perspective, it’s coaches that are usually the first ones cut when budgets get tight – but also because it’s only a small portion of the role that our delivery leads played.

So what makes a good scrum-master?

You're going to hate the answer.

The best scrum masters are those that are masters of the intangibles. It’s not whether they run the agile ceremonies. It’s how they run it. It’s how their team interacts. It's the vibe on the floor.

The best scrum masters are like good shepherds. They are keen observers. They protect the flock. They make sure the team are moving in the same direction and don’t go wandering off. 

Most of the time – you won’t notice them as they go about their work.

You will notice if the role in't being fulfilled.

Do you need a dedicated person?

Sometimes.

With new immature teams, bring in the experience.

Once the teams are established and humming, It's rare that i've seen enough work to keep it as a single person in the designated role. A lot of places have a scrum-master that looks after a few teams, or someone within the team playing the role. If you decide to do this - be careful of having the Tech lead/Dev Manager fulfil the responsibilities. That takes it back to a manager/team-member relationship and can affect the dynamics. It's too easy to slip back into a directorial position.

Remember - we're looking for self managing teams.

Leadership refined

One of my favorite questions to ask when I was interviewing with companies was why they switched or wanted to switch to Agile. What problems were they trying to solve?

At one of the interviews the Program Director that was interviewing me answered:

“It gave me visibility so I could micro-manage the teams better. The teams need that sort of oversight.”

I didn’t take that role.

Good agile teams are self-managing. They take initiative; they learn from mistakes, they unblock themselves without requiring intervention. It’s a far cry from being micro-managed. In fact – I’ve seen situations where the teams were successful in spite of poor management.

Unfortunately that success just reinforces the bad managers behavior.

The concept of agile scares a lot of mid-level managers.  Some got to their positions with a very direct management style.

If you’re at an organization that still has an “old boys club”, It is usually one of the toughest things to change when trying to do an agile transformation.

If someone has been rewarded and promoted throughout their career for behaviors that are now disruptive to the team and productivity – How do you change those behaviors?

Being able to guide them through their new roles and responsibilities will be crucial to your success, as they will likely be the loudest and vehement detractors if you don’t get them onside. Despite my dislike of mechanical agile, I find that being very prescriptive helps with the transition for these personalities.

It’s easy to assume bad intent when you run into these situations – but think of it a different way. Do they have the necessary skills? Do they know how to lead and manage any other way?

You may find it’s not a problem of motivation – it’s a problem of skill, and all skills can be learned. Even sailing.

Selling yourself

So what should you focus on to make yourself marketable?

Make sure you cover these 3 areas:

1. Relevance
2. Differentiators
3.  It’s not about you – It’s about them.

1.     Relevance: I recognized fairly early that my 11 year stint at Symantec was more of a hindrance than a help as it monopolized my industry experience. Most of the roles I was applying for were in the Finance, Digital Media and Telco industries, which I had no background with. You can combat that by highlighting the parts of your career that are relevant and doing your industry and company research before the interview.

Make use of the cover letter and make sure it highlights in point form the specific skills they are looking for in the advertisement. Most recruiters do a 5 second scan looking for keywords – so make sure you tailor it for each role. Keep it short and to the point.

2.      Differentiators: What makes you different from the other candidates that are applying for this role? Make sure you’re clear on that and get that across in an interview. What I noticed was that there were quite a few candidates floating out there with agile experience, but mostly as part of a team or as a scrum-master. There were very few that had taken a large organization through that agile journey and transformation and could draw on that experience for their future employer. So make sure you take time to identify what sets you apart from the field.

3.     It’s not about you: At the end of the day, the role is open because they have a need to fill / a problem to solve. Find out what that is. 

      

Use Questions like:

a.     Can you tell me why this role hasn’t been filled internally?

b.     What are the main challenges I’d face when I start this role? (it’s always nice to get them picturing you already in  the job J )

c.      What are you trying to solve with this position?

d.     What keeps you up at night? (If you're meeting the hiring manager, you can be fairly sure they are having problems they need help with)

As they respond to the questions, make it a discussion and tie it back to how you’ve solved such problems using examples from previous roles.

Usually, the Job description as advertised is basically a checklist that needs to be met before an interview will be granted. What’s really going to get you the job is how well you can sell yourself as the answer to the hiring managers problems.

Good luck.

Hunting

We’re taking a slight segue here and going to cover some topics around finding a job.

Having recently relocated home to Sydney Australia after 6 years in the US,  I found myself back on the job market in an entirely different economy.

Some very basic observations after a few weeks of job hunting:

1. Pay attention to when the financial year ends in your job market. Traditionally, Australian companies finish their financial year at the end of June. In the US, it was usually Dec. Either way, the quarter leading up to it is usually slow as companies crack down on budget to hit numbers.

Note: Unless your looking at public sector roles. In that case, it’s sometimes “Use it or lose it” and you will see government departments spending up big in the last quarter.

2. Despite the first point, there are always positions available. Even when it’s “slow” the companies that are hiring are serious about it.

3. Surprisingly – It’s not about the technology. With more and more software development moving off-shore, I found my Project Management background of much more interest to companies then my background managing technical development teams.

4. Linkedin, despite being the predominant networking and recruiting tool in the US,  plays a cursory supporting role in Australia. Use SEEK. That’s what everyone else does.

5. Recruiters are a necessary evil. Almost all companies have PSA’s (Preferred Supplier Agreements) these days, which means they work exclusively with a handful of recruiters. Whilst there are some organizations that will only recruit directly, your chances of getting your resume into a company are much higher if you get it into as many recruiters hands as possible.  Remember – they only have a handful of jobs each that they are trying to fill, so only working with  a few does not get your resume out there.

You can complain about the fees (particularly if you’re looking at contract work) but at the end of the day – They are paid on commission, and you are a commodity that is being sold.

Very early in my career, I spent a year moonlighting as an IT recruiter. It was during the dot com boom at the end of the 1990’s, and it was much less structured.  If you had a very good candidate, it was easy to become their advocate and reverse market them to companies you thought were interested.

With the increased prevalence of PSA’s, that’s increasingly rare. The recruiter’s customer is the Organization. Not the candidate. You’ll see their behaviors change if you get to 2^nd interview stage.  Your best mate will suddenly become a bit more insistent. They will push you to take the role, even if it’s not the best one for you. Which should be expected – they only get paid on placements.

6. It’s not about compromise.  Luckily, I don’t have children to support, so there was no urgency to accept a role that didn’t tick all the boxes. Be careful of falling into the trap of having to choose between a good job and crap pay, vs a crap job and good pay.

That’s a suckers choice.

If you're patient – you’ll find roles where you won’t have to make that decision.

So what was my experience like?

Despite it being the end of financial year, and dire warnings about the GFC,  surprisingly good.  I kept a log of my 2 week search so I could keep all the agencies/jobs/companies straight and the numbers ended up:

• Applied for twelve roles
• Interviewed with Agencies for Six
• Interviewed with Organizations for five
• Second interviews at four
• Offers received for three of them within 2 weeks.

That was much better than any of us expected. Friends, recruiters and myself included.

In the next post, we’ll cover how to make yourself more marketable.