Agile on Andrew Khoury

Things I learnt working for an I.T Consultancy

Sun, 06 Oct 2019 21:05:20 +0000

This was an old blog post draft that I planned on cleaning up. In the end I decided to post it as the raw stream of thoughts that it is. Each one of these thoughts could be its own blog post.

Things I learnt working for an I.T consultancy, doing the DevOps, building all the platforms, leading teams, and annoying a bunch of people along the way.

aka

Ramblings from a “DevOps Engineer”.

Resource Augmentation vs Outcome based work (the ongoing struggle of chasing high-value outcomes for clients).

The art of getting people to realize stuff (you might know what the “right” answer is for a given technology choice or next step for a project, but how do you bring people along for the journey and give them a chance to input their own ideas).

Hiring, promotions and bonus/incentives.

360 feedback — getting honest feedback, and getting it much more often that every 12 months
how your bonus is allocated — and why the worst time to talk about your bonus is when it’s being handed out
Why/Why/How you should negotiate $ — know your value, understand the ‘buckets’ of money in companies and the incentives from the companies perspective. Most important understand what your drivers are and what will make you happy. Is is just money, or do you have other wants?

Early in my career I used to think that process was the key, and I overlooked people and my teams.

Agile gone bad. How some so amazing has been weaponized over and over. There are literally hundreds of examples of this e.g: “Let’s start reporting on story points per person so we can compare individual performance”.

What’s wrong with LinkedIn, and (some) recruiters. And why my inbox looks like a dating app (with message after message of poorly thought out copy/paste solicitations).

Incentive to send messages (to meet quotas)
Incentive to get you to leave your job

How you should fill a role:

Ask them what they need done, use that to drive requirements for a role
e.g fix our pipelines, scale our app, reduce bugs in our app (by half, e.g from 50 to 25)
write an advanced thank-you letter to give to applicants/new starters so they have a clear goal of what to strive for
Let people pick their team members

How do you mange your projects? (hint: It doesn’t matter what software you do/don’t use — it’s more about how you manage blockers and how focused the team can be). Physical wall vs Virtual (JIRA board), this choice will be specific to the team and it’s needs. You may need to compromise on level of detail — that’s okay.

AWS. Their approach to development teams. Get on-board for building APIs so other teams in Amazon can consume them, and how it launched them into the biggest Cloud provider today.

Trust the people you hire. If you’re hiring people you don’t trust you’re doing it wrong.

One thread on LinkedIn from a hiring manger had the attitude “I’ll pay you 50% market rate until I trust you”. I really hope they were trolling.

As Steve Jobs said: Hire smart people to tell you what to do.

Train/Grow people. Don’t be worried about “What happens if we train them and they leave?” … be worried about “What happens if we don’t train them and they stay”.

Remote work. Pros/Cons.

Pair programming optional, Reviewing code mandatory.

Platforms. “Built it and they will come” is some of the biggest wastage in I.T departments that I’ve seen.

Documentation, too often it’s seen as not important but just like testing it should be part of the work you do not an “I’ll do it later” type thing.

Start thinking of your internal teams as customers (see AWS note about APIs).

Track/share Metrics. Make decisions through data.

Vision is important, have one, or follow someone who does.

Being talented isn’t always a good thing…

e.g being right and proving someone wrong in a group setting
intimidating someone by showing off how smart you are to them
challenging tech leads, delivery leads, sec, ops in a way that gets them off-side

DevOps teams & how they’re AntiPaterns. https://web.devopstopologies.com/

The power struggle between Ops Sec and the rest of the company.

Some people don’t want change.

There’s no one magic solution, or one magical person that can drive transformational change. Support is needed from the top, but also needed at all levels (It’s great to have support from the c-level, but if ops/sec blocks things you’re not going to have a good time).

Technology is actually pretty easy to work with, people are more complicated. If you manage teams meet with them regularly, care about them, and get out of that office when you have your catch-up. I had most amazing Delivery Manager who would catchup with every single team in our company every two weeks. He’d ask about what’s good/bad/blockers and what and what he could do help me. He also asked how I was feeling and if I was challenged. Mostly he actually cared about me and my life because each conversation felt like one with a good friend — and years later we still keep in touch.

Info

Also posted on medium as Things I learnt working for an I.T Consultancy.

A comprehensive guide to “Being Agile”

Sat, 24 Aug 2019 17:46:36 +0000

We need to talk.

Today I want to talk to you about Agile, and no I don’t mean Jira boards and sit-down-stand-ups. I want to look into why we do what we do.

Actually, I wanted to write an article about effective communication and how we (as actual human beings) have significantly more meaningful interactions in person than we do over video chat, real-time messaging or email. Join me on a short detour.

How we communicate

Try some of these (at your own peril) next time you’re talking to someone in person:

Stare at them with eyes wide open while you’re in middle of a regular conversation
Raise you eyebrows in shock as a response to something they’ve said — more fun if they haven’t said anything shocking
Invade someone’s personal space by inching closer and closer to them

You’re likely to get a response, and that’s because human’s are complex — our message isn’t just the words we say it’s so much more and the following only scratch the surface:

Facial expressions
Body movement and posture
Gestures
Eye contact
Touch
Space
Voice

Something bigger than yourself

I used to think all that mattered was code — as an individual contributor if I could just pop those headphones in and achieve flow I’d be able to develop the best solution possible, and life was good. But something happened — I was introduced to “DevOps” and something called “Agile” and I discovered the world of consulting.

