Agile in Everything

2011/07/13

In our experience, to be successful with methods you need to be agile, light and lean in everything you do while working with methods. This means, for example, that how you build your method, adapt it as you learn more and use it while developing real software all need to be agile, lean and light. Even if the method you work with is not agile, for instance it is based on a waterfall approach, you need to be agile in how you improve it over time.

To some extent inspired by the principles behind the agile manifesto, (see http://agilemanifesto.org/principles.html), we have come up with 9 principles we believe are useful in working with methods:

(1)      Active practitioner engagement is a must. Everyone in the team is important and should make valuable contributions to its way of working.

(2)      The best method to start from is the one the team already has. Don’t be revolutionary, be evolutionary – focus on delivery and your customer while improving the way you work.

(3)      Empower the team to change the method to fit their experience and the project context.  The most appropriate method emerges from the team itself.

(4)      Replace one practice at a time and make sure it works before moving on to the next. When you change, you experiment. Make sure your experiments have value, and that you understand the cause and effect.

(5)      Continually inspect and adapt your practices to address the challenges facing the team.

(6)      Make methods as simple as possible, but not simpler. Focusing on the essentials, the things that if not done correctly threaten the success of the project.

(7)      Build trust with your customer, deliver on your promises, and be consistent.

(8)      Better, faster, cheaper, and happier (teams as well as customers) are the primary measure of success.

(9)      Promote continuous and sustainable improvement.

We are sure these principles can be improved, maybe even replaced with better ones.  Please, contribute by suggesting changes.  At some point in time we want to be able to publish something stable for many years to come.

– Ivar Jacobson, Paul McMahon, Ed Seymour, Ian Spence

About these ads

8 Responses to “Agile in Everything”


  1. Focus on practitioners and guidance in terms of starting from where you are, being evolutionary and keeping practices simple is something that will win their hearts and they will gladly embrace it. However, from my experience I feel that the practitioners would struggle to put it into practice. They would need help from their team leader who can coach them in this regard. Semat should come up with some guidelines for the team leaders as well. This will solve another issue with agile which puts a lot of stress on making the teams self-organizing which makes the project managers uncomfortable as they see in it loss of control and power. Helping them to be still needed as a coach would greatly help.

    Another group of people who would be threatened by the Semat emphasis on practitioners is the process engineers & consultants. They could effectively coach the project managers as coaches. There is another area which they can contribute to. The software organizations need help in effectively managing the structural changes to support way of working improvements at organization level. I have explained these details in my blog at http://prkarve.wordpress.com/2011/07/04/practice-excellence-a-systems-view/

  2. skippletcher Says:

    10. Use data to find the pain and measure gain. The ‘next topic’ on the improvement agenda is the current obstacle to team success.


  3. Better and happier are mentioned as primary measures of success.
    How can “better” and “happier” be measured?

  4. Scott Ambler Says:

    Looks interesting. Here’s some thoughts about the individual principles:

    1. It’s not just practitioners, it’s stakeholders too. In Agile Modeling and Disciplined Agile Delivery we promote Active Stakeholder Participation in addition to active practitioners.
    2. Sometimes the best method to start from is the one that the team already has, sometimes it isn’t. Making a fundamentally flawed process a bit more efficient isn’t always the best strategy. Sometimes you need to do a method reset and that’s hard.
    4. Many teams can go faster than adopting one practice at a time. Also, some practices really rely on other ones. Could a team following a waterfall process really adopt a practice such as Agile Modeling’s Architecture Envisioning without adopting other evolutionary arch/design practices? Without continuous integration?
    6, 7. Motherhood and apple pie.
    8. Actually, my surveys time and again have shown that different projects have different success criteria. Very few teams seem to value everything you list. You should rework this wording. In DAD we talk about delivery of a consumable solution being the primary measure of progress. Also, shouldn’t there be one PRIMARY measure, not several as you list?

    You seem to have dropped several of the principles from the Agile Manifesto. That’s OK, but you should consider justifying that decision somewhere. Also, many people feel that there’s things missing from the Manifesto, something that clearly seemed to be true from our 10th Anniversary meeting in February.

    To answer Andrey’s question, yes, you can measure those sorts of things several ways. Happiness can be measured via surveys (might want to measure satisfaction though). Better would need to be defined as per the context, and then measured accordingly (is better focused on code quality, UI quality, …?)

  5. Hanna Oktaba and Miguel Morales Says:

    Dear All,
    To make the principle’s message clearer, we think that we need to:

    a) Define the relationship between method, practice and the way of working. For example: “Method is a set of related practices which define the whole way of working of a software development team”. Could a team have more than one method to develop the same project? If true, are those methods overlapping between them?

    b) Reorder the principles to give them some logical structure (related to method’s values, definition and practices).

    c) The difference between practice and method should be reflected in the principles. Now, if we replace the word practice for method it looks like the same?

    d) Eliminate the principle (9), redundant with (3) and (5), or clarify it.

    e) Define the principle’s sentences in a more uniform way.

    Our proposal for reorder the principles and some addings(in CAPITALS) is:

    Principles related to method’s and team’s values
    (8) Better SOFTWARE, faster DELIVERY, cheaper FOR CUSTOMER, and happier teams as well as customers, are the primary measures of PROJECT success.
    (7) Build trust with your customer, deliver on your promises, and be consistent.
    (1) Active practitioner engagement is a must. Everyone in the team is important and should make valuable contributions to its way of working.

    Principles related to method’s definition
    (2) The best method to start from is the one the team already has. Don’t be revolutionary, be evolutionary – focus on delivery and your customer while improving the way you work.
    (6) Make methods as simple as possible, but not simpler. FOCUS on the essentials, the things that if not done correctly threaten the success of the project.
    (3) Empower (WHO?) the team to change the method to fit their experience and the project context. The most appropriate method emerges from the team itself.

    Principles related to method’s practice
    (4) Replace one practice at a time and make sure it works before moving on to the next. When you change, you experiment. Make sure your experiments have value, and that you understand the cause and effect.
    (5) Continually inspect and adapt your practices to address the challenges facing the team.


    • Re: “agile in everything”… I understand the intent of this post, that the kernel and results of SEMAT should be flexible and applicable in multiple ways. But I urge caution on one point though…

      The end result of SEMAT (universals, language, kernel) need not itself be agile. In fact, the goal is to find a theory of software engineering that is CORRECT so it does not need to be changed constantly. We do not want our theory to be agile. We need to be careful about jumping on the bandwagon of agility just because it is the current flavor-of-the-month in software engineering. Our kernel needs to be able to define the next fad, which may not be agile.


      • Agile in everything means here ‘agile in working with methods’ and we have formulated some principles which will guide us. These principles are intended to be long-lasting and not the ‘flavor-of-the-month’.
        Regarding theory, I am sure we can find principles for how to be ‘agile in working with theories’. Much of the work on theories are unnecessarily clumsy and repulsive, leading to that most practitioners don’t even want to touch it.
        Most people working in Semat are strong supporters of agile principles, but not necessarily supporters of popular techniques and all the fashion and fads associated with such techniques.


  6. Taking measurable action is apart of process improvement.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 50 other followers

%d bloggers like this: