I asked this question on Twitter and received some interesting and thoughtful responses. So, those of you who didn’t can’t the question on Twitter. If you consider yourself an Agile Development Methodology practitioner and work either alone or in a small team (1-2 people), which aspects of Agile work for you?
I am a freelancer and talk to teams about their approach to Agile. I always hear repeated talk about:
- Peer programming
- Customer on-site
- Morning stand-up
As a solo developer working from home I see the huge benefits to Agile development but don’t have a peer to code with, no need for a stand-up, and no appropriate to have a customer in my home office. I practice some of the obvious things I can do alone:
- Test-Driven Development (TDD)
- Refactoring
- Short Iterations
I would like to hear folks who have this experience and what works and what doesn’t. Does being in a small team, even solo, give you too much freedom to let iterations or sprint goal slip? Have you changed your approach to Agile to customize it to work in this situation?
I see the amount of soloists and small teams growing over the next few years. I think Agile methodologies to be very good at keeping us motivated and focused on our work but the majority of of Agile really deals with larger teams. So, maybe cutting out what doesn’t work from the Agile Manifesto and tweaking what does for our unique position can benefit all of us.
So please let me know what is working and what is not.
I work on a small team but physically separate from the rest of them. I, too, tend to use those techniques.
In particular, to stay focused, I use GTD as a personal process where contract consultants may well use user stories instead. At the lower level, I pending spec perhaps 5 or 10 ahead of my current task at any given time to keep me on track (or, as I’ve heard another say, to avoid the hell of the "blank page").
As I’m working in a small team, when I give a work estimate, I see it as a commitment and treat it accordingly: I rarely slip.
I could see working solo as somewhat trickier in that regard. Sadly, I find it easier to break commitments to myself than to other people.
I work on a small team but physically separate from the rest of them. I, too, tend to use those techniques.
In particular, to stay focused, I use GTD as a personal process where contract consultants may well use user stories instead. At the lower level, I pending spec perhaps 5 or 10 ahead of my current task at any given time to keep me on track (or, as I’ve heard another say, to avoid the hell of the "blank page").
As I’m working in a small team, when I give a work estimate, I see it as a commitment and treat it accordingly: I rarely slip.
I could see working solo as somewhat trickier in that regard. Sadly, I find it easier to break commitments to myself than to other people.
From most to less impacting:
* short iterations
* BDD (or TDD)
* (careful) customer involvement
Refactoring is not so helpful, IMHO, if you code solo you tend to write (everyone hope) good code as possible (clearly meeting the deadlines…)
From most to less impacting:
* short iterations
* BDD (or TDD)
* (careful) customer involvement
Refactoring is not so helpful, IMHO, if you code solo you tend to write (everyone hope) good code as possible (clearly meeting the deadlines…)
@evan and @carlo – It seems the same things are working for both of you and the other folks I have heard from, which is great to know.
Of course, working solo we tend to be able to be less disciplined that if we were working with a company like Hashrocket.
I don’t know how to optimize the way we can work Agile being solo and still be efficient. Would either of you feel comfortable stepping into Hashrocket and be up to speed?
@evan and @carlo – It seems the same things are working for both of you and the other folks I have heard from, which is great to know.
Of course, working solo we tend to be able to be less disciplined that if we were working with a company like Hashrocket.
I don’t know how to optimize the way we can work Agile being solo and still be efficient. Would either of you feel comfortable stepping into Hashrocket and be up to speed?
RE: What Aspects of Agile Software Development are Working for Soloists?
Pingback from Double Shot #403 « A Fresh Cup
RE: What Aspects of Agile Software Development are Working for Soloists?
Pingback from Double Shot #403 « A Fresh Cup
There’s some discussion here:
c2.com/…/wiki
It’s XP-oriented, as the title would have you expect, but there’s a fair bit of sense.
Personally, I think the important thing is to understand the practices as originally intended for teams, then to consider how (or if) they may be applied to the solo developer situation. Then for those that are still important, consider how they might need to be modified to be useful.
There’s some discussion here:
c2.com/…/wiki
It’s XP-oriented, as the title would have you expect, but there’s a fair bit of sense.
Personally, I think the important thing is to understand the practices as originally intended for teams, then to consider how (or if) they may be applied to the solo developer situation. Then for those that are still important, consider how they might need to be modified to be useful.
@mike Thank you for the link, looks like a great soloist XP resource.
I think you are right on and right where I am. It is clear to look at Agile and take what works for teams and hone to the soloist.
My question is really, of those doing Agile who are soloists or small teams…what is working for you out of the larger Agile Development practices?
@mike Thank you for the link, looks like a great soloist XP resource.
I think you are right on and right where I am. It is clear to look at Agile and take what works for teams and hone to the soloist.
My question is really, of those doing Agile who are soloists or small teams…what is working for you out of the larger Agile Development practices?
Your article was painful to read because of the grammatical mistakes found in every other sentence. Please proofread your blog posts.
Your article was painful to read because of the grammatical mistakes found in every other sentence. Please proofread your blog posts.
@nick – thanks for your valued feedback, NOT. It was about the content not your grammatical critique. I guess you have nothing particularly valued to add to the Agile conversation?
At least you could do is leave an email so I could ping you directly.
@nick – thanks for your valued feedback, NOT. It was about the content not your grammatical critique. I guess you have nothing particularly valued to add to the Agile conversation?
At least you could do is leave an email so I could ping you directly.
In addition to what others has said, I often found the stand-up meeting approach still works sometimes if you think about it as just a quick exercise to do before you start your working day.
I know it might sound strange, but thinking about things like what you did yesterday, what you want to accomplish today (maybe writing it down) and think about what’s blocking you/preventing you from doing what you need/want sometimes helps to reorganize your head a bit before you start working.
Obviously you don’t need to stand up or talk loudly, but feel free to do so if that helps š
In addition to what others has said, I often found the stand-up meeting approach still works sometimes if you think about it as just a quick exercise to do before you start your working day.
I know it might sound strange, but thinking about things like what you did yesterday, what you want to accomplish today (maybe writing it down) and think about what’s blocking you/preventing you from doing what you need/want sometimes helps to reorganize your head a bit before you start working.
Obviously you don’t need to stand up or talk loudly, but feel free to do so if that helps š
@Matias – good idea, never thought of the standup alone but I guess if it works then why not.
Do you do this on a regular basis?
@Matias – good idea, never thought of the standup alone but I guess if it works then why not.
Do you do this on a regular basis?
@Rob – yes. Definitely not every single day, but pretty often.
@Rob – yes. Definitely not every single day, but pretty often.
@Matias – great. I was hoping for more comments here, maybe I wasn’t clear enough in my description or maybe there are very few soloists or small teams practicing Agile that it doesn’t matter to them.
I think small teams can extract out a workable subset of Agile to be very useful. I am trying to define this and write more about it.
@Matias – great. I was hoping for more comments here, maybe I wasn’t clear enough in my description or maybe there are very few soloists or small teams practicing Agile that it doesn’t matter to them.
I think small teams can extract out a workable subset of Agile to be very useful. I am trying to define this and write more about it.
@Rob – how did you bootstrap into using your Agile subset? Work in a team before, pick up the habits and mindset then filter when going solo?
@Rob – how did you bootstrap into using your Agile subset? Work in a team before, pick up the habits and mindset then filter when going solo?
@Guy I have been working as a freelance/consultant for a good number of years and ran a small software development company before that time. The larger projects I have worked on used waterfall methods but claimed to be agile, they weren’t.
What I have picked up as a subset has really come from what I learned from people on smaller agile teams and from James Shore’s book, The Art of Agile Development. It is clear his book, and most agile instruction, is geared for teams but I picked out what I thought could be applied to a soloist or a team of a couple developers. I think picking and choosing what works is the best approach.
I hope this helps.
@Guy I have been working as a freelance/consultant for a good number of years and ran a small software development company before that time. The larger projects I have worked on used waterfall methods but claimed to be agile, they weren’t.
What I have picked up as a subset has really come from what I learned from people on smaller agile teams and from James Shore’s book, The Art of Agile Development. It is clear his book, and most agile instruction, is geared for teams but I picked out what I thought could be applied to a soloist or a team of a couple developers. I think picking and choosing what works is the best approach.
I hope this helps.
@Rob, thanks. I have been a solo dev on intranets where the pace is less frenetic and the stakeholders are in the next room so agile/cucumber/bdd was less important, Now I am trying to break into the commercial rails dev shop club in London where these skills are highly regarded and sought after, I would like to read more about this subject
@Rob, thanks. I have been a solo dev on intranets where the pace is less frenetic and the stakeholders are in the next room so agile/cucumber/bdd was less important, Now I am trying to break into the commercial rails dev shop club in London where these skills are highly regarded and sought after, I would like to read more about this subject
I know it might sound strange, but thinking about things like what you did yesterday, what you want to accomplish today (maybe writing it down) and think about what’s blocking you/preventing you from doing what you need/want sometimes helps to reorganize your head a bit before you start working.
I know it might sound strange, but thinking about things like what you did yesterday, what you want to accomplish today (maybe writing it down) and think about what’s blocking you/preventing you from doing what you need/want sometimes helps to reorganize your head a bit before you start working.