Few friends (3) and I started a small company. But we weren't shure how to organize ourselves since everyone will work from their homes and in different hours of the day. How should we organize in terms of work to do, bugs, etc? Should we use an agile methodology like "adapted" for our small team?
Team Organization for Small Team
project-managementteam
Related Solutions
A few questions and suggestions:
- How are you measuring your output?
- How are you measuring the quality of your output?
- Are you able to extend your software easily?
It's always easy to say that 'We got more stuff done in the past', but without some sort of measurement (including a longer term cost e.g. The quality & extendsibility factors) you don't really know. There are software development methodologies (e.g. Kanban) that offer techniques to measure velocity and output (although it's never an exact science). In short you need to start recording how long it took to build x type of functionality at quality level y and then start measuring against that when you make process changes.
In response to the comments section below - In that case you want to start measuring output directly, even though you're working on different applications yo can still start measuring common units of work, e.g. 'SSO takes us about 3 days to build and we typically get 2 critical defects reported on it' or 'A CRUD screen that works end to end takes us about 4 days to build and we get 0 defects reported back (our Unit and Integration tests rock!)'
- Have you advanced your build infrastructure to Continuous Delivery?
It sounds like your infrastructure is good. But could you deploy to PRD in the next hour if the client wanted it?
In response to the comments section below - Start with good CI practices (Jenkins is a popular x-platform, x-language tool here) and then move to Continuous Deployment for your dev environments (In the Java world, JRebel is great for this) and Continuous Delivery for your test and prd systems. Doing this takes time, but it will pay you back in increased output.
- What development methodology are you using? Is it one of the Agile methodologies such as Lean or Kanban?
I never like to slavishly follow a particular methodology, but I'm currently a big fan of using Kanban as it shows the velocity and output of the team I'm working with. Most crucially it shows you very quickly where the blockages are "Oh look, we're developing the code really quickly, but we're overwhelming QA - so we can either add more QA or write more BDD/ATDD style tests to take that burden off QA".
In response to the comments section below - Whatever fits your team best, but you can measure the individual's and team's output. What's the unit? There is no scientific unit you can use :). You need to build up some historical stats on how long it takes to build something as well as keep an eye on the quality of that work (# of genuine bugs reported & difficulty in extending). I use JIRA and Greenhopper to track this as developers can put in their estimates and then the real time it took them to complete a task. Over time we learn how to split up tasks into 1 day chunks and we can then reasonably accurately measure the output. Please remember this is not an exact science and developers are not production line workers
- Have you got a team of 'smart people who get stuff done'?
- Are the team collectively responsible for issues?
The best teams I've seen always have the peer pressure to maintain a high quality bar through things like static code analysis (Sonar is good here) and peer code/design reviews.
In response to the comments section below - Start with the reporting that CI builds can give you. In the Java world its PMD, FindBugs, JDepend, Code coverage from your tests and many more. Very quickly individuals want to have the highest percentage of coverage, never break the build, least amount of FindBugs warnings etc. Also encourage ideas from the developers on how to improve quality and that sense of working with peers. Lunchtime or later afternoon presentations on a technology and that sort of thing help.
Also, you can encourage a collective approach to resolving issues. Assuming you've got the right culture in place, individuals know when they've screwed up and they also know that the team will work hard to help their colleague get out of the mess. We're all human and make plenty of mistakes after all! In fact dare I say that mistakes should not be punished - sometimes you need to make brave technical decisions that later on don't work out, it's the nature of software development (at times).
There are some people who simply aren't up to being part of a culture like that ('smart and get stuff done'). You may have to find them a niche or simply let them go (that's the harsh realities of business).
HTH!
From your description it is not clear whether the teams are actually working on separate projects - I assume they are.
In the ideal case, I think this should be mainly decided by the teams themselves, but they would come to more or less the same conclusion (i.e. using Agile). Especially if prominent members of the teams used to work together in the single Agile team before, they tend to naturally bring with them the practices they tried and proven to work.
However, each new team is bound to encounter its own, more or less different situation and challenges, so over time they will develop their own process a little bit differently from the others. And that is fine, within certain limits. In order to make management's life easier, it is advisable to agree upon and stick to some common way of reporting towards management. But since Agile is not reporting-heavy, I don't think this imposes huge restrictions on any team.
Now, if one team comes up with a process improvement, it is indeed useful for other teams to learn about it - as long as it actually solves some problem of theirs too. So IMO the best approach would be to keep up communication between teams regarding retrospectives and process improvement solutions, by way of some designated team members (one from each team would be enough - e.g. the Scrum Masters) to regularly meet after each sprint and discuss the problems they encountered, the solutions they tried, and the results.
So if Team A tells about a problem, it is possible that Team B has already got a working solution for it, which can be applied right away. Or if Team A has an idea to solve same problem, it is possible that Team C has already experimented with a similar idea and they have gained useful experience which they can share with Team A. Etc. The point is that any team is most interested in solutions to their concrete problems, so it is best to approach knowledge sharing from this perspective: adapting solutions to concrete problems, rather than trying to adapt processes to imaginary "solutions". Development teams would be pretty normal to resist the latter approach, but not the former.
Best Answer
My current employment is within an enterprise however the team size is small at 5 individuals. On top of that we are dispersed geographically, 2 in one state, 1 in another state, 1 in another state, and 1 in another country.
Our success thus far has hinged on using cloud based solutions within a Scrum methodology. We use tools such as ScrumWorks free offering (since it can be hosted within our domain however VersionOne has a free offering that can be up and running within their domain) as the base of the process. We then leverage Planning Poker which is also another free offering.
We follow the typical Scrum process complete with a daily stand-up meeting. The stand-up meeting has by far been the best approach in attempting to bring about cohesion throughout the team and attempt to remove the isolation that can exist in this type of atmosphere. The daily stand-up coupled with a live form of communication (we use Office Communicator in the enterprise however any IM client would suffice) are critical to insuring a sense of community.
With varying native tongues amongst the team the telephone is a prominent form of communication for in depth conversation however the benefit tends to vary as it can sometimes make the communication much more difficult; as a given accent can sometimes make it difficult however as with anything the more you do it the better you become.
On the flip side I have worked within a team that was located within the same building and no technology or methodology has provided the type of cohesion that close proximity can provide. There was a recent study that provided *empirical evidence to the fact that close proximity of team members is beneficial to the long term goal of the project.
Bottom line is that you will need to find out what tools work best for you. Make sure that the entire team speaks their mind on what is and is not working or isolation will surface very rapidly.
*I can not find the link at the moment but will post it once I do.
EDIT:
Based on comments...
Source control is via svn which is addressed by the enterprise via a custom solution leveraging CollabNet. This solution also takes care of defect management at a higher level as we then port those defects to ScrumWorks to get placed on the sprint backlog. In addition it also provides access to a build environment for CI and deployment.
Testing is attached to the stories from a unit/integration stance; ie...a stories point estimation should and will include testing. That is not a separate component; it is part of the development effort. The testing framework used is NUnit and tests are then ran within the IDE (Visual Studio) via a tie in into NUnit.
This allows the developer to constantly check in and run their tests as needed. Since we are a small team; ownership on problems within the code base rarely happen and we do not implement a strict only check-in when the code has passed all tests mentality as that is not the purpose of version control. Being dispersed it is critical that we check in frequently.
If you do not have access to an enterprise solution your next best bet would be to leverage a VPS hosting solution as they can be had for fairly cheap ($20.00 US/month) and it would allow you to centralize your source, provide version control, DR, deployment of ScrumWorks and other needs as they surfaced.