Group items tagged

It’s a lot easier to estimate a story that’s small — which can lead to more accurate estimates, and better predictability.

It’s easier to plan with smaller stories. With big stories — stories that might take weeks for a developer to implement — it becomes difficult to plan a development time-box — particularly when the iterations are only a couple of weeks. It seems that only a couple stories fit — and there’s often room for half a story — but how do you build half a story? Splitting them into smaller stories makes it easier to plan those time-boxes.

Shrinking stories forces earlier elaboration and decision-making. Where product owners could write their stories fairly generally and consider many of the details later, now breaking them down into smaller stories forces more thinking earlier in a planning lifecycle.

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.

I do believe for Scrum to work beyond the team you need more than Scrum

what to add to Scrum making it more effective when it won't readily work

lack of team agility is not always the major impediment to Enterprise Agility

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.

team that had some problems getting their process right

their velocity was decreasing and spirits were low. Luckily we managed to change our process by changing some basic Scrum practices and replacing some of them with Lean practices, inspired by the new Kanban articles and presentations. Productivity is now higher than ever and we can now focus on what really matters: product quality and customer satisfaction.

one major issue: getting things done. The major symptom was the frustration of management and the team with the project. The first 3-week time box (sprint) ending with about 30% (!) of all features still in progress, when, of course, they should all have been done and ready for shipment.

Simply using iterations, user stories and velocity doesn’t mean your project is agile – or on the way to success.

why “iterations” may be hazardous to your project: ‘’Danger grows when the results of the iteration are not directly linked to delivering the product to the end user.’’ Without that linkage, iteration results hang in the air

What gets in the way is that the project is set up as a pipeline, with programming put somewhere in the middle of the pipeline. In this project setup, there is really nothing the programmers can do to show how their work connects to deliveries, because there are work stations before and after theirs. All they can report is that “some new code is integrated into the code base.” They are doing incremental development but not agile development.

Connect Agile’s Benefits to your Company’s Priorities

aying that Agile is “better, faster, cheaper” may not be enough to cause a company to be willing to go through the often-painful process of cultural and process change.  You could implement Agile, but you could also try Six Sigma or Lean.  Saying that Agile is a general get-better remedy puts it in line with many other get-better methods.

ur last two releases have looked like me-too updates, where we are just barely keeping up with our competitors

Has the team made changes that make a difference to them as a result of the retrospective?

Has the team explored a variety of different topics/areas, or do they stick to pretty much the same agenda around continuous improvement? What is the balance of change/improvement work vs. working on the product?

For example, try looking at technical practices, teamwork, or customer relationships... choose what ever seems most relevant to bound the discussion. That might help the team dig deeper and find issues that have more significance for them (now...I'm sure the other changes were significant at the time).

Identify the technical leaders within projects; those that are “self-driven to produce quality results on time … combine technical ability with enough people skills …are trusted and respected by both their managers and fellow developers, are determined to make the team succeed, and usually live the work.” (Chief programmers, Chapter 2:  A Practical Guide to FDD).

Sell them the vision: if you cannot sell these people on the benefits to them, their colleagues and the organization of the new way of working then something is wrong

Provide in-depth training and on-going coaching. It is better to have a single lead person trained in-depth who can coach his teammates through the basics than to have the whole team trained on the basics with no-one on the team to turn to when the basics are not enough.

The responsibility of the Growth Facilitator is about more than simply prioritizing New Work goals and tasks. I see the role as contributing to the organizational culture, and helping to build the business in a sustainable way.

As Growth Facilitator, I am also responsible for guiding the team toward delivering greater value for our stakeholders. At Berteig Consulting, our stakeholders don’t just include the company’s owners. Our stakeholders include a wide range of groups, including customers, suppliers, employees, and our families, all without whose support nothing we do would be possible. Delivering value to our stakeholders requires that we keep them in mind when we commit to our tasks each week.

When I first started, I made goals that were broad, saying for example “to take care of our clients” or “to work at a sustainable pace.”

It is critical that everyone has the same understanding of, and commitment to, the desired outcome: a business that is reliable through predictable technology processes that deliver business agility. To do this, there needs to be a management commitment to develop a focused, on-going practice around the pursuit of organizational maturity. As part of this, gaps in skills and capabilities should be identified and positive action – training, coaching, process improvement and tools deployment – taken in order to close the gap

the work force needs to understand the business drivers for Agility. They need to be challenged to improve their quality, improve their cycle times, to improve the frequency of releases and the value they deliver to the customer. They need to know how these things fit within the bigger picture and why improvement is their responsibility.

To change a culture it's important to recognize that every knowledge worker makes decisions and takes actions that affect the performance of the business. The culture in the organization is the reflection of those decisions and actions.

Scrum places more emphasis on the project management practices. Kanban, places its emphasis on business and value flow practices.

its all the same elephant, but each approach has a different view of it. At the end of the day, its having the most appropriate elephant for any given context that is most important.

Kanban can be differentiated by identifying its Primary and Corollary Practices.

The Project Manager works with the Product Owner to insure that cost is always a consideration when evaluating the Product Backlog.

"Super Scrum Master"

Tracking costs, especially for production

To determine the truth of this we only need to look at the feature sets of the popular tools for managing eXtreme Programming and Scrum such as Rally, VersionOne, ScrumWorks, Mingle and very new tools like Borland Team Focus, to discover that not a single one of these tools allows you to set an explicit WIP limit. None of them provide a pull signal to start new work. Very few of them are even capable of reporting the quantity of work-in-progress.

s we learned more about the value of managing WIP, we introduced concepts to encourage and enable it, such as the use of Cumulative Flow Diagrams (a.k.a. Burn Up charts)

Agile teams encountering an impediment would generally mark a story as blocked and go on to another one

Part 2

The really hard part is around the people transformation - getting developers to work side-by-side with testers and users is a completely foreign concept.

The thinking is that IT is mission-critical, so let's not change things without giving it a lot of thought and a lot of consideration