By Mark Scott, Product Manager, Chrome

Cross-posted from the Chromium Blog

Event pages keep apps and extensions efficient by allowing them to respond to a variety of events such as timers or navigation to a particular site, without having to remain running persistently. But what if you need to respond to something that occurs outside of Chrome, such as a news alert, a message sent to a user or a stock hitting a price threshold? Until now, you had to do this by repeatedly polling a server. This process consumed bandwidth and reduced the battery life of your users’ machines. For a more efficient solution, starting today you can use Google Cloud Messaging for Chrome (GCM) - across all channels of Chrome.

GCM will be familiar to developers who have used Google Cloud Messaging for Android. To send a message, all you need to do is:

1. Request a token (channel ID) via chrome.pushMessaging.getChannelId(). 
2. Pass the returned token to your server. 
3. Whenever you need to send a message to your app or extension, post the message along with the token to the GCM server-side API. 

Your message is then delivered in near real time to Chrome. This makes your event page wake up (if it’s not already running), and the message is delivered to your chrome.pushMessaging.onMessage listener.



To use GCM, your users must be signed into Chrome, as the service relies on an efficient push channel that’s only established for signed-in users. Messages are automatically delivered to all the devices where the user has signed in and installed your app/extension.

To add GCM to your app/extension, take a look at the overview of the service or start with some of the sample apps—and start pushing!


Mark Scott is a Product Manager on the Google Chrome team. He works with a team in Kirkland on features that make Chrome a great platform for building apps.

Posted by Scott Knaster, Editor

By Nicolas Garnier, Developer Relations

We surf the web for a million different reasons – for everything from school research projects to time-killing memes. And when we find something relevant for us, whether that be our most recent pay stub or just an adorably awesome pic, we may want to save it for later reference or to share with friends in the future.

Starting today, Drive users can use the "Save to Drive" button to do exactly that. The “Save to Drive” button is an easier way to save files directly from a website. If you have your own website, you can improve the experience for your site visitors by adding the “Save to Drive” button to your page using two easy lines of HTML.

Saving an ebook to Google Drive from the O’Reilly website
Just try it out. Save this cute kitten’s image to Google Drive using the button below:
Credit: Krzysztof P. Jasiutowicz


Adding a Save to Drive button on your website is easy. You simply have to include the script and HTML tag below:

<script src="https://apis.google.com/js/plusone.js"></script>
<div class="g-savetodrive"
 data-filename="My Statement.pdf"
 data-sitename="My Company Name"
 data-src="/path/to/myfile.pdf">
</div>

You can also use the Save to Drive button’s JavaScript API, which allows programmatic and flexible control of the creation of Save to Drive buttons in your web pages.

The Save to Drive button works in the context of the user’s browser. This allows your users to save files that could require some form of HTTP authorization – such as a session cookie – without any special customization from you. In most cases, the Save to Drive button should be simple to integrate, plug-and-play!

Check out some companies that have already added Save to Drive buttons on their sites: Bigstock, Delta Dental, Fotolia, O'Reilly, Outbox, Ultimate Software, and Zen Payroll.

Saving a dental statement from Delta Dental
Saving your physical mail to Drive from your Outbox account
To learn more, have a look at our technical documentation, and if you have questions, don’t hesitate to post on Stack Overflow.


Nicolas Garnier joined Google’s Developer Relations in 2008 and lives in Zurich. He is a Developer Advocate for Google Drive and Google Apps. Nicolas is also the lead engineer for the OAuth 2.0 Playground.

Posted by Scott Knaster, Editor

Many geographically distributed teams struggle with stand-up or scrum meetings. This struggle can cause teams to stop holding stand-up meetings or even worse abandon Agile. Distributed teams need to work a bit harder to make stand-ups work, however there is no reason that you can’t hold effective stand-up meetings. Distributed teams tend to have three common problems holding stand-ups that can negatively impact effectiveness: finding a standard time, building solid relationships and making sure everyone stays engaged.

The first problem is finding a standard time that the team can hold their meeting on a daily basis.  Being spread across different time zones can make this a logistics nightmare. Try having team members shift their work schedules to create a time the team can meet. Don’t inconvenience one member or group of members for the whole project but rather spread the time zone pain by shifting who has to rearrange their day at the beginning of each iteration You can use tools like Doodle can help.

The second common problem for distributed teams is that it is hard to get to know your team members from afar.  Disembodied voices coming out of speaker are not optimal for generating the relationships that bind teams together.  Use video conferencing liberally (you do not have to use high powered video equipment to get the benefit, laptop webcams can be highly effective). Mike Cohn suggests creating a deck containing the picture of each person on the Scrum Team and then providing each team member with a deck. During meeting, team members hold up the picture of the person talking. The exercise helps team learn to recognize voices and makes it hard to answer emails at the same time. Raji Bavani of MindTree suggests getting the team together at least once when a large project begins, so that the team can match a face with each voice.

Finally, distributed teams sometimes find it harder for remote team members to stay attentive for the entire stand-up. Try having team members randomly alternate turns talking as one potential solution. When I see this issue, I suggest that the team check the agenda and make it very focused (that extra non-stand-up stuff has not be added), make sure the meeting runs no more than 15 minutes and ensure that the team is interacting with each other not just with the Scrum Master.

A stand-up meeting is important for the team to synchronize, plan their activities and identify impediments. A team that abandons the stand-up is almost always taking the easy way out, and will suffer in their productivity as a result. Distributed teams often need to leverage some of the more aggressive techniques discussed above to ensure that the stand-up meeting is effective.

A nice trick that business analysts can use now that collaboration technology like Google Docs exists is to allow meeting participants to simultaneously collaborate on documents during the meeting itself.  Simply have everyone in your meeting open up the document on their own computer, and then everyone can edit the document together in real time.  In spreadsheets, how this works is that whoever clicks to edit a cell locks only that cell for themselves, while every other cell in the spreadsheet can be edited by other users at the very same time.

This allows you do much more collaborative work in your meetings, and much more detailed collaborative work. Rather than relying on dictating your comments to the scribe responsible for updating the document, each participant can enter their own comments quickly and exactly as intended.  This saves time in the meeting, and also allows for more precision in the document itself.

Additionally, collaborating directly on documents allows for several different tasks to be taking place at the same time.  If one stakeholder is entering comments about one part of your document, other stakeholders can enter comments about other parts.  This prevents wasted downtime and allows stakeholders to work ahead when their topics are not being discussed.

A great use for this technology is to quickly gain a consensus on priorities. You could walk through a list of features and have a column for each stakeholder to enter their ranking of each feature. After you read off the name of the feature, wait a few seconds for everyone to enter their ranking, and then have a column that automatically averages all the rankings. Everyone can instantly see how everyone else has ranked the feature, and ask questions on the spot if they don’t understand other’s rankings. This may spur needed discussions and eliminate confusions about the feature. This method allows quick prioritization and records the input of every meeting participant, so there is no guesswork as to why a feature was prioritized the way it was. This allows everyone to have their say, no matter how many meeting participants there are. It works for small meeting just as well as for large meetings with dozens (or more!) participants. And distance is no obstacle. You could have participants all over the world editing the document as quickly as if they were in the same room as you.

A final benefit of opening your document to online collaboration is that the stakeholders can add more to the document after the meeting. If additional details or changes come to mind later, they can jump into the document and add them instantly.  Your document becomes a living document that doesn’t require repeated meetings to improve, since improvements can be made at any time day or night by all participants.

The quality and amount of collaboration your team experience varies greatly depending on the types of tools that you make available.  Simultaneous online document collaboration is a tool that you should employ as often as possible to make your team more effective through improved collaboration.

Want more tips? Check our BA online resources!

Collaborate on documents during your meetings is a post from: http://requirements.seilevel.com/blog

Conferences force us to sit next to people we don’t know, to interact during exercises and maybe even have a conversation that would not happen if you were watching a webinar in your cube.  Professional conferences force attendees to step outside of their comfort zone. Even if it is a tiny step, it can possibly change how we perceive the world.

