When some people talk about the future of Agile approaches, and Scrum in particular, they consider the spread of Scrum outside of IT. To properly accompany the Agile transition to another world, I think that asking how to move Agile outward from I...

As we prepare for RallyON, our annual user conference here in Boulder, I got to thinking about some parallels in my life as a purveyor of eggs. Our Rally staff is well familiar with the dozens of eggs I bring each week from our small farm, laid by my varied chicken population. They sit in cartons at the feet of my stuffed penguin muse, Bernard. Bernard nurtures and guards those eggs like any male penguin (March of the Penguins, anyone?). But what does this have to do with a user conference? Back to the eggs, and their source: the hens that lay them.

We have several nest boxes back at Martens Farms Incorporated, each shared by the many hens that are laying eggs. Interestingly, the hens are only in the nesting boxes to lay eggs; they are purposeful in that visit. Each hen contributes to the daily egg production, and is identifiable by the egg itself. When we gather the eggs, I know that our Bantams lay the small white ones (most of their energy is put into growing flamboyant feathers), our Araucana lays the light blue ones, and the very large brown eggs are from our Orpingtons.

Where am I going with this? In our Agile practices we collaborate across roles, across functions and across projects, contributing to the common vision and organizational goals. We share nest boxes (or in office parlance, cubicles or open space) to facilitate that collaboration. And we trust and celebrate each team member's unique and valued contribution (blue eggs!). The overall Agile organism–or organization–is bettered and team members interact in ways that serve each and all.

When we come together as a cross-functional group, removing even company and organization boundaries, we all get better. We share a nest box of ideas, new ways of thinking, and open minds to the different colors of eggs in our collections. RallyON is just such a place, where collaboration is celebrated, innovation is fostered and practices are developed or re-defined. I hope you'll join Bernard and me for this year's conference, where we'll carve a new path forward for Agile leadership at scale. And who knows, maybe I'll bring over a few blue eggs.

Join us in Boulder, CO to learn from industry experts and peers, hear what's next for Rally's product suite; and have a little fun while you're at it!

Schedule of Events

RallyON Hackathon
Fri - Sat, May 31 - June 1
National Civic Day of Hacking
Sat - Sun, June 1- 2
RallyON! Conference
Mon - Wed, June 3 - 5

Ryan Martens

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 6)

Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum

Stephanie G.: Now that we have already spoken about the Daily, I would say we continue with the first meeting of a Sprint – the Sprint Planning 1. Anything you would recommend to watch out for in this meeting?

Kristina K.: I sometimes find that Teams do not really discuss Stories or ask questions about them prior to Sprint Planning 1. As a ScrumMaster, one should keep an eye out for this. Particularly with distributed Teams, one should try to arrange discussions that would normally emerge in an everyday Team setting i.e. during lunch time after an Estimation Meeting. I  could imagine that the distributed setting makes the use of the Sprint Planning Checklist even more important, as it provides the Team members with a clear structure and can inform them about the Story by way of going through a set of topics. As you can hear, I find the preparation for Sprint Planning 1 – meaning the discussing and clarifying of the upcoming User Stories – to be absolutely vital. Ideally, the Team members should enter the meeting already knowing the upcoming Stories really well, so that they have lots of ideas for i.e. Acceptance Criteria and a list of questions prepared. In the best case, the meeting is shorter than the planned time-box.

Ina K.: Yes, it‘s the Product Owner‘s responsibility to give the required information to the Team in advance and make sure that it has been registered by all of the Team members before going into the Sprint Planning 1. You‘ll laugh – but yes, this also includes the access to where the Product Backlog and any additional information can be found.

Hélène V.: I recommend that – at the very beginning of Sprint Planning 1 - the Product Owner should give an overview of his expectations of what he wants the Dev.Team to have achieved until the end of the Sprint.  It is important that everyone on the Scrum Team has one shared big picture of the product. After that, there‘s always the possibility of dividing up into smaller groups either cross-location or per location and only coming together in Scrum of Scrums.