I had accidentally stepped into utopia — companies had identified some sort of issue or need and were calling out for help. They needed people who could code, who could deliver solutions in challenging environments and could help teams transform into better versions of themselves. Well if there was anything I loved more than code it was being in front of a group of people inspiring them and making their lives better one whiteboard or pair programing session at a time — and learning along the way.

Continuous Improvement

I take the idea of continuously improving very seriously. I want to improve myself, my team, my consultancy and my clients. I also spend time on helping my friends and family grown and improve. I get an enormous amount of joy out of helping people.

When trying to introduce the concepts in the Agile Manefesto many questions can arise, consider these:

How often should we do sprints
Being Agile means that we can add scope with no negative impacts, right?
Do we need to do standups every day (and why do we need to standup?)
We don’t think retros are valuable — they’re just another meeting
Our scrum master told us we’re not allowed to >insert any prescriptive directive from on-high without a rationale attached<
Do we have to do this meeting face to face — I’m busy — can I bring my laptop so I can work in this meeting?
We need to write a detailed plan for the entire project ahead of time — then report on it weekly to our finance department, explaining each deviation to them — but you can do that Agile thing within you own team at the same time, right?

So here’s the thing — Your team gets to decide if they want to “practice agile” or not — and if so, how to do it. But if you are going to do it you (your team, and your company) should understand its origins and get ready for a ride of continuous learning and improvement.

How to do Agile right

Here’s my crash course. Ask whatever question you like (like a magic 8 ball), then read the Agile Manifesto (I’ve included it below) for the answer, simple.

Hint: If you’re looking for more guidance — ask someone who’s done it successfully. Experience beats theory.

Wondering why you can’t lock yourself away and code the “perfect” solution on your own? Or why you need to meet with your team so much?

8-ball says: The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Not sure why this “retro” thing is happening every two weeks — and wondering if it’s really that important to do at all?

8-ball says: At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

We can use this method to unpack themes around business value, continuous delivery, environments at work that encourage growth and motivate teams. We explore what it means to produce high-quality working software in a metrics-driven fashion, but we’ll have to save those for another day.

Everything you ever need to know about Agile

https://agilemanifesto.org/

What is Agile?

A guide for better ways of developing software

I’ve only got 30 seconds — What do I need to know?

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

I need more please, how do I know if I’m doing it right?

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity — the art of maximizing the amount
of work not done — is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Info

Also posted on medium as A comprehensive guide to “Being Agile”.

The cost of failure is education

Tue, 12 Feb 2019 09:40:54 +0000

wow, so cool.

If you’ve ever been responsible for software running in production, you should already be well aware of failure. But it’s not only traditional “operations” roles that are affected by failure.

Consider some of the changes we’ve seen in IT in the last decade:

2003: SRE - Site Reliability Engineer, a discipline created at Google that incorporates aspects of software engineering and applies them to IT operations problems.
2006: AWS EC2 - The birth of the cloud “Amazon Elastic Compute Cloud (EC2)” which made Infrastructure-as-a-Service available to developers around the globe via APIs. It paved the way for CloudNative, Serverless, PaaS and the hundreds of services we have available to us today.
2009: DevOps - The combination of software development (Dev) with information technology operations (Ops)”.

It’s clear there have been changes in the people and teams who need to be involved in running software for customers. At the same time there have been significant changes to how we build, test and deploy software.

Culture is a common topic that comes up when we talk about things like DevOps, Lean Software Development, and SRE but what do we mean when we say culture? Do we just give developers pizza and beer until they produce good software and hope they don’t leave for another company offering gourmet pizza and craft beer?

Origins of lean in manufacturing

To understand the origins that paved the way for DevOps, SRE, and the “Culture/Transformation” we’re hearing so much about in IT we need to go back, back to 1990 and back to car manufacturing. Consider the following quote from https://en.wikipedia.org/wiki/Lean_manufacturing

Lean manufacturing makes obvious what adds value, by reducing everything else (which is not adding value). This management philosophy is derived mostly from the Toyota Production System (TPS) and identified as “lean” only in the 1990s

Steps to achieve lean systems

The following steps should be implemented to create the ideal lean manufacturing system:

Design a simple manufacturing system
Recognise that there is always room for improvement
Continuously improve the lean manufacturing system design

Sound familiar? These themes are present in Lean, Agile and DevOps.

The andon cord — Game-changing rope

Back in the early days of the Toyota Production System (TPS), Toyota implemented many unique tools and processes. The Andon Cord was born, and while it was just a rope it was the most powerful rope you’ve ever seen.

Anyone had the right to pull the cord at any time and pulling it would instantly stop all work on the assembly line. The technology behind this wasn’t revolutionary, but the thinking, culture and trust behind this system is something we can learn from today. The “Safety Culture” around this process was reinforced when the team leader arrived at the workstation, thanking the team member who pulled the Cord.

The team member did not, and never would be, in a position of feeling fear or retribution for stopping the production line

Toyota has so much to teach us about working together an respecting each other. Even if the team leader knew a better answer, Toyota principally felt that a solution from the team member was a better outcome.

Postmortums & lean software development

Leaving cars behind and getting back to software, Mary and Tom Poppendeick’s work on Lean Software development in the early 2000s paved the way for the sort of thinking coming out of Google (SRE), and one great example of that is postmortem culture.

Writing a postmortem is not punishment — it is a learning opportunity for the entire company.

As an IT professional with a decade of experience I’ve seen how the culture of the company can significantly impact how people, teams and the organisation grow and improve. The great opportunity that exists when failure happens is learning. The companies and teams that truely believe this are the ones that will continuously improve, both their software and their culture.

Info

Also posted on medium as The cost of failure is education.