Agile methodologies - a single programmer

Solo Scrum is interesting and, according to @Caputo's response, it was used by some people successfully.

But keep in mind that it will not be a "pure" Scrum, as the focus is on Time and various benefits of the methodology will be lost, such as daily meeting , where each one can expose the impediments and obtain orientation of the others.

Furthermore, estimating alone in the agile model is a problem. You will not be able to do Planning Poker or some other method where there is confrontation between the views of various developers.

On the other hand, make good use of time boxes to get a continuous delivery of an executable, avoid procrastination and not get lost in time.

As far as activity control is concerned, in my opinion, the most efficient method in an agile context is a Kanban framework:

So you can define your tasks or even User stories and have a good visual idea of the progress of your personal projects.

The short answer to the question is Yes! I get in the habit of picking up some Freelancer projects and what I do is to use ScrumBoard to control what I have to do and BurnDown to keep up with mine productivity as expected.

In this link it speaks of a Scrum adapted and calls SoloScrum .

This another link

Editing

When I'm working alone I follow these steps:

Product BackLog Definition

I write in the Post-its and lap in the first division of my picture in front of the PC, I evaluate and give a weight of 1 to 5 for each

Sprint BackLog Definition

I get the Post-its that I intend to do in the week and put it in the second part, knowing what my average weekly productivity is

Daily

I get the PostIt from what I want to do and move to Under implementation . When I finish moving to In Test I do not always do in sequence

Passed the test moved to Done

At the end of the day I update my BurnDown project / sprint and see if it is planned or if I have to make a bigger effort on the weekends or win a few nights off.

In a solo project, the biggest contributions you can get from Agile are the tenth and seventh principles of the Manifesto (in the same order) :

  

10º) Simplicity, the art of maximizing the amount of work not   done, is essential.

     

7) Software running is the primary measure of progress.

Working alone may be easier to get involved in waste (the "good ideas" ) that we have during the course or the preference to work on a requirement for being more challenging and not to be a priority) than working on a team, where pressure comes from all sides.

Apart from this, the values and most of the principles of the Agile Manifesto deal with software projects that involve both client and team, so the methodologies for Agile projects are also focused on projects involving client and team. So you will not benefit from an Agile methodology like Extreme Programming or Scrum, but you will benefit from some practices of these methodologies: prioritized requirements list ( backlog ), software ), Simple Design , TDD ...

As for estimates, working alone you do not need them . Do not waste time. If no one asked for estimates, making estimates is a waste ; especially if they are short-term ("how many requirements I'll end this week"). Maintain only your medium- and long-term estimates: "what is the least viable version of my product and when I finish it."

My general recommendation is to learn the Agile culture and the practices and techniques that support it, so it's easy to take advantage of it in a variety of settings, even when working alone.

I think Lean is currently the most effective methodology and can be applied "alone", that is, if you are the only one directly involved with the client ...

In these cases can be applied with "success", because I am using this methodology to serve a company that after almost a year, begins to demonstrate satisfaction for the service.

More generally you are never alone and this only works when everyone involved understands the process, and you have the resources to be able to handle the customer's need in a way that does not compromise you.

The well-implemented Lean is an absolute success in business, plus the difficulty of applying is very large, and it is very difficult to convince a customer to follow such a methodology, given that business is as transparent as possible. That's right! You have a customer who prefers the basics and is not open to other processes. If you want to know more about Lean, see link

Yes man, quietly.

Create tasks, describe them, estimate them, prioritize them, and finally work with small iterations, so you can get a sense of the evolution of your work.

If you want to know more about it, take a look at Scrum Guide

According to Scrum.org's Scrum guide:

The best size is that small enough to stay agile and large enough to complete meaningful work within a sprint.

Teams with fewer than three developers have reduced interaction and have lower productivity gains. Minor development teams may encounter technical barriers during a sprint, making them unable to deliver acceptable-sized delivery.

Having more than nine members requires a lot of coordination. Large teams generate a lot of complexity to manage an empirical process.

The fact is, having a programmer just is not recommended by Scrum.org

Source: link

Dear Leonardo, the SCRUM will be more beneficial if used by teams of 3 to 9 participants.

This detail is important because in other configurations, smaller or larger, there are losses in the capacity of collaboration and communication.

In the case of a single developer it does not make sense to adopt SCRUM because it is a team oriented practice, imagine a single person accumulating the roles of Scrum master, Product owner and Development Team.

Now, nothing prevents you from adopting some good practices that are common SCRUM, for example, the organization of requirements in the form of user-stories, prioritization of the backlog according to the importance of the requirements, the definition of a delivery rhythm of these requirements (every 1, 2, 3 weeks ...).

In the end, you will eventually create a self-employed methodology inspired by SCRUM. There must be some similar ideas on the Internet. I suggest you search for something along these lines, but do not get lost in purely theoretical ramblings.