Kristina K.: And don‘t forget to take more breaks than you normally would, since it‘s much more exhausting to do it over the phone. Also, make sure to involve everyone as much as possible, so that they don‘t fall asleep at the other locations.

Christof B.: Since the Sprint Plannings are the longest meetings in Scrum, it‘s important to be visually connected as well, as it‘s much more difficult to stay focused if you can‘t connect any faces to the voices. In the past, I‘ve actually attended the Sprint Planning of Ina‘s Team and it was always interesting to see how she would use a standard webcam and play film director with it. It‘s not very interesting to see static images – the mind stops noticing them after a while – but if you do it like Ina, who used to walk around the room, film people when yawning or chitchatting, it‘s much more entertaining and more real-life, I would say.

Stephanie G.: Ina, that sounds like you had quite a lot of fun during your meetings. But now I‘m wondering – what happens during the meeting itself?

Bernd K.: We actually came together for every second Sprint change, which was very helpful. For every other Sprint change, we generally used our tool iceScrum and while the PO would present his Stories one after another, each location would follow his talk on its respective screen. Whoever then had a question could use the computer mouse to circle the part in the User Story that needed more detailled explaining. However, we always had to ask explicitly whether the persons in Rumania had any questions, as they mostly had their microphones on mute due to the background noises in their office. Furthermore, the quality of the audio tool was not ideal, which meant that we had to repeat ourselves quite often. But the Sprint Planning 1 really made the progress of the Team quite obvious: in the beginning, the guidelines where more or less dictated, yet after a few months, the Team really began sitting down and typing up Requirements, User Acceptance Tests etc by themselves.

Deborah W.: We always used flip charts. I think that if you use actual paper, it might be easier for people‘s minds to start wandering off, while on the other hand, it‘s also much easier to get them involved again. We used flip charts on both sides and had static cameras streaming the image, and while the one location was writing, the other one saw the scene on their screen. We switched to the other location’s flip chart after every Story. The cameras were excellent, so we could decipher everything. Besides, we were also connected via teleconference. A piece of advice: if you don‘t have the chance to set up flip charts in all locations, then try to involve those watching with some small tasks – for example: get them to write down User Acceptance Tests in advance. Anything to get them mentally involved.

Christof B.: Yes, and don‘t forget to send the pictures of the flip charts to the other locations afterwards, so that they can print them off and hang them up on their own walls, too.

Stephanie G.: Alright – thanks a lot. Anything else to add that we haven‘t covered yet?

Ina K.: One last thing. What I always enjoyed doing as a ScrumMaster was to ask the Dev.Team a few – perhaps simple -  questions, particularly when a Team member looked slightly lost. This way, I make sure that nobody loses face by having to ask a question that should really be clear to all members of the Team. In the past, my questions have often triggered a discussion within the Team, showing that there had still been some slight confusion. Having asked my Team members for feedback, I‘ve also learned that a lot of questions aren‘t asked, as they think that it would be embarrassing and they‘d rather wait for Sprint Planning 2 in the hope that it comes up automatically. With this in mind, I would say that asking questions from an “outside perspective” almost belongs to the ScrumMaster‘s job description under the aspect of „Protect your Team“.

Stephanie G.: Thank you for all your input. Our readers will surely appreciate that a lot. Summing up the steps, you would recommend:

1. Make sure  that the Team comes prepared and knows the Product Backlog.
2. The PO should start the Sprint Planning 1 by presenting the big picture.
3. If you can use flip charts, do so – but don’t forget to send the images to the other locations.
4. Ask (some simple) questions to make sure that everyone has the same understanding.

Alright, now what about the next meeting – Sprint Planning 2?!

Related posts:

1. Sprint Planning with geographically dispersed teams located in different timezones
2. Should internationally distributed Teams be avoided?
3. The Pros and Cons of Electronic and/or Physical Taskboards

The Agile Atlas is a web site supported by the Scrum Alliance which is an information resource for Scrum and Agile practitioners. The purpose of this site is to provide an “encyclopedia” of information about Agile and related methods. Although the site is presently supported only by the Scrum Alliance, it is not intended to be a Scrum-only site in any way. We propose to provide as broad and deep a view of all the information topics relating to Agile, Lean, and even plan-based methods. We propose to cover as many ...

