This post is not about Agile.

It is about getting things done.

And it is about a process that serves business objectives.

That’s just a few words, but they imply so much.

• Setting S.M.A.R.T objectives
• Implementing and executing a plan to reach the objectives
• Tracking progress
• Getting a team to communicate (in words that everyone can understand)

It’s trendy to talk about Agile. But it’s not so trendy to use it correctly, for a fitting purpose.

And it’s also trendy, as a reaction, to say that Agile sucks.

Choosing the right methodology

Call it a cookbook, a process, a methodology, it all comes back to the same:

• Plan steps
• Execute steps
• Assess results
• Rehearse

Any methodology in the world, may it be Waterfall, Agile, one of its many declinations, or whatever else, will at some point get down to that.

I don’t believe any methodology which has been written and acclaimed by the crowd, or not, is perfect. All of them have flaws.

It is up to you to find the one that suits best your objectives, and work out the flaws so that they’re not blocking anything.

Understand your context

What’s essential is your context. What is it that you are building? For who? What’s your team like?

Maybe you need Waterfall, because it’s great for some industries.

Maybe you need Scrum because it’s great for some software developments.

Maybe you need Extreme Programming.

Maybe you need something else.

SaaS start-up company: my recommendation

My opinion, based upon my experiences (successes and failures included), is that Scrum brings the best solution, so far, to a SaaS start-up context:

• Online products (sold as a service), implying:
  • Revenue objectives, and urge
  • Date milestones set by your revenue objectives, the market and our competitors
• Team composed of technical and non technical persons, implying the need for appropriate communication
  • Implementation/technically-abstract way of describing features
  • Metrics that will enable to raise alerts asap, in order to find solutions asap

The great thing about this methodology is that it encourages the top-down design approach, and a lean management of the roadmap.

You start with describing the user and his problems you are trying to solve, then get down to what solutions you could bring, design the solution you prefer and finally leverage you technology assets. At any step, you get the opportunity of asking yourself:

• Is that really going to solve the problem?
• Is that feature directly solving the problem, or just bringing more comfort?
• Am I not over-engineering the thing?

And then decide to keep/drop.

The methodology you have chosen is the wrong one anyway

If you believe you can just run by the book as soon as you have chosen a methodology that looks like it fits your context, you’re wrong.

Methodologies can never cope with humans. At least not all of them. We all have different cultures, educations, characters, and it’s virtually impossible to make everybody agree on a universal answer.

Except on 42, of course.

Semantics

That’s the first issue with methodologies, whichever they are. They use words.

A word can mean something for someone, and something else for someone else.

The first thing you need to do, is to give them your meaning. The one that all of your team will understand and play with. And then you can still decide that Scrum should be named Apple, Sprints should be bananas, etc.

Don’t hesitate to write down an internal dictionary that you’ll share with your team.

Commitment

Wow. Scary word. No one wants to “commit”. What does that mean? That I’ll burn in hell if I don’t deliver?

I guess not. To me, that means “team work to get things done”. You need team work to get a methodology to work. You need team work to get a feature out. And potentially to find alternate solutions, or compromises.

And if you fail, the only thing you’ll be down to is team work to understand why. And team work not to fail again for the same reasons.

Tools

I love Jira. I really do. I should buy Atlassian stock options. At least as long as I’m working in a context where Scrum is the most suited methodology. And I will sell it the minute I quit that context.

Tools are here to support a methodology. They are not a methodology on their own. When you go buy your food, you can use you shoes to walk to the nearest supermarket, or your computer to order online. But you’ll still have to 1) ask yourself what you need/what you miss 2) select the products 3) check out.

Jira has built-in features that just make it easier to play with Scrum. Backlog management, versioning, boards, metrics, workflows. Of course, it does enable serendipity. You’re not a Scrum professional? Take a minute to browse the tool and get a better understanding of how good you are at using Scrum. But don’t try to learn the basics from it, you’re bound to fail.

Metrics

Ah, the burndown chart. Velocity. Complexity points! What a pile of junk! That is: if you didn’t accept and understand the methodology and the tools.

Yes, they come at the end of the food chain, and they are the hardest to digest. But using them properly enables you to assess what you’ve been doing, and understand where you need to put your efforts. May it be on developing features, or adapting the process itself.

There is no such thing as poor metrics. There’s only metrics you don’t understand, or metrics that don’t serve your objectives. Those defined in a methodology are here to help, so your best option is to try to understand how to use them.

Meetings!

Wait, no. They’re called ritual, or ceremonies, in Agile. Meetings suck. Everybody hates it. French people are acclaimed as the best in world at organizing useless meetings with a huge crowd of people who don’t even have a stake in what should be discussed.

And yes, Agile recommends regular meetings. But they have an objective in common, and each of them has an specific objective.

The common objective: have the right discussion at the right moment. That means you should be able to streamline your Top-down approach:

• No discussions about the development when we’re talking about the specs
• No discussions about the specs when we are developing
• Keep all of the complaints for the retrospective
• Make sure everyday that if you have a problem you can’t sort out on your own, the people who can help you are informed

Backlog refinement: That’s the moment when you talk only about the functional specifications, mockups, and in a general manner: solutions to the user’s problem. That’s where you challenge all of the ideas which have been written down before the meeting. That’s where everybody in the team understands the objectives that are set for the specific feature, and what it should look like.

Sprint Planning: Time to talk implementation. Now you can take those stories apart and discuss how it will technically work.

Daily stand-up: Any problems? Need any help? Now is when you ask. And the person who can help you will give you attention right after it. Which is the reason why it should happen at the beginning of the day, so that the person actually helps you instead of running for lunch.

Demo & Retrospective: Assessment time! How did we perform? What did we do wrong? It’s always good to hear that we’re happy, but now is the time to tell that we’re not, and to be constructive about it. The point is to find solutions.

Now you can tell me: “Such a waste of time! When is it that we actually develop?”. Let me calculate. The standard time for 2-weeks long sprints will be 2h + 2h + 10x5mn +2h = 6.8 hours. Less than a day every two weeks to get everybody in the loop, agree on everything, share the knowledge, resolve daily problems, assess the job done and feedback on how they’ve lived that previous sprint. At least now you can measure that time, and even make it shorter. Whereas with no discipline/methodology, it’s easy to waste several hours a day in endless discussions.

About the Agile Manifesto

I never read it. And I don’t think I will. I heard it’s obsolete as it was written in 2001. I guess it is. But what I know is that Agile is what you make of it. As long as you stick to some basic principles.

What I know is that if you fail with Agile, providing it’s suited for your context, the failure is in you, not in the methodology. You actually failed in understanding and owning a paradigm.

Now if you heard of a new paradigm that works better for my context, I’d be happy to hear 😉

Featured image by Lynne Cazaly