Dr. Alistair Cockburn will be in Israel.
I recommend you this user-group: Scrum Event. come and learn from the best.

See you there.

After one year of implementing Scrum at my place, I was asked to give a lecture to a new Team-Leaders, This Wednesday I will have my first Scrum Session, I spent a lot of time for the last few weeks to create a cool Presentation, I've also spent some time reading lots of data (some of them even more than once) about the Agile manifesto and its different methodologies.

I will update later on about the first session (next week). But to my readers I will give one great tip, two books bonus for a better start for your agile development:

This two books are "better together" - While reading them both you will understand:

1. Why to choose Agile (Or: The Values of the Agile manifesto)
2. Better Understanding for the problems within methodologies (Not only the non-Scrum ones)
3. What is agile at all - I've found many people not understanding the meaning of being Agile.
4. What is the difference between the methodologies (Scrum, XP, Crystal etc.)
5. Implementation (especially Scrum at Ken Schwaber's book)
6. and many samples from the experienced writers.

And here are some bonus links to my learning phase for the last year (stories from the last year as a Scrum-Master):

1. Scrum methodology - the scrum master
2. Trying to manage the team-pace better (or- Entering to Scrum For TeamSystem Template)
3. Improve your scrum Environment
4. Scrum for Team system feature requests

And here is one article I've found while start writing (back in the past while I didn't even know about being Agile)

1. Acceptance Tests

I hope you will enjoy those books (and links).

My team have been using the Scrum for Team-System template for the Team foundation Server
First, I must recommend this template to anyone who use Both scrum methodology and TFS as its source control.
Second, I would like to share with you new features we thought that would help us perform better.

I adopt the way of writing requirements from the Scrum4TS Forum:

As a <role> I want to <goal> so that <reason>.

Feature 1:
As a product manager,
I want to have the ability to create User stories in TS,
So that we can manage our user stories there instead of manual cards.
** Some may say that the Product Backlog Items also can be used as User-Stories - but I think they lack some important fields.

Feature2:
As a scrum master\product manager,
I want to have an automated task board view at the TFS,
So that we can manage our tasks visually on screen instead.
of duplicating tasks both in TS and by hand on boards

Feature 3:
As a manager\scrum master\programmer
I want the ability to see the current sprint tasks (also current sprint stories or current sprint products,
So the programmers can easily watch only the given sprint tasks.
(how? we may create fields for the given tasks which holding its dates)

Feature 4:
as programmer,
I want the ability to see the prioritization of my tasks and not only the prioritization of the product backlogs,
So I should now from where to start

Let me know what you think about the lack of those features.

For the last few weeks I read a lot on how to improve my team's Scrum environment and on how to create a more Agily workspace. I might also add here that we Scrumming for 9 months (on each month we change something else, improving, destroying, thinking again, etc...).

Collecting and reading great posts, I will share them with you:

• Cork Task Boards
• Scrum Room = Fun Room
• Oren Ellenbogen on Continuous Integration
• Chris - talking about Done

Those few Samples cause me think about how can I upgrade our environment, And I'll Explain my changes:

Programmer environment - better productivity
Upgrading the Programmer environment to a more productive workplace - Thanks to Yossi, we have two screens for each programmer. Now everyone can code on once and test on the other screen Or maybe can code on one and read the Design Requirements on the other, etc.

Cork board 
I've found out that most a the programmers do not really understand what everyone telling at the daily-standup-meeting, which cause them to dislike the meeting or maybe even forget the importance of this meeting.
The Cork-Board will help us to see (visualization) and understand(movement-at-realtime) the actual point of the team in the current sprint.

Done
People are different, This is a good fact, and we should understand it.
You need every one in your team understand what the Team want from him only his best. But when we can't explain ourself, someone can understand things not properly as we meant them, this will cause anger and disappointment.
Create a short document explaining what is Done - so everyone will be coordinated.
(Some types for Tasks that need to be Done: Writing Story Cards, Updating documentation, Coding, Bug-fixing. each one of those need to be fully Done)

Testing (not TDD yet)
Logic:
For me, one step before TDD-ing, the team must have a solid tests and a good understanding about the difference between integration, functionality and unit.
Framework:
After understanding the logic, you must have a solid framework for testing and a daily notification about your operations, so you and everyone else could see that you are working as we expect you to work.
So we create the Continuous-Integration workspace using the CC-Tray so everyone could know whether their friends are helping them or preventing from them to work properly.
The Imporatnce of testing:
After having this simple understanding, and this framework, everyone will finally understand that his testing methods are important.
And everyone will understand that unit-testing are part of the Done statement.
Moving to TDD-ing:
From here I believe that we could move toward TDD-ing.

Daily Scrum Standards
Right on time meeting, Every one standing, Only one people talking, Exactly 15 minutes, clarifications questions only.
Selecting the leading watch - everyone has its own watch, the team should understand which-watch is the one to set the scrum time. (I should buy an Egg-Watch, I am still looking for a funny one).

Setting Punishments (Penalties)
They should be a funny penalties, so everyone will like it (everyone but the one who doing it, of course).
like bringing the milk, or making coffee for everyone.
I see those punishments for a few fields:
a) destroying the build(errors and warnings)
b) checking-in tests that fail
c) decreasing the Code-Coverage,
d) late for Daily-Scrum