Shifting outside of our comfort zone, a state of mind without a sense of risk, makes it easier see things differently. Our comfort zone can be limiting, because it insulates you from perceiving change. Dr. Bill Joiner, in his keynote at the Scrum Gathering, Las Vegas 2013, suggested that today’s managers must have the ability to achieve sustained success in a rapidly changing environment or they won’t survive. I translate that to mean that comfort zones are a thing of the past.

In person professional conferences are a tool to challenge us intellectually and provide a platform for changing how we think about our professional challenges. For example:

• Presentations that challenge orthodoxy that wouldn’t draw as mass-market webinars.
• Free form programming such as Open Spaces or Un-conferences that open the lectern to anyone with an idea or a question.
• Access to experts for formal and informal conversations.

Regardless of your profession, not challenging ourselves to move outside of our comfort zone will make us intellectually lazy.  Without challenges we can’t hope to raise our game to meet the future.  Attending professional conferences and benefiting from not only the presentations but from the interactions is a powerful tool to meet the challenges of tomorrow’s workplace.

There have several rounds of how to use analogies and how not to use analogies in the past few years. 

These involved notions like agile is an untended garden. Actually and untended garden and called a weed patch.

Or we can't really stop and develop a strategy, because we're always putting out fires. Actually firemen rarely put out fires. They spend the majority of their time preventing fire with fire safety, inspections, fire inspections. Their job is to never have fires start.

And of course for false analogies of the double pendulum as a stand in for chaos and unpredictability. Since the equations of motion are easily defined - an exercise for any upper division physics student - and a MathLab plugin, you can plot the path of the double pendulum. 

And my favorite the attractor analogy, in which it is presumed that some how in chaos theory the attractor attracts. Without understanding  that those pretty pictures of the attractor are the result of the underlying equations for the system.

So with that in mind, there is a new book from one of my favorite authors, Douglas Hofstadter, Surfaces and Essences. In the book Hofstadter makes the case for analogy as the fuel for creative thinking. Using Robert Oppenheimer's quote... 

whether or not we talk about discovery or of invention, analogy is inevitable in human thought, because we come to new things in science with what equipment we have, which is how we have learned to think, and above all how we learned to think about the relatedness of things.

But as always we need to take care to assure that those analogies we use to expand the conversation, don't violate the laws of physics, gardening, or mathematics.

Related articles The Misunderstanding of Chaos - Again Happy 50th Anniversary, Chaos Managing in the presence of all things

By Mike Winton, Director of Developer Relations

At Google I/O 2013, we will share the future of our platforms with you. Developers from all over the world are the key innovators of powerful, breakthrough technologies, and that’s why we challenged ourselves to make the Google I/O experience available to every developer, everywhere.

Watch Google I/O live
From the comfort of your own home, office, secret lair, or anywhere you have a reliable Internet connection, you can stream Google I/O May 15-16 live. Brought to you by Google Developers Live (GDL), the Google I/O homepage will become the GDL at I/O live streaming hub starting on May 15th at 9:00 AM PT (16:00 UTC). From this page, you can:

• Stream 4 channels of technical content on your computer, tablet, or phone. You’ll feel like you’re right there in the keynote and session rooms, listening to product announcements straight from the source. Live streaming will run on developers.google.com/io from 9 AM PT (16:00 UTC) to 7 PM PT (2:00 UTC) on May 15 and 16.
• Watch exclusive interviews with the Googlers behind the latest product announcements. This year, GDL will be on site, broadcasting one-on-one product deep dives, executive interviews, and Sandbox walkthroughs from the GDL stage.
• Get the latest news in real-time. We’ll be posting official announcements during I/O. You’ll be able to see the feed on the Google I/O homepage, in the I/O mobile app (coming soon), and on +Google Developers.
• Never miss a session. All Google I/O technical sessions will be recorded and posted to GDL and the Google Developers YouTube channel. Subscribe to our YouTube channel for archived session updates.

Live blog the keynote
Grab our live blogging gadget to add the keynote live stream to your own site or blog. Customize the gadget with your site or blog name, live blog alongside real-time Google announcements, and share a dynamic Google I/O experience with your readers. Have questions? For more info, check out our live blogging gadget FAQ.

