Agile for the Solo Developer

Question

How would someone implement Agile process concepts as a solo developer? Agile seems useful for getting applications developed at a faster pace, but it also seems very team oriented...

Answer 1

• By doing test-driven development
• By developing in small sprints
• By having a lot of contact with the customer

I remember reading a thesis about Cowboy Development, that is essentially Agile for solo developers. The thesis can be read here: Cowboy: An Agile Programming Methodology For a Solo Programmer (PDF)

Answer 2

Further to the answer from klez (all good suggestions), I'd suggest the following:

• Keeping a product backlog
  A product backlog is basically a list of all items you intend to complete at some stage for this product.
• Maintaining a sprint burndown and a product burndown
  A sprint burndown starts with a list of all tasks you've decided to complete in this sprint (a subset of your product backlog to be completed over a set period of time - e.g. 2 weeks) along with the estimate of the work required. As you mark things off, you mark them as done; thereby reducing (or burning down) the remaining work for that sprint.
  Similarly, a product burndown tracks the remaining work for the whole product backlog
• Adopting the concepts of relative estimation and velocity
  Relative estimation is an estimation technique that uses the other tasks (or stories) as a guide. For example, if you know task A is easier than task B and about as twice as complex as task C, you'd make sure the "points" for task A were correct relative to those expectations.
  The emphasis is not on correctly guessing the amount of work required, but keeping estimates consistent with each other.
  Velocity is a measure of how many "points" you get done in a sprint. If your relative estimation is ensuring consistency, this velocity can be used to estimate which tasks you're likely to get done in the upcoming sprints. Note though that velocity should be constantly revised.

Answer 3

• Limit work in progress (in addition to time-boxing). Even if you use an iterative method (as opposed to Kanban), let's say your velocity is 8 points per iteration. Don't start working on all 8 at once. Limiting WIP by either the number of stories or story points is fine.
• Have automated acceptance tests for all of your user stories. Automate as much as you can in general.
• Err on the side of making user stories too small. As a rule of thumb, make the ratio of biggest to smallest story 3:1. If you underestimate a story in Scrum and it turns out too big, multiple developers can swarm it to get it back on track. But you don't have enough people.
• If, in a regular-sized-team context, you would hesitate whether to split a spike off a user story - in the solo or small-team context, do the spike without hesitation. This helps to keep stories smaller and more predictable.
• Retrospectives are important in agile in general, so Kanban (that would be Personal Kanban) scores extra points here, because its retrospective process is more data-driven. It's hard to play Triple Nickels when you don't have enough people.

These things apply probably to both solo and small-team (2 or 3 developers) situations.

ADDED: sometime after I wrote this answer, I found this conference talk and was very impressed: Personal Kanban: Optimizing the Individual Coder

Answer 4

• Either work to well defined sprints, or deliberately choose a Kanban approach. Don't accidentally end up in Kanban
• Bugs first, features second.
• Still keep a focus on Value vs. feature bloat. (YAGNI over Gold Plating)
• Retrospectives are just as valuable. And just as importantly, make process changes in small chunks. Don't decide that today you're going start to go TDD, Mock and IoC in one shot unless you really have no external features to deliver ATM. Bring one in at a time.

Ultimately, I define Agile really as "doing what makes sense for your team and customer and not adhering to old practices because they happened to look like they worked in the past."

Answer 5

Agile works just as well for individuals as it does for teams. It's about finding a process that works for you, and allowing you to adapt to changing circumstances once your project has already started. It's also about delivering value to your customer regularly, regardless of whether or not the software is actually "finished".

Agile processes are highly iterative. Work is done in short TimeBoxes/sprints/cycles/iterations. Some design work may be required up front, but can be refactored as you learn more about what it is you need a system to do. Unit testing is the backbone of nearly all Agile development methods, giving you an indication of whether your software is working, and if additions/changes to your software will break the existing code base.

If you adhere to BDD/TDD, allow your requirements to change with the wind and can adjust your feature priorities accordingly, if you build your entire system and run all of the tests often, and if you deliver working code at the end of each sprint, you are already Agile.

Answer 6

Recently, I wrote on how a single developer can use agile and other techniques in work and I named it as The solo developers Manifesto, which is available at this Github Repo

I then created Free Currency Exchange API using this manifesto and it took me 2 days to complete, so I would say this manifesto is pretty much practical

Here is the Complete Manifesto:

The Solo Developers Manifesto

This guide will help solo developers achieve what could be achieved by teams by God's mercy

