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.