Agile Development Blog

Michael Hugos, principal at Center for Systems Innovation [c4si], writes, speaks and consults on strategies for IT and business agility and mentors development teams. He spent six years as CIO of a multibillion dollar distribution cooperative developing a suite of supply chain and business systems that transformed the company’s operations and revenue model. He won the CIO 100 Award and Premier 100 Award for his work. He’s author of several books and writes an online column for CIO magazine called “Doing Business in Real Time.” We recently met with Michael at the Agile 2010 conference, which resulted in “Agile is Ready for the Enterprise” and sparked the idea for this blog post.

Rally asks: What issues and trends are you seeing across technology departments, development teams and in discussions with CIOs?

Michael Hugos answers: The example set by companies such as Google, Facebook and Netflix shows how companies can use iterative development to continuously enhance products and grow market share. This is being noticed by business and technology leaders in other companies and they are asking if they can do the same thing to drive development in their own companies. People realize that IT is right down the middle of everything a company does, and that traditional software release cycles of once a year, or even once a quarter, are not able to keep up with the pace of change and innovation these days.

Just like the word “athlete,” the word “Agile” grabs your attention; it sounds great. But moving from desire to reality always tests peoples’ commitment. A lot of companies are struggling with the all-too-common reaction of, “That’s not the way we do things here…” Agile approaches are interesting and fascinating to companies, but then there is the tendency to immediately criticize new ideas – we’re all prone to it. As soon as someone suggests a new way of doing something, we all think of 10 reasons why that can’t be done or why it won’t work.

Rally: What is driving enterprise adoption of Agile?

MH: To begin with, agility is no longer just a good idea; it’s now backed by law – the law of probability. This law says if a company can’t keep up with rapid rates of change in the world then its probability of success is getting smaller and smaller every day. And since companies need IT infrastructure and applications to operate, just as our bodies need a nervous system and muscles to move, IT agility is critical for a company to achieve business agility.

In the last few years, software tools have enabled executives to measure and track progress on Agile projects and to see the performance of Agile teams in widely dispersed geographical locations. That makes Agile methods more feasible for large companies. A pervading feeling exists throughout business that just about everything else has been tried and IT groups are still not really keeping up with the backlog of user requests. Users are starting to go around IT and do their own things using SaaS, social media and mashups to put together systems. So why not give Agile a try?

Rally: How do Agile methodologies help large organizations foster, regain or accelerate the pace of innovation?

MH: Agile practices offer the best way to improve communication and collaboration between business and IT. Meaningful innovation always starts with communication and collaboration. Another thing that Agile practices enable is the ability to try out new ideas and explore opportunities quickly without investing a lot of money up front. With more traditional approaches, companies invest a lot of time and money planning up front before they start something new. This is expensive. And since most new ideas don’t pan out in the end, this traditional approach makes it difficult (if not impossible) for companies to try out enough new ideas in a year to find that small handful of ideas that do work out and deliver the profits they are looking for.

I like to say that in this high-change and unpredictable economic environment, companies need to: “Think big, start small and deliver quickly.” That’s the best way to keep up, adapt and respond to change, and find the opportunities they are looking for. Agility means letting go of slow, deliberate decision-making in favor of quick, repeatedly-tested decisions. That’s why Agile methods are so appropriate for energizing companies and helping them develop innovative products and services.

Rally: How do you make a case for Agile and address the fears of risk-averse CIOs, CTOs or CEOs?

MH: First, I remind executives of something that has become a fact in the last 10 years: business operations and technology are so tightly intertwined that there is no meaningful distinction left between the two; you can’t do business without technology. That might seem obvious to many but, executives who have been around for a while (like me) may still remember the days when IT was just a back office operation.

Once people acknowledge this reality then I point out that, over the last 10 years, Agile practices have been thoroughly field tested and have an impressive track record for delivering success. There are software tools now, like Rally and others, that address Agile project management and reporting, business and IT collaboration, software testing, and the continuous integration of new software with existing systems infrastructure. So going Agile is not just a leap of faith anymore.

Agile is actually a better way to manage risk versus using traditional waterfall approaches. With Agile practices, big projects are divided into lots of smaller projects that build on each other. This enables people to employ short feedback loops, learn quickly and change plans in light of new information. Two of the biggest causes for failure in business and failure in new development projects is that companies have no inexpensive way to investigate new opportunities, and they blindly follow predefined project plans without change – even as the world itself keeps changing.

The IT profession is at a turning point: one group of IT practitioners has learned that agility is the way to go, but more traditional practitioners still call it radical. Yet, the traditionalists continue to apply the same old ways of doing things that result in the same old horrendously expensive, multi-year projects that produce systems barely better than what was there before, if they even work at all. More and more business executives are coming to the conclusion that the effective support of business agility is the main reason for their company to have an internal IT group. Otherwise, there are options now to just outsource IT operations to cloud computing vendors and get new applications from SaaS providers and social media.

Rally: What does the future hold for Agile and Lean development practices?

MH: Probably the biggest change will be analogous to what happens when a company grows and transitions from an entrepreneurial startup to an established business. When this transition happens, there is a need to become more pragmatic and less idealistic. In the Agile world, this means that “Scrum-but” will actually be the best way for most companies to adopt Agile methods. Each company will customize versions of Agile that best fit their needs and it will be some combination of practices from Scrum, XP, Lean, Kanban, etc. Even waterfall practices have some benefits which should be incorporated where they make sense. Agile practices will not be set in concrete; they will continue to evolve over time as companies learn more and the world keeps changing.

Another big change for Agile is the realization that Agile development is not an end in itself. The value of IT agility is its ability to drive business agility. In the end, agility is more about business than about IT. Instead of co-locating business people with development teams, we will embed IT people in business operating units and co-locate development teams with business people.

I talk about this in my most recent book Business Agility: Sustainable Prosperity in a Relentlessly Competitive World. Agile companies will become real-time organizations that use IT to drive a process of continuous focusing on and responding to opportunities and threats. They will employ IT to drive three continuous feedback loops that make their real-time operations possible. The first feedback loop (I use the Yin-Yang symbol), provides awareness of a changing environment and identifies threats and opportunities. The second loop (I use a sunflower because of how it constantly adjusts itself to follow the sun across the sky), provides balance and continuously adjusts existing operations and processes to fit changing circumstances. And the third loop (I use the leaping panther), provides agility in the sense that it is how companies create new processes and products to seize new opportunities. The figure below illustrates this.

This post will be split into two parts so that it, itself, will be half-assed with the suggestion of an additional half-ass to be delivered later :) And, in keeping with that spirit, the post mistakenly went live before it was ready for prime time. This time, I meant to push the ‘publish’ button…

Can you deploy Scrum to a test team?

Scrum is at its heart a product development process.  How can you leave the part of the organization – development – that actually makes product out of any Scrum deployment? Does it even make sense for other parts of the organization to be “doing Scrum” if development is somehow doing something else? Wouldn’t you be working towards what would be, at best, a half-assed deployment of Scrum?

Craig Larman and Bas Vodde in their wonderful book Practices for Scaling Lean & Agile Development certainly agree: “…a so-called test team Scrum is a contradiction in terms.” Ken Schwaber in The Enterprise and Scrum doesn’t seem to admit the possibility of deploying to functional groups – it’s projects he’s envisioning deploying to. For example, consider this advice for early goers of an enterprise-wide adoption of Scrum: “Establish preconditions that must be met before a project can use Scrum.”

The last 10 or so years of my career have been spent in big companies with very traditional structures: functional organizations with clear separation between development, test, usability, product management, etc; running projects that are very much plan-driven. Lots of agile practices that seem relatively straight-forward in other contexts aren’t in companies like this. Consider Schwaber’s notion of organizational deployment of Scrum again – this from the introduction of The Enterprise and Scrum: “This book is for those who want to use Scrum throughout their enterprise for product development.” It’s an awfully lucky convergence of thought and opportunity that would make such a deployment possible in large, traditionally organized companies. These sets of wholly distinct sub-organizations need to be both willing and able at essentially the same time. You might get a chance like that, but I wouldn’t hold your breath waiting for it.

You can start to see why that opportunity would be rare when you look at it from their perspective.  In taking a project-by-project focus in deploying Scrum to organizations like these – and assuming you’re holding firm to deploying every part of Scrum straight away – you’re essentially asking them to:

• Reconfigure their teams
• Change how they define and manage product scope
• Empower a single person to make scope decisions on each project
• Change how they plan their work
• Change how they approach their work in areas like development and testing
• And so on …

The point is that, even if limited to the context of a small set of pilot projects, they have to do all of this stuff first before they can realize the benefits of Scrum.

To me, this is exactly the same argument that we, as agilists, are very much accustomed to facing from development teams:  “We can do that feature but first we need to re-engineer the infrastructure to support it, which will take six months.”  We encourage teams making that argument to find ways to do just a bit of the refactoring to allow just a bit of the value to become realizable, rather than predicating all of the value on all of the refactoring.  Why can’t we make a similar argument in support of deploying Scrum to just a part of the organization?

What would Voltaire say?

One of my favorite lines – frequently quoted in optimization discussions but applicable equally well here – comes from Voltaire:  “Le mieux est l’ennemi du bien” (the best is the enemy of the good). “Best” is hard to define in any complex system like a large company but “good” seems a little more tractable. We should not let an inability to approach some notion of perfection prevent us from getting better.

A colleague was presented with this exact scenario a while back.  Representatives from a test group came to him asking if he would work with them to try Scrum.  He and I spent some time talking it over.

Things like product owner, product backlog and potentially shippable product increment looked like a tough fit for a test team, to be sure. But still, we thought of goals like “verify feature X” where the challenge to the team is to find a way to work together to get that done within the time-box of the Sprint. That might be a liberating shift in thinking after heavy doses of planning of the form: “We have a bazillion manual tests to execute. At 5 per hour, that’s bazillion/5 staff hours. With 20 FTE, that’s a bazillion/(20*5*40) weeks of testing.” Looking ahead to subsequent Sprints, we envisioned helping the test team bring some of their development partners into their Scrums – perhaps through broadening the notion of the verification goals to include “hardening” – finding and fixing bugs as a cross-functional team. And from there to the odd small feature, slowly working our way towards aligning the work of the test and development organizations in cross-functional Scrums. Even with such an odd scope of initial deployment, we could see potential benefits, including improved productivity through the iterate and reflect cycle, better planning and estimation and higher morale.  Not surprising, these are the same benefits we would suggest lay before any team looking to try Scrum.

Isn’t this the good that Voltaire would caution us against passing on?

Larman and Vodde have some great advice about how to go about ever more closely approaching the “potentially shippable product increment” goal of the Sprint through expanding the Definition of Done (DoD below):

“In general, these are the ways of expanding the DoD:

• Automate – for example, performance testing is automated
• Expand team cross-functionality – for example, a person with technical-writing skills joins the team”

That latter idea suggests a path to improvement that starts in development and then spreads over time to the remaining functions.  If we view Scrum deployment as being something we do in the context of projects and products, this is both natural and reasonable.  But, if we view deploying Scrum as something we do in the context of teams of people or if we view it simply as “transforming the world of work,” then why would we believe we have to start with any particular set of people?  Why not start with testing and grow our way towards development?

Would that be a half-assed approach to deploying Scrum?  Perhaps, but like Richard Dawkins’ half a wing or half an eye, maybe half an ass may prove a more useful incremental improvement than may be apparent at first glance.

So, can you deploy Scrum to a test team?

Sure, why not?

What do you think?

About the Author: Ed Willis has been a ScrumMaster, Product Owner, Scrum coach and trainer.  He is currently a developer in the telecommunications industry.

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:

Jean in action at Agile 2010

• True North Example

• True North Exercise

• Strategy A3 Template

• ORID Exercise

• Personal and Corporate Visioning Exercise

• Sample Quarterly Agenda

• Bibliography

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.

Ryan Martens is a tomato grower, founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

There are other conferences that cover Agile software development, but the Agile 20xx show reigns supreme. At nearly 2000 attendees from around the world, this year’s show is happening at Walt Disney World in Orlando.  (It was moved there after the flood in Nashville.) For the first time, three of the major analyst firms (and as a result 5 of  the key analysts who cover Agile and ALM) are attending the conference – Forrester, Gartner and IDC.

Rally coaches, sales and marketing folk at booth setup

As a result of the show’s success, it has become the most significant market rhythm in our industry.  So this week, we announced a few things:

• Rally Software Extends Agile ALM Platform to Meet the Unique Needs of Global Organizations – New customization options, full traceability with build and source code, and sharing with corporate dashboards create a single source of record for progress and quality
• Rally Software Extends Visualization of AgileZen Kanban Board – New non-profit program offers a 50% discount on leading visual project collaboration tool
• Innovation Games Company Announces Integration with Rally Software – The leader in serious games for business brings customers improved collaboration and prioritization capabilities
• Tasktop Introduces Agile Planner for Eclipse – New product enables Agile planning from the IDE and integrates multi-vendor Agile ALM solutions

I am speaking tomorrow on PDCA: Moving Beyond Simple Inspect and Adapt. (Thurs 9:00 a.m. in A-1). Other Rally speakers remaining this week are:

Get your Rally cap

• Former Rally developer turned Rally technical account manager turned Rally coach Chris Browne speaks Wednesday on The Art of the Hackathon (Weds 15:30 – 17:00 in Asia 3).
• Rally coaches Alan Atlas and John Martin speak Thursday on “Your Team, Your Freedom, Your Responsibility” (Thurs 15:30-17:00 in Asia 3).

Follow the news from the show on Twitter at #Agile2010. Come see us at the booth and get a Rally and Deliver ballcap. Or let us know if you’re not at the show and want us to send you one (send name and address to kcaraway@rallydev.com).

Ryan Martens is an organic farmer, founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

I have a reason for liking Bob Payne. Bob has empathy and a true love for giving back. That resonates with some of what we are trying to do here in Boulder. Rally, as a B Corporation, has expressly created a charter about giving back to the community: 1% equity giveback, 1% employee volunteer hours (over 2500/year in the last two years) and a number of other local not for profit initiatives. For Bob and us, adopting Agile has  been an important component in how will pull our empathy and our software skills together. With Agile, we seek to deliver feasible, effective, desirable solutions in our complex world. And reaching beyond our corporate walls to deliver that desirability catapults us to being truly empathic in our solutions.

When you meet Bob, you immediately get what “giving back” and empathy is about in his Agile work and beyond. Bob is always looking for new ways to bring Agile to our community and the greater community: our complex world. Out of his own interest in giving back to the Agile community, Bob set up his Agiletoolkit podcasts site. A gift for all of us. At the recent ADP West conference, Bob was there with his sound setup.  Bob took interest in Rally’s Agile Zen acquisition when interviewing Ryan Martens. And I  had the great fun of talking about Seth Godin’s book “Linchpin” that both Bob and I had read.

In this post, I’m so honored to have the opportunity to turn the tables on Bob and be the interviewer.

“Bob, what got you started recording your Agiletoolkit podcasts?”

I began recording the Agiletoolkit podcasts in 2005 after hearing several interesting podcasts and wondering if anyone would be interested in a podcast about Agile. I had always been a gadget person so fiddling with recording equipment and microphones was a natural for me. In fact, I now also have an iPhone App for the podcasts.

I love having the conversations and the podcast gave me an excuse/push to have conversations with people that I might not connect with in the halls at a conference.  A good example of that was when someone said to me, “You have to talk to this guy Arlo.” Without that introduction via the podcast I am sure I would not know Arlo Belshee as well as I do now.

While I am by nature gregarious, I do not search out “networking opportunities”. The podcasts have forced me into a new comfort zone that includes a lot more people from the community than I would have connected with through normal channels.  While I hope people appreciate and benefit from the podcasts, I do them for myself.  That affects the style of the podcasts. Since I am not trying to be polished or create an edited product, the podcasts have a more natural/comfortable feel.  I just wish I said “UM” less and a was little more polished on my delivery. But…I am who I am and it is what it is.

“How did you get into Agile philanthropy?”

Agile philanthropy started as a way of trying to meld my passion for doing good in the world with my passion for agile methods.  Using the power that is evident in the agile community to do great things is one of the goals of Agile Philanthropy.  Ideally we will get to the point that this movement is self-sustaining. But we are really just starting out on this journey.  I hope that I can grow the movement in the direction of local chapters doing work for local not for profits. Right now everyone is very busy and I am the bottleneck.  We are currently working with Mano a Mano and Haiti Partners. And, I would love to have people with a passion for a particular cause to contact me and start up their own chapter.

“What about your other philanthropic interests?”

I am very interested in local sustainable food, economic development and social justice. I volunteer in my kids’ schools quite a bit.  Most recently, I built incubators with the kids and hatched chickens and worked with the teachers to incorporate that into the curriculum. I have been working to get local food into the schools; to create school gardens; and, to relax the laws in Washington DC as they pertain to the keeping of bees and hens. Most of my other work is more directly related to the work I do in Agile Philanthropy.

“When did you start the Mano a Mano project work and what have you and your yearly teams accomplished at the Agile conferences?”

Seems like forever but we introduced Mano a Mano three years ago when the conference was in DC.  I was running the development lab in the basement and hoped that I could get some real work done in the lab that would do some good.  After that, I tried to make it more formal and improve what we have done for them each year.  They have been very appreciative and very patient with us since I am learning as I go with this process.

To date, we have moved them onto a Content Management Platform and developed their iPhone optimized donation page.  Most importantly, I am happy that I have connected Mano a Mano with David Hussman and a number of other volunteers in the Twin Cities that are helping out on a regular basis.  Wayne Simacek showed up for an event that Jeff Patton and Ed Kraay were holding to help Mano a Mano define their web strategy and ended up staying on as a volunteer member of their IT staff.

It is that kind of leverage that I hope to bring by connecting the two communities.

“What do you have in store for us at the Agile2010 conference?”

For the Agile2010 Conference, I am working again with the UX stage to do an Extreme Makeover for the Mano a Mano web presence.  We hope to be able to work on their information architecture and site design to improve the impact of the message that Mano a Mano is putting out. We are looking for volunteers to come by the LiveAid lab and help with the effort (hint, hint).

I also hope to get people interested in replicating this model for not for profits that they are passionate about.

You can do this too

To end this post, I want to thank Bob for the example he sets for all of us. I also want to emphasize Bob’s call to action to get engaged locally. You can do this through your existing local Agile group. Or, you can create a new group with an express charter to give back to the community. Recently Brad Feld here in Boulder wrote about the “Boulder New Technology Meetup” event that supported over 300 people engaged with 20 local non-profits. And here at Rally, we are marching along with Bob philanthopically working to give back: supporting  Intercambrio, donating time to local non-profits (Community Food Share and Growing Gardens) and working with the Salesforce Foundation.

Ah, Marketing.  Enter a world of countless project requests, numerous stakeholders, limited resources and rapidly changing market conditions.

Sound familiar?  In fact, marketers face a lot of the same challenges as development teams, and Agile can be a powerful way to alleviate those common issues and intelligently plan our work.

In steps 1-5, I’ll explain how Rally’s marketing team conducts our version of Release Planning.  In steps 6-10, I’ll explain how we run our iterations to meet those commitments. Our planning processes continue to evolve, though this method has worked for awhile now.

10 Steps to Successful Marketing using Agile and Lean Practices

1. We recognize that Marketing has challenges that are different from Development.

• There is no unique product owner.  For example, if we chose Sales, then we would always rank lead generation over branding, customer programs or analyst relations, and that could ultimately hurt our company. Therefore we have to use some best-guessing to prioritize our backlog and determine what is most important.
• We face hard event deadlines set far into the future.  Sometimes we have no choice but to commit to an event or sign a contract months ahead of time.
• Each team member has unique expertise, i.e. writing, event planning, PHP development and so forth.  So one shared backlog is inefficient.

Now that we’ve reviewed the challenges, we give ourselves permission to do what we need to do, have patience and adjust anything that isn’t working for us.

2. Conduct an ORID to learn from the past

Before planning for the next quarter, we hold a retrospective in the form of an ORID, “a means to analyze facts and feelings, to ask about implications and to make decisions intelligently”, a process created by the Institute of Cultural Affairs.  We gather as a team to share:

• Observations (O) – What do we know?
• Reflections (R) – How do we feel about this?
• Interpretations (I) – What does it mean for the organization?
• Decisions (D) – What are we going to do?

This strategic overview helps set context for us to prioritize our focus for next quarter.

3. Align ORID decisions with company strategy

At Rally, we conduct quarterly and annual planning using the Plan Do Check Adjust methodology as explained in Getting the Right Things Done.   As we look at the overall company direction and goals, we keep these in mind as we hold planning at our own level.   Ideally, our major commitments support and align with company strategy. This also helps inform our “stop doing” list.