Here are some pictures from the new environment

                                            My Agile Workspace 

                                           Two Scrum Boards

 
                           The new Cork-Board (still empty, till the next sprint)

Things To Be Done, {Till the end of the year}:

1. Find a funny (noisy) Egg-Watch
2. Create a field_penalty_list
3. Moving toward a TDD-ing sessions
4. Decide about the best period for the sprint (today we decide about two weeks, I am start thinking this one is too short)
5. Find the Product-Owner (This one may sounds funny, but we still did not find him\her, no one can take this position for now)

Scrum is not only the things you are saying and doing, it is more about what you (and your team) are feeling.
Scrum should be part of everyone in the team, so it will succeed.

At my team we start using the scrum methodology, we are now learning this stuff on the fly, for further understanding I recommend reading Avi Wortzel blog. Avi is the other team leader and a good friend and I admire his way of thinking, pay attention to him.
As Avi said, on daily meeting post, we are two team leaders and we make together the daily meetings (6 people), we both scrum masters each one gets his turn.

I would like to share my thoughts with you:

1. Fix the "daily meeting" method (or, one more question to the casual three questions)
   • The problem
     I have a problem with the way people are letting you know what they are going to do today, for example: I am working on this module or I am doing that aspx page. The real problem is that the day after it will probably be the same task.
   • Resolving the problem
     • my first rule: talk about the things you really do, the problems you are trying to solve today.
     • I also added one more question, "what did you had to do yesterday and didn't make it".
       This question is the connection between the first and the second. so a co-worker should say: "Yesterday I did this and that, and didn't make this," and then continue with: "today I would continue in that and this"  or maybe: "I won't make it today also it will be postponed to the next week".
     • Don't ask: "why didn't you do this!", you are a scrum master, not a mother, this will annoy your programmers! (read the "Talk to your co-workers not to me: " section for better understanding) .
2. Keep the order for better understanding.
   • The problem
     • programmers told me that they are confused and do not understand a word from the other programmers, there are many way to solve this issue.
   • Resolving the problem
     • try to keep the order of the sentences, about yesterday, today and impediments while the fourth question is like a hidden question between the yesterday and today.  the fourth is a connective question, you should still distinct between the three parts.
     • don't mess the sentences order, it will cause a confusion in some of your co-workers.
     • there are people who like to talk, that is not a problem, but do it in your turn, and in the right order.
3. Talk to your co-workers not to me:
   • The problem
     • I always feel that people are talking to me and not to the other co-workers at the room, I don't have a good solution for this issue, but as far as I know it will take them time to understand it.
       You are probably asking time? so when? I think that on the day that they will really feel that the last meeting was helpful to you he or she will do it right.
   • Resolving the problem
     • I don't have a good solution for this issue, but as far as I know it will take them time to understand it.
       You are probably asking time? so when? I think that on the day that they will really feel that the last meeting was helpful to you he or she will do it right.
     • Scrum master questions: don't!, if you are the team leader & also the scrum muster, you should try to be less dominant, your workers\programmers always feel that you are testing them, yes this is true the team leader is always watching you, but try to do this without irritate them, let them feel you trust them, let them make their mistakes, this will also help them feel that they are talking to their friends not to you. (it sounds stupid, but there is a lot of ego in the room after all, and some one should give up).
4. Implement the whole class do not left stubs out there. (or, daily meeting as a part of the whole scrum methodology)
   • The problem
     • People are implementing only part of the system.
   • Resolving the problem
     • I don't think that this is a real big problem, but you must understand the strengths and weaknesses of each feature in the methodology so you could choose whether to implement or not.
     • I think you can't do daily meetings without the scrum review.
     • I do think that you need to implement the whole methodology together, but if you need to start, it is better to start with
          part of the methods and learn the other on the fly.

What do you think?