One of the worst myths of agile, is that people think agile means to not plan at all. Actually, we do not plan in a traditional way, beacuse we use the rolling wave planning technique and we make a great use of visual management. When starting a new agile project, there are some mandatory plan [...]

Inspect and Adapt; Learn and Delight. Simple mantras keep us focused on the right things. My course program reflects these principles.

I extended and adapted my course program, based on feedback from my participants. What are the most biggest questions and requested improvement?

1. How do I apply this to my company?
2. How do I get management on board?
3. This course needs more time to cover the material
4. I need a course in German

To address the requests, I have updated my course program:

• CSM/Scrum in Management and Manufacturing - together with Joe Justice, I will be teaching a Certified Scrum Master course on applying Scrum beyond Software - get your management on board, get the rest of the organization agile! Book Now - course date May 28 & 29, 2013 (see more info, register )
• Certified Scrum Product Owner Courses - after Summer Break these will be a three day class so you can get beyond the basics of Scrum and focus on how to Leading Innovation effectively! (see more info, register ) 
• Certified Scrum Master Courses are now offered as 2 day or 3 day courses - you can book for two days or three. The third day is dedicated to Leading Change in a Scrum context. Apply the principles of delighting the customers.
• German language classes - this spring I have been offering courses on the principle English on demand, German on consensus. This fall I have courses that are guaranteed in German. (see the calendar for details)

BTW - My best kept secret is the Master Class Workshop: Scrum, Vision and Team Performance. I have been getting reports of tangible transformations within organizations, even just a few weeks after a few leaders participated in the workshop! (see more info, register ).

Nahezu jedes Unternehmen hat Erfahrungen mit der Beauftragung von Software-Entwicklungsprojekten und das sind zum Teil schlechte Erfahrungen. Durch solche schlechte Erfahrungen haben über die Zeit immer mehr Organisationen das Vertrauen in ihre Software-Entwicklung verloren. Ich möchte nicht behaupten, dass es nur furchtbare Software-Entwicklungsprojekte gibt. Aber ich behaupte, dass wir hier zu großen Teilen in einer Vertrauenskrise leben. Diese Vertrauenskrise hat nicht nur mit enttäuschten Erwartungen zu tun, sondern auch mit einer veränderten Welt, in der Vertrauen nicht mehr über langfristige Bindungen aufgebaut wird (Vertrautheit), sondern in der Schnelllebigkeit entstehen muss. Wir brauchen also einen anderen Weg, um Vertrauen über mangelnde Vertrautheit zu entwickeln. Kommen wir nochmal zurück zu den Software-Entwicklungsprojekten und verallgemeinern kurz: Umso weniger Vertrauen besteht, desto mehr Kontrolle möchte man ausüben. Vertrauen und Kontrolle versteht man weitläufig als entgegengesetzte Pole, die nicht gleichzeitig existieren können.

Wenn wir das Problem kennen, dann kennen wir doch auch die Lösung?

Vertrauen entsteht nicht über Worte, das wissen wir bestimmt, denn das ist neuronal in unserem Gehirn so verankert. Wir benötigen also Taten, die sich einer schnelllebigen Welt anpassen. Taten, die es ermöglichen, die Erwartungen eines Auftraggebers, eines Kunden und jene von Endnutzern mit dem Beauftragten abzugleichen. Wir als Software-Entwickler brauchen Lieferungen qualitativer, anwendbarer Software in kurzen Zyklen. Mit den Lieferungen zeigen wir, dass wir verstanden haben und liefern können was beauftragt wurde. Wir zeigen, dass wir den impliziten Anspruch auf Qualität halten können. Zudem rücken wir Kunden und Nutzer in den Mittelpunkt, beziehen ihn immer wieder in die Entwicklung ein und geben ihnen eine Stimme. Wichtig dabei ist, dass wir diesen Prozess wiederholen, ritualisieren, oft durchführen, damit wir als Software-Entwickler Verlässlichkeit zeigen können. Wir zeigen, dass es kein Glückstreffer war, sondern dass wir wiederholt qualitative Software  liefern können – wir zeigen professionelles Arbeiten. Im Scrum-Prozess stehen die Lieferung und das Präsentieren der fertigen Funktionen am Ende jedes Sprints, üblicherweise nach 14 Tagen. Am Ende jedes Sprints zeigt das Scrum-Team die lauffähigen Funktionen im Review den Kunden und Nutzern.

