5分でわかるSCRUM概要 (Katie’s “5-minute Scrum” article for our readers in Japan)

August 9, 2008

[Danube provides products and services to well-known and lesser-known companies all over the world. Recent inquiries from Japan have prompted us to provide a Japanese version of Katie Playfair’s article What Is Scrum, the Five Minute Explanation for Folks Not Yet Practicing It. If you don’t happen to read Japanese, click the link above for the English version! –mj]

Katie Playfair
樋上容子訳

●SCRUMとは何か
あるとき、電気工学の博士過程に進んだ友人が、彼の博士論文を私に説明しようとしたことがあります。その友人は、自分が開発したプログラムを一行ごとに説明しだしたのですが、私は工学の分野に詳しいわけでも、ましてやコンピュータプログラマでもないので、彼の言っていることはちんぷんかんぷんでした。専門用語を駆使することが日常になっていた彼にとって、外の人間に自分の研究を説明するのは容易なことではなかったようです。

SCRUM に携わる人間も、似たような状況に立たされることがあります。SCRUMにもバーンダウン、スプリント、デイリースクラム、振り返り(retrospective)などの専門用語があります。これらの専門用語があってこそ、SCRUMに携わる人間同士でのコミュニケーションが的確かつ迅速にできるのですが、SCRUM
に携わっていない人間にとっては外国語のように聞こえるかもしれません。そこで、SCRUM歴が浅く簡単な説明を必要としている人や、SCRUM歴は長いがSCRUMでどんな仕事をしているのか友達に説明できずに困っている人のために、SCRUMとは何なのかを解き明かしたいと思います。

SCRUMとは何なのでしょうか。この大きな疑問から始めます。SCRUMとは、フレームワークであり、価値観であり、そしてプロセスです。さまざまな観点から見ることで、異なったバックグラウンドを持つ方にSCRUMを理解していただけると思います。

・フレームワークとしてのSCRUM
SCRUM はプロジェクトをマネジメントする、もっと一般的に言えば、プロジェクトがうまく回るようにするためのフレームワークです。SCRUMはイテレーティブ型・インクリメンタル型です。どういうことかと言うと、SCRUMでは開発チームが短期間(スプリント、もしくはイテレーションと呼ばれる)のサイクルで開発を進めます。そして各期間の終わりに「完成品につながる実行可能な成果物(使える商品)」を出します。各スプリントの目標は、直前に行ったスプリントの成果に基づいて評価・交渉・確約されます。しなければいけない作業が山ほどあっても、SCRUMはその山ほどの作業を「消化可能な作業」(通常2週間で完了できる量)に分割します。

・価値観としてのSCRUM
SCRUM はまた、価値観でもあります。この価値観はチームが共通の目標を達成するため一つになるように促し、個人の成果よりも全体としての成果に集中するようにします。SCRUMはコミュニケーション、オープンな姿勢、透明性、自己組織性、個人そしてプロとしての価値、などを重視します。SCRUMを取り入れることによって、自分の仕事が好きになったり、チームに貢献することが素晴らしいことだと感じられるようになるでしょう。また、SCRUMは現実と同期するものなので、進捗を評価したりビジネス環境からプロジェクトの進む方向を明らかにしたりしてくれます。

・プロセスとしてのSCRUM
SCRUM はさらに、価値観をチームで共有するためのプロセスでもあります。ここで言うプロセスとは、チーム内で役割分担をし、定例ミーティングを開き、成果物を作成・維持することを指します。この単純なプロセスはソフトウェア開発チームが大きくなっても適用可能です(多少のプロセスの追加は必要かもしれませんが)。また、ソフトウェア開発以外の場合にも適用できるかもしれません。

●SCRUMの利点
SCRUM の利点とは何でしょうか。まず、不必要な官僚主義のない構造を作ることができます。この構造はコミュニュケーションを組織的なものにするため、従来ではありえなかった会話を生み出し、誤解が生まれる機会を減らします。誤解が少なくなると、多くの場合、結果として欠陥や誤りが少なくなります。

SCRUM を導入すると、チームメンバーと経営陣両方に発言する機会が発生し、個人が各々の日常業務をより大きくコントロールできるようになります。当然ながら、被雇用者の満足度は高くなり、継続的に仕事をしてもらえる結果となります。コミュニケーションが日常化することで、従来の重量級プロセスよりも早期にものごとが明確化・透明化されるようになります。

