Skip to main content

Yuval Yeret's Library tagged scrum →  View Popular

18 Sep 09

Do It Yourself Agile: Scrum and Kanban - Like Chocolate and Peanutbutter

  • When doing Kanban, you still need to do the equivalent of planning, assignment, estimation, retrospectives, delivery, etc. In Kanban, all of these activities are decoupled from each other whereas in Scrum they are all coupled to the iteration boundary.



    How can this be applied to Scrum? Consider retrospectives. If you are just starting with Scrum, you probably have an iteration length of 1 month (or four weeks). From that it follows that you will have a retrospective once per month. If you eventually end up with an iteration length of 1 week, then it follows that you will have a retrospective every week. But this actually seems like the wrong way to set the cadence of retrospectives. Wouldn’t it be better to have the cadence of retrospectives meet the need for them? If it eventually makes sense to do a retrospective every week, doesn’t it make sense to get the benefit of them on a weekly basis when you are just starting Scrum?
06 Jul 09

Scrum Alliance -Poisonous Scrum Anti-Patterns

  • It seems as though many people have their minds set on how long it should take to fulfill the duties of an average ScrumMaster
  • To be clear, if the ScrumMaster is not focusing 100 percent of their work time on team and organizational impediments and improvements, the ScrumMaster is not doing enough to make important organizational change happen.
  • 2 more annotations...
24 Jun 09

Social, Agile, and Transformation: The ScrumMaster - A role or responsibility?

  • So if they needed the ScrumMaster role filled, then this was something they were prepared to train and assign to either a project manager or possibly a technical lead. The consensus of this team was, if you found a project manager skilled enough to have a real technical dialog with the development team, then this person could be trained and perform the ScrumMaster role.
  • The Scrum Alliance published a survey that has some supporting evidence. Over 60% of the 1100 people that responded to the survey had nine or more years of industry experience, 15% of them had twenty or more years of experience, and 35% had Masters degrees. Also, of the people who responded, 22% were project managers and another 21% were either Managers or Directors. So my simple translation is that practicing ScrumMasters are managers (project or other) with significant (10+) years of proven experience. Training and assigning this role to experienced project managers or software development managers seems like a viable approach to have the responsibility filled and having a dedicated ScrumMaster separate from these roles may not be necessary.
16 Jun 09

Agile Resources: Velocity | VersionOne

  • Does maximum velocity mean maximum productivity?


    Absolutely not. In an attempt to maximize velocity, a team may in fact achieve the opposite. If asked to maximize velocity, a team may skimp on unit or acceptance testing, reduce customer collaboration, skip fixing bugs, minimize refactoring, or many other key benefits of the various Agile development practices. While potentially offering short-term improvement (if you can call it that), there will be a negative long-term impact. The goal is not maximized velocity, but rather optimal velocity over time, which takes into account many factors including the quality of the end product.

19 May 09

Scrum-ban | Lean Software Engineering

  • 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.
  • 7 more annotations...
15 May 09

InfoQ: Comparing Kanban To Scrum

    • Scrum in a nutshell

      Split your organization into small, cross-functional, self-organizing teams.

      Split your work into a list of small, concrete deliverables. Assign someone to be responsible for that list and to sort the list by priority. The implementation team estimates the relative size of each item.

      Split time into short fixed-length iterations (usually 1 – 4 weeks), with potentially shippable code demonstrated after each iteration.

      Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.

      Optimize the process by having a retrospective after each iteration.



      For more details check out “Scrum and XP from the Trenches”. The book is a free read online. I know the author, he’s a nice guy :o) http://www.crisp.se/ScrumAndXpFromTheTrenches.html



      Kanban in a nutshell

      Visualize the workflow
      • Split the work into pieces, write each item on a card and put on the wall
      • Use named columns to illustrate where each item is in the workflow

      Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state.

      Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.
1 - 20 of 39 Next ›
Showing 20▼ items per page

Selected Tags

Related Tags

Sponsored Links

Ads by Google

Highlighter, Sticky notes, Tagging, Groups and Network: integrated suite dramatically boosting research productivity. Learn more »

Join Diigo