Get together locally
Experience Google I/O with your local developer community by hosting or attending an I/O Extended event. If you’re hosting, register here and learn how to hold a totally epic event with our handy Organizer Guide. Otherwise, with over 400 sites in 90+ countries, chances are good that there is an I/O Extended event near you. Find an event now!

And before I/O, tune in to Google Developers Live programming to connect with Google engineers, prep for this year’s event, and browse our archived content. For official conference updates, add +Google Developers to your Circles, follow #io13 for big announcements, join the Google I/O community, and keep an eye on the Google I/O site.


Mike Winton founded and leads Google's global Developer Relations organization. He also enjoys spending time with his family and DJing electronic music.

Posted by Scott Knaster, Editor

Beautiful.

In a new digital economy and a world of ultra-competition, it’s great to shape a smart organization.

We learned this long ago.   Agile was part of the early Microsoft patterns & practices DNA.   We embraced agile methods and agile management practices.

We learned that execution is king, and that shipping early and often gives you better feedback and a way to make changes in a customer-connected way.

Here is what Gartner says …

“Accepting higher project failure rates can help organizations become more efficient more quickly, according to Gartner, Inc. Gartner said project and portfolio management (PPM) leaders who take a "fail-forward-fast" approach that accepts project failure rates of 20 to 28 percent as the norm will help their organizations become more agile by embracing experimentation and enabling the declaration of success or failure earlier in a project's life.”

Check out the article, Gartner Says Smart Organizations Will Embrace Fast and Frequent Project Failure in Their Quest for Agility.

This is an email interview with Viktor Klang, Director of Engineering at Typesafe, on the Scala Futures model & Akka, both topics on which is he is immensely passionate and knowledgeable.

How do you structure your application? That’s the question I explored in the article Beyond Threads And Callbacks. An option I did not talk about, mostly because of my own ignorance, is a powerful stack you may not be all that familiar with: Scala and Akka.

To remedy my oversight is our acting tour guide, Typesafe’s Viktor Klang, long time Scala hacker and Java enterprise systems architect. Viktor was very patient in answering my questions and was enthusiastic about sharing his knowledge. He’s a guy who definitely knows what he is talking about.

I’ve implemented several Actor systems along with the messaging infrastructure, threading, async IO, service orchestration, failover, etc, so I’m innately skeptical about frameworks that remove control from the programmer at the cost of latency.

So at the end of the interview am I ready to drink the koolaid? Not quite, but I’ll have a cup of coffee with the idea. 

I came to think of Scala + Akka as a kind of a IaaS for your process architecture. Toss in Play for the web framework and you have a slick stack, with far more out of the box power than Go, Node, or plaino jaino Java.

The build or buy decision is surprisingly similar to every other infrastructure decision you make. Should you use a cloud or build your own? It’s the same sort of calculation you need to go through when deciding on your process architecture. While at the extremes you lose functionality and flexibility, but since they’ve already thought of most everything you would need to think about, with examples, and support, you gain a tremendous amount too. Traditionally, however, processes architecture has been entirely ad-hoc. That may be changing. 

Now, let’s start the interview with Viktor...

The Scrum or daily stand-up meeting has a fairly structured format within the Scrum framework. Many teams make slight tweaks to make the process work better due the variations in teams and environments. However, allowing non-team members to actively participate in the stand-up is not a process tweak that ever makes sense. Stand-ups are the planning and synchronization meeting for the team. Adding active outside participants changes the dynamic. The meetings typically become more akin to a status update, or worse, an interrogation. It is difficult to collaborate when you are defending what you are working on. When planning and synchronization are impeded the team will deliver less value than should be possible.

When the stand-up shifts from a team meeting to an open meeting all sorts of changes happen. From a purely mechanical point of view two large changes can take the process off track instantaneously. First, less emphasis is placed on planning and synchronization portions of the meeting, assuming the time box of 15 minutes is respected. The problem is one of time if the conversation shifts t

o providing status or dealing with external interrogation of team members there will be less time for anything else. Second, if the meeting is given more time the participants’ attentions will wander. Both are problematic, but remember, once the collective attention spans have been breached, the effectiveness of the meeting is shot. Simply put, when team members stop paying attention to each other information sharing stops. How many times have you heard someone say “we talked about that this morning” only to be met with a blank stare?

