Jiri Knesl - Should we use an existing agile methodology or create our own?


####Should we use an existing agile methodology or create our own?

Picking a programming language, platform, and framework are key things that largely influence your development efforts. And for frameworks you have an important question: do you use an existing one or make your own?

When you use an existing framework you feel in control of the source code. Is this right? Sure, of course.

When using an existing framework do you have control? Many answer no but that’s silly. You can make changes to the source code (but face the bitter price of possibly losing the ability to upgrade the framework)

The next advantage of an existing framework is that it is already used. Those tons of bugs were already found and fixed. Sometimes though this comes at a price - higher complexity or lower performance.

All those things are valid for management methodologies as well. You can use yours or others. You have control. You can change it. With an existing methodology you don’t have to fix those bugs (yes, methodologies have bugs too).

The problem is when you pick a bad framework (bad methodology). Or when you develop your framework made to measure of your business and the market, technologies or people change. In this case using the same framework (same methodology) is like having a ball and chain. Your own chain and your own ball. Still you stick to something that doesn’t deserve it.

It is more difficult to succeed with your framework (your methodology) than you expect. I have studied frameworks for the last 8 years. Still never tried to write one. I have studied agile methodologies for as many years too. I made methodologies for my clients. I did lots of mistakes. Now I am aware what’s necessary. Still I don’t believe there’s any Holy Grail, best framework, best methodology for all the people and forever. You still have to react.

But there are best practices:

To have successful framework you need:

  • Very good common stuff - a framework is abstraction of a programming approach. You need experience to be able to abstract. In my opinion frameworks can be developed only by people with lots of hands-on experience. If you are a junior developer it’s better to practice writing applications or libraries.
  • Great documentation - a framework’s vital part is great documentation. If you’re not able to write and maintain documentation you lost. Open Source framework is without chance. An in-company framework without documentation will lead to high expenses to teach new colleagues.
  • Have a good programming style - even if you develop software for a very, very, long time you don’t have to be one of those who writes beautiful source code. When you have a bad style nobody will like using and changing your source code. Most developers read code more than write it. Even when you are an ingenious mathematician and developer, still nobody will use it.
  • Have endurance - it’s a marathon to develop a framework. Maybe you don’t realize how difficult it is. All those problems and special cases to catch before you’ll be able to solve the problem. It’ll be months to something useful and stable.
  • To be a great programmer - it takes experience, a good programming style and many other things which will make you a great developer. All people in a company rely on a framework. If you make a security bug in a framework then all framework users have that security bug, think about it.

It’s a similar story for methodologies:

  • You must know what works over time - a framework must survive longer then paradigms in fashion last two months methodology must survive too.
  • You must know how to describe it - all principles you put into the methodology must be described and bond to real situations. All the people in the team must know what to do and how to solve different situations.
  • People have to enjoy the methodology - people have to connect to the values and principles. There should be advocates of the methodology who will fight for it, think about it and improve it to an organization’s need. It’s not simple.
  • The methodology must persist even if it’s changed all the time - in our age we are facing constant change. You must run to stay on one place. But when you change the methodology basic principles should be vital after years and should help the company to prosper.
  • You must know how to make managerial methodologies - it’s the same as programming. It’s not simpler than making any other system. How many years you develop software and improve in SW development? And how many years you make methodologies and improve in understanding of organization of people and work? It is the same but instead of algorithms, data structures, security, testing you have culture, microeconomics, operation management, HR, strategy, R&D and so on.

You can be lucky and create a great company with a strong culture, the right people and you won’t have to try to build or use any special methodology. Even all those successful methodologies were created somewhere, right? But I believe it’s improbable.

If you don’t have those skills use an existing framework (methodology).

Or find someone who knows how to develop successful frameworks (methodologies).

Or spend years and learn how to write frameworks (create methodologies) on your own.

Did you enjoy this post?

You can listen to more from Jiri this September at SwanseaCon.

How to use Theory of Constraints to scale big agile development teams?

Subscribe via RSS


Our conference is dedicated to providing a harassment-free conference experience for everyone, regardless of gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, or religion (or lack thereof). We do not tolerate harassment of conference participants in any form. Sexual language and imagery is not appropriate for any conference venue, including talks, workshops, parties, Twitter and other online media. Conference participants violating these rules may be sanctioned or expelled from the conference without a refund at the discretion of the conference organisers.

This "Don't be a jerk" policy is a shortened, more casual version of the longer Code of Conduct policy. Read full version.