Phases:

Each Phase should be timeboxed

1. Planning:

• Define objectives/ from users' perspective (what user problem it solves, what user wants etc) and not from Devs perspective (Extra features, fancy looking etc), also write basic user acceptance test
• Start this Phase ASAP to avoid going beyond deadline
• Good Research for best simplest design (Includes learning new things)
• Good upfront design (avoids future blocking issues)
• Divide this phase into subphases i.e. Research, Designing, Estimation and timebox each one
• Subdivide the work recursively till you get the smallest task unit, this helps in proper estimation
• Story -> Features -> Task -> Sub Task
• Add the tasks in backlog & group tasks into meaningful group & Sort the group by priority/MoSCoW (Must have, should have, could have, and Won't have, use users POV during prioritization) & story points (Reprioritization/Re-estimation/Redo Dead lining if new feature is added to backlog)
• Timebox each Sub Task and keep daily tasks to do list

1.1 Designing :

• complicated user interactions/simple requirements interaction with simple use case design (draw.io)
• simple UI design with MS paint, use tested UI design patterns (e.g. Want to add search bar? use Google search bar design)
• Spike solution (small experiment/program to research the answer to a problem)
• simplest design (no fancy features etc, don't worry about future requirements)
• worse is better, Software that is limited, but simple to use is better, than buggy or complex software with complex features (less features, more quality)
• Don't program features until they are actually needed (YAGNI)
• Write programs that do one thing and do it well and work with other programs
• complete design: The design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.
• Use software standards for everything (e.g. semantic versioning etc)

1.2 Estimation:

• 10-20% buffer time while estimating deadline (E.g. 1-day buffer means, release date 29th-30th) (avoids stress & frustrations)
• overestimation-Parkinson's law, underestimation-no work/feature get done
• Proper estimation is very important for highest productivity (No time limit/deadline - Low productivity)

2. Implementation:

• Make sure I am following the manifesto properly
• Start day by observing/tracking yesterday's task and deadline, things TODO today, and any blocking issue to fix it
• Track the work daily to meet deadline (Zen Hub-burndown chart, Kanban board) & correct productivity/blocking issue if any and prioritize accordingly
• Use pomodoro Timer Technique for Time Management -> work for n tasks for x mins(30-90mins,depending on estimated time), small break(3-5mins) if fewer than n task completed else large break(10-15mins), pomodoro is indivisible and cannot be interrupted, other things should be done after pomodoro or else abandon pomodoro. After task completion any remaining time used for Reviewing the work and also seeing from learning POV (What I learned? What could be done better etc)
• Use Test-driven development (TDD) during coding:
  • Convert software feature/requirement -> test case (concise, note it down for future unit testing),
  • run test and see it fail,
  • write code to only pass the test (No refactoring)
  • run test and see it pass (the code should not break any existing feature) (if it's gotten hard to pass the above code, then revert the above code to avoid excessive debugging) & commit,
  • refactor the new code and the whole code & commit (deepcode/standardjs --fix)

2.1 Testing:

• Unit Test, Total feature test, acceptance test (users POV), stability test(stressing)

2.2 Documentation & PR:

• Minimal documentation for users and also about how the code works (for myself & future Devs) (Code comments, unit test cases above function, etc)
• PR/Marketing (Write Medium/dev.to/LinkedIn Article, Answering SO, Quora etc, 4P's-Price, Product, Place, Promotion, Market Targeting/Segmentation message with differentiation & positioning) (Refer similar software to make marketing message), use good GFX(pixabay)

3. Measurement:

• Measure & document the estimated time vs actual time taken for subtask, to help in future estimation using my historical values (by seeing time taken previous for similar subtask) and also for retrospective to make things better
• Google Timer to measure task and then use Google stopwatch to measure extra time taken (This helps in future estimation by comparing estimated time vs actual time)

4. Retrospective:

• Happens at end of sprint, involves looking back at how the sprint went
• what things I can use? where I can make things better?
• See why I am taking more time than estimated time for different task etc
• Try Sheets/Excel Charts to analyse my historical data(ZenHub provides great reports)
• Plot estimation vs actual time for task on a graph to see your personal time estimate accuracy trend
• Learn from mistakes (Unnecessarily complex solutions, being perfectionist, using unstable libraries effects quality/stability)
• Learn from customer question/feedback? Why is customer/user asking/saying that, is there a lacking doc/feature

Rules:

• Time/Deadline & quality (no compromise)
• Scope (features etc, high impact features first), cost (overtime, etc)
• Shorter Sprint (1-2 weeks) release product

Things to Remember:

• Eliminate waste (partial work, multitasking, task switching, bugs, extra features, relearning, unnecessarily complex solution, unnecessary stress, building wrong feature, rework)
• Implement new learnings
• Decide as late as possible (so that to know more about problem and not waste time on things that's not required)
• Deliver ASAP
• During major blocking issue during operations use stop the line technique -> stop everything (Give importance/resources to issue), assess the issue, and resolve the issue, and learn how to prevent it
• Don't beg for help, learn & do things yourself
• If stuck somewhere, then google search in Stack Overflow (& its sister sites) and GitHub issue
• If stuck, Explain the problem out loud to someone (I prefer God)
• Consider asking question at Stack Overflow as last resort (Not advisable)
• commits on one main branch to avoid merge hell (don't keep multiple feature branch)
• When a bug is found, tests are created before the bug is addressed (a bug is not an error in logic; it is a test that was not written)
• embrace change (new features etc)
• During sprint you might have personal ideas (Urge to Google search something), project related ideas (new features), just write those into personal notes/to-do list to refer it back in personal time. This will reduce stress and help us to be focused (GTD Method)
• Automated testing (unit etc), CI/CD is great for software which have to be maintained for long time/always and not for small GitHub hobby projects which are onetime thing
• High cohesion in function (only does one simple task) and low coupling (low dependency on other function)
• Take longer break(30-60mins) when no longer productive/frustrated, if doesn't work, then do the work next day
• Batch Check everything one time daily (emails, messages, SMS, calls, news, sites etc) (Don't check again & again) and mark imp emails to reply at end of work time
• Headphones (inc conc.mp3) to avoid distraction

Productivity Tools:

• G Suite (Calendar, sheets etc), code time (Time tracker metrics)
• Asana (Kanban boards)
• Prowritingaid, Hemingwayapp (Documentation/Marketing message simplification)
• GitHub Projects with ZenHub (Agile Project Management)
• GitHub Actions (CI/CD)
• DeepCode(code review), StandardJS(Consistent code style)

Why Solo is Great:

• Be humble & happy & be thankful to God for being solo developer, as you are saved from Ideocracies of a team
• No Difference of opinion
• No rework due to communication gap
• No need to show off work to someone
• No status updates
• No conflicts
• No junk office timings
• No begging for your rights (leaves etc)
• No need to lie
• No need to bow to someone
• No need to compete
• No rules you make the rules,
• No waste time travelling
• Great work/life balance being solo
• Your God is your boss

Daily Routine:

Prophet Muhammad (May God's Peace be on him) has been guiding example for this daily routine.

Because God says:

Indeed, in the Messenger of God you have an excellent example ... - Quran 33:21

Divide your daily routine into three different parts

• Work Time
• Personal Time
• Family/Social Time

You should give equal importance to each. Some people work whole day without giving time to themselves or their family/Other people. Use this manifesto or Note-Taking app (Google keep-TODO List) or Kanban boards (Asana) to manage personal & Social Time

Work Time:

• This is the time you work
• 8-9 Hours/Daily
• Prefer working after waking up
• 1-day rest after every iteration/sprint/release
• Take 15-30min nap 6-7 hrs after waking up (Increases Productivity)
• Have ergonomics Computer chair & table and take 20sec break every 15mins (Use strechly, stand up and move during break & stretch your body) (Prevents Computer related injuries)

Personal Time:

• This is the time you give to yourself, for example looking your health, clothes, hygiene, ID renewal etc (For example torn shoes, repair it or get it repaired from cobbler or buy new one)
• Exercise weekly twice (e.g.: Rope skipping 10mins for healthy heart)(Sat,Tue Fixed Date)
• Be physically active by performing household chores
• Start working on tasks in here after work time

Family/Social Time:

• This is the time you give to your family and other people, such as bringing grocery for family, giving time to wife, parents etc, taking family member to doctor when they are sick, helping in household chores etc
• Start working on tasks in here after work time

---

Manifesto Implementation:

The Free Currency Exchange API was made by following this manifesto by a single developer in 2 days time

Refer The Solo Developers Manifesto for updated manifesto

Answer 7

Wow. I'd try to keep a friend on the hook that I could call when I was in trouble - and talk through the coding problem. You know what I mean... just the act of explaining a problem out loud brings a solution to my mind 90% of the time.