16

You have three factors: Money Time Requirements If money and time are fixed and requirements can change then you would go after SCRUM. If requirements are fixed then you would go after waterfall.


13

WIP limits are designed to show bottlenecks so management can FIX them. If the limit is being hit in the "Done" area and the upstream guys can still keep going like nothing has happened, management might not know about it because it is no longer obvious. The very act of "stopping work because I hit the limit" is the mechanism that triggers the ...


13

I won't say that it is all about communication, but I think a large portion of the problem you see can be contributed to communications that could be improved. I work in the same field, and I've seen this behavior from many clients in different industries. What took me a long time to understand was that the way I initially present estimates can have a huge ...


11

checking SVN in a daily basis to review codes and to assess how much codes have been committed by each developer is a good way. is it fair and used in industry? The proposed metric is utterly unfair, regrettably is used in some organisations and is in my personal opinion a recipe for disaster. HasaniK and Jakub have already identified some very valid ...


11

First, remember that an estimate is highly unlikely to be 100% correct, so do the best you can with the information that is available to you. Second, break down the tasks as far as you reasonably can, and get figures for similar low level tasks from other projects that have been done in the past. Don't worry if they are not identical, as long as they are ...


11

You shouldn't be allocating story points to cards. The team should estimate the cards and agree on what to pull from the backlog based on their velocity. The team is accountable for making their own forecasts and sprint plans. You telling them what must get done in the next week is neither Agile nor Scrum. You're also likely demotivating your team ...


10

Will the software ever change after its first release? Waterfall is for building bridges and houses -- physical, rigid things that you don't expect to change much over time. Agile and Iterative approaches fit naturally with software development and its fluidity. You should expect and embrace change. I understand not everyone agrees with this, but using a ...


9

I was taught a great game that really stressed this concept. It's the paper airplane production game. What it brutally shows is waste when something unexpected happens. Say you're building five airplanes for a customer. Let's look at two scenarios. In both cases you are paid as each airplane is produced. Once a plane goes to the customer you get paid for ...


9

Have you considered a Squad system? The always-excellent Henrik Kniberg has an article that you may find useful on how this system is used at Spotify. The basic principle is as follows: Vertical multi-skilled (product, development, design) teams work on a single product or area of product development (e.g. infrastructure, customer feedback) - these are ...


9

checking SVN in a daily basis to review codes and to asses how much codes have been committed by each developer is a good way. is it fair and used in industry ? This is definitely not a correct measurement for a PAR for Software Engineers. As Jakub has also mentioned, design takes time,sometimes there are blockers which prevent dev team from finishing a ...


9

The biggest problem is Brooks' Law You did not say why you are trying to add freelance developers to the small project temporarily. If your project is late and you are hoping to crash the time line, remember Brooks' Law, "adding manpower to a late software project makes it later". It takes some "ramp up" time for the resources added to the project to ...


9

Answers Question 1: "Is [finishing early to allow for testing] an acceptable request?" Answer 1: It is completely reasonable because in Scrum, the Development Team is self-organizing: No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality - Scrum Guide This means,...


8

It doesn't seem like an efficient way of working because we've all been trained that we should all be utilised as close to 100% of the time as possible. In the example you give, it's not desirable for your analysis function to keep completing work over the WIP limit because you'll create a queue of work that the developers will not be able to keep up with. ...


8

The It depends pretty much answers all of your questions because they really depend on the context. My first advice is to change your questions by adding the why do I to the beginning. For example, "Why do I want to have one meeting per week?" Because I have to write a report once a week to my boss? Or, because I would like to know about the daily life of ...


8

David is absolutely right, there are very few instances whereby refusal to work can be considered acceptable, generally the accepted norms would be if to continue would compromise yourself and/or the organisation legally or as David has already said if to continue would constitute recklessness and present a risk to life etc. The developer’s behavior is ...


8

Disclaimer: I have never worked in a digital agency and I am aware that the role of Project Manager in Digital Agencies can be somewhat different to that commonly accepted in other I.T. operations whether in-house or software development suppliers. Furthermore I am not clear on the exact differences. Despite my disclaimer above, and taking the question and ...