4. Poll our stakeholders

As part of determining quarterly commitments, we poll our major stakeholders for their top requests.  We use a Google survey to rank these requests by importance, size each request and bring these epics into our release planning meeting, to be included as part of our ranked backlog.

5. Conduct Release Planning to prioritize and agree on quarterly commitments

Now that we have all of our inputs, we hold our quarterly Release Planning session.  We write each epic on a sticky note and look at all of the possible work we could do this quarter.  Then, we evaluate epics based on importance taking company goals, stakeholder wishes, market realities like conferences and our own passions into consideration. We decide what we can realistically commit to, and agree as a team.  We keep in mind that making and meeting commitments is a huge deal, and we try really hard not to over-commit.

Part 2 – Meet our Marketing Commitments

6. Create a task board

Since our marketing team is mostly co-located, we pin up several large sheets of paper to use as a task board.  This is where we review our commitments on a daily basis as a sanity check that our stories are prioritized correctly and that we are tackling the right work as the quarter progresses.

As a team, we write our quarterly commitments on the task board with the definition of done assigned to each one.  We also include our “foundational” work – recurring work like website updates, online ad campaigns, field events, press releases and other important work that we need time to do.

Note: this is not a Kanban board because we do not have a shared backlog nor do we have a team-wide WIP limit.  As we break into smaller project teams that do share a backlog, we often use AgileZen to manage this work.

7. Hold iteration planning every 2 weeks

Every 2 weeks, we hold an Iteration Planning meeting.  Each team member has her own sticky note color, creates stories on those notes and manages her own prioritized backlog using T-shirt sizing to roughly estimate each story.  In this hour-long meeting, we begin by expressing appreciation for team members who gave exceptional assistance.  Then we hold a brief retrospective on what worked and what should change for the next iteration.  Finally, we each read out our prioritized stories for the iteration, putting them on the task board’s backlog.  This gives everyone visibility to what’s happening, identifies if someone is over-committed and lets the team swarm any epics with looming deadlines.

8. Conduct a daily stand-up

At the same time each day, we hold a stand-up meeting (with a consistent conference call #) that is at most 10-15 minutes long.  We form a semi-circle in front of our task board and share no more than 2 cross-cutting significant actions or take-aways from the day before, no more than 2 that we are planning to accomplish that day, and whether our work is blocked by any issues beyond our control.   As we start working on stories throughout the iteration, we move them from the backlog into their section of the task board to show what we are working on.  When the story is complete, then we move it to a place on the task board labeled “Done”.  Once the commitment’s Definition of Done is met, we check off that commitment and feel good about completing it.

9. Be patient as things change

It would be lovely if nothing changed during the iteration, but that just doesn’t happen.  The goal is ultimately to respond to change rather than cling to an outdated plan.  As new opportunities arise, new time-sensitive information appears and new requests are made, so our iteration work changes and that’s ok.  We try to just document what we’re working on and create new stories so that we can make intelligent prioritization decisions during the course of the iteration.

10. Retrospect, inspect and adapt

As we keep running our iterations and fulfilling our commitments, we are always looking for ways to improve them.   Ultimately, we’re using Agile to improve the quality of our work life by using objective, smart ways of planning how we spend our time. And we’re learning a lot from the journey.

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:)

Finally, don’t miss the d.school’s blog and the coverage of their sugar cubes.

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.

Ryan Martens is a tomato grower, founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

Dear Readers,

Writing or receiving a break-up letter can be fairly daunting or shattering, depending on which end of the letter your name appears. That letter puts a pretty hard stop to a relationship. It’s communicating detachment and finality. It can create a lot of pain whether intended or not. In contrast, a love letter is uplifting. The endorphins fly! Someone is revealing their attraction for you, and their hopes and wishes for a future with you.

Now, there is a reason I have these letters on my mind. I’ve just returned from Rally’s Agile Leadership Forum – a great gathering of people eager to lead successful Agile transitions in their organizations. The event included a lively presentation from Forrester Research’s Senior Analyst Dave West: “Agile Adoption – Research Findings on the Adoption of Agile.” (You can find some of Dave’s data in the “Forrester Wave: Agile Development Management Tools, Q2 2010″). We also enjoyed an inspirational talk from our CTO Ryan Martens, called “Moving Agile Beyond Software.” These great presentations were followed by breakout sessions and a panel discussion about Agile challenges. Now, how to end the event?