Da wir gerade beim Kunden sind, bleiben wir kurz bei ihm. Es wäre fahrlässig, würde der Kunde die Kontrolle aufgeben. Die beauftragte Software ist relevant für die Ergebnisse des eigenen Unternehmens und soll dazu beitragen, die Zukunft des Unternehmens zu sichern. Als Kunden brauchen wir also einen Kontrollmechanismus. Diesen Kontrollmechanismus sollte man nicht an Worten, konkret Verträgen, festmachen, sondern man sollte auch hier wieder auf Taten setzen. Ein wichtiges, wenn nicht gar das Kontrollelement des Kunden sind die Reviews, die er einfordern und aktiv daran teilnehmen sollte. Das Review ist die Fortschrittskontrolle und die Kontrolle des inhaltlich Gelieferten. Zudem ist es die Kontrolle über die Schnelllebigkeit der Märkte, denn wenn Sie als Kunde agil entwickeln lassen, bekommen Sie Kontrolle über Time-to-Market und haben Einfluss auf Änderungen – idealerweise sogar “Change for free“, solange sie auch den Umfang Ihres Produkts/Projekts anpassen. Dafür sollten Sie auch einen Vertrag aufsetzen, der das Ganze widerspiegelt. Auch das ist heutzutage möglich und sogar Wunsch bei vielen Software-Entwicklungen.

Fazit

Liefern wir als Software-Entwickler regelmäßig in kleinen Abständen mit hoher Qualität, so haben wir die Chance, zerstörtes Vertrauen aufzubauen oder dem gewährten Vertrauensvorschuss gerecht zu werden. Nutzen wir Rückkopplungspunkte wie Reviews dazu den Kunden einzubinden, lösen wir sogar das Paradoxon von Vertrauen und Kontrolle zu unserem Vorteil auf. Letztlich gewinnen beide, der Kunde und die Software-Entwicklung. Die Software-Entwicklung vielleicht sogar ein wenig mehr, denn sie hat etwas zurückzugewinnen und das gilt für die gesamte Branche.

Related posts:

1. Value Based | Nutzen Schaffen (2)
2. Scrum und Festpreis
3. Führung in Scrum | Manager | Teil 4

The Challenge of Conflating Size of Work and Time of Work In my Lean-Agile classes, I often ask people how far away something is.  For example, if I’m in Seattle I’ll ask them how far away Portland is. I usually get an answer like “about 3 hours.”  I respond by asking “I can walk there in 3 hours?” “3 hours to drive.”  “What if I have a private helicopter?”  We might think this is just some...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

I presented at the Results Oriented Web Conference in Dallas last week.  It was a very nice conference with lots of interesting people.  I had fun with my presentation, The Marshmallow Design Challenge.  Turns out it was finger licking fun.

Finger licking FUN!
Marshmallow Design ChallengeA winner - 26 inches tall.Wondering what this fun exercise teaches?  Watch the TED video to find out.  Spollier Alert - it's more fun to experience it and then watch the video.

Next time I'm bring one of these:

From Amazon

Please don't excommunicate me! This article may seem a little Machiavellian, because it is. There's a lot of soft stuff talked about business change. Anyone who's implementing Scrum in a Waterfall-centric organization will understand that the rea...

