Technical debt in Scrum projects
Wednesday, July 8, 2009
- Aug 19 Wed 2009 10:29
- May 30 Sat 2009 05:41
Comparing Kanban To Scrum
Kanban v.s. Scrum, a practical Guide
Author: Henrik Kniberg
上次在"Scrum 和 Kanban 的比較"(http://www.wretch.cc/blog/kojenchieh/13367441)一文中, 有簡單提到Scrum和Kanban的差別.
- May 07 Thu 2009 09:45
Scrum 和 Kanban 的比較
Kanban v.s. Scrum, a practical Guide
Author: Henrik Kniberg
Kanban最近在agile community引起相當廣泛的討論, 以前都是在社群或是blog中才會看到他們, 現在已經開始有一些書籍介紹它們. 這裡有一本"Kanban v.s. Scrum, a practical Guide", 是由Henrik Kniberg所撰寫的. 他本身也是"Scrum and XP from the Trenches"一書的作者, 目前很多有關Scrum 的圖片或是插畫, 都是出自本書. 我記得在網路上很像可以找的到PDF版. 此外此書也已經被翻成很多語言的版本, 像是德文, 俄文, 西班牙文等等.若是你想對Scrum有些認識, 作者提供了一些網站來讓你快速上手
- Apr 20 Mon 2009 11:04
- Apr 01 Wed 2009 10:59
- Mar 30 Mon 2009 12:50
Questions About Burndown Chart
February 21, 2009
Posted by Jimmy Zhao
Published in Dig Knowledge Everyday
- Mar 29 Sun 2009 17:19
Comfortably Scrum: How Scrum Are You?
January 26, 2009
Published in Tommy Norman's blog
- Mar 19 Thu 2009 09:47
The Power of a Whiteboard
Posted by Kelly Water
Published in All About Agile
Agile的開發團隊通常使用一些low-tech, 手動的方式來追蹤他們的工作. 像是用便利貼來記載工作項目, 用手繪的burndown chart, 或是用手繪的architecture等等
你或許會很好奇, 像這樣高科技的產業, 應該有一堆現成的project management tools, 或是一些為特定目的所建造的工具可以使用, 會何會用這樣low-tech的方式呢?
- When you see something in print, somehow it seems more real. I guess because it's physical.
- A large number of post-it notes on a whiteboard looks like a lot of work.
- You can show some information like: Sprint Status, Burndown Chart
- You can put literally anything you like on it.
- Unlike an electronic system, there are never any constraints.
3. 白板可以快速, 有效的被修改
- You could completely reoarganise a set of cards in just a few moments.
- Or sketch something important in seconds.
- For people that like tactile, it feels good to move a card to done.
- You feel a sense of ownership when you pick up a card.
5. 它也讓你感到很新穎, 新奇的
- When a team starts doing agile - and they create great visibility using the whiteboard - it's remarkable how many people want to come and look.
- The whiteboard is interesting. It's interesting to look at. And interesting to talk about. When someone walks you through it, it's actually enjoyable.
6. 白板提供一個可以一起合作, 一起討論的地方
- It's a focal point.
- Like a campfire in days gone by. Or a fireplace in your lounge.
- Most team discussions happen round the whiteboard. Discussions about progress. Discussions about issues. Discussions about design.
7. 在白板上, 不同團隊會呈現出不同的文化
- The team can express itself through the things it puts on its whiteboard.
- It starts to show the character of the team, and therefore helps to create a visible sense of team spirit.
作者也提到他並不是反對使用工具, 只是他認為工具是用來輔助白板, 而不是取代它. 有些事情是白版無法做的, 像是keeping track of longer lasting information, doing calculations, searching等等.
- Mar 14 Sat 2009 14:57
Posted by Kelly Water
Published in All About Agile
如果你剛開始成立一個team, 並且大多數的人沒有做過Scrum, 或是沒有接受過Scrum的training. 這時候, 你要team開始使用Scrum來開發, 你將會遇到很多問題, 並且會有大的挫折.
- Much time is spent discussing the process and how things should be done as actually doing it
- The product backlog is confusing and disorganised
- Requirements are not clear.
- User Stories are not adequately prepared.
- Sprint Planning takes *days* instead of hours.
- No too many developers love sitting in meetings!
1. 首先最重要的, 把你的backlog排出重要順序
- Here I say you should proceed no further until this step is completed, otherwise you'll regret it.
- Accept the fact it will take your team at least 3 or 4 Sprints to get into any sort of rhythm.
- Refine how you handle the process in each Sprint.
- Mar 12 Thu 2009 09:52
When is Scrum not Scrum?
February 21st, 2007
Posted by Tobias Mayer
Published in Agile Thoughts
作者認為之前一些Scrum書中的practices有些過時, 根據他的過去使用及教學的經驗, 整理出一些他認為更有幫助的practices.
1. Product Owners應該要是團隊的一份子
- Having a hard separation between PO and team is unhelpful; it causes rifts and exacerbates the “them and us” culture.
- Encourage teams to incorporate the Product representative (not owner) into the daily meetings and the retrospective as well as the planning and review meetings.
- Thirty days for a sprint may have been appropriate twelve years ago when Scrum was developed.
- Today it is far too long. It is also true that teams are incapable of planning a thirty-day sprint effectively. It is overwhelming.
- A thirty day time frame also means a customer change request can take up to 60 days to be completed; that is far too long.
- Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach.
- In my experience team members find this practice frustrating and meaningless.
- Long ago I moved towards encouraging team members to break all tasks down as small as possible.
- A task must be completed in a single working day or it is considered an impediment, and should be marked as such.
- This approach serves two purposes:
*Ease and accuracy of burndown
burndown on tasks rather than hours
making the whole process binary: a task is done or it is not done
*It raises impediments which developers themselves may not see.
- Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.
- The Scrum books, and many courses promote the use of spreadsheets to track the sprint.
- This is really horrible. Spreadsheets hide information, and they lie.
- The best way to create transparency is to display everything on Big Visible Charts.
- The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.
- Again, moving away from spreadsheets.
- At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time.
- Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case.
- The less time we give to thinking ahead in detail on features that may never see the light of day the better.
6. 要有效率的Estimation Meetings
- Estimation is done before the first sprint, and then on a regular basis during each sprint.
- I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time.
- The estimation meeting is an integral part of a successful cycle.
- Having the backlog on the wall ensures developers have continual look-ahead time, thus keeping the estimation meetings short.
7. 要堅持使用一些Agile Engineering的 practices
- It isn’t enough to assume because a team is “doing Scrum” that engineering practices will begin to change. They won’t. And they don’t.
- It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start.
- This doesn’t mean the practices will all be undertaken immediately, but the importance of such practices must be stressed.
- Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices.
8. Scrum Master的腳色不一定需要
- An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to.
- The Scrum Master role becomes superfluous in a healthy Agile organization.
- There is a role for Agile leadership at all levels in an organization, but Scrum Mastering so often becomes a pointless role, and many organizations see it as another type of project management role, driving people.
- Coaching should be appropriate to the context.
- Mar 08 Sun 2009 08:28
eXtreme Programming Versus Scrum
XP 和Scrum到底那一個比較好呢? 作者聽到很多人問這樣的問題. 作者認為這兩者是很難比較的, 因為他們是不同樣的東西, 因此無法比較起.
基本上來說, 他們是根據agile manifesto和agiel principles所發展出來的, 有些地方他們是有重複(如user story, iteration/sprint, accpetance test 等等), 但是他們是不同面向的東西. 以下是作者的分析
(1) XP is an agile engineering methodology.
(2) If your motivation for agile is simplification of requirements management and improved product quality, XP is for you.
(3) XP is the more likely starting point when the adoption of agile is driven by developers.
(1) Scrum is an agile management methodology.
- Scrum and XP are entirely complementary.
(2) If your motivation for agile is wanting more visibility, better business engagement, team collaboration, a clear process for prioritisation, etc - Scrum is for you.
- If you use both(Scrum and XP), you will benefit from a more incremental, iterative approach to development.
(3) Scrum is the more likely starting point when the adoption of agile is driven by management.
所以根據作者的觀點來說, 他建議你應該兩者都採用. 但是你可以先用一個, 一個能幫你先解決目前你所遇到問題, 之後在adopt另外一個.
- Feb 27 Fri 2009 22:04
How To Implement Scrum In 10 Easy Steps - Step #4: Sprint Planning (Tasks)
前面在sprint planning meeting中, 已經釐清好backlog的reuqirement, 接下來就是規劃要完成這些reuqirement的細部工作項目, 以及所需的時間.
(1) Although Part 2 of the workshop can follow straight on from the first part, it is sometimes helpful for there to be a short gap between the two meetings; maybe 1 day.
(2) This allows time to clarify any outstanding questions arising from part 1 of the workshop before proceeding with the next step.
- Business Analysts if you have them. Testers if you have them.
- ALL Developers on the Scrum team for the product.
- The Product Owner and any customer, user or business representatives need not attend this part (part 2) of the Sprint Planning workshop, as it’s likely to be more technical in nature and is more about the team working out how the selected backlog items will be delivered.
- However, they should be welcome to attend if they wish, which may help their understanding of what’s involved to deliver the features, and may help if any further clarification is required as the tasks are discussed and estimated.
(1) Calculate the team’s Sprint Budget: the available number of hours the team has to work on the Sprint.
(The available hours in the Sprint Duration X the number of full-time people in the Sprint )
+ (For people who are working part-time in the Sprint, include the number of hours they can commit to)
- (Any reasonable deductions for time that team members will not be able to spend working on the Sprint)
(2) Deduct holidays, any known meetings, any time likely to be spent working on other projects, etc.
(3) Based on past experience, deduct a reasonable amount of time for support, if appropriate.
(4) Make sure all these calculations are transparent and visible to all.
(1) Go through each Product Backlog item selected for the Sprint. Break the requirements into tasks.
(2) Tasks may include the traditional steps in a development lifecycle
- For instance: Design, Development, Unit Testing, System Testing, UAT (User Acceptance Testing), Documentation, etc.
(3) Remember, agile software development methods do not exclude these steps. Agile methods just advocate doing the steps feature-by-feature, just in time, instead of in big phases.
(4) Each of these tasks, especially development, may be broken down further.
(5) Include all tasks necessary to make the Product Backlog item 100% complete
(6) Agree as a team on your definition of done, so everyone is aware what will have to be completed and included in the estimates.
(7) State tasks as deliverables, if at all possible.
- Deliverables are more measurable than tasks.
- Instead of describing what you’re going to do, describe what you’re going to deliver.
(1) Keep tasks small. Estimate all tasks in hours. Estimate each task as a team.
(2) Ask everyone what they think, in order to identify missed tasks, or to identify simpler solutions.
(3) Ideally task estimates should be no more than 1 day.
(4) If an estimate is much larger than this, the requirements should be broken down further so the tasks are smaller.
(5) Keeping tasks small enough to estimate at less than 1 day has some specific benefits.
- Breaking tasks down into very small chunks means they are easier to estimate. The accuracy of your estimating will be improved as a result.
- Tasks less than 1 day are more measurable in the daily Scrum (stand-up meeting). 1 day tasks are either done or they are not.
(1) Add up all the task estimates for the selected Product Backlog.
(2) If they are significantly over the team’s Sprint Budget, reduce the number of Product Backlog items selected for the Sprint.
(3) Remember the Product Backlog was in priority order, so if possible it should be the lower item(s) on the backlog that are removed from the Sprint.
(4) The remaining list of estimated Tasks – those tasks needed to complete the selected Product Backlog within the Sprint - is your Sprint Backlog.
(5) The team should commit to delivering the Sprint Backlog.
(1) Sometimes teams under-commit or over-estimate. Stranger things have happened! :-)
(2) In my experience this is quite common when teams are new to Scrum.
- This can sometimes result in an over-cautious approach to the estimates.
I think it’s because they are unfamiliar with the process and potentially out of their comfort zone initially. They may not have had much experience of estimating in the past.
And they may not have been asked to commit to their own delivery before.
This can sometimes result in an over-cautious(謹慎的) approach to the estimates.
(3) Always include some additional scope in your Sprint Backlog, over and above what you think can be achieved.
- This is important in order to have something ready if the team delivers early, as the Sprint should ideally remain a fixed length.
- Clearly identify these items as Stretch Tasks.
(4) Should never expect Stretch Tasks to be reached.
- No-one should ever be beaten up if Stretch Tasks are never reached.
- And if you do manage to complete any Stretch Tasks, this should be cause for celebration!
- Feb 25 Wed 2009 09:31
How To Implement Scrum In 10 Easy Steps - Step #3: Sprint Planning (Requirements)
Sprint planning meeting 對scrum來說是非常重要的一個步驟, 如果在一開始沒有先講清楚, 讓大家有一致的共識, 之後在這一個sprint就會很混亂.
因為他們會不知道要做的東西到底是什麼 ? 要做到怎樣才夠?因為在這短短的sprint中, 時間是很有限, 要做的東西應該是要十分清楚的.
1. 進行 Sprint Planning Workshop
(1) Make sure the meeting is attended by the whole team.
(2) Include all roles.
(3) The first thing you must do (in your first Sprint Planning meeting) is decide on your Sprint duration. This decision should be taken as a team.
(1) Scrum suggests 30 days.
(2) The optimum Sprint duration depends on many factors.
(3) A development team's 'cycle time' is a direct reflection of the maturity of their processes.
- A team with immature processes will find the intensity of Scrum and the overhead of Sprint Planning, Testing, Deployment and Review quite onerous for a short Sprint cycle.
- Whereas teams with very mature processes (for example automated testing, automated deployment, and teams who've become very quick at Sprint Planning), a short cycle might be very comfortable.
(4) Mike Cohn is one of the key exponents of agile development.
- See here for Mike's article giving further advice about how to select the optimum iteration length.
(1) Whatever Sprint duration you choose to go for, my advice is to keep it consistent.
(2) Allows you to get into a rhythm.
(3) Makes your process very repeatable.
(4) Allows you to start understanding how many Product Backlog points you can typically do in a Sprint.
(5) Once you've decided, you can now set up a Sprint Planning Workshop as a recurring appointment before every Sprint.
(1) Looking at the top section of the Product Backlog,
- What would seem to be a reasonable goal to set for the Sprint?
- Can you express an objective that sums up the goal for the next Sprint, or
- At least pick a section of items/features from the top of the Product Backlog that the team thinks can be achieved in the Sprint duration?
(2) Select your target backlog for the Sprint. Make this decision as a team.
(3) It's important to prepare more items during planning in case the team finishes early.
- These items can be clearly identified as stretch tasks and the Product Owner should not expect them to be completed.
(4) In future Sprints, you will be able to use your Scrum team's previous Velocity to help with this decision.
- Velocity is the number of Product Backlog Points delivered in a Sprint.
- This tends to fluctuate wildly early on when adopting Scrum.
- But it will settle down as the team get into a rythm, and in future provide you with a reasonable norm to base your target backlog on.
(1) Take each item on the Product Backlog. It's important to go through them methodically, one item at a time...
(2) The Product Owner presents each item and explains how he/she sees it working from a functional perspective.
(3) The whole team discusses the item in detail.
- The whole team asks questions about the feature in order to establish what it should do and how it should work.
- The outcomes of this discussion should be captured on a whiteboard or flipchart, or someone could write notes on a laptop as the discussion progresses.
(4) Write requirements in a way that is lightweight and visual.
- Agile requirements should be barely sufficient.
- The fact the features will be developed and tested within the next few weeks, and by the team that were present, makes this possible.
(5) Consider writing 'User Stories'.
- But the basic concept is to write features using this construct:
As a [type of user], I want to [do whatever], so I can [achieve what goal].
- The story can be backed up by a sketch of the UI, a wireframe or visuals.
- Annotate the sketch to describe the functionality.
- Backed it up with statements about how it will be confirmed (or tested).
- This will help to identify scenarios up front, before it's developed.
- Feb 24 Tue 2009 09:54
Scrum is not Enough
作者在scrumdevelopment Yahoo group上, 看到一篇post "Scrum and Architecture",
In order to employ emergent architecture, every Sprint must leave behind clean, commented, refactored work. Otherwise emergence hits the wall within six Sprints (or sooner, depending on how bad the morass is).
作者覺得很驚訝, 因為這段話相當於Kent承認Scrum 的practice, 除了short term以外, 是不足夠去處理每件事情. 當然啦, 不只Ken這樣講, 在這篇post中很多人也這樣講, 包括作者本身
Ken過去曾經不斷說明, Scrum已經有審慎考慮過很多事情, 因此不需要加入任何tech practices. (我個人認為像是TDD, refacotring, pair programming等等) 但是現在由這篇post看來, 如果沒有solid technical practices, Scrum是不足夠的
所以作者勸大家, 要考慮一下往agile process方向移動, 也就是考慮其他agile的process, 像是XP等等. 因為Scrum真的是不夠的
- Feb 13 Fri 2009 11:06
How we do sprint demos
from "Scrum and XP from the Trenches - how we do Scrum"
最近要作sprint的demo, 這可是大姑娘上花轎, 頭一遭. 還不知道要怎樣做會比較好. 因此survey了一下, 看看是否有人提說哪些東西要注意的.
在"Scrum and XP from the Trenches - how we do Scrum"一書中, 有提到相關要注意的事情.
1. The team gets credit for their accomplishment. They feel good.
2. Other people learn what your team is doing.
3. The demo attracts vital feedback from stakeholders.
4. Demos are (or should be) a social event where different teams can interact with each other and discuss their work. This is valuable.
5. Doing a demo forces the team to actually finish stuff and release it (even if it is only to a test environment).
- Without demos, we kept getting huge piles of 99% finished stuff.
- With demos we may get fewer items done, but those items are really done, which is
(in our case) a lot better than having a whole pile of stuff that is just sort of done and
will pollute the next sprint.
1. Make sure you clearly present the sprint goal.
- If there are people at the demo who don’t know anything about your product, take a few minutes to describe the product.
- Feb 05 Thu 2009 16:49
Should We Adopt Scrum or XP?
(1) 著重於 "let's create excellent software."
(2) 比較不容易開始, 因為要學習TDD, refactoring, pair programming, customer on site...不是很快可以做到.
(3) 開開始會花很多時間, 會很痛苦, 因為要adopt很多engineering practices. 如果度過後, 就不太會有code quality的問題, 並且performance會很高. 但是若是沒有撐過, 最後可能會失敗, 或是放棄.
(4) XP 不容易開始, 但是容易去精通它, 但是失敗時會以很吵鬧的方式結束
(5) You're less likely to successfully adopt XP, but you'll be well positioned for long-term success and mastery.
(6) If you're missing pieces, you'll probably be able to tell.
(1) 著重於 "let's create a self-organizing team"
(2) 比較容易開始, 只要team願意adopt, 工作規劃上照著scrum 的規則走就可以
(3) 但是Scrum 有較長的ramp-up時間, 並且很長一段時間會有code quality的問題
(4) Scrum 容易開始, 但是不容易去精通它, 但是失敗時會以無聲無息的方式結束
(5) You're more likely to successfully adopt Scrum, but the benefits won't extend to your codebase and you'll struggle with legacy code for many years.
(6) If you're missing pieces, you may not realize it.
- Jan 30 Fri 2009 08:32
Differences Between Scrum and Extreme Programming
Scrum and Extreme Programming (XP) 都是agile家族中的成員, 常常有人無法分辨他們的差別是什麼. 作者列出了他們的差別, 雖然這些差別不大, 但是很關鍵:
- typically from two weeks to one month long.
- typically one or two weeks long.
- Do not allow changes into their sprints.
- Once the sprint planning meeting is completed and a commitment made to delivering a set of product backlog items, that set of items remains unchanged through the end of the sprint.
- Much more amenable to change within their iterations.
- As long as the team hasn't started work on a particular feature, a new feature of equivalent size can be swapped into the XP team's iteration in exchange for the unstarted feature.
- Work in a strict priority order.
- Features to be developed are prioritized by the customer (Scrum's Product Owner) and the team is required to work on them in that order.
- Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop the backlog items.
- A Scrum team will very likely choose to work on the second most important.
4. 是否要遵守一些Enineering Practices
- Doesn't prescribe any engineering practices;
- XP does.
- For example: TDD, pair programming, simple design, refacotring...
作者認為要adopt agile, Scrum是一個的好的開始, 因為他已經有iteration, timeboxed的基礎. 但是若是能搭配XP會更好. 因為XP會告訴你要如何做的practices (如TDD, refacotring, pair programming...), 會讓你的能夠開發出品質更好的軟體.
嗯.... XP 確實難度是比較高, 但是應該是比較有用吧?!.....不過剛開始, 還是柿子先挑軟的吃吧, 先站穩腳步吧