Group items tagged

Responsibilities Vary by Software Business TypeSince the business mission, organization, operating methods, roles, titles and responsibilities differ dramatically across industry segments, it follows that the patterns of agile adoption vary across these segments as well

Information Systems/Information Technology (IS/IT) -teams of teams who develop software to operate the business; accounting, CRM, internal networks, sales force automation and the like. Customers are primarily internal to the enterprise.

Embedded Systems (embedded) - teams of teams who develop software that runs on computers embedded in other devices - cell phones, electronic braking systems, industrial controls and the like. Customers may be either internal or external to the enterprise.

A problem with the basic index-card task board is that there is nothing to prevent you from accumulating a big pile of work in process. Time-boxing, by its nature, sets a bound on how much WIP that can be, but it can still allow much more than would be desirable.

then you need another mechanism to regulate the “money supply.” In our case, we simply write the quantity of kanban in circulation on the task board, and allocate new cards according to that limit.

You might have a simple principle like: prefer completing work to starting new work, or you might express that as a rule that says: try to work on only one item at a time, but if you are blocked, then you can work on a second item, but no more. In our example, that rule gives us an effective WIP limit of 6.

How to make a LOT more money using agile

More frequent releases

expectations must be set for releases to be smaller but still have significant marketable value.  It also means managing scope for smaller releases so the value can actually be delivered to meet the expectations.  If we make the assumption these two pre-requisites can be handled, then we can also assume faster releases are possible.  Yes, I know, releasing software is expensive, requires other groups, etc.  For now, let’s assume all of those costs are negligible compared to the potential results and see where we end up.

Venture-capital financing model This can be used with any of the above contract forms. In this model, the sponsor gives a round of financing for a certain amount of work, and the contracted company must produce results in order to get more funding. The sponsor can cut their losses at any time if they are not getting the results they need. They can presumably alter the terms of the contract after each work period. The result of a work period need not be working software; it could be a paper study, or a requirements document, or anything the sponsor selects. The venture-capital finance model works well with agile providers, since the agile provider is used to delivering useful, working software early and regularly. I find it an odd irony that the venture capital financiers running start-ups that I have encountered don’t take advantage of their own model to the extent agile teams do. The venture financiers let the evaluation markers occur too far apart in time. If they attached funding to monthly releases, that would oblige the start-up team to think through what it really can accomplish each month. The monthly progress would give the financiers a better sense of the start-up company’s real progress.

Venture-capital financing model This can be used with any of the above contract forms. In this model, the sponsor gives a round of financing for a certain amount of work, and the contracted company must produce results in order to get more funding. The sponsor can cut their losses at any time if they are not getting the results they need. They can presumably alter the terms of the contract after each work period. The result of a work period need not be working software; it could be a paper study, or a requirements document, or anything the sponsor selects. The venture-capital finance model works well with agile providers, since the agile provider is used to delivering useful, working software early and regularly. I find it an odd irony that the venture capital financiers running start-ups that I have encountered don’t take advantage of their own model to the extent agile teams do. The venture financiers let the evaluation markers occur too far apart in time. If they attached funding to monthly releases, that would oblige the start-up team to think through what it really can accomplish each month. The monthly progress would give the financiers a better sense of the start-up company’s real progress.

Bob Martin’s idea Bob Martin of Object Mentor posted an interesting variant to get around this problem: a base fee per story point, plus a lower-than-usual (close-to or below cost) fee per hour. This biases the contracted company’s to deliver early, but gives them some protection in case work proceeds slower than expected. Bob Martin described it this way:”[A]gree to pay a certain amount for each point completed, plus a certain amount for each hour worked. For example, let’s say you’ve got a project of 1000 points. Let’s also say that a team of four has established an estimated velocity of 50 points per week. This looks like about an 80 man-week job. At $100/hour this would be a $320,000 job. So lets reduce the hourly rate to $30/hour, and ask the customer for $224 per point. This sets up a very interesting dynamic. If the job really does take 80 man-weeks, then it will cost the same. If it takes 100 man-weeks then it will cost $344,000. If it takes 70 man-weeks it will cost $308,000. Notice that this is a small difference for a significant amount of time. Notice also that you, as developer feel strong motivation to be done early, since that increases your true hourly rate.” I have not seen that model in action myself, but several people have written in recommending it.

Try to get the one person to move to where the rest of the team is.

Having one remote is a cost that must be borne by the full team. For the right person, it’s easily worth it. But sometimes, the person who is remote has not special skills, knowledge or experience to justify the added hassle.

continue to use the physical task board–it is simply too beneficial to the collocated team members to give it up in favor of a product backlog tool, especially if team members are already used to it and like it.

A good guide to follow is 20% of the total number of items. So, in the case of 30 risks being prioritized, each voting team member would receive 6 votes to assign across the population of risks.