The basic technique for a stand-up meeting states that anyone can attend the stand-up, if the team is comfortable with their attendance. While this might seem like a contradiction, attendance and participation are different activities. Only the team (product owner, Scrum Master and team members) can participate (read participate as talk). Tweaks to the process that expand participation past the team is simply a mistake.

Everything is simpler than you think and at the same time more complex than you imagine. ‒ Johann Wolfgang Goethe

I'm going to be speaking at Agile2013 in Nashville this summer. My 75-minute session will be part of an Agile Boot Camp track that is targeted mostly at people new to agile to help them understand the basic concepts, terminology, methodologies, and practices of agile development. My session will be on Monday, August 5 at 2 p.m. in the Delta B room. I hope to see many of you there.

Here's the session description:

Agile Planning & Project Management

In this session we will shatter the myth that agile teams can't plan. We'll start by looking at the benefits of the short cycles of iterative and incremental development. We'll then look at the six different levels of planning that occur in agile organizations. We'll see what user stories are and why they've become the preferred approach to planning and managing the work of an agile team. We'll look at how user stories are estimated with the popular Planning Poker technique. To do that we'll discuss the merits of relative estimating and abstract approaches such as story points and what a point really means. With an initial plan created, we'll look at how agile teams use the concept of velocity to measure and predict progress. We'll also look at information radiators such as task boards and burndown charts. We'll conclude by looking at how these concepts can be applied to complex situations such as fixed-date and fixed-scope projects.

I'm going to be speaking at Agile2013 in Nashville this summer. My 75-minute session will be part of an Agile Boot Camp track that is targeted mostly at people new to agile to help them understand the basic concepts, terminology, methodologies, and practices of agile development. My session will be on Monday, August 5 at 2 p.m. in the Delta B room. I hope to see many of you there.

Here's the session description:

Agile Planning & Project Management

In this session we will shatter the myth that agile teams can't plan. We'll start by looking at the benefits of the short cycles of iterative and incremental development. We'll then look at the six different levels of planning that occur in agile organizations. We'll see what user stories are and why they've become the preferred approach to planning and managing the work of an agile team. We'll look at how user stories are estimated with the popular Planning Poker technique. To do that we'll discuss the merits of relative estimating and abstract approaches such as story points and what a point really means. With an initial plan created, we'll look at how agile teams use the concept of velocity to measure and predict progress. We'll also look at information radiators such as task boards and burndown charts. We'll conclude by looking at how these concepts can be applied to complex situations such as fixed-date and fixed-scope projects.

Proactively managing logs can be critical to identifying and resolving issues within an application environment. We're excited to announce that Logentries is now available as an Engine Yard Add-on. Engine Yard customers can try it now for free. More information about Logentries on Engine Yard Cloud can be found here.

Through Logentries, users can monitor logs in real-time and get an easy to understand view across their entire application logs. Logs are analysed and visualised so that you can make sense of large volumes of log data, to quickly see and resolve system warnings or errors. Logentries can also be applied from a business analytics perspective to understand how many users registered, logged in, made payments and more over particular time periods.

 

Engine Yard Cloud customers can get started for free today, including 7 days of storage and a 1GB indexing limit.

Logging metrics is vital to checking the heartbeat of your business. When it comes to logging, it helps to know what you should be looking for. For a more complete explanation of the individual logs you should be concerned with when monitoring your Engine Yard setup, view our blog post Digging Into Engine Yard Logs.

If you are an Engine Yard customer, follow these steps to setup Logentries on your Engine Yard apps:

1. Head to https://cloud.engineyard.com/addons/logentries (login required) or navigate to "Logentries" under “Add-ons” in Engine Yard Cloud

2. Click "Set it up"

3. Sign up and follow the instructions for updating your code and deploying

And that’s it! Get ready to enjoy all the benefits that come with getting more insight into your application through proactive log management.