また、SCRUMを導入することで、インプットよりもアウトプットが重要だと考えられるようになります。チームがどれだけ忙ししくしているかという基準ではなく、ROIのような全体的な数字が重視されるようになります。結果的にSCRUMによって、「使える商品」をより多く作り出すことができるようになります。もしすでに「使える商品」を作り出しているなら、「使える商品」がおそらくはもっとよく売れるようになるはずです。
つまり、従来のプロジェクト管理方法よりSCRUMを導入したほうが、良質の商品をより低コスト・短時間で作り出すことができるのです。最後になりますが、私が家族や友人、また仕事を通して知り合った人たちにSCRUM
を説明しようとするときに、今回述べたことがうまく伝わればいいなあと思っています。

Advertisements

Flying with the Angels

August 1, 2007

Today, as before, I ran through the 10-minute checklist and engine start sequence, felt the tiny R-22 rock from side to side, then smooth out, as the blades spun up and went “whupwhupwhupwhup.” I checked the cylinder head temperature, carburetor heat, sprag clutch (rotor freewheel), the dual redundant magnetos, and the low-RPM alarm. The 900lbs R-22 should be called the Kent Beck Special; it’s the simplest helicopter that could possibly work. There are bicycles with more technology on them, and one that weighs almost as much.

Then my instructor hovered us above the “H” pad while we waited for Boeing Tower to clear us for take off. After 10 hours of instruction, I do most of the flight maneuvers but I’m not ready to hover near a busy runway. Hovering is like balancing a unicycle in three dimensions while random wind gusts try to push you over.

This doesn’t stop my instructor “Mike” from pushing me to try. I’ve never seen Mike break a sweat. He even stayed cool two weeks ago when I dropped us toward the ground in a flat spin and he had to pull collective hard enough to trigger the low-RPM alarm a few feet above the grass.

As I took off and pushed the cyclic forward through translational lift (~50 knots airspeed) I overheard Boeing Tower advise another aircraft “You’ll be following the F-18.” Sure enough, below us and to our right we saw a Blue Angels F-18 on final, wheels down. I never thought I’d see one of them from above, let alone as a fellow pilot. (I recently realized a student pilot is a kind of pilot!)

Today was windy, and tougher than last time. Hovering ten feet above someone’s farm, Mike asked me to do a 360 pedal turn. Nothing happened at first due to “weathervaning” from the wind. I gave it more pedal, and suddenly the wind whipped us around before I could catch it with the opposite pedal. Learning to fly requires learning to respect the wind. The pedals are backward from what you’d naturally expect, an ergonomic mistake from 1940 that will probably never be corrected. The trick to flying a helicopter is to give a lot of small corrections before you’re consciously aware they’re necessary. Any big movement will throw everything out of whack.

Later on Mike told me to fly up to 1000 feet so he could show me autorotation, an emergency procedure every student must learn before soloing. Having just learned more people are hurt during practice autorotations than in actual engine failures, I didn’t really feel like trying this. If rotor RPM goes outside a narrow range, you crash.

Mike throttled the engine down to idle and pulled us into a nose-high attitude. The cabin went silent with the engine almost off. I watched in horror as the engine/rotor RPM gauges split, as if the machine’s heart had stopped beating. I kept breathing deeply as my own heart’s RPM went off the scale. As we fell, the wind noise picked up and the rotor RPM increased. We were now a wind-powered gyrocopter with a glide ratio slightly better than a brick. Mike calmly demonstrated how all the flight controls still worked due to the wind pushing the rotorblades around. I realized the first autorotation of my life was probably Mike’s second or third of the day.

As the ground raced up toward us, Mike flared the cyclic and then the collective, exclaiming “Look! We can still hover!” And we did, for a few seconds. Then the rotor RPM fell into the yellow zone and we cranked the engine for a powered recovery a couple feet above the ground.

Someone said “Never drive faster than your angels can fly.” On my K-bike I have confirmed my angels can fly at least 140mph. But can they hover?

–mj


Scrum Teams That Don’t Put Test First

July 5, 2007

Here’s email I just sent someone. Does any of this sound familiar?
–mj

Our idea is that Scrum team members check their job titles at the door of the team room. After that, it’s just team members using whatever skills they have collectively, not “dev resources” and “QA resources.” Unfortunately our old habits and the way we compensate people discourage programmers from being interested in writing tests.

The TDD workflow is a few minutes of writing a failing test (ideally in the same language as the system being built), followed by a few minutes of writing code to make the test pass, followed by a few minutes of refactoring both to eliminate duplicate code and such. Red, green, refactor. Ideally people with QA backgrounds pair program with people with coding backgrounds so the tests are more robust. I’ve paired with QA folks while doing JUnit tests and they were able to help despite not knowing a lick of Java.

