Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm working on a software project which several members are working from home and some other are part-timers. We meet physically one time each month at least. We communicate mostly by emails. Our source code repository (mercurial) is on a jungle disk (workgroup) that we share together.
We have a working product and one customer. But, we are not agile enough (ie: one change in the code sometimes break something else, we don't have unit testing, code is not documented, etc.) I want to use an Agile methodology to coordinate our work and track our progresses. I also want to use TDD.
The team has no experience with agile methodologies (or other methodologies).
What is the best approach to use an Agile methodology with a geographically distributed team? Which methodology is best with that kind of team? How to implement it efficiently with the least resistance possible?
Thanks!
I have done this as part of a distributed XP team sharing source code and stories across 3 sites, each site being 12 hours apart (Seattle, Bournemouth UK, and Singapore).
Here are some write-ups of what we did:
Distributed Agile Patterns: http://www.keithbraithwaite.demon.co.uk/professional/papers/index.html#europlop2005
http://www.keithbraithwaite.demon.co.uk/professional/papers/index.html#xp2005
We found that it helps to get everybody physically together at the start of the project to establish standards and to build relationships.
We also found that it helps to have "ambassadors" - shipping different people around between teams to spread knowledge and build trust.
We were lucky to have three sites that were each 12 hours apart - so we could have a stand-up meeting first-thing in the morning and last thing in the evening. We called them "hand-over meetings" and did them over video-conference between the incoming team and the outgoing team.
We also found remote pair-programming worked - between a local pair and a remote pair (i.e. four people) but that it's very intense and draining and best done only for short periods of time when it's really critical to see what other people are doing remotely.
Aside: Kent Beck's Advice for people using Eclipse to remote pair: http://www.threeriversinstitute.org/blog/?p=584
Well, my first thought, given what you specified:
Add unit tests to your source code!
Without unit testing, most Agile methodology isn't all that useful. Being Agile is about being light and being able to respond to change quickly - unit testing is one of the main things that makes that work. Without unit testing, you'll never have the freedom to make changes without risking major breakage.
As you add tests, I would document your code. This, again, is critical for being able to change things, even more so when the team is distributed.
Once that's done, you can start implementing other methodology over time. Personally, I would have the entire team do this, and get started on having daily/weekly stand-ups (which work fine with a distributed team via conference calls, etc), where everyone describes what they've tested, how they're progressing, etc.
That will at least get you on the proper track...
Have a quick browse through this blog:
You're not agile if your team is dispersed. Yeah right!
Start with a Continuous Integration (automated build). I used CruiseControl.Net. I had two builds set up: 1) an automated build after every check-in and 2) a test build to build on demand.
You have to improve your communication for a start. Yes, engineering practices are important, but the key to agile is communication. Email is not the most effective tool to coordinate an agile project, but there are not shortage of tools out there that can help.
We have had great success with Skype (mostly pm, but also normal phone), and also with tools like MS SharedView it is possible to demo and even pair programme across sites.
Once you start to communicate effectively and feel like a team, the rest will follow. Agile is all about inspecting and adapting, so try things out and have fun with it. Start with the daily stand up and move on from there. Regular retrospectives will help you identify you problems and improve.
If you are into tools: To be able to do pair-programming or synchronous code reviews remotely, you could try the eclipse plugin Saros, which enables collaborative editing (including support for driver/observer roles and following users through the code).
(Disclaimer: Saros is a project of my working group at Freie Universität Berlin)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
most of the books about Project Management (if not all of them) describe management of one big project. Sometimes they describe how to manage very few projects in the same time. But I have very different situation.
I manage small team (4 people) with very small projects. Usually one engineer works on dedicated project. Some times One engineer work on few projects with different priorities (projects quite often switched to "on hold" state for a several days).
So my specific is:
Small projects with short lifetime (1 week to 2 month in general)
Projects usually are not shared between engineers
Number of projects can be 2-3 times higher then number of people (some projects go "on hold" quite often)
There are 2 longterm projects with lowest priority which can be shared between engineers
Can someone share own experience how to manage projects like this, or if you never had such experience but have an idea how to organize that I'll be glad to read it.
Of course if you know book which can help me - I'll be glad to check it as well.
May be there is ready methodology for thas kind of projects which I never heard.
Thank you.
I suggest looking at Kanban. Here's some links to explore:
Kanban (the book) on Amazon
David Anderson's site
Some Kanban info on InfoQ
The Limited Work In Progress Society
I have a team with this situation. My solution is to run each project with week long iterations and allocate an engineer to that project for a number of weeks, where possible. That way each project is only an average of half a week from being worked on if needed.
If you have higher levels of concurrency an alternative strategy would be to keep the short iterations and to set objectives for each iteration that include aspects of each project that requires attention. Multiple, concurrent burndown charts could be maintained to track the work for each project, but I would suggest these are a little academic if you aren't going to have effort expended on each project at a consistent rate. Using this approach would be unorthodox but would give you quick feedback, regular delivery of working software and progress on all the projects that need it so shouldn't rile the agile evangelists.
If you're stuck with this setup, the other responses give some reasonable ideas for dealing with it.
But this is a bad setup, and I'd advocate trying to change the situation. You have too many simultaneous projects, and a work process that doesn't allow teamwork.
If multiple projects have the same stakeholders, try to get the business to merge the projects. If this can't be done, or if it still results in multiple simultaneous projects, try to get the projects to be prioritized by business value so that you can put the whole team on the most important project, finish and deliver it and then move on to the next most important.
This will almost certainly involve getting people outside your team to make some difficult choices, and may be politically difficult, but there are gains for the business, which might help you with selling the change.
Getting a project out the door and in production more quickly will improve the cash-flow/throughput of your company. See throughput accounting.
Putting the whole team on this one project will reduce the impact of a developer absence (see bus number) and will mean your team is actually working as a team rather than as a bunch of individuals who happen to have the same manager.
If you can't get the business to prioritize down to one project at a time, by all means try for two, but with a team of only four developers, you should be doing one.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Currently I'm working alone on a small project for University and I wondered: Does it make sense to apply methodologies (XP, Scrum) or parts of it? If only for experience? Or does it produce too much "overhead"? And if it does, which one would fit best?
Methodologies give the approach to tackling a development, to me it would still be applicable if there was one or 100 people on the project. The only difference as you being the sole developer would take on multiple roles within the development.
It's certainly an interesting idea to be able to sprint towards getting a set of goals done in a certain time. It might add some motivation to hitting a deadline, and preventing feature-bloat.
As any skill, project management side of development improves with practice, so I'd say it's worth trying out.
Worth noting that XP and Scrum are development methodologies not project management methodologies.
Development methodologies (such as XP and Scrum) govern areas such as requirements gathering, development techniques, testing and release.
Project management methodologies (such as PRINCE2) cover elements such as scheduling and planning, risk and issue management, project scoping and business case management.
But the accepted answer is right regardless. Unless you're the only person who will ever see the software, input into it, code on it or interact with it in any way at all, methodologies of both sorts will absolutely have something to offer and should be looked at. Even if you are the only person they can still be useful.
Some of this depends on where you intend to go with your work: you're working alone today, but are you planning (or at least hoping) to build something big enough that you will need help? If so, then it is good to get some practices in place upfront - not so much that it will slow you down, but something that you can build on when you create your team.
A colleague of mine, who has left architecting high-volume trading systems to build software for the iPod and iPad, has done some thinking about this now that he is a team of 1. You might find it helpful:
link text
If you are working alone, then pair programming may be a bit of a challenge. :) At the same time, having a story board and moving cards may be useful for others to see if they are connected to your project,e.g. end-users or project managers. My suggestion is to read up on various approaches and if it seems like it may work, do a trial and see how if it makes things better or not.
I have worked on projects by myself and you definitely need to play multiple roles. I'm a better developer now than before I worked on my own, and definitely I can integrate to any development team working with XP and Scrum since I made sure than when I worked by myself I would do the best practices XP and Scrum suggests.
The only thing you couldn't apply is pair programming. Besides that everything is possible playing multiple roles, it will enhance your development for sure.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
We have a four person development team that is in need of a formalized project management system. I have a general understanding of Scrum and Kanban but it's hard to truly understand until it's been tried. We don't have the luxury of trying one for a few weeks and then switching to another so I was hoping that someone out there in a similar situation might have thoughts on which worked better for them and why. Also, any other systems for managing development that worked would be great to hear about.
Another note: there's the possibility of the team growing, of course, so we would need a system that scaled well.
Yet another note: We work on three separate software applications in Windows all of which are based on a central library which we also wrote (so i guess you could say four projects)
Both Scrum and Kanban are really process "skeletons". Neither is specific to software development. Scrum was popularised by software development organisations but is positioned as general management technique rather than a software project management technique. Kanban emerged from manufacturing and has been adapted to software development, initially by maintenance teams. Both Scrum and Kanban aim to manage the flow of units of work through the team that is doing that work, measure how fast work flows so that estimates can be made more and more accurately, and make bottlenecks highly visible so that they can be addressed.
Because neither is specific to software development, teams using Scrum and Kanban add software development practices to the process to help them incrementally and iteratively release and improve the software. Most teams, whether working within a Scrum or Kanban process, adopt the technical practices of XP and reflective practices of Crystal.
XP is basically Scrum applied to a single team plus guidelines about what makes code "high quality" and how programmers can achieve that. Crystal Clear also applies to small co-located teams but is more flexible about programming practices although it also recommends the XP practices (the book describing the process is excellent and full of invaluable advice, whatever process you decide to go with). Scrum teams also usually adopt the reflective practices of Crystal: regular "heart-beat" retrospectives and larger retrospectives after every major milestone. Kanban requires continual reflection and improvement but some teams use retrospectives too.
If you want to start applying an incremental/iterative process in a small programming team, then I think XP is a good process to start with because it sets the bar pretty high for technical capability and is very well documented. How continuous-flow and Kanban best applies to different areas of the software development industry is still being debated on the kanban-dev mailing list and elsewhere.
I would recommend also performing regular retrospectives to improve the process and adapt it to your specific situation.
The most important part is to have a reflection/retrospective mechanmism in place which facilitates continuous improvement. Start with some process model and evolve it over time for your needs. Stop doing things that are not worth doing. Keep on doing things that bring in high value. Try new things that you think could be valuable or address specific problems.
I think Scrum works for small to medium team. Compared to XP it leaves out some details, so you can borrow from XP or do something that makes sense. Either methodology you pick, you have to consider the role of chickens(customers/managers/stakeholder/domain experts) role. Sometimes you have to play the roles yourself, but many agile methodologies work because there's external pace car with grounded knowledge of the domain.
Other key aspects are the communication level among your team and some form of quality assurance mechanism. It's hard to do pair programming if you are not located in the same building. Scrum tries to get a feature to acceptance within a sprint cycle, and XP tries to get the feature integrated within the day using unit tests, code review, and continuous integration.
*) Sprint can range from 15-30 days.
What is you question ? Is it which methodology would be most suitable ?
You don't get much benefit from all the overhead that a formallised system will impose with that size of team. Instead, try a good management technique to make sure everyone is listening to each other and blocks are removed.
I've worked with a team of that sice and even bigger on two teams that shared some common libraries. Scrum worked well for us. Now I work with a team with 6 members and we use XP and I think it works as well. The first team developed a product and the influences from 'the outer space' were not that big. So longer iterations worked fine. No we develop a customer project and therefore shorter release cycles are better for us.
But SCRUM and XP are more than that. Now we use TDD and Pair-Programming (both more from the XP world). We also have daily standup meetings that are more SCRUM like. So we adoped XP and SCRUM to work for our project and our situation.
I would start with short cylces (1 week) and reviews of this cycle. It will take some time to adopt a new methodology in your team but if the members are willing to learn and change it will work.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am going to be starting a new job in a few weeks where I will be responsible for both the maintenance and development of a couple of existing web applications and the development of new web applications.
As I will be the only developer on the project and the previous developer was more of a hobbyist, no formal project management or planning techniques have been followed. Additionally no bug tracking has been used or if anything has been recorded its just been notes on paper.
I would therefore like to introduce a better system to help resolve some of the issues and help ensure things run more smoothly. I intend to develop using an agile process (likely scrum) and would therefore like to know what all-in-one solutions people could recommend for me to look into further. I am looking for something which will provide at minimum:
Project Planning
Defining new features
Time estimating
Ability to organise tasks by priority
Project Management
Tracking active tasks
Reporting
Bug Tracking
I would also like to let other staff easily submit new bugs in the applications which they find or customers report. Additionally support for them to add new stories / high level tasks would be of use so they can note down other new requirments/features and I can then work with them to outline more detailed tasks and estimates.
So far I have looked at a number of systems including:
FogBugz - Seems great for bug reporting but would need something else for project planning / management
Agile Buddy - This is probably the best solution I have found so far
Trac
Smart Sheets
Pivotal Tracker
However, as I have not actually used any of these systems myself I do not know what ones would be best or whether there is a better solution out there??? So any recommendations you can provide would be much appreciated.
Actually, FogBugz does project management as well. It will even try to learn how accurate time estimates for features are from each user, and give you estimated milestone completion times accordingly, with probabilities of finishing at various dates. I've used it for the bug tracking, and really liked it, but I've also read enough about its project management features to know that it has them, and they're pretty good.
FogBugz feature list
When I was working as a solitary developer, I picked up a copy of Planning Extreme Programming and bought a pack of 3x5 cards and a plastic box for them. I used those in the Planning Game and stuck the ones I was working on on my wall. My boss could walk by and see what I was working on. This worked well and cost little.
We're currently using Zen at work - it's a web-based Kanban board for planning. This is nice when your stakeholders aren't co-located or if priorities/requirements change frequently.
You can enter bugs as user stories with either system, or you could use a separate defect-tracking system.
I'd question if Scrum is suitable for a one-developer shop. It's targeted towards project management. I'd rather not have a stand-up meeting with myself. ;) XP (minus pair programming) works fine for a solitary developer.
For a one-man show, you don't need any tools to speak of.
Tools -- generally -- are for coordination.
If it's just you, what -- precisely -- are you coordinating?
If you want to make things visible, a pair of simple internally-focused web pages built from static content will do.
Bugs.
Burndown for Features.
That's about it. Use the simplest tools you can possibly use. I recommend using docutils to generate the HTML from plain, simple text.
Don't go tool-happy until you have a large enough team that simple text doesn't work any more.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
There are numerous Agile software development methods. Which ones have you used in practice to deliver a successful project, and how did the method contribute to that success?
I've been involved with quite a few organisations which claimed to work in an 'agile' way, and their processed usually seemed to be base on XP (extreme programming), but none of them ever followed anywhere near all the practices.
That said, I can probably comment on a few of the XP practices
Unit testing seems to prove very useful if it's done from the start of a project, but it seems very difficult to come into an existing code-base and start trying to add unit tests. If you get the opportunity to start from scratch, test driven development is a real help.
Continuous integration seems to be a really good thing (or rather, the lack of it is really bad). That said, the organisations I've seen have usually been so small as to make any other approach seem foolish.
User story cards are nice in that it's great to have a physical object to throw around for prioritisation, but they're not nearly detailed enough unless your developer really knows the domain, or you've got an onsite customer (which I've never actually seen).
Standup meetings tend to be really useful for new team members to get to know everyone, and what they work on. The old hands very quickly slack off, and just say things like 'I'm still working on X', which they've been doing for the past week - It takes a strong leader to force them to delve into details.
Refactoring is now a really misused term, but when you've got sufficient unit tests, it's really useful to conceptually separate the activity of 'changing the design of the existing code without changing the functionality' from 'adding new functionality'
Scrum because it shows where the slackers are. It also identifies much faster that the business unit usually doesn't have a clue what they really want delivered
Scrum.
The daily standup meeting is a great way to make sure things stay on track and progress is being made. I also think it's key to get the product/market folks involved in the process in a real, meaningful way. It'll create a more collaborative environment and removes a lot of the adversarial garbage that comes up when the product team and the dev teams are separate "silos".
Having regular retrospectives is a great way to help a team become more effective/agile.
More than adhering to a specific flavor of Agile this practice can help a team identify what is working well and adapt to a changing environment.
Just make sure the person running the retrospective knows what he/she is doing otherwise it can degenerate into a complaining session.
There are a number of exercises you can take a team through to help them reflect and extract value from the retrospective. I suggest listening to the interview with Linda Rising on Software Engineering Radio for a good introduction.
Do a Google search for "Heartbeat retrospectives" for more information.
I've been working with a team using XP and Scrum practices sprinkled with some lean. It's been very productive.
Daily Standup- helps us keep complete track of what and where everyone is working on.
Pair Programming- has improved our code base and helped remove "silly" bugs being introduced into the system.
iterative development- using 1 week iterations has helped up improve our velocity by setting more direct goals which has also helped us size requirements
TDD- has helped me change my way of programming, now I don't write any code that doesn't fix a broken test and I don't write any test that doesn't have a clearly defined requirement. We've also been using executable requirements which has really helped devs and BAs reach requirements understandings.
kanban boards- show in real time where we are. We have one for the Milestone as well as the current iteration. At a glance you can see what is left to do and what's being done and what's done and accepted. If you don't report in your daily standup something pertaining to what's on the board you have explaining to do.
co-located team- everyone is up to speed and on page with what everyone else is doing. communication is just-in-time, very productive, I don't miss my cube at all.