Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I know slightly close questions have been asked before but this question is a bit different.
We are a start-up company with a very limited budget and we are looking for a completely free Agile software development process tool without any limitation on the number of users. We don't want to have a limitation for the number of users because there could be a lot of people who would do small tasks for us and if they pass the number of user limit all of a sudden we'll have to pay a lot of money for the tool monthly.
It would be very useful if it could support:
Kanban board
Task hierarchy (so that you can define cards within cards)
Hosting the tool online (not download)
Commenting system
Different roles
Swimlanes
I have checked a lot of those tools here:
http://agilescout.com/best-agile-scrum-tools/
but I didn't find any that is absolutely free for unlimited users. Some of them also don't have a Kanban board. I checked Agilefant but its online version is going to be paid from 2014. I also checked Stackoverflow for this but none of the questions were targeting "completely free tools".
Your help will be greatly appreciated.
Trello.com Trello is free for unlimited users. Period.
You almost definitely don't need "Sub-cards". Use the checklists instead, or if you REALLY need sub-cards, don't have a parent sub-card. Just name the tickets something like "Epic - Story A" or "Story - task Z" or whatever.
Another idea is to create two boards (did I mention you can have unlimited boards for free too?). One for your epics and one for your stories. Call one your product management board and the other your sprint board, or whatever you like.
I'm not sure what you need different roles for - but, people aren't crazy - they know their job. As a startup if you already have problems getting people to not do crazy things (Where you need to restrict their permissions) you have much much bigger issues.
The point is that you need a SMALL tool to help you track stuff. Not a super rigid tool that makes you work in a super specific way. As a new (I assume?) startup, you should let your process grow into a tool. Don't beef up your process to fit a tool.
Back in 2010 we had the same problem and i successfully employed GoogleDocs with our small Agile Development team (8 Devs in 3 Countries).
GoogleDrawing will serve in the exact same way as a physical Scrum board would, with all the upsides of full flexibilty and also the downsides of zero automation but with the big additional upside of being virtual and accessible from anywhere with an internet connection.
It also was used for the retrospective at the end of each Sprint
GoogleSpreadsheet was used for a concise list of all the tickets from our bug tracking system (Redmine, manually transfered) and also for the (manually updated, albeit with formulas to calculate the progress) burndown chart.
The combination of these different elements is actually quite powerful, as you have the full flexibility over the content and its representation and can have your team communicate via VoIP while all are looking at the same documents and can modify them in real-time.
Here an example of the docs used in a sprint (all sensitive data removed):
Scrum board Example (GoogleDrawing)
Retrospective Example (GoogleDrawing)
Burndown Chart Example (GoogleSheet, formulas to automate calculation)
Ticket list from Bugtracker (GoogleSheet)
As mentioned before, the only downside is the fact that you have to invest some time to maintain and prepare the data for each sprint, but for us that was hugely outweighed by the flexibility and accessibility that the Team of GoogleDocs + VoIP gave us.
You can check out https://kanbanflow.com
It's free for now because it's in beta and they say there is no time limit. It behaves very similar to AgileZen
I second the google doc, or you could use an online collaborative board that multiple people can edit.
Or you can host a more robust excel doc in skydrive from MS. I haven't tried that yet.
Mura.ly is another one that I am playing with currently. It has unlimited collaborators, though I think you would probably have to invite them everytime?? with a free account.
Hope that helps!
Try http://www.icescrum.org . It is free to use. And it has lot of cool features. Perfect for scrum teams.
EDIT: Kanbanize is a commercial product and offers a 30 day free trial.
Disclosing: I am a co-founder of http://kanbanize.com/
Mark, I understand your desire to find the perfect application with all these features inside, but I really doubt that you will get it for free. There's a bunch of super cool apps (including Kanbanize) out there, but none of them is completely free.
Be careful what you call a Kanban board and what not, though. Trello is definitely NOT a kanban system (no WIP limits, no analytics, etc.). It is a great visual management system, but not a Kanban one.
Finally, to answer your question, tools that deserve attention in my opinion are:
Kanbanize (of course), LeanKit, KanbanTool, Kanbanery and probably a few others. My personal bias is that LeanKit is the most advanced to date followed by Kanbanize and KanbanTool.
I hope that helps.
One possibility would be to use a Google Drawing, part of Google Drive, if you want a more visual and easy-to-edit option. You can create the cards by grouping a color-filled rectangle and one or more text fields together. Being a sufficiently free-form online vector drawing program, it doesn't really limit your possibilities like if you use a more dedicated solution.
The only real downsides are that you have to first create the building blocks from the beginning, and don't get numerical statistics like with a more structured tool.
Although, I'm a big fan of Kanban Tool service (it has everything you need except free of charge) and therefore it's difficult for me to stay objective, I think that should go for Trello or Kanban Flow. Both are free and both provide basic features that are essential for agile process managers and their teams.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I recently started using "Jira" with the "GreenHopper" plugin. However, I don't feel like this is really doing what I want. I saw a cool feature in "Scrumworks pro" where you can run the app as a desktop application. My requirements therefore include things like:
Must have a really easy UI for managing scrum tasks
Must preferably have a desktop version that plugs into web version
It DOES NOT have to be free, just as long as it rocks!
It must NOT be a butchered app, but rather something specifically designed for Scrum, with a good development team.
It would also be an extra plus if it can integrate with Subversion somehow.
It would ne another extra plus if the sprints could send summaries to business owners of the work that was completed. I.e. Custom reports.
Any suggestions?
You could try IBM Rational Team Concert.
Easy UI: Very, especially the Eclipse version.
Desktop: You can use web, VS add-in, or eclipse version, by team member preference. Like I said, I recommend Eclipse (but haven't really seen the VS add-in)
Price: I believe it's free up to 10 developers, then it's IBM pricing schemas. But if that's not an issue...
(non-)Butchered app: It's IBM, so it's not a hack; and it's built on Jazz, so there's some extra developer community juice there. While it's supposed to be able to support both traditional and Agile, in my experience it's strongest for Scrum. Also, the configuration is highly customizable.
SVN integration: While there's no official bridge for this, I'm pretty sure it's been done before (e.g. by Clearvision), and can be done again if need be. Also, RTC comes with its own SCM system - I don't know if that would work well enough for you to replace SVN altogether, but it might.
Reports: Lots of (somewhat) customizable dashboards and charts. If there's a way for it to send automated reports, I haven't seen it yet.
All in all this sounds fairly close to what you were describing.
EDIT: By popular demand, some screenshots... From my actual Production environment. This is going to be long.
This is the Work Breakdown view of my current sprint. You can see that you have user stories, tasks, you can have defects, ARs, risks, impediments, what have you. It's actually customizable so you can add additional object types, each with its own properties and state machine.
Each of the properties you see can be changed from this view - so it's very easy to just add a new task under a story, set its estimate and a brief title, and you're good to go. All in all maybe 10 seconds for creating a new task. Ctrl+S commits your changes (takes ~1-2s).
In fact, I almost never have to leave this screen during a sprint. You can assign work to someone by making the item under their name, dragging an existing item under their name, or right click -> assign to Owner -> their name. You can change states and set time spent (or time left, the view is customizable) from this screen as well.
Occasionally you want to open an item for individual editing, which you can do by right clicking any object. That opens it in a new tab.
You can see that each individual team member as well as the team as a whole has a work done vs. expected. This is based on the release dates I've set for the sprints and total work estimated. If you're doing Scrum correctly, then by the second-third day you've already assigned each story the vast majority of its tasks. You get a handy meter for how many items you have unestimated. In fact, you can even filter out estimated items so you can focus on estimating the remaining ones (which again is two clicks).
P.S. My teammates don't necessarily have good task breakdowns / estimates here. But you get the idea.
The views you can have are many, and can be customized. So if you like a sticky board for your tasks, you have...
I don't actually use this a lot, but it's there. You can either view it by bunched groups of in progress, resolved etc. (like the screenshot) which is good for viewing several different object types; or you can do it by a specific object type's state machine (so for defects you could have Resolved, WNF, etc.)
Speaking of defects, this can integrate with ClearQuest (though it's got bad limitations if you're using multi-site solution for CQ). I don't know if I'd let RTC completely replace a different defect tracking system, but you conceivably could.
BTW the taskboard is intuitive in the sense that you can drag a task from one state to the other and it would update its state, assuming that the state transition is allowed by the state machine you determined.
More views are possible. Another filter I use during sprint planning is "Execution items", which leaves me only the stories and epics - no clutter under them.
Speaking of "under them", you could have other types of relationships than parent-child, such as "related" or "blocking". To do those though I think you have to go into the specific object. Parent-child can be done that way too, but usually you just drag objects on to one another.
I'll add here a couple of side panel screenshots and then I think I'm done... Because you should get the idea.
Team Artifacts panel lets you browse the relevant objects. Generally for Scrum management that would be Plans, which is where you keep all your work items. The "Work Items" item actually a bit misleading in that regard, it lets you do queries (e.g. "Open assigned to me"), which then appear in a bottom panel. I personally prefer using the plans.
You can also see builds, source control in there - for some teams they are indispensable, for others (like mine) they aren't really used.
Last screenshot...
Actually got three areas in the Team Dashboard (four with "Builds" not presented here, which I don't use). "My Open Items" can actually display any query, by any order. This one uses priority. Hovering on any of these displays the relevant items (takes 0.5-1s to think about it), with F2 enlarging the tooltip. Clicking any of these columns retrieves the items for the bottom panel.
Event Log is what you'd expect, stuff your team has been doing. Likewise easy to expand, clicking on an item opens the corresponding work item in a new tab.
Then there's Team Load, which compares estimated assigned items to each team member's expected hours left to work in the iteration, as well as total. This draws from individual setting of work hours and planned absences (alas, absences don't seem to support any half-day scheduling, only full days).
By complete happenstance, I have one team member with no load, one with load exactly matching their expected hours, and one who apparently chewed more than he could swallow. Of course, he just needs to update his tasks, though in this particular case he really is overworked. This dashboard lets a Scrum Master identify this sort of situation quickly and try to resolve it before it's too late.
(Don't ask why that didn't happen in this case).
Performance is also surprisingly good. I'm not sure what they did in their architecture, but it's a lot smoother than other enterprise solutions I've used. By far.
Maybe I should make it clear that I'm not in any way affiliated with IBM, Jazz, RTC etc. I just think the tool is pretty nifty. I'm not yet done exploring it, actually, but for Scrum it seems pretty darn good and I'm happy to spread the word :)
Is this what you are looking for?
P.S. There are a ton of Agile tools out there, you could continue to look around. But if JIRA wasn't good enough for you, then that probably disqualifies maybe 90% of what's out there which is worse (e.g. Rally).
Pivotal Tracker: http://www.pivotaltracker.com/
No desktop version, but it pretty much rocks. Has many integrations and third-party tools.
VersionOne is very good. Free up to 10 users, nice web interface and rich plugin base.
We have been using Assembla (www.assembla.com) for more than a year. It is not free and does not have a desktop version but it definitely rocks.
Some things I love:
The UI is clean and simple being suitable for developers and business owners alike.
Tasks and commits are integrated from SVN and Github so it makes it easy to track code changes relating to tasks.
The Cardwall/Kanban tool is excellent at quickly tracking tasks.
It is being developed constantly with new features like code review and enhanced cardwall features.
I can't compare it functionality to all of the solutions out there but I can tell you that it works fine for our team, is much better than what our partners use and clients are happy with it.
As a Scrum Practitioner for 8 years and user of most of the above mentioned tool, I recommend nothing better than a simple white board and concentrate on your process.
But if you have to use a tool especially for distributed teams...
I recommend ScrumDo.com Fast, Easy to use.
Nice Kanban board, integrated planning poker, intuitive story management with drag-drop, great for distributed teams.
Also we like the easy source code and time management integrations.
The prices scale very well with our growing teams.
Also the open source version helps out security minded team to install within the firewall.
Scrumdo is highly recommended. Agile Project management made so easy. I am hoping that all the teams in our company will use Scrumdo!
Try AgileWrap. I am sure you would like it.
It has clean, lean and easy-to-use interface for managing scurm user stories, tasks, defects, iterations, releases and backlogs.
Integrates with Subversion and Gits. Has API/Web services.
Free for 5 users team. Very affordable for larger size teams. You can use on-demand or on-premise whatever suits your needs. It does not come in desktop version though.
You can create custom reports as well as use many standard charts - velocity graph, burn-down, burn-up, story cumulative flow etc.
Definitely take a look at OnTime by Axosoft. It fits your wish list to a tee, including Subversion integration (if you're using Visual Studio), desktop and web clients, etc. I've used OnTime for the last five years and highly recommend it.
Best of all, their site has tons of information so I don't have to spend an evening creating screenshots to match Polymeron's answer.
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 have been trying to get our software department to adopt some kind development process methodolgy. We only have 9 developers, and about as many projects. Currently, we can only be described as chaotic. Or perhaps 'crisis driven development' as I've seen another SO user call it.
Using Kanban seems like a it could be a good fit for us. So I've discussed it with everyone else, everyone thought it sounded good. But when we discussed how the board(s) should be arranged, everyone wanted to do one board per person.
Now, I've never tried Kanban, or any methodology really, but it feels like having each person managed on their own board would negate the benefits a Kanban process is supposed to provide. This notion makes me sad, and want to say 'ho-hum let's scrap this whole idea.'
Do you think implementing a Kanban board per developer can be worthwhile?
If you must have a multitude of boards, wouldn't it be better to have a board per project rather than a board per developer ? Maybe in time some natural groupings of projects (and therefore consolidation of boards) will emerge, maybe not.
One purpose of the boards is to serve as "information radiators". A large number of project boards progressing at a snail's pace broadcasts the message "we are seriously overloaded" and/or "someone needs to set some priorities". A large number of per-developer boards just radiates the message "we don't do teamwork around here".
Kanban is actually as system for restricting flow through a system, which is why we have WIP (Work In Progress) limits on kanban boards, and as a person can do only one job at once I don't think this could work.
Having one board per developer really doesn't give any advantages (And I'd argue it's not really kanban). One board per project is a better idea.
Then if another developer joins in for some tasks you can still see the overall progress of the project.
I think it might be worthwhile to have another discussion with your group. Before adopting any kind of new technique/practice/methodology, one should be very eyes-open about why you want to adopt it, and what problem you're trying to solve. It almost sounds to me that you've stumbled upon Kanban Boards and want to adopt it without really knowing what problems you're tryying to solve.
My advice would be to try do some more thinking or analysis on the problems you see in your environment, do some root-cause analysis if you can (something like the 5-whys), and then try find some practice that will help you solve those problems.
The very fact that people in your group suggested using a board-per-developer implies to me that a. they don't understand the kind of problems they have, and that you're trying to solve, and b. they don't understand what Kanban boards are trying to achieve. I.e., your problems are such that using Kanban boards will not solve them.
It's not wrong to have a board per developer. The board is there to visualize the work. If the developers work on different projects, then it would be easier to visualize project-specific work with separate boards (which is usually the case). If your developers work on separate projects, then they work on separate projects. Technically, they're not really a single team, but more of a "practice". From that perspective, it might be a more natural approach to have them working separate boards.
When I work on personal projects on my own I still use a Heijunka Box - what software developers in the west often (mistakenly) call a "Kanban Board" - and I do this to visualize work, work scheduling, and to help limit the number of things I'm working on at once.
I've implemented Kanban for my team which does Operations Automation (more or less half Ops work and half Dev work). Here's what we found worked best for our team. We have a common column for INBOX/Backlog.. Then a 'in development' column broken down into 5 sections, one per developer, with a per-developer WIP Limit. Then another common column for 'to integrate', and finally a common column for 'release to production'.
The advantage of Kanban is that the WIP limit ensures developers can focus on what they are doing - in our case each developer is fairly autonomous in working on their project, but we have the common columns for INBOX where a developer can pull any new task, and for 'integration' / 'production' where the team-lead is involved in shepherding the change through the remaining steps.
So my recommendation is to have some common columns (perhaps your backlog and your release) and have some columns that are per developer (like 'in development'). That way each developer can manage what they are working on, and at the same time the board can help visualize the state of all work that is flowing through the pipeline.
The two most important reasons to apply Kanban to a process is to visualize that process and limit work in progress (WIP).
If you have one board per developer it's more of a personal kanban mechanism, and you get to visualize and limit WIP for one person at a time, but no overview at team level.
If you have one board per project or team it depends if there's shared resources, i.e., people working on more than one project or team. If so, you loose some overview and some of the benefits from limiting WIP if you have people working on stuff shown on more than one board. F.ex. bottlenecks are harder to see.
My feeling is that it might be better to use one Kanban board, with all the developer tasks on it, rather then one board per developer. Reason I think this is because the idea is that Kanban is a visual tool for all team members, and if each dev has their own board, then I think it misses the idea a bit.
Subnote
If you're using Microsoft TFS, then you could use use Telerik Work Item Manager. I've used this myself and it's great. Each developer runs a copy of the tool on their PC, and they can view their work items on a visual task board (with colour post-it's). This board can grouped and filtered by various ways, so a developer can see all their own tasks, but then they can change the filter to view all the tasks on the project.
(If you're not using TFS, apologies for the uninteresting subnote :)
Indeed, create at least 2 or 3 teams, affect only one project to each of them and so one board by project. Then an another board to manage projects status.
To resume: One by project with every tasks, one to follow project status it will help the developers and also you to communicate with the managers.
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
For those of you who have implemented Scrum in your organizations, what were your biggest obstacles and if you did overcome them, how?
Background: In 2006 I contracted with a large company which had adopted Scrum cold turkey just months before I arrived. The company hoped Agile/Scrum would save their huge enterprise software product. Of the hundred or more programmers there, I worked closely with a team of about a dozen for a year, observing and participating in their Agile experiment.
Summary: I believe Agile helped more than it hurt. By the end of the year, the team could consistently estimate and produce features, whereas previously their productivity was rather erratic.
Implementation: Since this was a large organization and a large product, the project ran as a "scrum of scrums." There was one scrum master for about every 15-20 developers and these teams were often divided into smaller, closely working scrums of about 6-8 people for an iteration. Teams were largely independent, could adjust their own iteration frequency (1 month down to 1 week) and were given lots of flexibility to implement agile as they saw best. The company regularly brought in Agile coaches (such as Object Mentor) to help train the scrum masters, teams, and management.
Obstacles: Plenty. Some of them related to Agile, some not. In no particular order, here are some lessons learned:
The product backlog was revised way too often in the beginning. Eventually, the team and management took several days to go over all the features, estimate them, and prioritize them. It was a big hit, but it helped tremendously. Lesson learned: get your product backlog in order early and keep it maintained. Product owners must have a clear idea of what they want.
We lost time experimenting and dealing with fads and hype. When you start, you have no way of knowing if you're doing things correctly. There's temptation to constantly fiddle with the agile process taking the focus away from the product. Lesson learned: having an experienced Agile coach does help reduce this learning curve. There should always be someone pushing back on any experimentation. Limit the number of "spikes".
A good scrum master is invaluable. Certainly in the beginning, it's a full-time position.
It takes time. It took several months before the team started to be comfortable with the process.
Pick your battles. Some programmers will be understandably skeptical and others will outright dislike and flight the change. Allow for some flexibility. For example, enforce the use of a product backlog and iteration schedule, but don't require everyone use note cards. Be particularly sensitive to introducing tools and programming methodologies such as pair programming or test first development.
Finally, keep communication open and manage expectations.
Good luck!
While working as a Delphi developer a few years ago, I managed to get Scrum adopted by my development team for a time.
The whole process worked very well for us - having the team estimate prioritized tasks on a backlog gave us meaningful timeframes to target, and the whole "Managements job is to remove impediments" was great.
The biggest problem was that the process was always perceived - and referred to - as "Bevan's good idea".
While the team appreciated the value we gained, and were happy to continue with Scrum, the Team didn't take the scrum methodology on board as their own. After a while, I got tired of "pushing" and we "fell out" of following the Scrum approach.
Lesson: Make sure the team takes Scrum on board and owns the approach.
We do mostly scrum projects at the customer site. Hardest part in my experience is finding a good product owner in the customer organization:
Too many people think they should be the product owner,
The product owner has a hard time following the pace of the team
Product owner has a hard time getting all the detailed information the team needs
Moving items down the product backlog to add something with a higher priority is difficult
etc.
Training internal teams to use scrums is doable, bringing in your own scrum master is doable, but a good product owner should be part of the client organization. It's harder to train this external person.
Having a proxy product owner, who works together with the customer product owner does help a lot.
I moved from a company that adopted Agile to the tee to another company which follows the traditional methodologies.
Perhaps the biggest difference I have seen is that the second company struggles to prioritize. There is so much work on each person's plate that they fail to deliver on time. IMO, Agile brings about some transparency to the situation and lets the team as a whole prioritize.
A scrum master in the Agile world would take care of fire-fighting and be the voice of the (sprint) team. In fact, in the first company (where we had a separate scrum master and program manager), the scrum master would fight it out with the program manager when the latter makes false promises to the management. Meaning, the scrum master knows how much a team can produce/deliver after a few sprints, which helps her nail down on the predictability of a team.
I also noticed that the R&D resources have a sense of accomplishment at the end of each cycle, and are looking forward to the next one. But then, a good project manager could get this done in traditional scenarios as well.
The biggest issue, as already stated, that I too have experienced is the lack of buy in. It is very difficult to get people to truly become vested in the process.
The other issue, which is also one that directly contributes to the above issue, and also in a large part one of the founding causes of Agile is the lack of management to stick to the outlines of the manifesto of Agile.
In Scrum, Lean, or whatever version of Agile you are working with one cannot break from the manifesto points. If a process is being used to break away from those priorities then most likely the management is screwing up and the buy in will fall apart. The manifesto MUST be followed:
Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Some scenarios might be when a gantt chart appears from one of the above processes for whatever reason. Gantt charts can be useful, but if all of a sudden a developer is reviewing a gantt chart with management, the last point is broken. Responding to change has slowed because encouragement of the plan is being favored over change. Instead a board with stickies should be used, simplify what is on the board with only the current working items and back burner items. This makes changes easy. Once anything is solidified in a "tool" it slows responding to changes. Sure, management needs to record and track things in some ways, but pushing that onto development only slows the responding to change, and pushing tools onto developers (unless they want them for development and can utilize them appropriately) messes up the first point, of the individuals over tools and process.
In another way, don't stop development for the purpose of writing comprehensive documentation. Unless you only have a single developer, then someone should take the documentation load autonomously from the development role. Pushing these things together drastically slows development and for periods of time, can shut down any effort to actually get working software.
The last point, is to always, ALWAYS stay in contact in some way with the customer or prospective customer. Talk to them regularly about what they want. Talk to them daily and show them as much as you can of UI, or even data flow work. Anything that they would understand they should see. Talk to them, educate them about the architecture and ideas going into the application and never forget that you are building the application for them.
Summary:
Biggest issue is buy in. Second is management sticking to the manifesto guidelines.
If you can mitigate these two risks, you should be good to go. Anything else is cakewalk after getting buy in and getting management to understand that they'll need to be truly strong, and non-micro management managers. Specifically, managers might even need to become leads, or fill a different style of role.
...hope I didn't stray off point too much. :)
I have been running Scrum in several projects. The biggest problem, as I see it, is that not everybody in the organization is into the process. Everybody needs to be committed. Not only the team of developers. Often the managers are the persons that initialize the process and expect that things will change to the better without them doing anything.
My suggestion is that you run a workshop with the whole organization so everybody knows how the process works. Not only the developers. It's essential that you have a person that is really into the process. A person that can answer questions the team and organization have. A mentor.
Being agile is about welcoming change. You should not let the process gets in the way of sense. Do things that works for your organization, but you should try out the whole process before throwing something out.
We implemented Agile (set of SCRUM - management and XP - engineering practice) in an environment that was waterfall with large projects in an environment that was heavily integrated. The waterfall police were everywhere. As you can imagine, many projects failed. Having done Agile at a previous employer, we received permission to trial agile for the project.
Internal to the team, we used the Agile practice. Externally, we wrapped the agile practices with waterfall processes meaning primarily reporting. Thus, we looked from the outside like a waterfall project. However, there was a big difference, internally we were using agile and consequently we delivered, on time, within budget with high quality.
The critical success factors were embedded coaches (Iteration Manager Coach, Dev Lead Coach, Test Lead Coach and a Solution Analyst Coach). Securing commitment from dependent system in advance (required that we look ahead to identify depend systems and the work required from those systems) was a must in a heavily integrated environment. Prior to starting, we immersed the technical and business members of the team in an agile boot camp. This ensured that the key players (product owner and technical team) knew there roles and could execute effectively. Finally, the wrapping of the project with waterfall reporting enabled us to tie into all the existing reporting structure in the enterprise.
The net result is that the company is now moving waterfall projects to agile. This is all possible only because we have been able to deliver high quality software at a sustainable pace.
Where I work has been using Scrum for a while now but it seems to have gone through a few phases. In terms of obstacles, one part is to prevent putting in too much change at once and just introduce things slowly,e.g. put in a daily standup one week, a couple weeks later put in a story board, a couple weeks later bring in pair programming. This allows for the various tweaks that will happen to work and if the changes improve things then this can help build up some good momentum. Another point is to make sure that if there should be changes in how something is done that the person being corrected isn't belittled or mocked. At times this may mean that you interrupt someone or that you bring in a "Can we get back to basics?" or something similar to try to put things back on track rather than just yelling at someone or doing something else that is counterproductive.
Bringing in consultants was one of the best things done around here, IMO. Now, these guys came in to help evolve how development was done here. Bringing in pair programming, TDD, concepts like broken windows, organizing project folders, and bringing in mocking for tests, were all excellent additions that while we may have gotten there on our own, it may have taken a long time which wouldn't work out so well.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
We are an all Unix shop (Solaris, Linux). This last product cycle I returned to a project lead capacity, and needed to produce a schedule. I asked what tools my managers would accept, and was surprised to hear "text files". My teammate and I gamely tried this, and probably worse, HTML tables, to track the tasks we wanted to size. It was pretty painful.
We then tried a few tools. MrProject is buggy, limited and crashes too frequently. My manager swears that Microsoft Project is inflexible. Whenever they needed to change a task, reassign a resource or rebalance, it generally hosed their plan. So I started looking around on the Internet for a Linux-capable project planning tool. One that sounded interesting is TaskJuggler. It's neat in that the inputs are declarative files. I feel like I'm building a makefile for a project.
However. I have a limited amount of time to devote to evaluating this tool and it seems pretty complex. Before diving into the next product cycle, I'd like to know if TaskJuggler is robust enough, flexible and capable of handling multi-month, multiple resource projects with frequent changes. So I'm calling on all engineers who have had experience with this tool to share their insights. Thanks!
There is nothing free in project management, and managing a complex project with software is inevitably complex. The real question is, does the chosen tool help with this?
Task Juggler has a learning curve, and in the end is suitable for someone who doesn't mind reading the manual (an absolute necessity for this tool) and isn't tied to graphical input. Task Juggler requires that you think about your project and structure it in a meaningful way. It is helpful if you do a diagram in advance (many TJ users make mind maps and there is a tool out there somewhere to generate TJ input statements from a FreeMind mind map). It is also very helpful if you organize your input file in some meaningful way, making things easy to find.
That said, once you get going, creating a project with TJ is super fast. You don't need to bother with a million dialog boxes, you just tell TJ what you want in TJ's text language.
But all of that aside, what I like about TJ (and hated at first, coming from a legacy of other more traditional tools) is that it ensures that your schedule makes sense. OpenProj happily schedules resources at 300% and more. TJ will give you an error and make you fix it. Yes, it's annoying. But the end result is that you have a project schedule that makes sense and can actually be executed. Imagine that!
As I started out by saying, nothing's free. TJ requires study and some effort. The reward is rich and copious reporting, all the information you need to manage your project to cost and schedule, and the enforcement of a logical, reliable approach to scheduling and resource allocation. And it doesn't cost $499 or whatever MSP goes for --- it's free.
I have been using taskjuggler for the past 4/5 years now (4 projects with an average duration of a year or more). I find it very useful to create my initial estimates of
how long the project will take
When will each resource group be freed.
What if we added more resources with varying level of experience and efficiency to different domains of the project.
Typically the kind of stuff that upper management will ask you about your schedule can be generated much faster and at a more accurate granularity compared to doing something similar using MS Project or other GUI based tools.
Till recently I was using taskjuggler to get my initial schedule and using ms excel to track the project.
This is the first time I am using task juggler to actually track the project on a weekly basis. and so far the results look good.
TaskJuggler's syntax is rather easy, but do take your time to read the documentation.
My experience with TJ:
very powerful and expressive syntax
useful for detailed calculation of large projects
However in reality a manual planning takes into account many implicit constraints, which TJ requires to be made explicit in order to obtain realistic scenario's. This is of course true for every planning tool, but I found it rather cumbersome to add and edit manual constraints in large projects in TJ... Therefore I found it less suited for project tracking and rescheduling afterwards.
I now use OmniPlanner, which is a far simpler tool than TJ and MSProject but turns out to suit my needs (especially in tracking, analysis and reporting).
I am using Taskjuggler to develop a very detailed task manager for big movie productions. It's brilliant cause of it's syntax and csv outputs.
I have been using it for 1w and love it.
The acceptance test, so to speak, is if you find text/coding more expressive than UI based input.
If you do feel comfortable expressing your thinking in a structured language but prefer/expect UI then do not spend time with TaskJuggler.
See http://www.pegasoft.ca/coder/coder_july_2008.html for these remarks like
"Don't expect a nice user interface with an "Add Task" button here."
"Even reports must be designed in it's awkward, C-like language"
If that is how you think then do not spend time with TaskJuggler.
TaskJuggler is (almost) a DSL for planning.
If you do not know what a DSL is then do not spend time with TaskJuggler.
Or learn about DSLs. :-)
For the rest, try it because it might just put planning in your own hands and take it away from the hands of people who demand it from you only to ask for status.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
There's not a lot to add to the subject really.
I am after a free task board/ burndown reporting tool for Windows.
If you're willing to host your tool,
TargetProcess
(http://www.targetprocess.com/)
XPlanner(http://xplanner.codehaus.org/)
If not,
Pivotal Tracker (http://www.pivotaltracker.com/)
ScrumWorks (http://danube.com/scrumworks/basic)
All are either free or have a free version.
Depending on your real needs, solutions range from :
hand-written cards complemented with a manually drawn burndown chart as big visible chart as recommend by Ilja
spreadsheet-based list with automatic burndown graph generation (example)
online tools such as scrumy, scrumpad and skinnyboard
local application with web access
free ScrumWorks basic, Icescrum2
or commercial ScrumWorks Pro ProjectCards, or, as Eliza recommended, TargetProcess
Remember however the Agile manifesto is recommending to favor "Individuals and interactions over processes and tools".
I'd recommend starting small, perhaps with a spreadsheet if you insist on automatic burndown charting.
Check out SeeNowDo at www.seenowdo.com
It's a free online taskboard for distributed Agile teams. It's pretty cool and provides convenient features like 'always-on' and 'instant-sync' capability. It also has some cool ways of managing the taskboard layout once you have alot of tasks on it. Best of all, it's completely free.
Apparently I got to disclose I built this product
You might want to try: http://www.burndown-charts.com
It's a free webapp for managing burndown charts. You create a team and a sprint and you are ready to go. Enter your tasks once they are done. Perfect for when you still want to keep a board and/or post-its. You can add teammates to your team if you need.
You're not going to spend an hour figuring out how to use it.
That is exactly what Scrumy.com is. It is a whiteboard with sticky notes. The pro version has a burndown.
Try Mingle. It is free for upto 5 users.
Open Source app: http://taskboard.cognifide.com/
Fast, tidy tool :)
EDIT
Ok, we are working on something that does just what you asked and way more:
Actionable metrics
Powerful analytics
All this on a slick Dashboard
It's meant to eliminate the use of excel sheets to build your own reports by hand.
It's a far better solution and it is in beta right now.
Sign up and participate in the beta to make sure your features are well covered!
http://www.in-sight.io
Well, without knowing more about your situation, I have to highly recommend a wall of index cards and a handdrawn chart on flip chart paper. Works much better than any software in the standard situation.
If you really have to use software, there is none that I could recommend unreservedly, let alone a free one. You might want to keep in mind that some of the commercial ones are free for open source or academic projects, too. Which one's right for you will depend, besides other things, on how much you want it to define your process.
You might consider creating your own solution using a spreadsheet.
That way you get low overhead on data entry and as much reporting capabilities as you want, without having an external tool define your process.
Especially on single-person projects (as this appears to be from the comment on Ilja Preuß's answer), I find that a simple spreadsheet actually works better for me.
I keep all my tasks in one workbook, and the formulas that pull out interesting data and calculations in a separate workbook.
I made a basic plugin that can be inserted in google wave and be used as a taskboard. More details in http://agilebooknote.blogspot.com/2009/11/taskboardy-available.html.
Cheers,
-fede
I'm a fan of google docs because of the simplicity and also because I can give access to my team so that they can update their tasks on a daily basis. The template I use and a tutorial on how to use it is available at
Burn Down Chart Tutorial: Simple Agile Project Tracking
I know this is old thread, but I came across this question looking for something similar. I signed up for AgileZen (http://www.agilezen.com/) and it's actually quite good.
I wanted something free that my wife and I could use for personal/home stuff. It's free if you're willing to have only one project (I call it "Home") and one other collaborator (my wife). It's a pretty good solution for us.
I promise I have no affiliation with them! Except that I now use their product.
If your project is open source, non-profit or a classroom you can get free access to Atlassians' JIRA + Greenhopper (and other tools) for agile project management. Otherwise small teams can get access for a nominal fee.
see http://www.atlassian.com/software/greenhopper/overview and http://www.atlassian.com/software/jira/overview.
See http://www.atlassian.com/software/views/open-source-license-request if your an open source project.
http://www.atlassian.com/software/views/community-license-request if you are a non-profit
and
http://www.atlassian.com/survey/classroom-license-request if your a classroom.