Being Agile in a Non Agile Environment (Part 1)

Introduction

I was recently asked to manage a project in autonomy, in a view to develop a software component. The deadline was extremely short in relation to the expected features. In order to manage the project correctly, I needed a method that would help me to stay focus on the project objectives, and that would be adaptable to the situation. In a view to meet such requirements, I could have used methods like XP or Scrum. But, they are rather intended for project management with a team, not for a lonely developer.

I had already used a method of my own that met such requirements. It was a method that incorporated some best practices from XP, Scrum, and Kanban. So, I decided to use this method and to enhance it not only to make it as agile as possible but also to improve my own performance.

In these series of posts, I describe the method I have used to manage a project in autonomy. In this post, I will stay focus on the principles and previous work, while I will ask myself about the agileness of this method. In the next posts, I will spent time to present how I organize the project and how it evolves through the use of tools like spreadsheets. Then, I will detail the development phase.

Motivation and Principles

I have developed such a method, because I have noticed some difficulties when I have to achieve a significant project. The major difficulty was to have a better focus on the objectives. Sometimes, I’m starting a project with a high productivity. But, all along the development, I should test different implementations in order to provide the best solution. By doing this, I lost little by little the main thread of the project. And at the end, I’m working on a different project without realizing.

Another difficulty I have experienced was the lack of communication especially with the managers. If you do not communicate or if you do not provide the good information, and even if you do not point out the difficulties, you are going to develop an application that is not what is expected. You are like a fly without a head! Some questions about decision to take in term of implementation are best answered by other developers. Other questions need an advice of a business analyst. And some management difficulties need decision of the managers in order to point out the priorities.

By working on a long and urgent project, it is difficult, even impossible, to get an accurate planning from the start. In such a case, the planning should enumerate the main tasks, but it has to be relatively vague. The planning may change all along the project: tasks may appear or disappear, others may be shorten or last a longer time. Thus, to provide an accurate planning, it is the same thing as to invest in risky assets. In the same time, you have to respect the imposed deadline. So, if your project is defined in term of tasks, in order to control your tasks and thus to control your time, you need flexibility in your planning.

For a better method, it is interesting to have feedbacks of the work you have done. One idea is to use the communication. Another idea is to collect data of your abilities and limits during the project. This will help you to make assumptions about your abilities for the rest of the project and improve your performance. Furthermore, these collected data enhance the communication with the rest of the team.

From these preceding points, we can infer that it is interesting to increase the perception of your project. In the one hand, you know what you have done, on the hand, you know where you are going to. By doing this, you will not lose the focus on the objectives and you will be kept aware to every opportunities and/or difficulties that appears all along the project.

There is a last point. Things getting better if you’re motivated. As Confucius said:

Choose a job you love, and you will never have to work a day in your life.

— Confucius

A good way to get motivated is to see your project rather like a game than like a pain. And the best to see this, it is to turn your project management so it looks like a game. Thus, if the programming seems boring for you, you can make things funnier with such a project management.

Is a method based on these principles an agile method?

So, you are alone and you are the team. You have to self-organize yourself. But, with the principles I have enumerated above, can you claim that you are Agile? These principles favour the interaction with the people in your environment (your local customer),  because you are supposed to communicate. You are helped to be motivated by your work, because you perceive it like a game, and the feedbacks help to enhance your performance. Moreover, the flexibility principle and the fact that you have an enlarge perception provide you a fast response to change. Moreover, the fact that you are focused on the objectives helps you to deliver a working software.

In fact, there is a missing Agile principle for me: deliver a working software and  deliver it frequently. According this principle, your planning should be created so you deliver frequently a usable software, component, or framework. This is especially important in order to test the integration of your project in the rest of your development or those of your customer as often as possible (that is why we speak about continuous integration). This is also important if another team is waiting your implementation. If things are well done, you can already deliver a bundle version, before you deliver a fully functional version.

Can you soon be agile in a non agile environment?

The method I want to present is not the only one. There are already others.

There is the Personal Software Process (PSP) of the Software Engineering Institute (SEI). This institute is best known for CMMI. PSP provides to the developer methods to drive his project to success. But PSP is not considered as an Agile method. Furthermore, it is complicated, full of documentations. In response to this, Y. Dzhurov et al. have written a paper called Personal Extreme Programming – An Agile Process for Autonomous Developers. This method, also called PXP, is a kind of refinement of the XP method adapted to one-person team. It is combined with the Personal Software Process (PSP). It has been proven that this method is more efficient than an ad hoc method. A test has been made on the basis of Visual Studio.