8

Firstly, look at whether you can split your stories any more. Secondly, why aren't the engineers on your team cooperating. The way your describing your system sounds like a you've set a minimum work in progress limit of one story per developer. Of course your cycle time is high (cycle time = wip / throughput after all). Instead cooperate on things to reduce ...


8

Keep in mind that different stories can have different users. If you are building you UI off of your own SDK, it isn't uncommon to have these two use stories: As an SDK user, I would like to be able to grant permissions to a user so that I can manage what different users can do. and As an interface user, I would like to be able to grant permissions ...


7

Scrum Does Not Prescribe Development Practices Scrum is not a development methodology; it's a project management methodology. The Scrum process holds no specific answers for you from a requirements standpoint. Scrum Provides a Framework for Your Questions However, Scrum holds that the questions you are asking are part of the self-organizing that your team ...


7

I was managing a team of five developers and we started out with CI using CruiseControl. I am hard-pressed to think of a situation involving more than one developer where it would not be advantageous to do CI. Hudson/Jenkins is a good platform and we later moved to it. Also, you get A LOT more bang for your buck if you are doing CI against a build system ...


7

TL;DR TANSTAAFL. If you want to scale, you need to add more teams. However, if you add more teams, you have to manage the additional complexity and communications overhead that comes along with that. Direct communication channels scale poorly. The formula is generally expressed as N(N-1)/2. If you don't have a project management model that addresses this ...


7

This is a pretty big question that might create a lot of advice, but I'm sure there are also nuances that we will not get here. There are also multiple questions and challenges embedded into your question so I'm going to answer generally. You are right that grouping by areas of expertise is considered a bad idea as now no one group of people actually has ...


7

TL;DR How to share developers between multiple agile projects? You don't. Doing so is inherently non-agile. This smacks of an X/Y problem, where X (the real problem) is likely to be an executive mandate to "do more with less" without prioritizing projects based on both business value and resource constraints. However, you or your organization may have ...


6

I encourage teams to put a WIP (work in progress) limit on the code review column, usually 3. When the column is full, developers can no longer put something into that column. Instead, they have to either review some code or chase someone else to do a review. This is a Kanban practice rather than Scrum, but I usually find it's the first useful place to put ...


6

The first question I have back at you is, what benchmark are you using to establish "average." You say, 'most are below average.' I would bet the performance of your most is your average. I would further bet that your population of workers fits nicely into the standard performance curve, which means your MODE = Median = Mean. I am going into this not to ...


6

The Purpose of CI for Project Management While the question as originally posed isn't really an ideal fit for this site (e.g. it's more about development practice than about managing projects) it is nevertheless a useful question when properly framed. The Value of Automation to a Project Manager From a project management perspective, real-world projects ...


6

I rather suspect that I would approach this as "tools & techniques to construct work packages". From my limited understanding, a "feature" is nothing more than a work package - a discrete deliverable with schedule & requirements. I don't know of any software to assist in constructing and managing work packages, but I think that @CodeGnome's law ...


6

As far as I understand the question, and if you allow me some humor, you want to know if it is ok to change a pseudo-chaotic (non-)process into a highly bureaucratic PMBOKful one at once. Based on my experience the answer is no, for several reasons: The team is not trained in such a heavy process and it will take a long time before they are efficient. Not ...


6

Unfortunately, you aren't doing Scrum. You simply apply certain practices, but not following the mindset. You are close when you are saying that "... every sprint gives us a version, a product which we can use but that we need to improve". However, sprints not necessarily produce versions and in Scrum we are aiming for feedback at the first place. So, we do ...


6

Sprints and Branches Are Separate Concepts Can we say that a Sprint and a source code branch are almost the same things? No, a Scrum Sprint and a Git branch are not at all the same things. While you can use an online Source Code Management (SCM) system like BitBucket or GitHub in the development process, there is no one-to-one mapping between the project ...


Only top voted, non community-wiki answers of a minimum length are eligible