Recently the word “Agile” has become very popular, and, as it happens to all popular terms, passing through the lines of people like in the Chinese whispers game, it becomes something significantly different from the original. This game’s result is scary – the rejection of methodology by developers, clients. And sometimes the result is a complete fail of agile projects, not because of agile methodology, but because their methodology has never been agile anyway.

I was lucky to have an internship in PAWM. This team is practising the Agile in the way that corresponds to the Manifesto, i.e. the way that doesn’t deform the initial meaning and purposes of Agile. The team was international: with one part of the team in Singapore and another in Montpellier Agile happened to be a natural solution to deal with the great distance between us and the time lag. Btw, I learned the term “Agile” only in the end of my story there, when I started to write a report about my activities, and my tutors suggested to mention “agile” as a team-management approach. During 5 months of my internship I never heard the word “agile” from anyone of the team, but I noticed how effectively they worked and communicated, and thought what a luck is to work in such a well organized team.

Trendy Agile

Since I left PAWM I talked to my friends and colleagues from all over the world about their “agile” experiences. I was very surprised to see that Agile as I knew it in PAWM, is interpreted in a different way in other companies, and moreover, almost all developers and engineers to whom I talked about it, consider “Agile” at best – useless, at worst – awful.

Why it happened? I’ve interviewed some friends about their perception of “Agile” and reasons they rejected it. The more people I interviewed, the clearer view I got. To make sure, that I’m on the right way, I’ve turned to those who “gave life” to Agile:  Martin Fowler, Dave Thomas and Neil Ford.

So first of all let’s see what they defined as the two main features that differ Agile from traditional planning methodology.

AGILE vs PLAN-DRIVEN

Surprisingly, project managers, while implementing Agile, often go against these two features: they impose the process on people (so there is no more “people-first” rule) and then set up the plan of meetings – every day, every week, every month and of course they don’t forget to mention “Agile” at every one of them.

And, simply put, that doesn’t go well.

It seems that the only reason the project-managers decide to implement Agile at all is because it’s trendy. And often the implementing stops here – on a wrong terminology:

Because everybody knows of cause, we become incredibly rich by coining the terminology… I wish, –

Martin Fowler

It’s a common case with fashionable technologies and methodologies, when people without good understanding why it should work, pay a lot of attention on how it should work. It’s not surprising that a lot of people rejected the Agile approach: without understanding its benefits they were not able to appreciate it.

A lot of planning?

Because of free (and so far wrong) interpretation of Agile principles by managers, developers face the new problem – working without a plan and documentation at all.

But Agile doesn’t suppress Plan or Documentation, it just doesn’t make them primary. Plan still stays very important, but it becomes adaptive, non rigid. It seems to me, that Agile imposes doing even more planning, but in the process, and not instantly like it was in traditional methodologies, because embracing the changes means updating the plan all along the development cycle.

The plan is a constantly evolving way
of figuring out what change means, –

Martin Fowler

People – first

By contrast, because people become primary, they adapt the plan to their needs and circumstances, and it’s up to the team to decide which process will work for them.

Many developers don’t admit to be resources or slaves anymore, they asked not only for money but for acknowledgement of their work, and recognition of their contribution to the projects.

Commercials aren’t everything, however. A good metaphor I stole is that revenue is like oxygen – you need it in order to live but it isn’t what you live for, –

Martin Fowler

Agile engineering responds to the needs of people, simply putting the human in the core of software development. It’s well-known that even excellent specialist will perform badly if he adopts the bad process. Professionals can and should decide what they do really well and how they will do it, and this brings the teams of great specialists to achieving the most challenging goals.

How to use it?

Some developers told me that Agile had nothing to do with them. Agile, they said, is for a project management, and Scrum – for a software development. But Scrum is just a method among many others, and as Dave Thomas said:

No rules are Universal

All rules need Context

It’s up to all the team-members to choose or create the method, that fits their needs. The only algorithm that will work for everyone is one that keeps the common sense of all the processes:

  • Find out where you are
  • Take a small step towards your goal
  • Adjust your understanding based on what you learned
  • Repeat

That works for project-management as well as for software development, and for any other industry.

Communication is important

Rather than impose the process, manager should propose the effective ways of communication for all team-members. It doesn’t mean to set up the planning of meetings, but to propose the tools and methods that enable to be in touch all along the development cycle. It’s a common case when the front-end and back-end developers meet only when front-end developers have problems to built their services on the top of back-end: resolutions may be not rapid and easy, cause the problems are discovered late enough. They could be avoided if both parts constantly communicated from the beginning. The front-end should care about the back-end and vice versa, and it’s not easy without establishing the good practices inside the team and adopting some useful tools like Pivotal Tracker.

Neil Ford gave a good example about it. Almost in every country there is a law that forbids talking on a cell phone while driving. If you ever tried to break this law, you could notice how distracting it was. But on the other hand there is no law that forbids you talking to the person next to you. Why this type of communication is less distracting? Important reason is while talking on a phone your brain tries to reconstruct missing communication channels, that you have on face to face communication. So giving only the voice on a cell phone, the brain tries to recreate the other parts to have more complete picture. It reflects the importance of interactions between team-members, rather than putting enormous effort on detailed documentation.

‘Individuals and interactions over processes and tools’

Manifesto

Be realistic

I figured out another principle that seems to be right here :

The terminology is secondary,

the common sense is primary.

Keeping it in mind helps to not deviate from initial goals of Agile, hence to avoid “semantic diffusion”, because we call the right things with the appropriate terms, instead of fitting the things to the wrong terms.

It can be a long journey. I liked a lot the approach of my tutor in PAWM who spent considerable time preparing his environment for work, but then delivered the better solutions more quickly, because of the well-organised environment which helped him to avoid multiple hidden obstacles during the development. And on a bigger scale :

The key thing I realize : This is a multi-step approach,
and it’s approach that takes time and investments to reach. And if you are thinking…
I mean, I remember somebody coming in to me saying :
-We gonna take this big enterprise, we gonna turn it all agile
and we gonna do it in six months.

My consulting skills kind of failed me because I just couldn’t stop laughing, –

Martin Fowler

 

 

SHARE viaShare on LinkedInShare on FacebookShare on Google+Tweet about this on TwitterPrint this page