You’ll still need manual testing, BTW. Dunno if I mentioned successful expensive aerospace projects I’ve been on got deterministic results with a effort ratio of about 4 “verification” hours (mostly writing tests) to every 1 “development” hour, which is why I feel pretty safe getting on a plane. One pre-Scrum aerospace project I worked on had QA folks as the *leads* of cross-functional teams. You can bet our work was thoroughly checked out.

I’ve had more success working with people that want to learn this than trying to push it from outside. As a Product Owner, I’d have no problem scoring zero velocity Sprint after Sprint until it dawns on the team they need to figure this out one way or another. You’re doing C#, right? C# has great tools for TDD, refactoring, and continuous integration. I don’t feel it’s micromanagement to specify “main success scenario plus alternate flows are verified by automated test that runs on every future checkin” in a Product Backlog Item’s acceptance criteria. There is business value (future maintainability) in that end state. How they self organize to achieve that is still up to them.

–mj


iCal + AppleScript + SkypeOut = Conferences That Call YOU

June 10, 2007

Since Danube consultants travel for a living, we do our daily Scrums via conference call. Doing them in person is way better, but doing them via telephone is better than not doing them. I try to structure my gigs so that I’m available for the call, which is held at the same time every day, at the same “place” (our conference calling center).

In less than 20 lines of code, the Mac can three-way call my cell phone and the conference call center at the usual time each day. The cool thing about this is I don’t have to be anywhere near my computer for it to work. It could be made to call everyone, so no one has to remember to dial in. But that might be obnoxious.

It also sets iChat (and GoogleTalk) status to busy during the call.

This is my first shot at AppleScript so shouldn’t be used as model code!


Call_Danube_Services_Conference_and_My_Cell.scpt

Who needs cron? Here’s how you can set up iCal to invoke your own scripts at the scheduled time:
iCal entry to call AppleScript

–mj


Aping the Bonobos

May 22, 2007

Dr. Linda Rising (author of Fearless Change) explores links between human teamwork and that of other primates in this InfoQ interview by Deborah Hartmann. Her observations shed light on why teams larger than 10 are less productive than smaller teams (we are hard wired this way), how the subconscious mind contributes to problem solving, and other cultural issues that impact management practices.

Some of what she discusses in her interview might make you uncomfortable: politically incorrect generalities about how women contribute to Agile teams (confirmed by my own observations), “fuzzy” approaches to problem solving, and intimate behavior between bonobo apes that humans would be more inclined to keep private, if you catch my drift. You’ve been warned.

http://www.infoq.com/interviews/linda-rising-agile-bonobos (WARNING: POTENTIALLY OFFENSIVE)

I couldn’t help laughing about the different conflict resolution styles between chimpanzees and bonobos. Rising notes that throwing a bunch of bananas to a community of chimps will cause them to fight or intimidate each other until the dominant male and his sycophants have all of them. Bonobos, in contrast, respond to the same crisis by launching into a frenzy of, um, affection, and then later sharing the bananas.

We humans are equally related to chimps and bonobos, and blessed with the ability to choose when to use which model. In some situations we use force (or the threat of force) through our position in the hierarchy to get our way, without regard to the long-term consequences for the larger organization. This clearly works for many situations, or else chimps wouldn’t have evolved this way.

In other situations we can emphasize the relationship and work things out for our collective benefit, as the bonobos tend to do. A friend of mine decided to let 40 or so developers (five or six Scrum teams) figure out their own seating chart. It had been a source of stress because some spots were more coveted than others. So he gave them an hour to resolve it themselves, and left the building. He returned after 45 minutes to discover they’d already worked it out. One interesting thing is that the higher status people did not wind up with the more coveted spots. This is counterintuitive if we use chimps as our role models, but makes perfect sense when we take a broader view of self interest.

Dr. Rising’s findings suggest we can resolve conflicts for longer term gain by starting with a mutually enjoyable experience, such as the Fearless Change “Do Food” pattern. So let’s have lunch.

–mj
Michael James
Software Process Mentor
Danube Technologies, Inc.


Recent Danube Agile, Scrum, etc. articles

May 9, 2007

We’re doing our more serious blogging at the Danube website. Here are some recent articles:

Also note, the latest version of ScrumWorks Pro was released Monday. ScrumWorks is the only software PM tool designed exclusively for Scrum. ScrumWorks Basic is still free, so there’s no reason to be using Excel spreadsheets for this.

–mj