As emcee of the forum, I not only kicked off the event, but it was my job to bring closure to the gathering as well. How can we have people walk away with thoughts about Agile? Why are they interested in the first place, and where do their concerns lie?  I was inspired by a video I recently saw about “breakup letters.” The Breakup Letter is a design research tool that Smart Design uses to understand the emotional connection between people and their products, services, and experiences. One person broke up with his cell phone, another, her single-cup coffee maker.

Now, just how does this relate to the Agile Leadership Forum? I liked the concept of the breakup letter, but I decided to entirely flip the idea and close the event by asking everyone to write love letters instead. In the spirit of Cyrano de Bergerac, I asked each table of participants to work together in crafting a “Dear Agile” letter. In this letter, they were to convey their attraction to Agile. And, they were to reveal where they were concerned about as well. All letters were to be from a secret admirer :-)

Once the groups began to read their letters, I knew we were on to something. Though I don’t have the reading of the letters on video, here are a few examples of our “Dear Agile” love letters.

Run this exercise in your own group to find out what the Agile “lure” looks like and also what the “turn-offs” might be.

Breathlessly awaiting your comments,

Jean

p.s. If you want to read some of the transcribed texts of the love letters, read on!

__________________________

Dear Agile,

I have admired you from a distance for some time. Waterfall and I are in the process of an ugly breakup. There is so much about you I need to know. My friend says great things about you. You are so simple and straightforward– no mind games like Waterfall.

This won’t be simple. Waterfall still has clothes at my place. My Facebook status is confused.

In the relationship as we get to know one another, we will have to know each other carefully– co-locating right away? Are we sprinting too fast?

Be gentle with me.

Looking forward to a rapidly developing future.

xoxoxo,

Secret Admirer

__________________________

Dear Agile,

I love you because you offer quick cycles, better quality, and better teamwork. From the first time I saw you, I thought I could begin saving money and add business value.

But, fair Agile, you are not so simple. I’ve heard you are a micro-manager. I don’t totally understand you. Some people are confused by you. On the surface, you sound so perfect and simple, but the more I get to know you the more questions I have.

But, among all my choices, I choose you. You promote collaboration, and allow me to turn things around quickly. You’ve helped me trim weight and stay lean. Don’t disappointment me, I trust you!

With all my love,

Megedá

___________________________

Dear Agile,

I loved you from the first moment I saw you, I loved your fast, speedy releases and that you don’t come with a lot of baggage or documentation. You’re simple and down to earth. You are a great communicator. I always know where you are and my friends love you, too.

I am, however, a bit concerned that not everyone accepts our relationship. I am worried that as my job continually grows and my needs scale up, whether you can handle the increasing challenges. And I’m concerned whether I can afford you… Our relationship and your attachments are what intrigue me the most.

Looking forward to spending more time with you and getting to know you better.  – Your secret admirer.

___________________________

Dear Agile,

We love you, we think you are awesome – for the following (bulleted) reasons:

• Agile accepts changes and encourages frequent changes
• Agile can start implementation before full requirements are known.

We do however have a few problems with you agile –

• Handling cultural change in the organization
• Does not solve all our issues
• Makes distributed teams harder to work with

- Your secret admirer -

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.

This is #4 in a Series on the Culture of Innovation with guest blogger Lee Devin.

Do you notice a difference between problems and difficulties? A problem has a solution. When engineers solve it, the problem goes away. It’s a question raised for solution with fixes, tests, and checklist updates. In contrast, a difficulty has no solution. A difficulty wants you to sit with it, address it, not solve it. Artists know this world of the difficult very well.  No definitive fix, test, or checklist will suffice. Sitting with and playing with the difficult is simply part of the knowledge work of the artist.

For both the engineer and the artist, a difficulty is often what tangles up the solution to a problem. We see problems and difficulties all around us in the world of innovation. What’s needed to address a difficulty may not be clear at first, if ever. You may, in fact, never achieve that lovely industrial clarity. And yet, our ability to gaze unflinchingly into the face of difficulty will lead us to solve problems with greater innovation and deeper artistic mastery.