I read one of these poignantly humorous comics on Not Invented Here a while back and since I wasn't sure it was OK to repost I emailed asking for permission. Nada. Then I saw Martijn de Vrieze posted a collection of scalability comics from NIH and decided what the heck (click image to read on site):

Thanks to Martijn for curating the collection and NIH for creating them.

And I agree with Martijn, they do capture an ineffable quality about the entire space.

Joy Beatty and Anthony Oden discuss the top questions about managing software requirements with global teams. What skills do you need to develop in your teams? What process frameworks should you put in place? What requirement tools are available and which should you consider?

Introduction to Joy and Anthony.

Joy kicks off the Webinar by giving an overview of the concept “Being Global,” and shares an example.

This section of the Webinar covers the requirements framework that must be established for all requirements activities.

Joy initiates the conversation around building requirements skills. She discusses taking into consideration what each team member brings to the table and how to tailor the learning path for each individual in the team.

Knowing how to build requirement skills and mentoring people is important to making your projects successful. Hear Anthony cover how to educate your team with the skills.

Covering the next level of the pyramid, building a framework. In this video the team discusses building a common framework: terminology, methodology and templates.

Continuing the conversation on frameworks, hear a real life example of how frameworks benefit your projects.

The third layer of the pyramid, tools, are covered in this portion of the Webinar. Joy discusses the five types of tools that Seilevel uses during projects.

Covering the top layer of the pyramid, this portion of the Webinar talks about measuring the success of your projects and sample outcomes you should consider.

Skills, framework, tools and metrics in the perfect world are covered in this Webinar summary video.

Want to see more? Visit Seilevel’s website for additional tips and videos.

How To Successfully Manage Software Requirements In A Global Organization is a post from: http://requirements.seilevel.com/blog

In PM Network magazine, Jesse Fewell wrote a great article on Agile Downsizing? Why Agile Skills Improve a Project Manager’s Job Security.

Here are a few highlights:

“Agile wasn’t designed to improve the bottom line like that, but it’s a misconception that has some project managers worrying whether a move to ‘self-organizing’ teams would make their position redundant.  Even more concerning, many of the formal approaches, such as Scrum or Kanban, do not define a project manager role.”

Project managers are in higher demand than ever.  Fewell writes:

“PMI research shows the use of agile approaches tripled from December 2008 to May 2011, and 63 percent of hiring managers would encourage their project managers to pursue agile certification.”

It’s not doing more with less. 

Fewell shares a few skills that project leaders with agile experience can show on their resume:

Delegating more work – “Do you have a bent for process and facilitation?  Then create that well-oiled machine and groom an analyst to manage the business. The most successful project managers I’ve met have focused on their strengths, and found capable hands for the rest of the work.”

Leading more – “Agile approaches place a dogged focus on delivering business results by improving collaboration.  Once you’ve delegated the daily minutiae to the project team, you can invest in more strategic relationships.”

Driving more improvement – “… if you’ve equipped and trusted your team to handle the details and you’ve improved collaboration with stakeholders, then you finally have the energy and influence to brainstorm solutions to that quality problem, stabilize a more reliable delivery cycle than last year, or launch a product-strategy working group to mend some broken fences and get everyone on the same page.”

The key take away is this:

“The project manager with agile skills has evolved past a positional title babysitting details.  The new role is about building the capability of your teams, partnering with senior stakeholders and driving incremental improvements across the board.”

You Might Also Like:

10 Ways to Make Agile Design More Effective

Agile Life-Cycle Frame

Agile Methodology in Microsoft patterns & practices

Are You Used to Delivering Working Software on a Daily Basis and Changing the Software in Response to Emerging Requirements?

Methodologies at a Glance

Roles on Agile Teams

The Art of the Agile Retrospective

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted here.

Standard Scrum advice is that the daily scrum is strictly time boxed to fifteen minutes. Don’t dare let it go any longer than that. I want to share an example of how I sometimes have teams throw that rule out the window.

One challenge distributed team members face is getting to know one another. Members of a collocated team get to know one another through small talk. You and I get in the elevator together and ask each other innocuous but friendly questions: Do anything this weekend? How old are your kids now? and so on. This type of water-cooler conversation doesn’t happen with distributed teams.

