Agile methodologies - one programmer
I've heard a lot about Agile methodologies and I really liked the idea. Of course, from what I have seen, 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, in reality, 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 a software in several iterations each composed of analysis, design and programming.
Searching further though, everything I found relates to teams. I found several ways to use Agile methodologies, such as Scrum, etc. But everything I read about it talked about teams, splitting tasks, etc.
My question is: Is there a way to use Agile methodologies working alone? If so, where can I see more about it?
7 answers
The Solo Scrum is interesting and, according to @Caputo's answer, has been used by some people successfully.
But keep in mind that it will not be a "pure" Scrum, since the focus originates is on time and several benefits of the methodology will be lost, as in daily meeting, where each one can expose the impediments and get guidance from the others.
Also, estimating alone in the agile model is a problem. You will not have how to do Planning Poker or some other method in which there is confrontation between the vision of several developers.
On the other hand, make good use of the time boxes to get a continuous delivery of an executable, avoid procrastination and not get lost in time.
When it comes to controlling activities, in my opinion, the most efficient method in an agile context is a Kanban board:
Then you can set your tasks or even User stories user) and have a good visual idea of the progress of your personal projects.
The short answer to the question is Yes! I have a habit of picking up some freela 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 it SoloScrum.
Is other link it brings, in Portuguese, a way to use scrum for goals in general ( which fits what you wish)
Edition
When I am working alone I follow the following steps:
Product Backlog definition
Note In The Post-its and lap in the first division of my frame in front of the PC, evaluate and give a weight of 1 to 5 for each
Sprint Backlog definition
I take the Post-its that I intend to do in the week and put in the second part, knowing what my average weekly productivity is
Daily
I take the PostIt of which I want to do and move to in implementation . When I finish I move to in Test which I don't always do in sequence
Passed the Test move to done
At the end of the day I update my BurnDown of the project / sprint and see if it is within the planned or if I will have to Q make a greater effort on the weekends or win a few nights off.
In a solo project, the largest contributions you can get from Agile are the tenth and seventh principle of the manifest (in this same order):
10th) simplicity, the art of maximizing the amount of work does not done, it is essential.
7º) running Software is the primary measure of progress.
Working alone can be easier to engage in waste (the "good ideas" we have during the journey or the preference for working on a requirement because it is more challenging and not because it is priority) than working in a team, where pressure comes from all sides.
Other than that, the values and most principles of the Agile Manifesto deal with software projects involving client and team, so methodologies for Agile projects are also geared towards 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 ), progress tracking (Working software), Simple Design, TDD ...
As for estimates, working alone you don't need them. Don't waste time. If no one asked for estimates, making estimates is a waste ; especially if they are short-term ( " How many requirements do I 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.
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 supports 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 that you have the resources to be able to deal with the customer's need in a way that does not compromise you.
Well-applied Lean is absolute success in business, plus the difficulty of application is very great, and it is very difficult to convince a client to follow such a methodology, considering that business is as transparent as possible. That's right! There is a customer who prefers the basics and is not open to other processes. If you want to know more about Lean see here http://www.lean.org.br /
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 the Scrum Guide of Scrum.org:
The best size is one small enough to remain agile and large enough to complete significant work within a sprint.
Teams with fewer than three developers have reduced interaction and have lower productivity gains. Smaller development teams may encounter technical barriers during a sprint, rendering them unable to perform an acceptable size delivery.
Ter 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
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 in terms of collaboration and communication capacity.
In the case of a single developer it makes no 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 the requirements in the form of user-stories, the prioritization of the backlog according to the importance of the requirements, the definition of a delivery pace of these requirements (every 1, 2, 3 weeks...).
At the end, you'll end up creating your own SCRUM-inspired work methodology. There must be some similar ideas on the Internet. I suggest you research something in this line, but without getting lost in purely theoretical ramblings.