This week both Jean and I delivered talks on the Agile organization at Agile 2010 in Orlando. Whether you were able to attend one, both or neither, this post shares the handouts and materials that we used in the talks.
If you attended, please provide comments on what you liked, were puzzled by and might change in the future.
Jean’s work was a three-hour tutorial on learning models for managing the Agile organization. She ran three exercises and provided a bibliography of books/resources that we have used here at Rally:
In addition to Jean’s talk, I presented an experience report on our use of Plan-Do-Check-Act (PDCA) at Rally. This report tells a story of our evolution of strategy execution from Gazelles/Scrum to Lean/Agile.
We hope these resources provide you with ideas for scaling your own Agile efforts beyond their current levels. Again, please comment on the blog with what you got from the materials or the talks. We want to hear from you on this topic.
I am passionate about design; if it were not for the boom-bust cycles in architecture, I would have followed that education/career path. As a result of that passion, I got really excited when I saw HiveLive four years ago. So excited in fact, that Rally jumped in as key first customer and based Agile Commons on HiveLive’s platform. I even personally invested in the effort led by three Kembel brothers: John, Jeremy and Geoff. Last year, HiveLive’s journey took another turn as they sold to RightNow. After meeting RightNow’s David Vap and speaking with a good part of their technical team, I would say John, the VP of Social Solutions, is right that they made a great move.
John’s design-thinking approach was front and center to HiveLive. It came from his background at Standford’s design school and a stint at IDEO. As I got to know John, he mentioned all the great things going on with his other brother and twin George. George was busy creating a new version of the design school, called the Stanford d.school. The new d.school has broadened beyond just a partnership of art and mechanical engineering to become a interdisciplinary school that brings design thinking to all majors. As I learned more about this, I started pulling on John’s shirt to get me out there so I could go see the place and meet George. Well last week, I participated in the first ever d.social summit for two days with 15 folks focused on the intersection of design thinking and social thinking. Twins John and George Kembel actually facilitate in stereo. To watch and be a part of their combined effort was like drinking from a fire hose.
The event and the people were great fun to work with and pushed my limits on the overlap of design thinking and social thinking. Working there really made me feel strong and I found myself in a flow most of the time. It caused me to notice that I really love the expansion of design to design thinking. But for you and your agile teams, the innovations in team room furniture was really important. Creating a culture of innovation relies on creating the right environment. If you have read Takeuechi and Nonaka’s book on Knowledge Management, you will recognize the concept of “Ba.” Ba is the shared space that creates context for the knowledge-creating company. (See figure 4.3 on page 102 of their book for a cool illustration of the whole concept)
The d.school is full of flexible, collaborative space of all kinds, shapes and sizes. They are constantly trying new things there. Built for running multiple, parallel design projects in 15 week cycles, it is empathetic to extreme users. The space is in its sixth iteration of the space. Scott Doorley and Dave Baggeroer worked with George over the last five years to really make this place something special. As a result of working at the extreme of rapid collaboration, they have come up with some fantastic furniture designs that you should consider copying for your team and meeting rooms. Unfortunately, you can’t buy this stuff – you have to build it locally.
Here is a set of stackable and highly portable white boards.
Notice the Z-shaped foot that allows them to stack and move around corners. These ideas came from retail stores. Also notice the red peg in the whiteboard. This is designed to hang portable whiteboards that you can take back to your own space. It could also hold a pad of flip-chart paper.
This line is where they store the student efforts. Notice how the hanging whiteboards are stored. It is easy to imagine collaborating in another person’s office and then bringing the whiteboard back to your office without using tons of flip chart pads.
Below is a portable wall system built with spring-loaded feet to allow you to make semi-transparent or opaque walls by lightly snapping them into place. You can see them used above to make the line where student’s store their work.
These cool pommel horses, pictured below, make great furniture for a team collaboration space. You can sit, stand or work at the structures and they force you to not think in hierarchies:)
I hope some of these pieces of furniture compel you to try some new furniture in your space. If you are not quite sold, you might read Tim Brown’s new book “Change by Design.” It is a great living example of the approaches that IDEO and the d.school use to create empathy, insight and desirable design in physical, virtual and social systems.
Do you have any experience applying design thinking in your agile teams? Jared Spool’s talk at Agile 2009 was a great example of applying design thinking to software.
Matt Phillips is a Senior Project Manager who has spent the last few years helping shape the Agile development process at Lulu.com. He currently heads up the Lulu Project Management Office and has spent several months setting up Agile practices in Lulu’s India office, based in Bangalore. In advance of his executive panel discussion at Rally’s Agile Success Tour in Raleigh, NC, we sat down with Matt to ask him 5 questions about Agile.
1. How have you implemented Agile across your organization?
We’ve rolled Agile out among all of our distributed teams, which are located in Raleigh, NC, the Ukraine and India. The time zones have historically been a challenge, so we had our remote teams spend several weeks in the Raleigh office working through daily Scrums. Now, they’re essentially as included in the process as possible. We use video conferencing for daily Scrums and to schedule iteration planning. All the teams collaborate to define stories, determine velocity, and plan iterations. We use Rally to make projections, track our velocity, and get visibility into the health of our projects. The metrics have become indispensible for judging how we’re doing, making accurate projections, and delivering upon our commitments.
2. What was your #1 reason for adopting Agile development?
Lulu adopted Agile at a point where the company was very much in start-up mode. The ideas were coming at a frenetic pace and the engineering team size was poised to expand. Agile methodologies were a good fit for Lulu’s culture and environment. The concepts of short iterations and regular release cycles paired with Scrum provided a quick time-to-market period for new ideas. At the same time, by adopting Agile methodologies, Lulu gained increased insight into the development team’s progress and performance as the team grew and feature sets became more complex.
3. What has been the biggest benefit of adopting Agile?
The metrics and amazing visibility we have into development projects. This is especially important for a team that’s 9,000 miles away. We have visibility into how they’re progressing on features, what’s coming next in the roadmap, and really flushing out what the product backlog looks like and where we’re headed. Prior to implementing Agile, it was very hard to sync-up (because of the 9 ½ hour time difference), maintain a feedback loop and foster collaboration with teams so far away.
4. What one piece of advice would you give to new Agile teams?
My advice would be to ease into it – kind of like steering a cruise ship, not turning on a dime. Start with familiar concepts and gradually introduce Agile practices over time. We started with familiar ideas like release dates, associated task lists, estimations, and tracking criteria. Then, we used a phased approach to introduce the concepts of iterations, story points and relative sizing, velocity, and ranking. We continue to work toward more granular inputs to smoothly coordinate roles, tools and dependencies within Rally as we go along to continuously perform at higher levels and get better outputs.
5. How can you tell that Agile is successful at Lulu.com?
One of top ways I can tell that Agile is successful in our organization is that people, even outside of engineering, are speaking in story points. That tells me that Agile has really taken hold. Using story points and velocity for our release planning makes it easy to arrive at a date that everyone is comfortable with. On top of that, our track record since adopting Agile shows that we’ve been delivering on our commitments every time.
Last week I had the pleasure of sitting down to breakfast with David Douglas, co-author of Citizen Engineer, and Bernard Amadei, founder of Engineers without Boarders. It was great to get them both to meet and discuss the need for global, citizen engineers in this increasingly complex and interconnected world. If you are an engineer and you have not seen or read David and Greg Papadopoulos’ handbook for socially responsible engineering, then you are missing a great picture of the future of engineering driven by purpose and the question “why?”.
To put it simply as possible, Citizen Engineers are the connection point between science and society – between pure knowledge and how it is used. Citizen Engineers are techno-responsible, environmentally responsible, economically responsible, socially responsible participants in the engineering community.
- Citizen Engineer
I happened to catch Bernard on the way to speak to the National Academy of Engineering on “Engineering Sustainability in the Face of Natural Hazards.” This brought us to the oil spill in the Gulf Coast. If you buy the tenents of the Citizen Engineer, then an engineer would be the spokesperson for BP in a situation like this. In that role, the Citizen Engineer would talk about the situation and help educate the public on the implications of technology of deep water drilling. At breakfast, this conversation gained a bunch of energy and stimulated me to explore this idea more completely.
Based on my experience and ideas contained in the Citizen Engineer, I believe we need to create more Citizen Engineers. If this happens, we can jump quickly past the island of blame and towards faster learning and more constructive solutions. By moving to a more visible, open and collaborative discourse, we can work together to address these global and complex difficulties. So, my new favorite phrase is, “What would the Citizen Engineer do?”
In a world of increasing complexity, accidents happen. This accident is a tragedy with 11 dead and 17 injured in an explosion that created the worst oil spill in the history of the United States. Let’s start the clock over on these events and explore what a Citizen Engineer would do.
Managing the Gulf Coast Oil Spill, the Citizen Engineer way
It is April 20, just after the blow out. The Citizen Engineer, holding the title Chief Engineer at the company, was notified immediately by email, text and phone. Right away, she started a number of things in parallel. First, her office took control and governance of the situation and began acting as the general contractor for the accident. There were four fronts to work on:
NASA photo taken May 24 - from web site http://2010gulfoilspill.com/
Root cause of explosion and rig stability
Continuing leaks
Spill clean-up at sea
Spill clean-up on land
This Chief Engineer’s office placed lead engineers on all these fronts, but to illustrate the point of our story, we will focus only on efforts to stop the continuing leaks.
In the first 24 hours, her team classified the accident as a complex situation, beyond the solution scope of past accidents. It was classified as complex due to the depth of water, pressure, size and number of leaks and the state of the well including the stuck drilling rods. It was clear that relief wells would be the correct long-term fix, but they were months away. As a result, her team quickly realized that this complex situation required them to learn as fast as possible from as wide group of people and as many experiments as possible. Simply reaching to internal or known experts of past solutions in shallower, more straight-forward situations would be fine in a complicated situation, but the pre-conceived solutions could actually hurt in this situation. After meeting her response team on-site, she launched the following parallel efforts:
Opened communications to the world via Internet to communicate video and known conditions of the accident including live underwater video feeds, movies of experiments and well configurations.
Called for counter-measures ideas and technologies from the petroleum engineering community with special requests to Norway and Brazil, the two leading countries with deep water well expertise.
Set a daily cadence for coordinating status and learning inside her team.
Pulled well experts from their partners, Halliburton and Transocean to staff her disaster response team.
Procured the submarines and well capping equipment for these depths.
Developed a model of the underwater site to make communication about the situation more clear.
Authorized the drilling of relief wells for long-term containment.
By opening communication of the situation to the world and inviting engineering help via the Internet, her team encouraged a crowdsourcing and expert sourcing approach to the problem. As a result, they quickly received estimates on the amount of oil leaking from scientists who were familiar with measuring flows simply based on the video feeds. Having understood the large magnitude of this flow, the response team was able to garner more dollars to expedite experiments based on simple, back-of-the-napkin estimates of costs due to fines and clean-up that would accumulate each day the well leaked.
Simultaneously, the web site was collecting potential countermeasures from petroleum as well as civil and aeronautical engineers from around the world. These countermeasures were filtered by the web team and small groups of response team engineers were doing quick research, experiments and models to boil up the most feasible and effective ones. A web-based social media voting and comment system was allowing outside engineers to validate their thinking. As the most effective countermeasures emerged, the team started to describe experiments necessary to learn how to evaluate the valid sets of potential solutions. Using their growing resources, the response team launched multiple experiments using models and simulations to accelerate their Orient-Observe-Decide-Act loops. Based on what they understood, they took a set-based approach to running these experimental solutions under the sea.
At the end of the first 24-hour cycle, they were clear on the first three underwater efforts. These efforts were quick, easy and non-destructive to other efforts. Within the next three days, their first experiments did not attempt to slow the leak, but they learn much more about the actual situation of the undersea drill rig, the actual leak size and mix of gas and oil. This data allowed them to update their models and again narrow their choices, as well as feed the root cause and leak containment teams some valuable facts. They were learning and now major equipment was starting to arrive at the site. They chose to work on the quickest solutions that had the highest estimated effectiveness and least likelihood to ruin the well site for further efforts. All of these models, experiments, and solutions sets were published on the web site in real-time. The web site formed the basis for governmental and public communication updates as well kept the worldwide crowd of paid and volunteer engineers in the loop.
This learning-first approach led to some quick wins that started to slow the leaks only 10 days after the accident and fully contained it 14 days later. There was now an estimated 200,000 barrels in the water. Her attentions turned to other teams. One had the long-term, relief well underway with an estimate of 2 more months to completely contain the band-aided well from other leaks. The results of the response teams efforts kept the total spill size to less than the 250,000 barrels spilled by the Valdez in 1989 and less than the 7 million barrels spilled during Katrina. The Chief Engineer’s teams had used all the best thinking and resources from around the world to narrow to a short-term fixes very quickly.
To conceptually “pay back” the world of volunteers and future deep sea oil teams, the problem sheets, experiment results and retrospective meeting notes are all freely available on the corporate web site. This site and content are open and shared with the world in an open source manner. These notes provide data for future Chief Engineering teams to reference during future accidents. They also provide an engineering case study and market data for equipment suppliers to the petroleum industry to help make these kind of efforts safer in the future. They know that by working fast and leveraging all the world’s resources, they directly attacked the highest economical, ecological and social risk quickly.
Are you a Citizen Engineer?
Things are changing, as we are rightfully blurring the lines between economic, social and environmental responsibility. Everyone is having to become more responsible to the triple bottom line. In this new world, the Citizen Engineer needs to be responsible to technology, ecology, society and economics. In many cases, the Citizen Engineer must acknowledge the difference between problems and difficulties. Problems have answers, but for the difficulties we can do nothing but try to address it in our increasingly large-scale, interconnected and complex world.
Who knows if this approach would lead to a smaller spill in the future, but it would certainly lead to faster learning in the next set of accidents.
How does your engineering team behave during your organization’s accidents?
It’s clear, there is not a one-size-fits-all way to define Agile success. Every organization is different, every Agile team is different, and every software development project is different. Each organization has to figure out how to pilot, extend and excel at Agile. Distinct Agile teams within the organization also have to determine how to move to performance in their own ways and make the most effective use of team members to meet their commitments. Full participation from everyone involved is critical to move the organization, process and infrastructure to a better place. The successful approach to adopting Agile acknowledges Agile is not just fad or a quick fix, it is part of an ongoing dialogue of what’s working, what’s not and what are we going to change.
Bringing the Agile community together is a great way for both new and mature Agile teams to share best practices, pain points and success stories. Rally hosts regional events, called Agile Success Tours, to bring the Agile community together for just this purpose. At a recent event in Dallas, we asked participants how they defined Agile success and posed the same question to Twitter. We caught some great answers on video and got some nice, succinct tweets defining Agile success:
These answers illuminate that Agile is a different way of thinking and working for organizations. It’s a smarter, more skeptical and fun craft that addresses the systemic issues found in our increasingly complex and interconnected world. Through Rally’s work over the years helping organizations both large and small adopt Agile, we’ve come to figure out some fundamental components of what success looks like. Agile success comes down to creating the yearning to continue to ratchet up your agility and discipline as a team.
There truly is a simplicity behind Agile adoption when you create the shared commitment and vision that drives your organization – then you begin to see the beauty and the possibilities attainable in an Agile business.
I would like to welcome Ed Willis to our blog, as a guest blogger. I spent a couple of days with Ed and his team of internal coaches this Winter and I am glad to have him share some of their lessons from the field of large distributed Agile – Ryan
Question: What are we, as Scrum team members, committing to in a sprint?
The higher-level Sprint Goal or the more detailed set of selected Product Backlog? If you are a customer of the team, what is the team telling you it will do?
I recall being pretty confused about what the team was committing to in Sprint planning after reading Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle, for the first time. There seemed to be some ambiguity around whether the Scrum Team commits to the set of selected Product Backlog items or to the Sprint Goal, which is a higher level and less precise concept. A couple of quotes from that book will help illuminate the situation:
“A team commits to achieving a Sprint Goal.”
“The Scrum Team commits to turn a selected set of Product Backlog into a working product.”
And this from Schwaber’s The Enterprise and Scrum: “… the team selects as much Product Backlog as it believes that it can transform into a completed increment of potentially shippable product functionality by the end of the Sprint. The team commits to the Product Owner to do its best to complete that amount of functionality.”
From the first book again, “The Sprint Goal is an objective that will be met through the implementation of the Product Backlog … The reason for having a Sprint Goal is to give the team some wiggle room regarding the functionality … If the work turns out to be harder than the team had expected, then the team might only partially implement the functionality. “
Note that that last quote appears nearly verbatim in a recent (Feb 2010) version of the Scrum Guide published on scrum.org.
Between the current Scrum Guide and 2001’s “Agile Software Development with Scrum”, Schwaber’s Agile Project Management with Scrum presents an overview of Scrum in its first chapter which does not discuss the Sprint Goal at all – similarly, “The Enterprise and Scrum” provides a summary of Scrum in an appendix that does not talk about the Sprint Goal.
So what are we, as Scrum team members, committing to: the higher-level Sprint Goal or to the more specific set of selected Product Backlog? And why am I so focused on Sprint-level commitments? I focus on commitments because my stakeholders and customers value them. Their plans are in part based on my team’s delivery and so being able to make and meet short-term commitments makes us a better partner to them – “don’t trouble your customer”.
Can You Commit to an Incomplete Sprint?
“Agile Software Development with Scrum” states, “Sometimes only a partial Sprint Backlog can be created … define the initial investigation, design, and architecture work in as much detail as possible, and leave reminders for work that will probably have to be done once the investigation or design has been completed.”
Both that quote and the earlier one on the purpose of the Sprint Goal suggest that the Scrum canon allows for both incomplete Sprint planning and a mechanism to de-scope the Sprint if the team falls behind. If you find yourself in a situation similar to mine (and I suspect many, many of us find ourselves in this situation) where your customers and stakeholders really do value the ability to make and meet high-level commitments in terms of working software that will be delivered at Sprint’s end, then I think that finding a way to do this more regularly is a path you can and should pursue. And it’s one my colleagues and I have embarked on wholeheartedly. All you really need to do to become a better partner in this regard is advance your Sprint planning practices and adapt the strategies you use when you discover you’ve fallen behind.
Reliably Committing to the Selected Product Backlog – One Group’s Perspective
Being able to reliably deliver against Product Backlog commitments isn’t hard conceptually – it starts with doing a better job in Sprint planning. There are probably many ways to do this but I thought I’d share what we’ve done to accomplish this.
Capacity Planning
Our Sprint planning starts with a detailed view into capacity. Is anyone on the team going to be away on training or vacation during the Sprint? Will the remainder of their time be focused on the Sprint? If not, how much do time they think they’ll have to spend in the Sprint? Knowing the total capacity of the team in the coming Sprint is the foundation of a solid Sprint plan.
Ideal Time Estimation
To estimate our Sprint Backlog tasks, we use “ideal time” as it is described in Planning Extreme Programming by Beck and Fowler: “Ideal time is time without interruption where you can concentrate on your work and feel fully productive.” Ideal time on any given task is in essence the answer to the question “how long would this task take you in a perfect world?” Ideal time is then converted into real time in a very similar manner to how story points are converted into expected duration for stories – you measure the velocity of the team. For example, if ideal time velocity of a team is measured at 0.66, then two ideal days of work has been seen in the past to be about three calendar days.
That use of past experience is critical because it rolls up estimation error, overhead, interruptions et al into a single factor used to improve the accuracy of the task estimates while only requiring of the people doing the estimates that they do so consistently. We’ve found it useful. Conceptually I also like it because, along with the use of story points and their corresponding velocity, it increases Scrum’s fractal, self-similar nature.
Assigning Tasks
Typically we assign all the tasks in the Sprint Backlog during the planning meeting. There’s probably enough divergence of thought on this point to warrant its own post, but to stick to the matter at hand, we do this for reasons relevant to the goal of producing more reliable Sprint plans. One major motivation is the fact that estimates provided by the person who will actually do the work are demonstrably more accurate. The second major motivation is our observation that, when trying to achieve greater work sharing and improve the flow of value to the customer by avoiding bottlenecking through specialists, we do a better job of supporting people who are branching out into unfamiliar territory if we know they’re going to do so a priori. Specifically, we can build time into our Sprints for the people who are more knowledgeable in a given area to mentor or review the work of those who are working in areas less familiar to them.
Spikes
We make frequent use of spikes to allow us to develop a better or more complete understanding of what a given story will entail thus giving us the insight needed to build more complete Sprint plans.
Reviewing the Sprint Plan
We review our Sprint plans to look for mistakes we commonly make. We’ve gone as far as enumerating the mistakes we make most often to help us look specifically for those as we do Sprint planning. Most of these are different flavors of not applying our “definition of done” and thus ending up with incomplete plans. If your goal is to develop challenging plans but plans that you’re likely to deliver on, then trying hard to ensure your plans are complete is important.
Note that none of the above should be intended to suggest that we value immutable Sprint Backlogs or task assignments. We can and do frequently grow and shrink the Sprint Backlog as the team uncovers more information about what’s needed to deliver the committed Product Backlog. Similarly, we shuffle (and re-estimate) tasks regularly. What we don’t do is allow significant parts of the work to go unplanned or unassigned at the point we decide what we’re committing to deliver.
Beyond Yes or No
Beyond improved Sprint planning, the second critical aspect for us in delivering committed Product Backlog in a Sprint is how we deal with falling behind. I frequently say in delivering Scrum training that if someone comes to you asking if a bunch of features can get done given fixed resourcing by a given date, that the best of all possible answers is “yes”. The worst of all possible answers is “no” – but not because you’re delivering bad news but rather because saying “no” reinforces the fallacy that that decision is really binary in nature and ignores the great value to be gained by digging into the details to see what’s actually possible.
Similarly when Scrum teams fall behind, they frequently see their choices as being to either: stick with the plan or remove lower priority Product Backlog in consultation with the Product Owner. Those are reasonable choices but I much prefer a third option: work very closely with the Product Owner to find an easier way to deliver the committed Product Backlog items in the time remaining – essentially, use the combined talents and insights of the Product Owner and the team to find simpler, cheaper ways to get the selected Product Backlog done. Honestly, it can feel like magic when it happens.
We once had a Sprint on a tool development project that had fallen far behind – it appeared that no amount of plan scrubbing or task shuffling would allow us to deliver the committed Product Backlog by Sprint’s end. We met with the Product Owner with the intention of choosing Product Backlog to remove from the Sprint. In the course of conversation though, the Product Owner got a better feel for the approach the team was taking in developing one specific item – the item that was driving most of the over-run. Collectively, they realized that the approach was fancier than was really required and in short order sketched out an alternative. We immediately revised our Sprint Backlog to remove the old approach and built a plan for the new one – in about an hour, we went from hopelessly behind with no chance of delivering the complete set of Product Backlog to being close to on schedule. I think having a strong team desire to deliver the whole of the selected Product Backlog was key to making this happen.
Anecdotally, I can say that my colleagues and I worked hard to improve our Sprint planning and replanning practices and pretty quickly found ourselves doing much better in meeting our Product Backlog commitments. For example, during one ten month stretch, I counted 93% of Product Backlog items delivered on time in the Sprints in which they were planned. This isn’t the only thing that matters but it made a big difference to us and our stakeholders: it gave us confidence in the team.
Conclusions
Use the Sprint Goal to capture over-arching but incremental project goals if this concept is meaningful to you and if goals like these are more meaningful commitments than would be the selected Product Backlog – but definitely don’t use the Sprint Goal as a crutch to support poor Sprint planning practices.
Don’t let the Scrum canon hinder your team’s thinking when tuning your process to better satisfy your business needs – the canon wasn’t created to limit your thinking.
And above all, don’t believe that your team won’t be able to reliably commit to the selected Product Backlog Sprint over Sprint – you almost certainly can and, if your team and your stakeholders value this, then by all means pursue improvements in this area.
I’d like to thank Anne Greenhaw, Selaine Henriksen and Ryan Martens for their help in developing this post. Thanks to Ryan also for inviting me to post here.
About the Author:This is the first guest blog post of Ed Willis. Ed was a soldier, a cab driver, a security guard, a tree planter, an auto glass installer and shop manager, an employee of several bookstores, a house painter, a dish-washer, and a foot messenger, among at least a few other things before buying his first computer. Since then he has worked as a research assistant at Queen’s University, driven a data mining company into the ground and ridden Nortel Networks nearly all the way down. He currently works for company in telecommunications. Born in NY, NY, he now lives in Ottawa, Ontario.
I’m traveling this week to Rally’s Agile Success Tour in San Diego. I love attending these events because they’re a lot of fun and participants seem to get a lot of value – getting out of the office for a half day is a great way to learn and think about how you can get started or get better with Agile. Plus, the Rancho Bernardo Inn is pretty nice place to spend a day.
The site of Rally's Agile Success Tour - the Rancho Bernardo Inn
But my day job is as a Product Owner, so I’m still trying to keep up with my team while on the road. And this trip has been a good reminder of the challenges of working remotely. Here are seven things I’ve remembered that make a big difference if your team has remote members:
1. Actually log in to your chat client. Instant messaging is a great way to quickly make contact with people on your team, but if everyone isn’t actually logged in to chat, you often can’t reach the best person. If I want to talk to Fred, but I can’t reach him, I’ve got to make a decision – do I wait, or do I interrupt Jason, a developer on his team?
2. Dial in the bridge. If you’re having a meeting, and you have remote team members, make connecting to the conference bridge a habit, even if you don’t think anyone remote is going to be attending. Plans change; something comes up such that someone who was going to be in the office is out. If you don’t connect the conference bridge, remote employees will either give up, or frantically try to catch local participants on IM in the hopes that someone brought a laptop to the meeting.
3. Check in and out on the phone. Assign someone in your meeting to remember the remote team members during the discussion. And make sure you check in with the people on the phone before you hang up at the end of the call. (Give them a few seconds to unmute before you assume they’re gone!)
4. List your cell numbers. At Rally, we have a Google spreadsheet that lists office and cell numbers for everyone. I’m rarely at my desk during the workday, so cell is the only reliable way to reach me.
5. Skype your standups. In our team room, a couple of the machines have Skype running. When you’re remote, video goes a long way to improving connection with the team. Showing some video of the absurd furnishings or the view outside the hotel room makes it fun. This morning, I had some bandwidth issues and could only use voice – it didn’t work nearly as well. Also, with a team like mine, a remote employee who doesn’t enable video for an early morning Skype session will invariably be subject to baseless accusations of not wearing pants.
6. Leave Skype running for a few minutes after the standup is over. Often interesting conversations pop up in the 30 minutes following this meeting. As a PO, I often overhear useful bits of information at this time, and it makes it easy for people to ask me questions they might have forgotten during the standup.
7. Update your stories. This morning, when I logged into Rally, it looked like a ton of work was in progress. Turns out, my team just hadn’t updated their tasks and stories. Often Rally is the window your remote team members have into what’s going on. If you don’t update stories, you can end up with unnecessary confusion. Fortunately, we cleared it up in our daily standup meeting.
These were the things I remembered this week. So what tips do you have for making life easier on remote team members?
On the road to Agile adoption, I often get asked, “how do you get teams spun up on Agile fast?” The short answer is to just do it. The long answer is that I believe there are 3 options. 1) Rally and other Agile coaching organizations offer programs that place a coach in your team to help with preparation, planning, estimating, setting norms, committing, tracking, daily stand-up, demonstrations and retrospectives. 2) You can take the DIY approach, but watch out for the unintended consequences. 3) Finally, I think there is the intensive practice approach. Let me give you some examples:
A Sprint Per Day for the First Week
While speaking and attending Agile Vancouver in 2008, Linda Rising facilitated a fishbowl exercise with a custom development firm in Vancouver. Given they were starting and stopping projects and reforming teams all the time, they had developed an approach to speed the team through the formation process and inculcate new team members (employees and customers) to the process. The would run a scrum sprint every day for the first week. This intensive process would allow them to work through tons of issues in a very intensive week. I would call a form of this preparation over planning.
A Sprint Every 90 minutes for a Weekend
If that is not fast enough for you, how about a sprint every 90 minutes? That is what the folks at SnapImpact did last weekend in Boulder at their SnapCamp (based on the notion of Startup Weekend).
I heard about this from one of the organizers and fellow Sprint Triathlete Dave Angulo. Dave is co-founder of the non-profit SnapImpact, a guerrilla non-profit that has a mission to “Make Doing Good Easy.” They developed an iPhone application and Wordpress plugin to simplify how people learn about volunteer opportunities near them. It takes feeds from HandsOn Network and soon All for Good. It is cool, I’ve been playing with it for a year. Anyway, ran into Dave at a CTO lunch in the TechStar’s bunker today and he told me about the wild success they had with 90 minute sprint process through the last weekend.
To give some background, SnapCamp was the kickoff effort for developing v2.0 of All for Good, the platform which powers http://serve.gov and a number of other sites. It’s the largest single repository of volunteer opportunities in the world. Version 1.x was pushed into production quickly and, while it is up and running, there have been a number of technical limitations which have frustrated All for Good’s partners and limited the platform’s usefulness. SnapImpact offered to develop v2.0 of All for Good because of the close alignment of the two organizations’ missions and their desire to have a more comprehensive list of opportunities for their iPhone app.
Ryan – Tell me how the 90 minute sprint process worked at SnapCamp?
Dave - We started the weekend with dinner on Friday night to allow time for everyone to meet each other, learn about each other’s backgrounds, and have a shared group experience. We had people from all over the country as well as a great local contingent. Some were die-hard SnapImpact volunteers, others had only heard about us recently. The dinner allowed for folks to get to know one another in a casual setting without having to do it in between trying to get work done.
Saturday morning, we laid out the business problem, context, and goals for the weekend, then I announced we would do 90 minute sprints. The business teams (we had marketing, UI, and product teams as well), would adhere to the same schedule. The beginning of the first sprint for dev was spent laying out four areas of technical problems and having the team self select into what tickled their fancy. Everyone then got to work. I moved between the teams to discuss possible technologies for them to consider and dive deeper on the problems they needed to solve. The volunteers then took over and by the end of the first sprint everyone had a handle on their problem areas. Most even had a initial plan of attack.
Everyone has heard of Forming, Storming, Norming, and Performing. With 2 days to get work done, we had to get them to performing as quickly as possible. The dev teams were all about 3 people in size with differing skill levels and familiarity with the technology stack we were using. The 90 minute sprints forced a tempo which required the teams to get to performing quickly – no one wants to report out nothing was accomplished. Yes, some of the progress initially was small, but these were hard problems to tackle in a weekend. I had one team who’s requirements were being developed by the business team through the weekend, some sprints the deliverable was “received requirements from business and developed a response.”
By the end of Saturday, all of the development teams had produced something which was merged into mainline for the other teams to pick up. That was huge and everyone could see the bar moving.
Sunday started with a review and then everyone picked up where they had left off. The development teams reformed and started working before we even had the morning review. The pace on Sunday kept accelerating, merges occurring after every sprint, until late afternoon, when we started winding down.
I have run many volunteer projects. The SnapImpact team had actually completed one earlier in the week involving several hundred people with BDNT, and it’s absolutely critical volunteers feel like they are moving the bar. Given the scope of this project, it was going to be very easy to have volunteers lose sight of the progress they are making and give up. The 90 minute chunks with progress review and planning helped ensure the volunteers didn’t lose sight of the progress we were making that weekend. As project owners, we had goals of our own on what was going to be delivered at the end of the project. The sprints allowed us to keep moving in the direction we needed to go as well as identify trouble areas.
Ryan – What did not work so well or would do different next time?
Dave – Training – One decision I made was to use a relatively new technology stack, Scala/Lift, for the framework. Instead of holding a formal training session for those unfamiliar with it, I made sure there were experienced people in each group and let training happen “on the job.” I think next time it would be better to do a short training session, as given the pace, sometimes that training disrupted forward progress. Just the basics, so when a concept was discussed it wouldn’t be completely foreign.
Deliverables – We got sloppy during the reviews and didn’t nail down specific deliverables for teams. At times, it caused teams to lose focus during the sprint. The reviews were every 90 minutes, so the lack of focus was caught sooner rather than later.
Insert more fun – Because the tempo was so high, I’m not sure folks had as much fun as they could have during the event. I’m a big believer in fun being central to any successful project and I think teams could have bonded a little more and we may not have been as exhausted by Sunday afternoon. There was some fun, we just needed more.
Ryan – Tell me about the emergent end deliverable? Can people see it on the web?
Dave – Our goal was a beta of existing functionality by the end of the weekend. We’re very close to that now, but some decisions made during the weekend prevented accomplishing that goal. The SnapImpact team is continuing development and once the existing functionality is in place we’ll start working on a host of new feature requests from the business team. We’re entering all of that information into Rally now and beginning the planning process. Folks will see v2.0 at http://allforgood.org in June.
Ryan – What did you do to prepare or plan for this process?
Dave - Preparation started weeks in advance. My role in this project is CTO and VP of Engineering. So, the 3 critical things I needed to accomplish before the weekend started was making sure I stacked the deck in my favor with some talented people, had a toolbox ready with possible solutions to the technical challenges we would face, and had stakeholders present to make decisions.
Given the new technology stack, I needed to recruit folks with some very specific skills. To enable that effort we recruited the leader and founder of the Lift project, David Pollak. He helped us motivate a few people with experience using the technology. We also had the SnapImpact team actively recruit their friends. The result was a very high quality team capable of getting the job done.
When the teams started work, they would spend too much time investigating everything unless I gave them a starting point. By bringing some ideas (not solutions) to the table to solve their problems, it helped define their playing field and allow them to make a decision quickly. Implicit in this was understanding the known business problems that needed to be solved.
We knew we would hit roadblocks during development waiting for business input on implementation details. So, we made sure to have some present the entire weekend. One of the stakeholders even brought a developer who was using the existing system. We embedded the dev in one of our teams working on implementing some external interfaces. Yes, that really accelerated the implementation decisions. Also, the stakeholders were really disappointed with certain aspects of the existing system. We had ideas to resolve those issues, but needed to ensure they met the stakeholders needs.
Thanks Dave for the great details on this event and example of agility at work!
Plan to do what you want. Prepare to do what you must.
Don’t get us wrong, we value planning: it’s important and highly creative work. But in the Culture of Innovation preparation means much more. In a world that defines success as a result and failure as a step along the way , we plan regularly as we adjust to results, outside stimulus, and feedback. Preparation marches us up the stairs faster and ensures that we’ll arrive someplace new and valuable.
Planning is an exercise for imagination and not spreadsheets.
In planning we figure out what we need to accomplish this task. It‘s a process of creative thinking, dialogue, narrowing to convergence, healthy skepticism, and risk mitigation. In planning we need to treat difficulties as a challenge; to resolve a creative tension between reality and what we want. Teams brush away perceived limits as they press toward understanding by asking WHY? Thinking in the 5 Why’s of Fishbone diagrams, these teams do not simply work with WHAT and HOW. Once done and aligned, the plan becomes a communication of intent and result and NOT a goal or commitment. Dependable results come from a focus on the limits to throughput, sources of failure, and lack of preparation.
In our experience with Agile teams, we see advanced Scrum teams begin to let go of some planning practices as their expertise grows. The benefits of pull-based planning and smooth flow delivery create new space for them in the market. As a result of their growing confidence, they increase their ownership of their process, a key step on the way to a culture of innovation. That culture creates, not just one off innovations, but an environment ready to take advantage of opportunities and happy accidents. A big part of creating that environment comes from a focus on preparation.
Let’s consider preparation. Teams and managers must learn and practice a set of skills that taken together can help them create a culture of innovation. These skills often seem off the subject, not to the point, and therefore difficult for teams and managers to make time for. We think of preparation in three main categories: for collaboration and leadership; for comfort in ambiguity; and for daily productivity. In this brief introduction we won’t suggest a detailed program. Instead, we’ll outline an abstract of the culture, seen through the lens of preparation.
Collaboration and leadership
You can prepare for collaboration (innovative team work) and leadership (team direction and support) by learning and practicing release and concentration. Teams and their leaders need release from tension, as a way to increase available energy and flexibility; and release from inhibition and vanity for freedom, to include the work of others in their own and to regard the success of the team as their own success.
Take a look at athletes for good examples of release from tension; at actors in a play or movie for good examples of release from inhibition.
Watch Sharapova’s face as she looks up at the ball she’s about to whack; see the pitcher take a big breath and whoosh it out before he throws the ball. Look at a still photo of what the pitcher does to his arm in the delivery: it’s not hard to imagine what would happen to those muscles if they weren’t completely released, free of any kind of tension. Look at Paul Newman’s famous eyes blaze with rage (as Harry Manning, dumped in the river: Where the Money Is) or fear (Buffalo Bill astride a fractious horse: Buffalo Bill and the Indians).
We’ll use a story to illustrate what we mean by concentration. Once upon a time two students of Zen walked along the lake shore. They spoke as follows:
First Student:“I have the world’s most amazing Master.”
Second Student:“Have you?”
First Student: “He performs miraculous deeds. The other day he walked right out on this lake and spoke to us, standing on the surface of the water. Then he walked back, and his shoes weren’t even damp.”
Second Student:“That’s certainly amazing. I congratulate you. My master, however, can do something much more important and amazing.”
First Student:“No way.”
Second Student: “Yes way. My master can do one thing at a time.”
Who among us can do one thing at a time?
As you plan your week next Monday, think about these questions.
What is the #1 Thing you have to get done right this week? Be clear about that to yourself and with your team and put your best time and focus on this one item.
What preparation or practice can you do to release tensions with regards to this item?
Who can you collaborate with to make this an outstanding result?
What can you do to celebrate the results of this effort?
What might you do to prepare to execute these choices? What kinds of practice might you build into your daily, weekly, monthly, routine?
Comfort in ambiguity
Accident, serendipity, new things. Innovation confronts the team with all of these sources of ambiguity. What’s gonna happen? What should I do? What on earth is this thing? How do we know when it’s complete?
How does preparation contribute to comfort in ambiguity? It gives us grounds for confidence in our ability to manage the new, the surprising, the unpredicted. We don’t need to dread the uncertainty of innovation because we know that we can make good use of whatever comes up.
Teams and managers who do innovation find ways to live with uncertainty about the outcomes of their work. They know that outcomes will be unexpected and surprising. If they could anticipate them, how new could they be? Preparation will involve getting free of the reflexive invocation of the past: “That isn’t how we do things here”; and embracing the uncertain future: “Let’s see what happens when we do this.”
Preparation will sometimes replace planning.
Of course we plan, so that we can do what we need to do. We plan to have the materials we need, space to work in, the right people on the team, to make an efficient schedule. Planning creates sequential progress toward a known goal. Preparation, on the other hand, aims at collaborative iteration toward an emergent outcome. No one can predict the results of a true collaboration. We prepare to cope with whatever happens. In a culture of innovation, whatever happens is likely to be new. It will elude any kind of sequential progress toward a known goal. When an outcome doesn’t seem to have any immediate value, we recognize that nothing is lost: we set it aside (Might come in handy some day.) and press on.
The notion of emergent design conditions any serious innovation. At Rally Software, we do a number of things in the context of Agile software development to keep from planning too much and to hold space for reaction to ambiguity. First, we acknowledge multiple levels of planning with less precision as the time frame goes out. Second, we insert free time into our schedule in the form of slack and programmed innovation time. Third, we work “sets” of designs through a narrowing process to keep from choosing the design before we learn. Finally, we do not plan until after we have closed the last cycle: We check the results of that last cycle and consciously review our goals. We “Plan to get lucky” and provide room for that to affect our next cycle.
We took a young engineer to visit an acting class at People’s Light, the theatre we know best. A bunch of teenagers were practicing improvisation. One sat on a bench in the park. Another passed by, stopped to talk. A story began to develop. Suddenly from the class a third jumped up and walked into the park, joining the two. This newcomer brought an entirely new slant to the story. After a moment the first actor remembered an appointment and left the other two. Someone else from the class joined in. And so on. The story grew, got elaborate, got simple, got turned inside out: the kids never repeated themselves, never stopped. No one ever refused the new material offered by an other. The engineer turned to us and whispered: “This is exactly what my guys need to learn how to do.”
This kind of practice fairly closely resembles the desired skills. Engineers like to look for an answer in the back of the book; they need practice in making up answers out of the available material. The kind of preparation we’ll call exercise strays from the skills it prepares for; it’s off subject, away from the actual work. Athletes exemplify this kind of preparation. “The champ,” goes the saying, “is always in the gym.” Larry Byrd was famous for staying in the gym after practice. Why? To shoot 100 free throws. To build a reflexive confidence that supports the hectic innovations of the game. What’s more, the champ has decided, has made the choice, to like being in the gym; how could he do the work otherwise?
As you plan your week next Monday, think about these ways of practicing or preparing for emergent innovations:
Schedule some creative time into your schedule to spend in a creative place and time.
Step back from your #1 item for the week and ask yourself a question about its value: What other things could I do to deliver even more of this value?
Find one example of yourself closing down to new solutions based on the concept that “This is the way we always do it.” Can you release that constraint?
Ask yourself: What is the most important thing I have to do this month or quarter? Not urgent. Important. Do I have enough time, support, and space to do this right? Try removing less important or merely urgent things from your calendar to make room for this.
Daily productivity
In a culture of innovation, everyone chooses a professional obligation to work happily, enthusiastically and at maximum energy.
Artists and athletes again serve as models. Neither group can do what they do unless they’re totally fired up. High morale and physical readiness are basic conditions of their work and they must learn how to create and maintain them, no matter what. An actor arrives at the theatre well before the half hour call (On time is already late.), and begins the day’s work with an extensive warm up. Vocal exercises, calisthenics, stretches, lines; actors have routines they follow religiously.
An actor we know told us this story. He used the 30 minute drive to the theatre as his time for vocal warm up. One night, distracted by some domestic emergency, he only got through part of his routine by the time he arrived at the theatre. In rehearsal he had discovered a way of saying one of the lines in the 2nd act that every one liked a lot: his voice got deep and sexy, very nice moment. On this night the performance went very well, in spite of the truncated warm up. Until that deep sexy part. He said that line exactly as he had done dozens of times before. But instead of deep sexiness, what came out of his mouth was tired little squeakiness. The audience were too embarrassed even to laugh. You can bet that actor never missed another warm up.
In software development, this is akin to doing some manual work outside the scope of your automated build, deploy, test cycle. It can seem quicker to do a simple, one-off integration or system test outside that environment, but unintended consequences always catch-up . In our experience, cutting the preparation corners usually costs 10X more in the whole lifecycle than it saves in the short-term. Beyond the interrupts of customer-impacting defects, the team loses a bit of the pride and belief necessary for the Culture of Innovation
Team work demands a no less total performance than acting or tennis playing. It needs, but rarely gets, the preparation of a warm-up. A basketball team combines individual warm ups (stretches, shooting around) with group work (lay up and passing drills). Why should knowledge work be any different? Imagine the energy available if your morning stand up included a vigorous warm up led by a different person each day. Jump back!
As teams and organizations reach an Innovate level of Agile adoption or Ri , they take ownership of their process and environment. Their improved throughput, collaboration, and preparation have brought them to a place where many of the vanilla iteration, planning, and estimating practices of Scrum and XP stop serving them. These structures helped the incremental transition down a path of increasing agility, but in a Culture of Innovation, where smooth, continuous flow of one thing at a time is the goal, the focus moves from planning to preparation.
Next up in our series – Options, Fall-back and Design Sets
Failure and success are handy terms when we want to characterize closure in an industrial making process: We call a thing that works a “success,” and a thing that doesn’t work a “failure.” In an iterative collaboration that leads to an emergent result, they’re not so clear cut, not so handy. We come to closure on an iteration. When we test it, we find it doesn’t do some of what we need.
Thinking industrially, we say “This sucker won’t work. It’s a failure.”
But we need nuance here. It makes sense to observe that the thing failed the test. It makes non-sense to say that the thing’s a failure. As part of an iterative collaboration the current thing is a necessary part of a journey toward an innovation. Chances are pretty good that this iteration contains the seeds of the one that finally does the job.
We think of starting to build a new culture by reconceiving a couple of words because we believe that language is the key to our work; use of language is, after all, the fundamentally human action. Those old Greeks had this idea: they thought of language as a distinguishing feature of a human being. They knew creatures in the world who did not speak Greek, who made unintelligible sounds like “Bar, bar, bar, bar.” They called such creatures “barbarians.”
We won’t go that far, but we will suggest that language is our best tool for thinking and making choices, for knowledge work.
In this Blog Post by Tim Walker at Hoovers - Tim asks, How do you cope with Failure?
Before we make suggestions about how to address this difficulty, let’s revisit an important feature of any culture of innovation. The dominant way to make innovations is to run collaborative iterations. Get an idea of what you’d like to have; make one; test it and discuss it among the team and, if possible, with the end user; on the basis of this discussion, reconceive what you’d like to have and make new one; use everything you can from the previous iteration; chase new ideas to their end without predicting results; test and discuss; reconceive; make a new one; and so on until the project reaches closure. You recognize closure when anything you can think of to do makes the thing worse, not better.
Most of us are okay with the idea that the end product of an innovative process emerges from that process and is, finally, unpredictable. What we have not confronted is the idea that the words we use to think about processes and products may interfere with that and may need reconceiving.
Redefining ‘failure’ and ‘success’
If you can plan for and schedule a process, how new will the outcome be? Not very. But, how can you start on a project without identifying a goal, making a plan to reach that goal, and without confidence in your plan? We all know these keys to success, and unsuccessful equals failure. Right?
Failure! “I’m no good. Better go out in the back yard and eat worms.”
Failure! “Thank God, let’s drop this sucker and move on. Now that we’ve failed, and learned from our failure, the next idea will be a good one.”
Well, maybe not. Maybe instead of failing, you’ve taken an essential step along the way.
Maybe you haven’t reached an end point and suffered a defeat. Maybe you’ve moved toward an unpredictable closure. Some innovators, Tom Kelley of IDEO among them, believe that to succeed you must fail often. Works for him.
We think there’s a better way.
We can begin by noticing that our models for “failure” and “success” limit our work. This means that we need to make a cultural change, from industrial (plan, design, execute) ideas of making toward artful, innovative ones (prepare, iterate, test, iterate again). Think of a staircase. We don’t regard the first step as a “failure,” as “unsuccessful” because it doesn’t get to the second floor. It’s a step. One of many. Just so, we need to decide to put our attention on our process, conceiving it as a journey.
The change of mind here is: we can’t say, exactly, when we’ll complete the journey, or when we’ll arrive. In fact, sometimes (out of which times come the really good stuff) we’re not even sure where we’re going. But what we can say is what we just learned and what we recommend that we do next.
At Rally and in many Agile teams, we use a notion from eXtreme Programing called spikes. In a spike, the engineer sets out to learn what she does not know by conceiving of a simple test to prove or disprove a theory. These spikes are used to help narrow an estimate, gather data on a continuum of choices or narrow a field of options. By calling it a spike, the XP creators helped us RECONCEIVE the ideas of success and failure for a story and thus helped themselves and the rest of the team.
Suppose we decide to go further beyond just a small task like a spike and conceive of each iteration toward an emergent innovation as an essential step along the way. Suppose we decide to conceive success as a measure of progress, not closure. In our culture of innovation, this means we conceive product as a result, not a goal. We’ll know it when we get to it.
Here’s an idea that can help. “Nothing is lost, and wonders never cease.”
Artists live by this mantra: when the work reaches closure it contains everything done on the way. (You’ll see actors who don’t seem real. That’s because all they’ve done is learn their lines and blocking and a way to say the lines so that they’ll sound good. You’ll see actors who seem as if they are the character; you can’t believe they’re not personally like that. That’s because all they’ve done is spend hours and hours of thought and research into creating the given circumstances, a complete history, of that character.)
Instead of discarding work that didn’t reach a goal, reconceive the idea of “goal” into “result” and decide to use what you just made as material for the next iteration toward a result that you’ll recognize when you see it. The more of the current iteration you can find to use, the better. The harder you have to work to include everything, the better. In combination with the new ideas you (the team) get from discussion, and from the imaginative effort you spend, something unpredicted, something new, will appear in the next pass. This will happen.
The cultural principle here is: Collaborative iteration equals Innovation.
In this model, we can measure the progress of effort as it converges on the product. What were the tests results with which stakeholders? What paths will we not follow any further? What potential design sets still need to be tested?
The failure of tests down a path is actually progress and a sign of innovation. Progress is a narrowing of options toward an optimal solution and failures are critical to narrowing.
By adopting the iterative process of Agile we increase the opportunity for innovations, but ultimately we need to prepare for improvisation by changing our idea about language. We need to use language; to decide what words mean. To use language, in other words, as a tool we control, not as a reality that traps us. And that’s a cultural change, not a tip we can quickly use.
We do have a tip, a simple (but not easy) way to begin this complex change. Never say no. Hang that on your wall next to the “No Sniveling” sign. “NEVER SAY NO.” This simple (but not easy) change cannot fail to increase the creative range of individuals, teams, and the organization. It’s not a final answer, but it’s a step along the way.
RallyDev.com
Matt Phillips is a Senior Project Manager who has spent the last few years helping shape the Agile development process at 
I recall being pretty confused about what the team was committing to in Sprint planning after reading 
Similarly when Scrum teams fall behind, they frequently see their choices as being to either: stick with the plan or remove lower priority Product Backlog in consultation with the Product Owner. Those are reasonable choices but I much prefer a third option: work very closely with the Product Owner to find an easier way to deliver the committed Product Backlog items in the time remaining – essentially, use the combined talents and insights of the Product Owner and the team to find simpler, cheaper ways to get the selected Product Backlog done. Honestly, it can feel like magic when it happens.
About the Author: This is the first guest blog post of Ed Willis. 