One of the suggested improvements for our AgileFest! 2013 was a  "How-To" document for planning a conference.  So in the nature of an experiment in gathering some "validated learning" I'm going to post a rough draft of this future book here.  If it gets some interest, hits, comments, suggestions then I'll turn it into an eBook.
Since this page will be an on going effort to create a draft, outline, sketch, etc. of the whole how-to guide, you may want to revisit this page in a week, and again in a month.First, creating a conference is an Agile project, so treat it like any other agile project.  Hold several visioning meetings and workshops.  Insure that you and the core group explore your vision of the conference, understand the explicit goals, and try to uncover the hidden agenda of the conference drivers.  Don't kid yourselves there are alterative motives - everyone has some, so get them out in the open.

Define what a success will look like.  Define what a failure will feel like.  Now simply create a set of actions that will move along this continuum toward success.  At this point you should be dreaming big.  There will be plenty of time to reign in the dreamers.  Wait until later, or you might just kill the conference right here and now.

How will you reduce the risk of putting on a conference that no one attends?  One way is to partner with a group that already has success, and is looking to expand their reach.

An example of this is Version One's Agile Palooza events.  Version One builds community via these partnerships with clients and host wonderful events.

"AgilePaloozas are the ultimate community events. They’re fun, low cost events that bring internationally recognized coaches and trainers into communities for a day of learning and advancing agile methods. These events are about serious agile learning in a fun atmosphere."

"The world of agile changes fast and AgilePaloozas are specially-designed to keep you in the know."

We partnered with VersionOne in 2012 for our first event.  Building upon this success we then created AgileFest! 2013.  An event so similar it was astounding, and also very successful.

AgileFest! GoalsIf you are use to agile projects then you must know about backlogs.  Creating a backlog of tasks, stories, and goals for your conference is an early milestone.  If having a template to iterate upon helps you, then use this one AgileFest Backlog (cvs).

AgileFest! Tasks

AgileFest! Improvements and Stories
Please leave a comment if you are interested in the topic or wish to download the backlog of AgileFest stories and tasks.

Edit: iceScrum R6#4 has been replaced by two successive minor versions that fix these bugs:

• ICESCRUM-648 – Estimation with « . » as decimal separator isn’t saved when creating a task (fixed in R6#4.2)
• ICESCRUM-524 – Impossible to delete stories from the backlog (fixed in R6#4.2)
• LDAP configuration is reinitialized (iceScrum Pro, fixed in R6#4.1)

Hello everybody,

This new version of iceScrum brings the following bug fixes:

R6#4.2 – R6 – Sprint 4 (08/03/2013 – 12/04/2013) Bug fixes

• ICESCRUM-523 – Tags lost when updating an element in table view
• ICESCRUM-645 – Better error handling on file and network interface exception when starting iceScrum
• ICESCRUM-643 – Display issue in the modal window when batch accepting stories in the sandbox
• ICESCRUM-629 – It is often impossible to delete a project
• ICESCRUM-637 – Sometimes, stories can’t be deleted
• ICESCRUM-632 – It is impossible to delete the last sprint
• ICESCRUM-636 – Pushed data don’t have the proper charset
• ICESCRUM-634 – Attachment limit is also displayed in tags (iceScrum Cloud)

Some changes require additional explanations, here they are:

• ICESCRUM-516 – Unstable language

Some users reported random language changes when using the tool. Please not that this may have lead to errors in iceScrum regarding invalid dates. Indeed, dates have two format depending on the language. Your feedback is welcome in order to ensure that all language / dates problem are solved by this fix.

• ICESCRUM-641 – No more IE6, IE7 and IE8 support at all

We wrote a blog post in order to explain why iceScrum won’t be accessible anymore for outdated Internet Explorer versions, and why we think it’s good for the future of iceScrum: https://www.kagilum.com/blog/about-browser-compatibility/

• ICESCRUM-640 – Unwanted logout after 30 min of inactivity

In the previous sprint, some technical changes under the hood restored the default behavior of our security system, which logs out users after 30 minutes of inactivity. Such a behavior is quite common on web applications so we decided to give it a try. However, agile development is user driven and your feedback isn’t very positive about that so this timeout will disappear in R6#4!

iceScrum Pro users, here are manual operations required in order to ensure this upgrade works smoothly.

• ICESCRUM-644 – Disabling LDAP plugin doesn’t work (iceScrum Pro)

Because of this issue, LDAP authentication may be disabled after the upgrade. Please ensure that you re-enable it so your users can log in!

• After upgrading, there is a corner case where your licence can be displayed as invalid. If such a problem occurs, please contact us and we will solve it immediately.
  

Before I joined Rally full time, Ryan and I sat down in 2003 and talked about what we wanted to do this time around. We had built other companies together and knew each other pretty well at that point. Though we loved very different things, we shared a worldview that was harmonious and compatible. I wanted to build a company of real scale. I knew that I wanted to have a tremendous impact on our community, on our customers, and on our employees. I wanted to build something that wasn't just a build-to-flip company.

So we created Rally. We hired our first group of developers, many of whom stood with us today, sharing our excitement on the floor of the New York Stock Exchange. Today's achievement represents a goal that was only a dream when we started.

Agile is not just about transforming the way organizations manage the software development lifecycle. It's about creating an environment where people truly love to come to work. It gives me great pride that we can have an influence on that. Ultimately, work is just part of our life.

I'm exhausted. I'm excited. I am so very thankful to all of our employees, our customers, and to everybody who has had even a small hand in supporting Rally over the years. And now I think I’m going to go to bed and sleep for 18 hours.

 

Tim Miller

I am going to be in London, May 16 and 17, 2013. I am offering two interactive public workshops, one on starting your agile project right, and a master class on coaching. See the detailed syllabus and signup page for Starting Your Agile Project and Coaching Master Class here.

The syllabus for Starting Your Agile Project Right on May 16, 2013 is:

1. Introductions
2. Chartering a project (vision and release criteria)
3. Working with sponsors to define the tradeoffs
4. Iterations, kanban, or both?
5. Create boards for maximum transparency
6. What to measure
7. Wrap-up and summary

The syllabus for the Coaching Master Class on May 17, 2013 is:

1. Introductions
2. Simulation
3. What is coaching?
4. How to coach
5. Explore coaching stances
6. Implementing coaching
7. Wrap-up and summary

The workshops will be held in the Clerkenwell area of London. I expect to finalize the location within a day or so. I hope that if you are in the UK, you will join me. If you have questions, please email me.

Hi! Here are my slides Stop Starting, Start Finishing from Aggro Pekuliar. Thanks for attending! And what a cool conference, nice to hang out with a bunch of non-techies for a change

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 5)

Part 1: Does distance cancel out efficiency of internationally dispersed Teams?

Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards

Stephanie G.: Now that we have discussed internationally distributed Teams in broader terms, I would like to get to the more practical part of this interview. Let‘s start with the most frequent meeting: the Daily Scrum. Would you say that it‘s more difficult to stay within the time-box of 15 minutes in comparison to co-located Teams? Is there something that you would really advise watching out for during the Daily?

Ina K.: No, I wouldn‘t say that it‘s any different in terms of keeping the time-box. It‘s all about keeping an ear open for discussions that don‘t belong in the Daily. Sometimes it‘s just a matter of using the microphone and asking the Team, “Is the current discussion of interest to everyone? Could we perhaps talk about this afterwards?“ The ScrumMaster should always ponder over how the Daily Scrum could be made even more efficient, since a lack of concentration and focus by the Team members leads to a downward spiral of effectiveness. I always found it important to act as a kind of motivator, meaning that I would try to make the Daily Scrum at least a little bit entertaining. As a ScrumMaster, it is important to get a feeling for the Team – what jokes do they enjoy, what are their character traits, do they prefer technical discussions, do they ever speak of their private lives etc.?! Once you understand your Team, it is much easier to integrate the Team members from the other locations into the Daily. I have seen far too many ScrumMasters (no matter whether co-located or distributed, actually) that sluggishly stand in the background waiting for the meeting to be over – if you don‘t show any enthusiasm for what you propagate, why should your Team members?!

Kristina K.: Actually, in contrast to Ina, we didn’t stick to the 15 minutes, as the Team seemed to need a bit of extra time in order to make the meeting most effective. At the time, I found this to be more important than sticking to a time-box of exactly 15 minutes. It is no surprise, as my Team consisted of about 11 Dev. Team members and several locations. The English language levels varied strongly, the technology was a definite impediment and – as I have already mentioned during the previous question (Interview 4 link) – the tool did not facilitate the flow of the meeting. Still, I always continued analyzing the meeting in terms of its time-box, as this helped me to develop new ideas that could help my Team plan their day better as well as maybe hold an effective meeting in less  time.

Christof B.: That‘s true, Kristina, your situation is not so unusual. Distributed Teams are often larger than co-located ones. If that‘s the case, one simply has to accept the fact that it may take slightly longer than the standard 15 minutes. Also, communicating over the telephone with each other makes the meeting more exhausting (which is why Ina‘s tips are great, by the way) and if the technology was not specifically selected for the Team‘s needs, the likelihood of having to repeat yourself a lot is rather high. Staying within the 15 minutes time-box can really be quite difficult.

Stephanie G.: I‘ve also experienced that the technology has a large impact on the efficiency of the Daily. What do the others think?

Deborah W.: As a ScrumMaster, it‘s important to make sure that all the technology is set up properly well in advance. Ten minutes should suffice if it ensures that the equipment is ready to be used right from the start. As Christof mentioned – depending on the transmission (sadly, most Teams do not have the budget that we had spoken of earlier – see Interview 3), you might have to set the time-box at 20 minutes. When my Team started out, we only used to be able to hear each other, but after less than a week, the Dev. Team independently bought a webcam, so that they could combine the voices with images.

Bernd K.: Oh dear – speaking of transmission. I can‘t even count how many times our connection broke off during any kind of meeting. Also, we didn‘t have a webcam, so it was very important to ensure that everyone knew whose turn it was and who was currently speaking. Whether this is done by saying one‘s name before speaking, through colour codes in the Taskboard tool or some other way, is up to the Team.

Christof B.: I always liked the idea of having a Speaker Token, which can be passed around depending on who wants to go next. You can also play Ping Pong with the Team members in the other locations – Team member in location A followed by Team member in location B, then someone in location A again etc – but this makes it even more difficult to stay within the 15 minutes and the ScrumMaster really has to keep an eye out on who‘s up next. The advantage is that people stay more focused.

Bernd K.: Oh, that sounds quite good, Christof. I‘ll try that out next time. But generally, the Daily was interesting, as it showed a large cultural difference between the Team members in Romania, who were rather held back, and those in German, who would talk quite a lot. As a ScrumMaster, I had to ensure that everyone got his or her turn to voice the current progress of the Tasks.

Stephanie G.: I can imagine that if – as you say – the Team members in Germany were quite talkative, that must have made it difficult to stay within the time-box, as well?! I know my Team always wanted to use this meeting to discuss everything right away and get all questions answered – although these questions had mostly little to do with planning the work for the day.

Bernd K.: That‘s exactly one of the issues that we had. The Team was simply trying to use the opportunity that the connection between the two locations was already established. So I tried to separate the „Now“ and „Later“ a bit more strictly and pushed them towards using group chat rooms more frequently or setting up a telephone connection in the middle of the day in order to coordinate their work. I also encouraged the Team members individually to start picking up the phone and directly calling each other outside of the Daily, too.

Hélène V.: Bernd, I am completely with you. I would really advise to start using the Daily for shortly coordinating everyone‘s availability for the upcoming 24 hours. When sitting together in one room, it‘s easy to figure out the best available time for meeting up and discussing something. This isn‘t the same for distributed Teams. Another option would be to simply say that the Daily is automatically followed by another synchronisation meeting a few hours later. That way, coordination takes place more often and it becomes more natural for the Team members to talk to each other several times throughout the day. But I can say this about the Daily: It really is a challenge to ensure that everyone knows exactly what each Team member is currently working on. This is not just difficult for distributed Teams. But it is important to use the Daily for making this transparent! No matter which tool the Team uses, it should be elusive on what progress has already been made and what is still missing.

Stephanie G.: Thank you! You‘ve given our audience quite a few useful tips. Let‘s see whether I can summarise them as:

• Keep discussions short by objectively asking “Is the current discussion of interest to everyone? If not, could we perhaps talk about this afterwards?“.
• Enable the synchronisation of the work progress across locations.
• Ensure that the distributed Team members speak to each other again at some point over the upcoming 24 hours – whether it be during a second Daily, group chat, staying in the line after the Daily etc.
• Add your personal touch as a ScrumMaster and remember that it‘s up to you to make the meeting more fun and thus more efficient. 
• If the 15 minutes are not possible, make sure to set a different, but equally short time-box and work on eliminating the impediments that are hindering the Team from achieving the original time-box.
• As with every meeting, make sure that the technology is up and running well in advance.

Related posts:

1. Should internationally distributed Teams be avoided?
2. Sprint Planning with geographically dispersed teams located in different timezones
3. Scrum Spaces of internationally distributed Teams – the Do’s and Dont’s

The cleverness and dexterity of Egyptian workmanship, as evidenced in the pyramids, is magnificent. In them we can see the unlimited human capacity for imagination and architecture. Even today, researchers still study the organizational chart and ...

Protected Branches and mandatory code review give you a fast way to get your entire team working on test coverage and coding standards.

You will need this tool if you are interested in continuous integration or continuous delivery.  If you are adding continuous integration to your development process, you need tests.  You need to get automated tests from your developers.  If your developers are like my developers, some of them are enthusiastic about adding tests, and some of them don't bother. You probably work with smart, creative, opinionated individuals who don't always respond to requests exactly the way you want them to.  You can flail around for months looking like a jerk, and still not get the tests and standards that you want.

Code review is a simple way to get what you want.  You can send code changes to the team members who are enthusiastic about automated testing.  They will review the changes and, when needed, ask for better test coverage and standards compliance.  When we added this type of review to our process at Assembla, we got almost everything we wanted within the first week.  The change was fast and permanent.

Protected branches give you a ONE CLICK way to get what you want:

* Mark your master or trunk branch (the branch you run CI on) as protected.  Click.  Now, users who are not on a special list cannot commit directly. They have to make merge requests, which will get reviewed. 

* Git repositories give you a super simple way to enforce mandatory code review.  The system will automatically take a push to a protected branch, and move it into a temporary branch with a merge request.

* Find the developers who support your initiative, and add them to the list of people who can write to the protected branch.

You can try training, incentives, and persuasion for months and not get the test coverage and standards compliance that you want.  You will get them immediately with this simple tactic.

Protected branches are available for both Git and Subversion.

About the Author: David has enjoyed success using lean and agile techniques at several companies in San Francisco and Washington DC. He joined his first dot com startup in 1999 and helped lead it to a 13 million dollar acquisition in 2006.

David’s current focus is bringing startup thinking into large organizations to foster corporate entrepreneurship. He can usually be found writing, speaking and coaching around lean startup, business model generation and kanban.

You should check out this and other great tutorials by David on his site http://www.davidjbland.com/

A Business Model Canvas is an easy to use, lightweight and powerful tool for anyone looking to sketch out business models. It is quickly becoming the preferred strategic management tool for start-up organizations.

While it is available in .pdf form from Alex Osterwalder’s site, I couldn’t help but feel that companies could benefit from an online, collaborative version of his template.

So, I asked him…

It only takes a Google Account, a few minutes of your spare time and best of all it’s free.

Create a Google Drawing

Give your drawing a background color

Select the rectangle tool

Draw a large rectangle

Select the line tool and slice the rectangle up into 9 sections

Use the text tool to add in each section label

Include the help text for each section in a lighter gray font color (optional)

Fill in the background color and create the header & footer

Create sticky images in photo editing software

Import the sticky images into the Google Drawing

Drag the images off to the gutter so they do not get in your way

Use the text tool to overlay text onto your sticky

Drag the sticky over to your business canvas

Copy, paste and move the stickies around as needed

I’ve shared the Business Model Canvas I created in this demo if you wish to get a better idea of how it is structured. It is only a guide, and you can customize it in many different ways if you like.

Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.

When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!