Archive for the 'project management' Category

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

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

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

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

A personal story about validation

February 13, 2007

For the last few months I’ve been remodeling my bathroom, a little bit at a time. One of the easier (though crucial) tasks was to paint the bathroom. In agile terms, this was an epic, as it would take a number of stories to take advantage of my free time. So, the first story was “Buy Paint”. Grace (my wife) and I went to Lowe’s, picked a paint chip, bought the paint, and took it home. Story complete, right?

Well, that weekend, while Grace was away, I painted the bathroom to surprise her. Great job, too, no drips, no spills, no errors… then she comes home. “Too purply,” she says, “do it again.” So I did, and I had her check the color after the first chunk of wall… I learn from my mistakes.

“So, Dan, what’s the point,” you ask. Good question, and here’s the answer. My story “Buy Paint” was not actually complete, as the result was not ‘fit for use’ in the next story, “Apply the Paint.” This lesson came in real handy when it came time to buy the grout for the shower, let me tell you.

We went and selected the grout and I spent an hour applying it to some scrap tiles on a piece of plywood. The next day we took it around and looked at it under various lights, and determined it was too light in color. So we did it again and selected the right color. This was a GOOD THING, as redoing grout is a royal pain, so we would probably had to live it.

“Ok, ok, is there a lesson here?” You betcha! Think hard about your “doneness” criteria for a story or PBI. Make sure that these criteria focus on fitness for use, not just on being finished… this will keep you out of trouble.

Dan 😉

Dan Rawsthorne
dan@danube.com

The Simplest Resume That Could Possibly Work

February 11, 2007

Usually when I see words like “methodology” I get the impression the writer is more concerned with sounding smart than with communicating. Look at me! I know a five-syllable word! This doesn’t bode well for how a person will do on a team.

I just saw a resume that said “I utilized the Scrum methodology.” Oh please! Can I trust a methodology utilizer to do the simplest thing that could possibly work? I’m more interested in people who have practiced Scrum, or at least WANT to practice Scrum.

By the way, we’re hiring ScrumMasters and C#/.NET developers, particularly in the Pacific Northwest. Get your simple, clear resume to me or Crystal.

–mj

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

CSM in the EU – breaking my mental barrier

February 9, 2007

I’ve been trying to plan this European Scrum tour and I just keep hitting these self-imposed roadblocks! All of our modern technology and the internet have narrowed the once-gaping distance across oceans, but somehow that just makes everything seem more intimidating… I’m not really sure where to start on getting the word out. I’ve been meaning to join some groups (maybe on meetup.com or something) but I don’t want to be invasive. Yes, I’m selling something, but I’m really not doing it because of the selling. It’s because I believe in what we have to offer and I think that everyone should embrace Scrum (it’s very evangelistic, I know). I usually use a lot of CraigsList (which is one of my all-time favorite personal and business reference tools) doesn’t appear to be as widely used in the European cities that I’ve searched. I’m a little confused by international phone numbers (and I think that our database is too), so a lot of our current customers can’t be filtered by area code the way that our domestic customers can be. I’m sure that it’ll all come along fine, but I’m frustrated by my own lack of knowledge and direction… Ack!

Tommi

Hey you, stop asking questions!

February 8, 2007

I survived a painful phone interview with a candidate today. I can only describe it in the following manor: imagine Batman saying to Robin, hey sidekick, take your own car and don’t crash here either. Or, a football coach saying, it’s not about the team, rather individual performance!

This applicant had prestigious employment addresses such as highly rated research centers, recognizable global service providers, a PhD from a top rated university, with titles along the lines of Sr. Systems Architect and Scientific Programmer, with 15 years experience. Pretty impressive so far.

I was really looking forward to talking with this person. After all, in general, I hold the endeavors of most institutions of advanced research and learning in high regard.

After exchanging the usual pleasantries and introductions within the IT industry, I asked him about his experiences with Agile practices, admittedly, he said:

“I do not know what this is, what is the meaning of this? Agile? What is this? Not something for me to care about, who cares about this?”

I tell him it is a methodology, a way of developing software, it is not technology specific. Agile exists to address the high
percentage of software projects that fail in various ways for different reasons.

“The industry leaders, the international companies, they are not practicing this, this is something new, they did not get where they are using Agile, it is not widely accepted in the market, so, it does not matter to me. Why do you keep asking these questions about methodology?”

At this point I mention I am a bit surprised at his responses. His voice raises, he starts talking wildly about things like global politics mentioning world leaders and established industry standards.

I was able to end the conversation relatively gracefully by saying I’d send him some reference material.

I do respect insights based on higher learning. However, I do not appreciate uninformed resistance to new ideas. This quickly seems ridiculous. Never, ever, stop asking questions. Never, ever stop increasing your knowledge.

Crystal Richardson