Difficulties require “AND” thinking

Difficulties are fuzzy. Improving how we address difficulties requires us to hold a large container with the word “AND” versus the word “OR.” This concept was first introduced to me in Peter Senge’s Fifth Discipline Fieldbook. I also delved into the topic in his course on Leading and Learning for Sustainability. To work with difficulties, we hold and play with a spectrum of possibilities, multiple solutions sets: this AND this AND this AND this. For the actors in a theater ensemble, AND means absorbing a variety of possibilities with the materials surrounding the play. Many innovative outcomes await based on the ensemble’s ability to hold the ambiguity of the art and embrace that sense of release.

For engineers, this might look like the following: you are solving multiple simultaneous equations for problems you see in the larger system. To be able to hold on to this container, you and the team have to feel safe “failing” with lots of little experiments. You must keep the “art of the possible” in mind. This is not an easy task for an individual, much less a group. Difficulties that accompany problems require the courage and patience to sit in a large container of ambiguity.

Consider the wicked problem example

In their book Wicked Problems, Righteous Solutions Peter DeGrace and Leslie Hulet Stahl help us delve further into problems and difficulties. Wicked problems arise out of several conditions. First, the problem domain is complex and fraught with difficulty. Then, the solution domain is similarly complex and difficult.  Finally the two overlap. That is a wicked problem. Wicked problems hold nests of difficulties. Let’s compare the wicked problem of an engineer and one of an actor.

The engineer’s work begins by reading a user story and exploring the problem sheet from the architecture council. In this assignment, the engineer must be prepared to address known and unknown difficulties on the path to a solution. The engineer recognizes that there is no one solution. How difficulties are addressed may be the key to just how innovative the resulting solution is.

This assignment is the equivalent of a script given to actors. The script is not a limit, but rather material on which to perform and interpret to create something new. There is no one solution. And so, the actors hold ambiguity as they move to the ultimate offering to their audience.  How the final play comes together may depend on the ensemble’s ability to play with and address the large realm of possibilities.

The art of the possible and innovation

Like actors, engineers and other knowledge workers need to do our homework, invite innovation and alternative solutions. We need to address difficulties not by point solutions, but by applying “AND” thinking, creating large containers of possibility. We must embrace the art of the possible. In the case of the actor, this comes in the form of rehearsal, ensemble and release that ultimately leads to the actual performance. In the case of the engineer, this work comes in the form of design spikes, set-based engineering, and tests. In both cases, experiments create space around difficulties. The art of the possible broadens the team’s or troupe’s innovative outcomes.

For such a culture of innovation, “AND” thinking is a vital function. At Rally, we apply “AND” thinking in how we address difficulties in a variety of ways. We may take a particular problem with its difficulties and spread it across a paired team of engineers. The teams work safely in an “art of the possible” mode for addressing difficulties in a way that leads to a better solution. We eventually move through the “AND” to a final solution, having addressed the difficulties in a variety of contexts. How you invite “AND” thinking and the art of the possible into your organization may include your Chief Engineer, a Product Owner, Director of System Engineering or a peer engineer all working in a new larger container.

Say “No,” to “No way!” and “Yes,” to “Imagine if…”

Within given circumstances, which are different for each team member, and a safe container for the conversation, the group can play out the implications of a solution, and discover its virtues and flaws. As with an ensemble of actors working through the possibilities of a scene, the only rule is: Never say, “No!” Swallowing that “No” can be hard! You must fight your first response to a suggestion or proposition, which is often “No, there is no way that it will work.”

Instead, the thing you must do is think, “Wait a minute. Let’s assume it will work. Let’s find out what happens when it does.” And, you’ll find out what happens when it does by behaving (thinking, talking, deciding) as if it is in place and working. If your first response is “Oh, wow, what a great idea!” the release might be, “How do I fit myself into this? What can I do personally to make it work?” The tool here is imagination.

We must find comfort in ambiguity and uncertainty. The question is: how can you create the container that allows your team to live with this difficulty and keep from jumping to try and solve it? If we create a culture friendly enough to notice accident and serendipity, we set ourselves up for the asymmetric payoffs associated with successful innovations. Our “AND” thinking and art of the possible ferret out the wicked problems and harvest collective team creativity.