You can find over Internet a site describing the method Personal Kanban. It is a good method based on the Kanban method that helps to visualize your project. It is not dedicated to IT processes but more generally for personal productivity. This is a good base to start. But for me, it lacks some statistics about your own performances during the project and other feedbacks, because Kanban provides only a snapshot of your work in progress (WIP). Other methods in this case exist like Pomodoro or Getting Things Done (GTD). They are not considered as agile methods, but they help you to improve your productivity.

Conclusion of the Part 1

In this post, we have seen principles that can be helpful for a developer in order to manage a project in autonomy:

• stay focus on the objectives,
• communicate with the team,
• have flexibility during the project,
• collect feedbacks on your abilities,
• increase the perception of your project,
• be motivated by your work, perceive the project as a game,
• deliver frequently.

We have seen that this principles helps to make you an Agile developer. In the next posts, we will see a way to organize your project according to these principles.

Advertisement

Chuck Norris Doesn’t Need to Be Agile

The first reference of Chuck Norris in the Agile world has appeared in a post of Markus Gärtner named Scrum Norris. It was in February 2010. The post presents a list of humoristic facts about Chuck Norris, in the same way as the site Chuck Norris Facts. After the XP2010 conference, during June 2010, it gains a popularity over Twitter (twitter:#scrumnorris).

Recently, I have even found a reference to Chuck Norris in a presentation about TDD by John Ferguson Smart: Real Developers Don’t Need Unit Tests.

Here are some of my favourite facts:

• When Chuck Norris says “done”, then it’s “done”.
• Chuck Norris always wins at Planning Poker.
• Chuck Norris doesn’t technical documentation. He just stares down the code until it tells him everything he wants to know.

Here is mine:

Chuck Norris doesn’t need to be agile. The customer is always satisfied with what Chuck Norris delivers.

At last, you will find another version but applied to Jeff Sutherland (…among others): Jeff Sutherland Facts.

Who is Chuck Norris in fact?

Who Chuck Norris might represents? Is there a kind of developer or of manager that might meet this facts? I am sure you have met him, at least once, in the real life. I am sure you have still met such a developer saying that he does not need to test what he has delivered:

Chuck Norris writes the code first, never the test (He doesn’t need to test at all).

You have seen another one manipulating production code.

Chuck Norris does not deploy, he develops on the production environment.

On the other hand, you may have worked in an environment where you have to be right at the first iteration.

Chuck Norris doesn’t do iterative development. It’s right the first time, forever.

In reality, Chuck Norris may have different faces. He may represents all that guys, sort of veteran of IT architecture or other sceptical gurus. He is convinced to know everything. For them, every new knowledges are just hypes. He is one of your developer or, in the worst case, he is your leader.

Chuck Norris may also represent young developers thinking there is nothing more than what they have learned at University.

Maybe, he is you (or he was you)!

So what to do?

If Chuck Norris is you, the solution is simple: be open minded. Look at new practices, read articles, try the technologies before criticise them, do not be biased. If Chuck Norris is not you but someone else in your team, I think nothing worth a good friendly chat. And as any good Agile evangelist may recommend:

Pairing sometimes works. (J.F. Smart)

Link

• Seth Eliot, Is Chuck Norris on your software engineering team?

Markus Gärtner

Defeat the splash

There is an expression in French to say that a project has fallen through. This expression is tomber à l’eau. It means word for word: to fall in the water. And when it falls in the water, you heard splash! (or plouf! in French).

In the webcast Vaincre le Plouf, Guillaume Duquesay speaks about the splash. The splash is used as a reification, a metaphor, to name the series of (in)actions that drive a project to failure. It is necessary to recognize it and to fight it, because it can be really harmful for the success of your project. The splash may attack the project of a team in a company as it may attack  your personal project. So what can we do?

I put the webcast link (in French, sorry) below. You will learn to recognize it, to recognize its call, to know where it leaves, and at end you will know how to defeat it efficiently.

Link:

• Vaincre le Plouf