JUnit Is Not Just For Unit Testing Anymore!

March 7, 2007

http://danube.com/blog/michaeljames/junit_is_not_just_for_unit_testing_anymore


Don’t be stupid on purpose!

February 24, 2007

This’ll be short. This’ll be a rant. Here goes… I’ve taught three scrum classes in the past two weeks, and I get a lot of questions like “…but, scrum says we’re supposed to produce releasable product every sprint, and that’s too hard – so we can’t use scrum, right?” or “scrum says we’ve got everybody we need on our team, but we’ve only got one tech writer, so we can’t use scrum, right?”

WRONG! The essense of agility is reacting to the reality that is right in front of you, and scrum is just a management framework for doing that. I know that every process is a crutch that takes care of the easy stuff for you, but that does not give you license to give up thinking altogether, does it? Sorry, rhetorical question… what I meant to say was “this does not give you a license to be stupid on purpose.” And, when you know something is not going to work for you, and you do it anyway, that is being stupid on purpose. Don’t do that!

Just do the best you can. Your reality is seldom the reality you want – deal with it, improve it, and get on with things. Just keep moving…

Ok, I’m getting calm now… backing away from the keyboard… talk to you later…

Dan 😉

Dan Rawsthorne
dan@danube.com


Why RUP Failed

February 21, 2007

What went wrong with the Rational Unified Process? A lot of smart people were involved with creating it, and it seems to incorporate so much wisdom and experience. In the early 90s I was very influenced by Grady Booch‘s ideas. I believe he helped us write some of the world’s highest quality code for aircraft/spacecraft embedded systems, in Ada of course. (Ada is still the best language I have ever seen, both for determinism and readability. But that’s a topic for another day.) How could he have let me down?

At first glance the RUP seems to give us standardized, well thought out ways to handle situations that come up over and over in software projects.

But every time I hear about RUP nowadays, it’s in association with a project failure, or at least waste that people would like to eliminate. In Agile circles, RUP advocates constantly take on the role of apologists. “RUP is actually incremental and iterative! You just haven’t seen RUP done right! Scrum is just a highly tailored version of RUP!” Etc. It starts to sound shrill. It reminds me of my leftist teachers who kept insisting communism wasn’t actually that bad, we just haven’t seen true communism yet. Granted, communism has killed 100 million people (and counting) while (as far as I know) RUP hasn’t killed anyone except Scott Ambler.

I guess I’m a little like these people by ranting against “ScrumBut.” But even doing Scrum badly is usually an improvement over what was happening before, while doing RUP badly usually seems to make things worse.

Here’s how most people tailor RUP: They start with everything — or at least everything they know since no one seems to know all of RUP. Then they remove the parts they can justify removing.

When people do Scrum, they start with the simple, bare bones framework, and add things they can justify adding.

In theory, the additive and subtractive approaches should meet in the middle with the same result. But due to where we put the burden of proof, we get a cleaner result by starting with a nearly blank slate and only adding things we determine we need.

–mj
Michael James
Danube Technologies, Inc.
http://danube.com/blog/michaeljames/
http://scrumworkspro.com


Information Really Does Want To Be Free

February 15, 2007

Information Really Does Want To Be Free
(or, devoted to indignation and information)

In the spirit of Open Source and Agile-ness, a peer of mine shared the following (Java) frameworks Open Source code. I have personally reviewed the code and approve, note: I am not a software developer. I did want to share it with you however, and I hope you find it useful as well as inspiring.

http://chriscoy.wordpress.com/2007/02/14/
javaspaces-the-codebase-problem-and-a-solution/

Rationale: We require access to un-obfuscated source code because you can’t evolve programs without modifying them. Since our purpose is to make evolution easy, we require that modification be made easy.

I admit, I did have to look up the meaning of “un-obfuscated”…

Un – ob – fus – cat – ed:

Not to make so confused or opaque as to be difficult, to perceive or understand, a clear solution.

I like that, my Scrum interpretation:

We require access to information and open free communication within our team as equals because we can’t secure hyper-productivity individually or with draconian micro-management. Since the purpose of Scrum is to evolve as a team, we unilaterally require respect as professionals, open daily communications and honest straightforward interactions within the Scrum environment.

I like that too. I can’t imagine ever working in a non-Agile environment again. Yes, as a recruiter for Danube, I am on a Scrum Team, 2 week sprints and all. I may be the only recruiter in the world doing such, who knows?

Crystal Richardson
Agile Talent Specialist
Danube Technologies, Inc.
Office 503-630-4114
Danube main 503-248-0800