Agile methodologies - a single programmer

Question

I have heard a lot about agile methodologies and I really liked the idea. Of course, from what I saw, the client needs to cooperate, but it seems to me that for own projects (that is, whose idea is mine and not of a client) these methodologies can help a lot.

My question, really, is whether these ideas all apply to programmers who work alone. The idea of agility, the first time I saw it, seemed to be basically the idea of breaking the process of developing software in several iterations, each composed of analysis, design and programming.

Researching further, however, everything I found relates to teams. I found several ways to use agile methodologies, such as Scrum, etc. But everything I read on the subject talked about teams, division of tasks, etc.

My question is: is there a way to use agile methodologies working alone? If so, where can I see more about it?

Answer 1

Solo Scrum is interesting and, as the @Caputo response, was used by some people successfully.

But keep in mind that it won’t be a "pure" Scrum, since the original focus is on Team and various benefits of the methodology will be lost, as in the Daily Meeting, where each can expose the impediments and get guidance from others.

Also, estimating alone in the agile model is a problem. You will not have how to do the Planning Poker or some other method in which there is confrontation between the vision of various developers.

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

As for controlling activities, in my opinion, the most efficient method in an agile context is a Kanban framework:

So you can set your tasks or even User Stories (user stories) and have a good visual idea of the progress of your personal projects.

Answer 2

The short answer to the question is Yes! I have a habit of picking up some freelance projects and what I do is use Scrumboard to control what I should do and Burndown to keep up with my expected productivity.

In this link he speaks of an adapted Scrum and calls Soloscrum.

This another link brings, in English, a way to use Raw for goals in general ( what fits into what you want)

Editing

When I’m working alone I follow the following steps:

Definition of Product Backlog

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

Definition of Sprint Backlog

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

Daily

I take the Postit of what I want to do and move to In implementation. When I finish I move to On test which I do not always follow

Past the test I move to Done

at the end of the day I upgrade my Burndown from the / sprint project and see if it is within the plan or if I will have q make a greater effort on weekends or earn some nights off.

Answer 3

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

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

7º) Working software is the primary measure of progress.

Working alone can be easier to engage in waste (as "good ideas" that we have along the way or the preference to work on a requirement to be more challenging and not to be a priority) than working on a team, where pressure comes from all sides.

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

As to estimates, working alone you don’t need them. Don’t waste time. If no one has asked for estimates, make estimates is a wastage; especially if they are short-term ("how many requirements I will finish this week"). Maintain only your medium- and long-term estimates: "what is the minimum 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 is easy to enjoy it in various scenarios, even working alone.

Answer 4

I think that Lean is currently the most effective methodology and can apply "alone", that is, if you are the only one involved directly 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 it only works when everyone involved understands the process, and you have the resources to deal with the customer’s need in a way that doesn’t compromise you.

Lean well applied is absolute success in business, but the application difficulty is very great, and it is very difficult to convince a client to follow such a methodology, given that business is as transparent as possible. That’s right! There are clients who prefer the basics and are not open to other processes. If you want to know more about Lean see here http://www.lean.org.br/

Answer 5

Yes man, quietly.

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

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

Answer 6

According to Scrum’s guide to Scrum.org:

The best size is that small enough to remain agile and large enough to complete a significant job within a sprint.

Teams with less than three developers have reduced interaction and lower productivity gains. Smaller development teams can encounter technical barriers during a sprint, making them unable to deliver an acceptable size.

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 isn’t recommended by Scrum.org

Source: http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100

Answer 7

Dear Leonardo, the SCRUM is 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 regarding the ability to collaborate and communicate.

In the case of a single developer it makes no sense to adopt SCRUM as a team-driven 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-Tories, the prioritization of the backlog according to the importance of the requirements, the definition of a delivery rate of these requirements (every 1, 2, 3 weeks...).

In the end, you’ll end up creating your own work methodology inspired by SCRUM. There must be some similar ideas on the Internet. I suggest you research something along these lines, but without getting lost in purely theoretical ramblings.