Further, a distributed team’s meetings rarely have any of the playfulness that may occur with a collocated team. I’ve seen members of a collocated team hold up a rubber rat when another members goes too deep into a topic (referred to as “going down a rat hole”). Even if team members could do things like that when distributed, they often don’t know each other well enough to feel comfortable doing so.

As a ScrumMaster for a distributed team, I find it important to help team members get to know each other well enough that they can exhibit this type of playfulness. A great way I’ve used to do that is by starting each daily scrum with a bit of small talk--the type of conversation that happens naturally when collocated but won’t with a distributed team unless someone explicitly makes time for it.

I’ve gone so far as to tell teams that their daily scrums are required to start with five minutes of mandatory small talk. No mention of the project is allowed. Team members need to talk about their hobbies, what their kids did the night before, the great movie they went to, or things like that. After a mandatory five minutes of this, we start the normal part of the daily scrum, which is time boxed to a further fifteen minutes.

One of my favorite things to hear about during this part of a daily scrum is how team members in a different country will be celebrating a holiday. For example, on next Friday my friends in Norway will celebrate Syttende Mai, Norwegian Constitution Day. The first time I was on the phone with Norwegian team members and they told me they’d be off on May 17, I wanted to know what type of a holiday it was. Was it one of those holidays when you have a big meal with family (like US Thanksgiving)? Or was it a holiday best spent outside with friends (like US Memorial Day)?

Similarly, when on the phone with members of a London-based team I got to find out what Boxing Day was all about. I’d certainly heard about it despite living my whole life in the US. But I had no idea why the British were so anxious to put on boxing gloves and all fight each other. I also learned why they care about “bank holidays.” In the US, I’ve never cared when the banks were taking the day off.

I’ve learned about all manner of holidays from working with distributed teams this way. More importantly, though, I learned little details about the lives of my remote teammates. And that helped us all work together better. So, while I fully support a fifteen-minute time box to the daily scrum, for some teams, I will occasionally add another rule that we start with five minutes of small talk. I suggest you try it, I bet you’ll learn a great deal more about your remote teammates.
 

That’s a pretty good question, and timeless, too.  

I remember several years ago, when a vendor asked me that, and I remember laughing and thinking, “yeah, that’s what we try to show other people how to do.”

What was great though, was the vendor followed up with a short-list of precise questions:

1. What is your current software development process?
2. Key milestones?
3. Release frequency?
4. Daily practices?
5. Build frequency?
6. Approach for getting / learning requirements?
7. Approach for dealing with changing / emerging requirements?
8. Approach for creating testable software? (e.g. you change the software for requirement X, how quickly can you make and verify the change)

That’s actually a really good set of questions both to quickly get a handle on your software development process and to test how “agile” you really are.

It also reveals your culture and how responsive to change and feedback you really are.

You Might Also Like

10 Ways to Make Agile Design More Effective

Agile Life-Cycle Frame

Agile Methodology in Microsoft patterns & practices

Methodologies at a Glance

Roles on Agile Teams

The Art of the Agile Retrospective

I got myself involved in co-organizing a conference.

Again.

But this is not just any conference. This is DARE!

DARE is a conference conceived by Maarten Volders, the organizer of the wildly successful Lean Kanban 2011 Benelux. Maarten has teamed up with the initiator of the weirdly successful Stoos Stampede (Amsterdam) (that’s me) and the Happy Melly business network.

DARE is for people who dare to discuss wild ideas about organizational change. For people who dare to introduce bold new practices in their businesses. For people who dare to make work more engaging. And for people who dare to quit their jobs.

DARE has a great line-up of speakers: Dean Leffingwell, Jim Benson, Benjamin Mitchell, Ken Power, Paul Klipp, Hakan Forss, Karl Scotland, and many more. And… it has a great looking website, launched yesterday! I find the layout quite daring actually.

DARE is for agile workers, lean practitioners, systems thinkers, Scrum coaches, Kanban experts, change leaders, complexity thinkers, culture hackers, lean startups, and Stoosians. Only the people who don’t dare to make at least something better in their organizations are not invited.

Will you dare to be there?