tag:blogger.com,1999:blog-1697388841986104302.post7959438141180885209..comments2023-07-02T10:36:44.294-05:00Comments on Agile in a Flash: The Only Agile Tools You'll Ever NeedAgileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-1697388841986104302.post-71943951640968554122010-11-04T14:17:39.250-05:002010-11-04T14:17:39.250-05:00That's a reasonable number of _groomed_ storie...That's a reasonable number of _groomed_ stories. It doesn't hurt anything to keep lists and all. I don't want to cramp anyone's style, but for managing the work it's all about the art of immediacy.<br /><br />I worry when we're looking further into the future than we can reasonably predict. What will we be doing in 8 months? What will the priorities be in 4? What will the customers really want once we've delivered the first 1/3 of the system? <br /><br />So grooming stories (adding details, tests, acceptance criteria, etc) for distant dates and features a year out is waste, though thinking about the future is a good exercise.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-43168608348880272602010-10-29T18:31:40.835-05:002010-10-29T18:31:40.835-05:00Jeff and Tim, thanks for your answers.
They were ...Jeff and Tim, thanks for your answers.<br /><br />They were very clear and useful, I could learn a lot.<br /><br />I am very convinced about agile methodologies since I read about them at university (I am 21) and I got more convinced since I work with them, but I have to encourage myself to follow your advises because you success doing that.<br /><br />>If you have to have a fancy tool to manage >backlog, I suspect your backlog is too large and >too deep. You really only need to have enough >stories in hand for the current iteration, the >coming iteration, and maybe a few you're >grooming for the one after that<br /><br />So, my Product Backlog should have nearly the same number of stories than the sprintBacklog*2, isn't it?. Does it mean that the client must think on the project as a small piece of software since the first sprints instead of think about it as a big software and then trim the project? <br /><br />Thanks.<br />Santiago.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-89597283203105779852010-10-29T08:07:23.244-05:002010-10-29T08:07:23.244-05:00> What I was trying to say is: If you dont have...> What I was trying to say is: If you dont have any <br />> software tool (like notepad, spreadsheets, gdocs, <br />> xplanner or anything you want), how can you manege <br />> (add, delete, and modify stories, mark them as <br />> duplicate, show them to the product owner, let him <br />> add new functionalities) your product and sprint <br />> backlog?<br /><br />It sounds like you could do all of those things via index cards. You can delete (throw away), add (add), show, modify (rewrite), and stack them up in piles for backlog. I'm not sure why you would need software for that.<br /><br />Now, there are tools that are neither agile nor non-agile, and those might include some kind of bug tracker (my employer uses jira), CI tools (hudson, cc, etc), and email, and production logging, etc. Anyone with half a brain has a good version control system (we like git). <br /><br />For tracking details, you should have your ATs. You can do a lot of backlog grooming by writing acceptance tests. They really are executable specification and executable documentation. <br /><br />If you have to have a fancy tool to manage backlog, I suspect your backlog is too large and too deep. You really only need to have enough stories in hand for the current iteration, the coming iteration, and maybe a few you're grooming for the one after that. <br /><br />As jeff says, being distributed hurts. We are in the midst of the "distributed agile" experiment, which works far better than we had expected but still has a obvious downside.<br /><br />But when someone asks "how do we manage hundreds of stories in the backlog", the answer is generally "don't have hundreds of stories in the backlog." When the question is "how do we get more detail on the cards" the answer is "don't put details on the cards, put them in tests."<br /><br />As a result, most of the need for tools is from having too much work in progress and too much of a big design done up-front. Neither is agile, nor lean. I think it is better for a team to wean themselves off of troublesome practices instead of devising electronic systems to enshrine them.<br /><br />Your mileage may vary, of course, and I'm willing to be convinced otherwise. <br /><br />TimAgileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-56606824277649369242010-10-28T17:00:55.834-05:002010-10-28T17:00:55.834-05:00The best tool we've seen in common use was a c...The best tool we've seen in common use was a cork board with story cards attached and a set of simple rules behind it. As far as control, generally the customer or proxy (often a project manager) decides what goes onto or off of the board. If everyone is in the same room, the state of the sprint and the status of each story is always clear.<br /><br />Behind the scenes, the customer can (and almost always will) still choose to manage a project/product backlog. He or she can maintain this list on index cards, in a spreadsheet, or whatever, and choose to broadcast it or not (via google docs, email, etc). The point is that the team only controls movement of story cards (i.e. updating of their status) within the sprint. They do not update the backlog directly--that's a customer's job.<br /><br />[If your team is unfortunately deriving and controlling its own stories, then you'll need something to manage the backlog--as before, as simple Google spreadsheet will suffice. Give your product owner access to this. If you are worried about people corrupting the integrity of it, Google docs allows you to set read vs write access. But you then really have a bigger problem that access rights in a tool will only mask. ]<br /><br />A story board is not effective, of course, if your team is distributed. And that's really the primary point of the post. Distributed agile--which is counter to the values system of agile--demands software tools. Agile as intended and designed does not.Jeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-57999515629205287322010-10-28T16:39:03.366-05:002010-10-28T16:39:03.366-05:00What I was trying to say is: If you dont have any ...What I was trying to say is: If you dont have any software tool (like notepad, spreadsheets, gdocs, xplanner or anything you want), how can you manege (add, delete, and modify stories, mark them as duplicate, show them to the product owner, let him add new functionalities) your product and sprint backlog?<br /><br />The point is, Do we ever need a software tool (no matter the power, it can be Notepad or Redmine) or do you recommend some techniques or tips to remember all the product backlog and manege it on an easy way?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-56509147627426367832010-10-28T16:23:59.243-05:002010-10-28T16:23:59.243-05:00I'm not sure what you mean by "control&qu...I'm not sure what you mean by "control" in this context, and what you're trying to prevent or cause to happen. Maybe a little more info and I can help?Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-59392847304896567662010-10-28T16:15:44.076-05:002010-10-28T16:15:44.076-05:00Hi! Nice article, it is very helpful and the comme...Hi! Nice article, it is very helpful and the comments too.<br /><br />I arrived here because Tim Ottinger suggested me this post because I was looking for an agile tool for Scrum, like Xplanner (it had to be Open Source)<br /><br />Perhaps I was not clear (I twitted my question). What I was needing was a tool to control de product backlog and the sprint backlog, because the experience teached me (as a developer on teams) that the team never team will complete all the documentation of the sprint, they just will add/remove stories, complete their board with the sprint backlog and use it as a tool to show to the product owner what they do and that kind of stuff (we dod that every sprint and it work very well).<br /><br />So, I think that it is important metion that because it is very difficult to control the backlogs from an spreadsheet or a simple text editor.<br /><br />Am I wrong?<br /><br />Thanks!<br />SantiagoAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-16829334844526592112010-10-25T10:54:44.176-05:002010-10-25T10:54:44.176-05:00Come see what else has been said along these lines...Come see what else has been said along these lines?<br /><br />http://www.millwardbrown.com/Libraries/MB_Case_Studies_Downloads/MillwardBrown_CaseStudy_Neuroscience.sflb.ashxAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-57981733842335925132010-06-23T10:49:14.377-05:002010-06-23T10:49:14.377-05:00@brad: Absolutely! That's not even agile or ev...@brad: Absolutely! That's not even agile or even software, that's basic development of ANY shared artifacts. It is so foundational, that doing any work without versioning should be considered unprofessional.Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-4141557077693061962010-06-23T10:15:05.572-05:002010-06-23T10:15:05.572-05:00Dont forget version-control in the list of things ...Dont forget version-control in the list of things right after "now that we've said that, you really need ..."Brad Appletonhttps://www.blogger.com/profile/15136106921504315995noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-3099174797180549752010-06-21T09:43:24.273-05:002010-06-21T09:43:24.273-05:00Hi Malapine--
Immediately the concern that comes ...Hi Malapine--<br /><br />Immediately the concern that comes to our mind is the bigger problem of stakeholderS, i.e. plural. One of the most important things is that the customer speak with a single voice. If you have many stakeholders, how are they coming to consensus on what they want and what has priority? Usually if you can solve that problem, the distributed nature of the project isn't quite as problematic. The goal would be to get to a single point of contact for all stakeholders, and have them available (on the phone, I suppose) as much as possible. This proxy would be the one who would need to clarify what the customer is looking for, and to accept what the team has produced.<br /><br />It's a tough problem without them being there.Jeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-87555068161249035712010-06-18T16:18:51.668-05:002010-06-18T16:18:51.668-05:00Any suggestions for what to do if the team is co-l...Any suggestions for what to do if the team is co-located but the stakeholders are remote (distributed across NY, SF, and Japan)?Malapinenoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-45282489739844602202010-06-18T00:25:29.622-05:002010-06-18T00:25:29.622-05:00The first rule of distributed teams is not to have...The first rule of distributed teams is not to have them. The second rule is that if you *must* have distributed teams, remember that latitude hurts but longitude kills. With increasing distance between members, the agile practices fall "like dominoes."<br /><br />Jeff touched on that a bit, above, suggesting that it is better to have a strong team in each location than a crippled team widely scattered across continents and time zones.<br /><br />Tim Gifford and I have conducted a workshop on remote pairing. Again the first rule is "don't." The second rule is "if you must then don't drag down the nonremotes." <br /><br />Our company (Tim G., Jeff, and I work together) has most employees on-site and a few of us oddballs off-site pairing via remote desktop/audio/video software. We remotes pair with on-site people who can ask questions, overhear conversations, view the work board, and keep us up to date.<br /><br />Being able to work from home is an advantage and a disadvantage. I am frankly surprised that it works at all. It does allow GeoLearning to hire people who aren't neighbors, and it allows us to work with a great company that isn't local to us, but it is not without some struggles.<br /><br />Again, first rule is "don't", second rule is "latitude hurts but longitude kills", and the third is "don't drag down those who are close enough to work closely." I'll let you know about the other rules when we make them up.<br /><br />timAgileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-24408752069957662122010-06-18T00:17:57.330-05:002010-06-18T00:17:57.330-05:00Hi Donna--thanks for the inquiry. Both Tim and I w...Hi Donna--thanks for the inquiry. Both Tim and I work distributed and helped teams improve at being distributed. While it's not ideal, you can certainly succeed with distributed team members.<br /><br />To be fair, since we came down hard against conceding agile's strengths, we'll do a card on distributed agile in the future (maybe a month or two out--we're backlogged a bit).<br /><br />Regards,<br />JeffJeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-2262263375508991482010-06-17T18:13:30.616-05:002010-06-17T18:13:30.616-05:00What about DISTRIBUTED TEAMS? Any suggestions th...What about DISTRIBUTED TEAMS? Any suggestions there? thanksDonna Reedhttp://www.agilistapm.comnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-91547574144868673962010-06-17T10:03:17.631-05:002010-06-17T10:03:17.631-05:00We recognize that we should add "build/test s...We recognize that we should add "build/test servers" and "automated acceptance test tools," although that's not the point of the card.<br /><br />This minimal set of tools, BTW, has worked for many teams, including those up to triple the size you suggest. It's worked for organizations with numerous such co-located teams. But as you<br />scale to and beyond that point, you start seeing communication issues. That's a limitation of agile-focused oral tradition, not of the toolset we suggest. As mentioned in the post, it just means you have to make concessions to agile, which means you are moving in the direction of less potential for success (at least if you buy into the precepts of agile itself).<br /><br />Most agile teams can do just fine without an expensive tool. Instead of justifying the use of one, we're suggesting that you should move in the other direction and find ways to eliminate constraint-reinforcing assumptions.Jeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-89160109173445132912010-06-17T06:33:18.919-05:002010-06-17T06:33:18.919-05:00How would you automate your tests? May be this wou...How would you automate your tests? May be this would work for small co-located team of size 5-7 members! <br />I'm not sure you have a scalable set of tools!Shankarnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-78908935891392690312010-06-16T15:45:24.310-05:002010-06-16T15:45:24.310-05:00I guess my brain/heart count, because most people ...I guess my brain/heart count, because most people do think I'm a big tool.Jeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-74313207003196940042010-06-16T15:38:33.044-05:002010-06-16T15:38:33.044-05:00I would add brains and hearts to the listI would add brains and hearts to the listYvesHanoullenoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-24756211139542061232010-06-16T14:35:09.070-05:002010-06-16T14:35:09.070-05:00It is also probably worth noting that we're bo...It is also probably worth noting that we're both remote agile developers right now. We are "virtually" present during work hours, and collaborate like crazy, and we know and expect (practically demand) that we'll be inconvenienced by being remote.Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-31359615426890849452010-06-16T10:59:51.988-05:002010-06-16T10:59:51.988-05:00- coffee and ostensibly mints come under "foo...- coffee and ostensibly mints come under "food"<br />- good refactoring editor comes under "pairing station." In the card that will appear in the book, we indicate that the pairing station comes replete with the best possible tools to create quality code.Jeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-76927181533203373912010-06-16T09:36:21.777-05:002010-06-16T09:36:21.777-05:00Now that we've said that, you really need a go...Now that we've said that, you really need a good refactoring editor and a reliable coffee pot. And breath mints. And a CI computer. But you get the point.Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.com