Early on as a manager, I came across Agile methodologies, but wasn’t able to get training in it, so I had to figure out how to implement it myself.

After reading countless books and immersing myself in whatever I could find online, I was able to implement several key elements. But I still was missing a few crucial pieces.

It was only after working in a self-described “academic” Agile – with a capital ‘A’ – environment that I know now what I was missing. Sadly, all it took was a few days, immersed, to see.

I’d like to share my lessons learned for other managers going at it alone. Some lessons will be things I did on my own, and did right. Others lessons will be things I just couldn’t see how to implement, until I saw them in practice.

So as not to overwhelm with a megilah I’ll break my thoughts on implementing Agile into several posts.

Daily Scrum a.k.a. “Standup”

The single most impactful step I took at the beginning was implementing a daily standup. This is one of the “events” in the Scrum Guide, also known as “rituals”.

Each person on the team answers the following questions:

• What did I do yesterday?
• What do I plan to do today?
• Are there any “blockers” getting in the way of me accomplishing the task at hand?

It’s important to time box this. So each person should be limited to 30 seconds. It’s also done standing up to keep the meeting short.

If you can’t measure it, you can’t improve it.

– Peter Drucker

This quote can be used to justify, pretty much, every agile event and artifact. All of Agile is geared towards facilitating smaller iterations, delivering functional software, and constant improvement.

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

– One of the 12 Principles of Agile Software in the Agile Manifesto

At my first job as a developer I did not communicate the challenges I was having. That led to several all-nighters with the top developers helping me sort out the spaghetti I called code. I had come from working as a freelance developer where you say “yes” first to every project – so you can eat.

“Standup” helps to fix that. We did standup daily at that job, but I hadn’t expressed the challenges I was facing. The engineering manager is responsible for pushing back in these cases.

As a manager myself I missed the signs with some of my developers. No one wants to look like they’re not up for what they’ve been tasked with.

Standup is designed to help expose this issue. When the team is paying attention, they should see the signs of a developer who is blocked, or stuck on a problem.

Standup does this by creating small iterations that creates space for feedback early and often.

Implementing standup was the single most impactful step I took at the beginning was implementing a daily standup. Immediately I was able to measure the daily progress.

When you measure, you can improve. I also started seeing sooner issues that were coming up, until then without my knowledge, and unblock them.

About the image: Grand Central Station NYC