http://www.bosstalks.com/ BossTalks.com Tag: agile en Wed, 08 Sep 2010 00:25:04 +0000 http://www.bosstalks.com/topic/46#post-2127 Thu, 01 Jul 2010 01:43:18 +0000 jkeppens 2127@http://www.bosstalks.com/ <p>Scrum doesn't need a Project Manager. In the projects I worked with, we typically give the Product Owner role to the PMs. It works fine as long as the PM takes onboard the responsibilities and limitations that come with the role.</p> <p>1. he is the owner of the product back log. Basically he communicates to business and creates the user stories and adds them to the backlog. He is in charge of deciding what priority each item on the back log has. This means basically he is in a effect in charge of planning and deciding what features are developed when. (initial estimations are done with the dev team at projects I work with. We estimate in complexity points, which means you estimate how much work something is compared to another task you did. The PO then puts a time on this).</p> <p>2. the product owner calculates each sprint what the available complexity points are for the team. This is done taking holidays, vacation, etc... in mind. Based on this calculated number, he makes a prioritized list of backlog items he would like done in the sprint. This is discussed with the team during the first part of the sprint meeting (at the start of the sprint). In the second part of our sprint meeting (we call it the technical sprint), our dev team typically does small analysis of the stories and divides them in tasks. We then estimate the tasks and if needed we split the tasks further (task max 2 working days or 13h actual work). Based on this we couple back to the PO what the real estimates are and he can decide to add a story or remove a story if needed. Very important: never overcommit! it doesn't work!</p> <p>3. during the sprint, the team has their daily scrum meetings. All problems and questions that arise are relayed back to the PO by the Scrum Master. The PO is then responsible for providing answers on the questions. In our company we also relay things such as "we need 2 extra servers" to the PO and he talks to the responsible departments for it. </p> <p>4. If for some reason extra important features are required, the PO has the possibility to halt the sprint and start a new sprint. This is an exceptional situation and should be used with care. Never start messing with the content of your sprint mid sprint: emergency break + new sprint.</p> <p>Earlier I said that the PM should also take on the limitations of the PO role to make it work. With this I mean that:</p> <p>1. he should stay away from the team as much as possible mid sprint. Asking "is it done?" a million times leads to frustration. If developers can concentrate for a longer period of time, you loose momentum and your velocity drops. If there are issues, the SM will inform the PO. You need a good SM that dares to say NO to the PO btw. An SM that always says "yes", will lead to contra-productive situations.</p> <p>2. he should not try to (micro-)manage the project or play boss. Scrum leads to self-managing teams. It works quite fine. Interaction in the team is very important and a good mix between junior and senior members where the juniors receive coaching by the seniors is needed.</p> <p>3. if working with a burndown chart, keep it away from your PO, unless he knows how to interprete it. A burndown chart is not rocket science and it surely isn't a straight line down. If the PO starts panicking when you are above the most ideal line (especially in Greenhopper where it's a straight line down, while it's actually a curved line with slow slope in the beginning and steeper at the end), it will lead to frustration, annoyance and mockery. </p> <p>With kind regards,</p> <p>Jeroen </p> (read more) http://www.bosstalks.com/topic/46#post-202 Tue, 09 Dec 2008 04:43:37 +0000 annasmith 202@http://www.bosstalks.com/ <p>I have found a software which Shares Microsoft Project schedules with team. Includes Project Portfolio Management, Issue Tracking, Risk Management, Timesheet Management, Document Management, Calendar Management, Forums, Reports and Project Dashboard.</p> <p>A good hosted Project Management software that suits my EPM needs is called valleyspeak project server, which I found at <a href="http://www.valleyspeak.com." rel="nofollow">http://www.valleyspeak.com.</a> One of the main reasons why I like the software is the fact that I could continue to work in Microsoft Project 2007 while sharing my Microsoft Project plans with my teams.</p> <p>ValleySpeak Project Server provides 100% 2-way integration with Microsoft Project 2007. While Project Managers can continue to plan and manage projects using Microsoft Project 2007 as usual, Team Members can now view and submit updates to the project plans in real time, simply by using any web browser.</p> <p>Because it is a hosted service, I did not have to buy expensive software or deal with installation and maintenance headaches. The functionality that I have with valleyspeak to manage my geographically dispersed teams works well for me. We also evaluated Basecamp and some other solutions but were not impressed. </p> (read more) http://www.bosstalks.com/topic/57#post-136 Wed, 28 Mar 2007 19:16:34 +0000 white 136@http://www.bosstalks.com/ <p>I've heard guys still doing development in PHP, Perl and even Lisp, however, I really have no clue how could the Web development be made on Lisp. </p> (read more) http://www.bosstalks.com/topic/57#post-135 Wed, 28 Mar 2007 19:08:20 +0000 white 135@http://www.bosstalks.com/ <p>I've heard guys still doing development in PHP, Perl and even Lisp, however, I really have no clue how could the Web development be made on Lisp. </p> (read more) http://www.bosstalks.com/topic/57#post-133 Wed, 28 Mar 2007 16:23:40 +0000 green 133@http://www.bosstalks.com/ <p>Hi,</p> <p>I've been talking with different people (especially during this <a href="http://www.bosstalks.com/topic/52">Startup School</a>, and especially with people which are doing their own startups) about how they are doing Web development "agile-way", and most of them were mentioning <a href="http://rubyonrails.com/">Ruby on Rails</a>. Almost everybody, frankly speaking. Once or twice I heard <a href="http://www.php.net">PHP</a>, but that's it. Couple of people mentioned <a href="http://www.springframework.org/">Java with Spring</a>. I personally really enjoy Java with Spring. No any freaking "hard-heavy-mutants", just plain JDBC and Spring. That <em>is</em> Agile. But why Ruby that much? My experience with it is weak, but I see it to be much interesting than PHP. But Java with Spring is a neat tool, really nice and easy at the same time. Flexible also, I should say. So why Ruby? Because it's the only alternative which is not "big" like C/C++/Java? Any thoughts? </p> (read more) http://www.bosstalks.com/topic/46#post-112 Sat, 24 Mar 2007 17:30:36 +0000 andy 112@http://www.bosstalks.com/ <p>Sorry, but software development does not need management. You need management for the company and its employees but not to develop software<br /> First: Team Spirit: team spirit is built by developing great software, challanging tasks and good working environment. I start to gag when people talk about how to motivate developers. If you need to get drunk then go together to a bar and drink beer.<br /> Second: Conflicting Situation: normally the business drives that and IMHO senior developer should be able to find a solution if the conflict is technical nature otherwise fire them. Any Senior Developer who thinks that his way is the only way is not Senior at all. Unfortunately there are many developers out there who think they are Senior but which aren't.<br /> Third: People Management: many projects are composed of many developers and in bigger companies their are coming from different departments are so they are not managed by the PM or Scrum Master. In my opinion the developers' manager should not be part of the project and if the company is quite small then it someone from the upper management anyhow which are most likely not involved in the project.</p> <p>Just look at JBoss, Apache or Linux where the is no people management made within the project and they still drive. Of course, that is only true for the development side of the projects. </p> (read more) http://www.bosstalks.com/topic/46#post-111 Fri, 23 Mar 2007 17:37:20 +0000 white 111@http://www.bosstalks.com/ <p>Well, so who is expected to manage people if not PM? I know that Scrum people call it Scrum Master, who's defined as a mentor and the one who is responsible for making decisions. However, people management as an essential part of any project and somebody has got to be responsible for this, too. </p> (read more) http://www.bosstalks.com/topic/46#post-110 Fri, 23 Mar 2007 17:36:02 +0000 green 110@http://www.bosstalks.com/ <p>Guys, let's imagine the following team - 2 senior developers, 4 developers, 1 junior developer. They are working on same project. Who lead be accountable for the project progress? Who will be responsible? Who will make decisions in conflicting situations? Who will be able to manage people and build team spirit? Andy, it's not <strong>one</strong> senior developer (who really can be project manager at the same time), but <strong>two</strong>.<br /> I agree to stop giving names. But one person in a team has to be <em>main</em>, <em>very senior</em> -- you name it. But he will be moving the project forward.</p> <p>Loose management sucks. It's better no management at all. But sometimes no management can screw up best team, best project and best idea. </p> (read more) http://www.bosstalks.com/topic/46#post-109 Fri, 23 Mar 2007 08:47:38 +0000 andy 109@http://www.bosstalks.com/ <p>I think that the PM normally does not manage people but the project. A PM is only necessary and crucial when the developers need a manager because they are not experienced enough. Any senior developer can manage himself and knows best what to do and how. I don't think the PM role should be rotated but the project should be split up into sub projects where someone is leading it. This also could mean that two developers share this position. I also don't like the process for the sake of the process. Scrum does not work because you like it but because the company is living it. If you forgot about the process you will find that the Scrum process if used in open-source projects quite a lot..</p> <p>Well, today a lot of the software we are using are open-source software and therefore are commercialist by some means. The nature of open-source projects shapes the development team quite a lot but because it works so good maybe companies should try to adopt it. A few key features of open-source is that is have some strong technical leaders or visionaries, the developers are all senior or at least have the drive to become one and they all work in a very losely coupled team where management is done through motivation rather than authority.</p> <p>-Andy </p> (read more) http://www.bosstalks.com/topic/46#post-108 Thu, 22 Mar 2007 16:00:27 +0000 white 108@http://www.bosstalks.com/ <p>By the way, the open source product is not a commercial product, and vice-versa. I believe that at some point there is a very significant difference, especially concerning the <strong>people</strong> management. </p> (read more) http://www.bosstalks.com/topic/46#post-107 Thu, 22 Mar 2007 15:59:11 +0000 white 107@http://www.bosstalks.com/ <p>I really into your point, especially after several hours trying to find people with sucessfull projects managed with the pure Scrum. :) And the only one reason I was doing this because few days ago I had a conversation with the guy, who was completely Scrumified and devoted to it, and he wanted to share his excitement about this with all people around.</p> <p>Speaking about PM as a position, you are very right, but my main concern was about how people can rotate the PM <strong>role</strong> between each other in the Scrum process? Being a good developer doesn't mean that you can manage either people or process. And my concern is that giving the PM role to a wrong person can at least slow down the whole development process, but in the worsiest case it can put it on the wrong track which leads to failure. </p> (read more) http://www.bosstalks.com/topic/46#post-106 Thu, 22 Mar 2007 15:45:42 +0000 andy 106@http://www.bosstalks.com/ <p>Well, if you have a look into open-source, like it did working for JBoss, you will see there is no boss. Some a leading a project but mostly due to their knowledge and contributions. So working where there is no PM is not difficult.<br /> I also worked for companies where I was having more influence that the PM just because of sheer number of contributions and in-depth knowledge.</p> <p>On another note a PM does not make sense in a Software Project whatsoever because he/she is most of the time not the developers boss because they do not have the authority to approve vacations, leave time, promotions etc. The idea, as far as I know, of the PM is to have a single go to person that leads the project and not the developers. But that is quite tricky if your developers know more than you are, what they should, and they don't want to go through the PM to discuss or design the project with other members of the team.</p> <p>Finally I never saw Scrum really fly. The bigger companies screw it up quite easily and smaller companies don't need it because their customers are driving their business and so planning is not that important. In open-source I never saw it either because planning resources it fairly futile because they contribute or they don't.</p> <p>-Andy </p> (read more) http://www.bosstalks.com/topic/46#post-101 Mon, 19 Mar 2007 21:03:04 +0000 white 101@http://www.bosstalks.com/ <p>I know there are some people in this forum who are familiar with the Scrum methodology of software development process. Personally, I never had experience with it, but during passing through different iterative strategies, I was pretty surprised with one of Scrum's point, what is the missed position of Project Manager in its life-cycle. Yes, the PM position is really missed in it, however, not the role. According to Scrum ideology, the team consists of even members, each of them are driven with the same goal and experienced enough to share one PM role from time to time. </p> <p>Well, keeping in mind the Scrum is taken from the rugby term, which is also has connections with the chaos model, that explains a lot. However, having no PM in the team sounds weird to me. Sharing PM's role between each other sounds even more weird. I just can't understand the process. Who's the boss then? Who chooses the person, who will play PM next round? What if the chosen person sucks as PM badly, but still a good team member; is he about leaving a team or he'll still be engaged in the PM role rotation?</p> <p>From the other hand, I heard a different opinion that the PM position still exists in Scrum strategy, but they call it Scrum master, like a coach in a sport team; however, his role is still supposed to have an indirect authority, rather then direct boss. Although, Scrum master is required to make decisions.</p> <p>I'm totally lost now and I'd like to hear something back from Scrum-guys. I hope you can help me out.</p> <p>Speaking about other question, had anyone see a successful Scrum implementation in the medium to large teams, or is it all about small ones? </p> <p>Thanks. </p> (read more) http://www.bosstalks.com/topic/9#post-98 Sun, 18 Mar 2007 15:37:57 +0000 white 98@http://www.bosstalks.com/ <p>Well, I never spoke about the silver bullet. Also, it's strange why you can't understand the benefits of 24x7 development cycle. If the company delivers a product and it wants to increase a productivity, 24x7 development cycle is a key factor to do this. By incorporating several-timezones development cycle you can deliver product at least 2 times faster.</p> <p>Speaking about problems in intergration like you mentioned (when one team produces an error which stops other team from continue work) these problems should be solved the same way like you solve other problems in your company. First, it' depends on clearely stated development cycle and last, but not least, it is a test-driven development that will keep you safe. </p> (read more) http://www.bosstalks.com/topic/9#post-96 Sun, 18 Mar 2007 14:32:49 +0000 melan 96@http://www.bosstalks.com/ <p>Practically I don't see any reasons to have 24x7 development cycle for regular software development. The approach is OK for support teams which produces some kind of hot fixes. I can ground my assertion.<br /> First of all the approach makes life of project manager (coordinator) extremely hard because the guy should be available for the developers any time. From the other side you may hire 2 or 3 PMs. It the case we have problems with the managers' team coordination and responsibilities.<br /> Also you need to make very detailed project documentation (design, requirements and etc.) for such kind of teams.<br /> You may say that we may hire testers, developers and CM team from different time zones and in the case testers will have hot versions of the product at the beginning of their working time and developers will have new bugs in the morning of the next day.<br /> It is really great assumption but in the case we have new problems again. For example CM team can't compile new version of the project because of some unfortunate misprint in code. What should they do? Should they awake developers to fix the misprint or they should not do anything? Another problem is the long term testing sessions.<br /> I'm sure any schema of distributed development process should be weighted and assessed in details.<br /> Because there is no silver bullet in Software development. </p> (read more) http://www.bosstalks.com/topic/9#post-94 Sat, 17 Mar 2007 18:30:23 +0000 white 94@http://www.bosstalks.com/ <p>What you see as the worst case scenario (several developers, spreading over different time zones) is an actual world scenario and one of the most possible future where outsourcing leads to. Nowadays, too much companies are seeing outsourcing's main benefit is ability to build 24x7 development cycle, switching from each time zone during the work day (and night). </p> (read more) http://www.bosstalks.com/topic/9#post-91 Sat, 17 Mar 2007 15:34:24 +0000 melan 91@http://www.bosstalks.com/ <p>According to my experience there are several schemes of cooperation with remote teams (I'm not talking about remote employees):<br /> - You have only sales and customers support departments in your head office:<br /> In the case you need to have well organized remote team that can execute all the required activities through software development life cycle . And you only share requirements, clients features requires, bugs and your recommendations about future scopes. All the other work is the team responsibilities.<br /> What do the risks of the approach? Bad work of any office is the main risk. But you don't need meetings often and so on because each group has own sphere of responsibility.<br /> As for me the schema is the best. Because your managers near their teams.<br /> - You have all the departments mentioned above + planning, product specialists and high level architects in your head office and all the other tasks are covered by remote employees.<br /> In the case you need more communications between offices but both the offices work independently the most of time. Risks are the same. The approach allow you take you hand on project's pulse.<br /> - You have distributed development team (some developers are located in the head office and some are located in the remote one).<br /> The worst approach. The first problem is that your developers need to spend a lot of time for communications. The second issue is that you have two managers: one in the head office and the second is in the remote office. You will never know how is responsible for the project's fails (Responsible for the problem is another leader :-) )</p> <p>So I see next keystones that are important for successful utilization of remote dev. team:<br /> - You should delegate as more independent parts of project as possible. To exclude unnecessary communications.<br /> - You should be familiar with remote leaders/managers. In the other case you will be only e-mail address for the remote team but not a man.<br /> - You should provide detailed documentation for the project to the remote team. You know more about the project then the remote team and they need as more information as possible.<br /> - You should participate in few first iterations of the project's development. The participation will allow to share your knowledge with the remote team and establish interpersonal communications with the remote team members </p> (read more) http://www.bosstalks.com/topic/9#post-81 Thu, 15 Mar 2007 12:06:42 +0000 white 81@http://www.bosstalks.com/ <p>Twice a year travels for the whole team? You've got to be kidding... Who's gonna work then? </p> (read more) http://www.bosstalks.com/topic/9#post-80 Thu, 15 Mar 2007 10:41:32 +0000 ayurov 80@http://www.bosstalks.com/ <p>As I know there is only one possible solution: great team leader inside the remote<code> strong</code>team<code>strong</code>, team building actions and regular (twice a year) travels. </p> (read more) http://www.bosstalks.com/topic/9#post-79 Thu, 15 Mar 2007 09:41:33 +0000 green 79@http://www.bosstalks.com/ <p>sir,</p> <p><em></p> <blockquote><p>..but, what will also help is having a coach on the team's side that will facilitate them meeting their goals by removing the impediments on their way. </p></blockquote> <p></em></p> <p>this is the best way out, the most proven to work, but impossible. our developers are just too far from each other.</p> <p>as for the development - you are right, and iterative development is usually an answer in outsourced software development; however, even if it does help minimizing risks of such development, it does not help with team control and supervising. with iterative development you just can be sure that if some of developers will screw you up, it woudn't affect whole huge piece of project.</p> <p>but thank you. your notes are helpful - hopefully also this discussion can help other people to consider agile development from the very beginning, if they are just thinking on starting outsource development. </p> (read more)