Agile 2010 Conference Notes

I used to attend Agile and quality related conferences years ago and have saved notes from many of them. While some topics have become overtaken by events since then, there still seem to be some useful ideas that I’d like to pass along.

[Fortunately, I have the names of other people who offered their views on this conference as you’ll see below. One side note: this was held in Orlando but was planned to be in Nashville; however, flooding in Nashville at the planned conference venue, with repairs expecting to take months, caused it to be moved.]

7 tools for PO (Alistair Cockburn)

This was a workshop/discussion. Our table discussed the dual Product Owner as outward facing accountable to the customer and inward facing as responsible to the business (strategy).

We also discussed the Kano model considering how much more (or less) would we pay for a feature’s presence (or absence)? We also touched on how the Delighters might be viewed as more important than other items, though there was real debate about how Delighters would compare to core items.

Alistair also went over the concepts of Shu (learn) — Ha (practice) — Ri (explore).

Keynote (Dave Thomas)

[I was copying down items rather quickly and had not put them into a coherent narrative, though Thomas did when they were presented. What follows are my quickly written notes of the thoughts I picked up from the keynote.]

Improve predictability: simplify workflow, collaborative estimation, short iterations, simplify visual progress tracking

Improve quality: improve requirements communication, continuous integration, integrated teams

Improve productivity: fewer mtgs, reduce stress, reduce research, improve communication, response to change

Death by iteration/incrementalism. [As I recall he was expressing his concern over a too narrow development view of what iterative development seemed to have become with a focus on cranking out stories rather than understanding value being delivered.]

Collective ownership: share knowledge, pairing, reviews/inspections

Testing shows the presence, not absence, of bugs (Dijkstra)

Practices [behaviors] before methods and [certainly before] tools

If you cannot do it by hand, i.e., cards, fancy tools won’t do it for you.

Apprenticeship — competence by practice

Absence of tests significantly increases risk

Communities of Practice — people doing self-improvement on their own time

Systematic change over 18–36 months — change mgt plan

Without acceptance criteria, you have a “wish,” not a requirement

Non-formal requirements should have stories

IT viewed as an expense rather than adding value — bus execs don’t understand IT

Agile is FrAgile as it depends on sustainable leadership and discipline

OO is drowning us in complexity

Maintenance and integration dominate development

Shortage of product designers and domain knowledge

Need more expressive, higher-level languages; smaller, more loosely coupled programs; more data-driven programs

[In a few years, Thomas would begin to express his concern over what Agile had become in blog posts such as “Agile is Dead (Long Live Agility)”.]

Scrum and Kanban (Damon Poole)

Poole’s talk focused on ideas related to decoupling Scrum activities from a pure timebox focus saying, as in football, “you get paid for touchdowns, not yardage.” Continuing the metaphor he said goodbye to the burndown chart as it was like measuring yardage (at least for task hours) instead of the “score” (i.e., value delivered).

(Various things he said had me thinking about understanding the assumptions and motivations in phased, sequential (i.e., waterfall) development which informs behavior people bring into agile efforts.)

Scaling Agile (Dean Leffingwell)

[Those wondering where SAFe came from might view this as one of the precursor presentations as, among other things, Leffingwell spoke of the “release train.”.]

It was clear Leffingwell was trying to emphasize lean ideas such as flow, “control through data,” and moving from “too many projects” to continuous content delivery (i.e., from projects to products.

He also made comments such as:

· Teams must learn that dates (and commitments) matter

· POs must learn that priorities matter

· If you cannot plan together and do CI, don’t bother trying to do agile at any scale

· Simplified business case proposals — don’t invest months in it; get an exploratory sprints budget; make it easy to stop/kill, but also to see early value

· PMO role to enable, foster and promote agile practices — but must change waterfall governance model into an Agile one.

Lean Overview (Mary Poppendieck)

Mary’s talk, compared to Leffingwell’s, was specifically focused on lean ideas such as:

· If it doesn’t add customer value, it’s waste.

· Build quality in, not expect to test it in. [Straight out of Deming’s 14 points “for transforming business effectiveness” as were other things Mary mentioned.]

· Manage workflow, not schedule.

· Relentless improvement

· Respect for people

· The “right” documentation is the documentation someone “is dying to use,” i.e.., who is the customer of any documentation?

· A fully utilized highway is a parking lot — cannot violate capacity. Understand and accept that some stuff is not going to get done — stop accepting more than you have capacity to produce

· Figure out how to say “no” early, not late

· Ask not how long “X” will take, but how much “X” can we get by date “Y”

· Define largest problem and visualize perfection — take a small step toward perfection (high-leverage behaviors that head in that direction) [Somewhat related to Goldratt’s Theory of Constraints.]

Thoughts from Martin Fowler

Last week I attended the Agile 2010 conference in Orlando. I’ve not been a regular attender of the main agile conferences, but I did go last year as well. Rather than attempt a consolidated description, here are a few scattered impressions.

· Attendance was 1400, more than 2009, but around the same as 2008. So although it has been hit by the Great Recession it’s weathered it reasonably well.

· I was delighted to see Elizabeth Hendrickson and Liz Keogh win the Gordon Pask award.

· My sense was that most people were relatively new to agile, which is in line with my sense in 2009.

· There was a much higher proportion of women than I usually see at software conferences.

· There were lots of talks going on, which felt overwhelming to me: 16 stages (tracks) with 214 talks.

· I was pleased to see the tutorial on Continuous Delivery that Jez Humble gave with me seemed well-received. (We currently have it booked again for QCon and OOP.)

· Most of the emphasis was on team collaboration and soft skills. This led to some criticism from people on the programming side.

· My unscientific sample of talks I attended showed a higher proportion of badly presented talks than I would like.

· It seems there’s a movement to re-create XP Universe for next year.

· I prefer a conference in a real city to one in a holiday resort.

· This year marks ten years from the first agile-oriented conference.

I have mixed feelings about the complaints on the lack of programming topics. Certainly programming plays a central role in software development and attempts to marginalize it correlate well with dead-ends. But programming is part of a very interconnected system which involves lots of pieces — and making these interconnections work requires exactly these kinds of “soft and woolly” skills. There is a real tendency for programmers to look inward and obsess on technical issues rather than engaging with those outside programming. One of the things I like about XP is that it recognizes this: blending technical excellence with collaboration.

I would hate to see programming detached from the agilexx conference with programmers going to different events. There’s a need for places where the intermingling can occur. The JAOO and QCon conferences seem to do a very good job of this — as well as having a better quality control over the talks themselves. Their format isn’t universal, and there’s room for more options. Our crucial task is to engage in excellence in the programming side without cutting off the essential collaboration.

Highlights Of Agile 2010 From Tom Grant and Dave West

Dave: This year’s event featured the now-familiar smorgasbord of sessions, including discussions in and out of “open space” where participants could build their own content and sessions. Aside from increasing the number of interactions around an event, open space generates additional energy within the event. Many times, I tried to walk from point A to point B, only to stop and listen to a heated discussion on a particular topic.

Tom: Unfortunately, after the event, some of this energy dissipates. The Agile community really needs a community hub, a site that serves the needs of beginners and veterans across a wide range of topics.

UX Design And Agile

Dave: We heard many interesting discussions on how to make user experience (UX) design and Agile work well together. The sessions on this topic concentrated on solving one thorny problem: cadence. Traditional designers push for a complete picture; Agile teams want to build a more incremental understanding. Participants made the following recommendations for making the UX and Agile gears mesh successfully:

Integrate the designer into the team. Embedding the designer in the team helps resolve the disputes between the need for a holistic view and incremental discovery. In addition, as part of the development process, the designer can tap new sources of inspiration and insight.

Don’t start until you are ready. Agile methods encourage some thought prior to building software. In Scrum, this is called “Sprint 0,” which focuses on defining the initial backlog, team, and plans. Designers need to add their own milestones, such as indentifying personas, understanding context, and determining UX goals.

Make usability testing part of the normal test process. As unfamiliar as it might be to some teams, incorporating usability testing into normal testing provides immediate feedback loops for both development and design.

Tom: My only addition to Dave’s observations is the following slogan I may put on a bumper sticker: The importance of UX increases every day. UX played a conspicuous part at Agile 2010 because, among other reasons, people are putting a higher premium on the UX component of their applications. That’s a whole other blog post, or several blog posts, to explain why.

Dev Ops/Continuous Delivery

Dave: Agile 2010 could be described as the breakthrough event for dev ops professionals responsible for delivering what Agile teams produce. Integrating development with operations and release is crucial for long-term business agility. At Agile 2010 the discussion about dev ops focused on:

Shared goals. Developers (and Agile developers in particular) want frequent delivery; the system admins want infrequent delivery. People who are trying to square this circle are introducing incentives for the two groups to partner more effectively.

One life cycle, one process. ITIL, CMMI, and to some extent Agile methods have reinforced the separation between development and operations. ITIL 3.0 may be the basis for an integrated view of the end-to-end process as applications move from development to deployment.

Tooling that integrates. Currently, ALM tools support the SDLC, and IT service management tools support the operations groups. Organizations need tools that span these processes and teams. The scions of the Agile movement may have distrusted tools, but it’s hard to imagine solving the dev ops dilemma without them.

Serious Gaming

Tom: Agile focuses attention on the quality of decisions that guide the development process. By shortening the iterations, teams have seized the opportunity to assess their past decisions then make mid-course corrections (and even early-course ones). However, there’s nothing inherent in Agile that tells you how to make a better decision or even spot the bad ones. The exception, perhaps, is planning poker, a conspicuously game-like activity that, for many teams, makes scoping more accurate. Now, teams are considering other games to help with other decisions, such as prioritization, process flow, and design.

Managing Technical Debt

Dave: The Agile community has faced a lot of hard questions about how a methodology that breaks development into short iterations can maintain a long-term view on issues like maintainability. Does Agile unintentionally increase the risk of technical debt? Israel Gat is leading some breakthrough thinking in the financial measures and ramifications of technical debt. This topic deserves the attention it’s beginning to receive, in part because of its ramifications for backlog management and architecture planning. Application development professionals should:

Start capturing debt. Even if it is just encouraging developers to note issues in the comments of code as they are writing it, or putting in place more-formal peer review processes where debt is captured, it is important to document debt as it accumulates.

Start measuring debt. Once captured, placing a value/cost on the debt created enables objective discussions. It also enables reporting to provide the organization with transparency of the growing debt. I believe that this approach would enable application and product end-of-life discussions to happen earlier and with more accuracy.

Adopt standard architectures and open source models. The more people who look at a piece of code, the more likely debt will be reduced. The simple truth of many people using the same software makes it simpler and less prone to debt.

A Quick Synopsis of Agile 2010 by Alan Shalloway

The networking was awesome as usual. Some of the people I had long exchanges with were Alistair Cockburn, Dennis Stevens, Mike Cottmeyer, Tom Poppendieck, Mary Poppendieck, and many others. I also attended some great presentations — Israel Gat’s had a real impact on me. Unfortunately, the presentation quality [varies with] some being excellent, some being fairly poor. Given the nature of the conference where fringe type talks are often delivered, this isn’t surprising and is a necessary difficulty.

I felt a little like being in a time zone. The industry is clearly maturing and that is good. Many things that Lean/Kanban thought leaders have been saying for years — sometimes resulting in fierce opposition — were being touted as natural and having always been that way. These included the need to optimize the whole, go beyond the team, include management, do acceptance test-driven development, manage your work in progress levels within an iteration, amongst others. It’s funny how people flip from opposing to ignoring to advocating but don’t seem to acknowledge the flip.

The interest in Kanban was very high. Unfortunately, I don’t think all the Kanban talks represented it well. There is a wide range of Kanban ‘expertise’ out there now. Some people have been doing it for a few years, others have taken David Anderson’s coaching class (a great class, btw) and now consider themselves experts. Oh well, that’s the way the industry goes. I was glad to see Henrik Kniberg and Karl Scotland present. I attended an experience report re Ultimate Software that converted to Kanban that was great. Interesting how they expanded their team sizes — which Kanban allows for.

I was happy to see ICAgile ‘s announcement of certification. While this is not a fully fledged certification approach, it is a step in the right direction in that it will at least discuss competencies required for certification. I have long stated that the first step of a certification program is to specify the competencies that represent what the certification is for. As far as I know, other than our own certification program, this is the first such program available. Whether it will succeed or not is in question, but it is a step in the right direction over existing programs. [Ahmed Sidky, head of the ICAgile organization, had presented his research work on team assessments at past conference, but this conference seems to have been where that effort wasn formally announced.]

Although I greatly enjoyed this conference, I still find the Lean/Kanban conferences I’ve been attending to be more useful for learning new things — and the networking is just as great.

Bottom line, the Agile community is both maturing and becoming more fractionated (if that’s a word, but I think you get my meaning). The overall trend is good. Both consultants and practitioners understand the need to go beyond the team and to start using Lean and Kanban.

Agile 2010 — Industry Analyst Roundtable by Shane Hastie

On Tuesday afternoon the conference hosted an Industry Analyst round table to hear their take on the current state of Agile and where the industry is headed in the future.

The four panelists were:

· Dave West, Forrester Research

· David Norton, Gartner

· Melinda Ballou, IDC

· Michael Azoff, Ovum

Jim Newkirk, chair of the Agile 2010 conference, led the questioning by asking the panel to introduce themselves and then to comment on the Top three things an organisation needs to do to ensure success in an Agile rollout:

David Norton

Make the Agile change a part of the “organisational DNA”. Many organisations underestimate the depth of the change that an Agile transition needs, it’s end-to-end cultural change across all aspects of the organisation. Look beyond the software development area of the business and address changes across the whole range of disciplines within and outside the information technology area — such as enterprise architecture, infrastructure deployment, HR policies and so forth. To be successful an Agile change cuts across all areas of the IT and business space.

There are 3 C’s that drive effective Agile implementation:

• Continuous Testing
• Continuous Integration
• Continuous Deployment

Without focusing on the three C’s organisations won’t get the benefits of Agile rollouts.

Michael Azoff

He referenced the session by Israel Gats on Culture. Culture is the key — does the organisation’s culture support an Agile approach? Understand the local organisational culture, find it’s strengths and work with those strengths to adopt an Agile culture.

Agile techniques emphasise the importance of collaboration beyond the development group — collaboration with the business, the end user community, support departments such as IT operations and Human Resources; it is vital that Agile teams build strong relationships and build trust to ensure that they are given the time that Agile needs to enable the collaboration and dialogue to happen.

Agile is not something that can be imposed on people — it needs to spread by example. Having “evangelists” within the organisation helps — role models that people will come to for advice and guidance.

Dave West

Agile adoptions are most successful when there is a reason to adopt — in response to internal or external changes and the software development group needs to adapt to delivering faster, delivering innovation and focusing on value. When there is a compelling reason then the organisation can address some key issues to make Agile stick:

Make Teams Work — most organisations talk about teams, but don’t actually work in teams. People are measured on their individual activities (number of requirements, lines of code, number of test cases, etc); to have people working as a team, they need to be measured as a team — create a culture that facilitates and enables teams.

Figure out how to really align what the development teams are building with what the business really needs. He says “you can do great Agile and build rubbish for the business — we build lots and lots of really good mousetraps, when the problem is you have a bad case of the elephants, and mousetraps aren’t successful with elephants”.

Bring in lean thinking (reducing waste, increasing value, transparency…) at the highest level in the organisation creates an environment where effective teams and alignment emerge naturally.

Melinda Ballou

Agile has been very successful in environments where organisations are struggling to be dynamic and responsive to competitive situations, where there is a very clear need to make a transition. It is important that there is significant intrinsic need within the organisation, so the Agile changes will stick. There has to be readiness and an understanding of the needs that are driving the transition to Agile.

A focus on communication across the whole team, business people and the technical people talking freely and openly creates alignment.

Managing the disparate pieces that need to be pulled together for an Agile adoption. The largest barriers at an enterprise level is the fear of chaos, so it is important to put structures in place that pull the pieces together and show the benefits of Agile changes — faster time to market, better quality etc. Making the benefits visible establish good grounding for successful adoption across the organisation as a whole.

A question from the audience was addressed next: where is Agile in the technology adoption cycle — has Agile actually crossed the chasm?

Dave West

It depends on the industry and organisation — different industry sectors are at different points in the technology adoption curve. The ISV sector has completely crossed the chasm — in that space Agile is now mainstream and is probably reaching a plateau; Agile is a natural fit to the needs of the ISV community.

Other communities have a long way to go — heavily regulated industries are far behind, government is surprisingly ahead in some areas and behind in others, the pharmaceutical industry is in the early stage, financial services further ahead. It depends on the industry you are looking at.

Melinda Ballou

It is an evolutionary process. The financial crisis of the last year has been a strong driver to doing more with less, and this has been a very strong driver for the Agile takeup in many organisations. It has crossed the chasm, but there is lots of room for more growth.

Michael Azoff

COE’s are demanding of their organisations that “we need to be Agile” — it now has traction and will not fall down the adoption chasm, the future is further growth and is now in the Early Adopter phase, and is part of the mix of choices for many organisations today — less waterfall, more iterative, more mixed, more hybrid, more Agile.

David Norton

There are a vast range of organisations out there that are adopting Agile, for some it is an easy adoption, for others it is like turning an oil tanker. 71% or organisations have adopted agile, but only 15–20% have adopted it in a measurable way. For some it is a case of rebranding existing bad practices (“we used to be bad at documentation, now we’re Agile and don’t do documentation”) as Agile without actually making changes.

Jim Newkirk then asked the panellists to each give one scenario where they recommend not adopting Agile

Michael Azoff

Where requirements are fixed and will not change then Agile is not going to deliver cheaper. Irrespective of this, any process will benefit from applying some of the Agile practices, such as bringing testing upstream.

Dave West

Remember that should & can are not the same thing. Where you have a very well known technology platform, with a very well known requirements and a very well known team then the benefits of Agile will be less than where you need to manage many unknowns.

There are also some situations where an Agile adoption has no chance of success — sometimes the organisational environment and culture simply won’t allow it to happen. If you haven’t got a team culture, if you haven’t got a connection with the business, if you haven’t got a willingness to take on the Agile values, if you’ve not got the willingness to accept a slight overhead, if you’ve not got the tools and technology to support Agile, it is probably best not to even try — go and get a job somewhere else.

Melinda Ballou

You need structures and links for the organisation to be successful with an Agile adoption. Agile works best where the organisation is most dynamic. Where the culture doesn’t fit, where the executives are not ready rather don’t attempt a full Agile makeover — rather use some of the capabilities and techniques and migrate the cultural change slowly. Don’t adopt Agile just because it’s fashionable — ensure there is a clear business need to make the change.

If you can see that Agile is going to fail — don’t do it!

David Norton

There are some cultures where Agile simply will not be able to work — places where the business people leave when IT walk into the room, places where processes haven’t changed in 20+ years.

Many organisations are adopting hybrid approaches — taking on the practices incrementally and growing into an Agile culture from the ground up.

A questioner from the audience asked is there room for Agile outside of software development (for instance in imbedded devices)

David Norton

Agile in imbedded systems organisations has been very successful in many organisations today.

Dave West

Agile works in imbedded environments (he gave the example of Boeing Space Systems), but it does require some sophistication and additional practices around the use of tools and abstraction techniques. He gave an example of how an organisation that is building imbedded systems was able to identify and resolve a problem with the hardware/software interface early because of the use of continuous integration.

Melinda Ballou

They are seeing the takeup of Agile and integration with product lifecycle management in imbedded systems organisations. Teams are finding ways to bring the benefits of Agile around quality and time to market to product development organisations.

David Norton

In the imbedded world the use of software products is growing exponentially and these organisations are grappling with the problems that pure-software organisations have been dealing with that drove the uptake of Agile techniques, and as a consequence we see the uptake of Agile in the embedded environment being a major growth area.

A follow up question asked why Lean manufacturing principles were not taken up by the embedded systems providers as Lean came out of the manufacturing world

Dave West

In manufacturing environments there is a push to get the IT groups to work better with the product development teams. IT traditionally didn’t embrace the Lean principles and were seen as hindrance to the Lean transformations in manufacturing organisations. The Lean manufacturing groups have been frustrated because of the cumbersome IT processes that have been used in many environments. It is only now that Agile has come onto the IT radar that the sensible Lean techniques are spreading into the IT groups.

David Norton

The manufacturing quality improvements such as TQM went on around the IT departments, and IT held itself outside of these changes and improvements. Lean comes from a manufacturing background, and Agile is software development grass-roots, and they have evolved independently until recently.

Melinda Ballou

Given the increasing importance of software in manufactured products and the high human costs from poorly performing software in imbedded systems, there will be an increasing an evolution as Agile techniques provide a confluence across hardware and software development.

A question came from the audience: How do we get CxO level managers to understand the importance of the disciplines and rigor surrounding Agile as opposed to simply hearing “agile” and expecting changes from their team without investment in changing engineering and people practices.

David Norton

There have been many implementations where the impetus for an Agile change comes because the “CEO heard about it on a flight back from London” but the organisation has immature engineering and people practices. There needs to be an education exercise to bring the C-level management to a realisation of the importance and value of making the cultural and engineering practice changes that are needed to implement Agile.

Dave West

At the Cx level it sometimes requires that the software development leadership acknowledge that the way they have been working hasn’t been successful (or even that they’ve been lying about project progress). Leadership needs to understand that the way projects have been governed and implemented has forced this behaviour and the “old way” of building software products has not worked and will not work in the future. Software is now crucial to the development of most products and services in the economy today. 15–20% of the R&D cost of the modern automobile is now spent on software — the new Mercedes S Class has over 20 Million lines of code in it’s navigation and entertainment system alone.

Michael Azoff

Executives need to understand that the ways we have been working hasn’t delivered value. Emphasise the business value — getting products to market faster, earning value earlier, responding to customer needs. Executives do not want (nor do the need) to know “what a Scrummaster does” — they want to know what the business value is that will be generated as a result of adopting the new process.

Melinda Ballou

The history of software failures is important in helping executives understand the value of Agile. Organisations have spent multi-millions of dollars and much time building products that turn out to be irrelevant to their customers. Focus the Agile discussion on fast turnaround — delivering the most important piece of business value quickly, and allowing the project to adapt to rapid changes in the marketplace. This gives the organisation the ability to be responsive and quickly create value. These are the things that resonate most with executives and that drive an Agile adoption from the top down, allowing the effective investment in the organisational and cultural changes that are essential for Agile adoption. Organisations make the investment based on the value that is made.

Dave West

These changes require that organisations take a long-term perspective, there is an upfront investment required to deliver this value. The perspective of “get something out the door quickly” and quality doesn’t matter is challenged, and in some ways the financial crisis has helped because people don’t move jobs so quickly (“I’d better build it well because I’ll have to be around to support it”).

David Norton

Agile enables organisations to focus on value rather than cost — they are able to see software development as an investment in the future rather than an immediate sunk cost.

The next question asked “What is the future of CMMi?”

Dave West

The SEI have published a paper talking about the future of CMMi that talks about the need to be more agile, and more ITIL but the details are not yet available. CMMi is not going away, and it will change significantly, but what shape that future will take is unknown at this point.

David Norton

The area of CMMi that gets all the press is the Staged Version, which talks about the maturity levels. Behind the scenes there is a continuous improvement focus that looks at the practices and techniques, and it is in this area that the CMMi will grow and change.

Michael Azoff

CMMi is about telling you what you should do from a process perspective, not telling you how to do it. There is a healthy exchange between CMMi and the Agile community at the enterprise and very large scale area where there will be a healthy intersect between Agile at scale and CMMi.

Dave West

The world would not miss CMMi if it went away, but it is probably not likely to go away.

David Norton

The largest area of conflict with Agile is not CMMi, but with ITIL — ITIL imposes restrictive practices in change and release management that do not fit well with Agile approaches.

Dave West

This is where Agile leaders should be engaging — working with the ITIL teams to identify ways to change the ITIL approaches to work well with Agile practices.

Melinda Ballou

There are opportunities to engage with ITIL and identify common ground and adaptive approaches that meet the organisational needs and still embrace the Agile adaptability.

Both CMMi and ITIL standards need to be applied with common sense — build on the best of what we have, and pull in the other pieces to create a synergistic whole that delivers maximum organisational value.

The next question dealt with Usability: We have a very mature Agile implementation — how do we integrate useability into the Agile development process?

Michael Azoff

This addresses the broader area of incorporating business process modelling and techniques such as whiteboarding utilisation, and that is a fruitful area for further growth. It ties in well with the push towards understanding what the customer wants and there is opportunity for tools support and pushing the Agile practices into business process management.

Dave West

Design agencies don’t like Agile methods, they want to define the whole UI and all the interactions up front, and Agile teams are resistant to that type of up-front work. New-media implementations put pressure on traditional design groups because of the looseness that mash-ups and collaborative toolsets allow in the UI area. We are seeing a lot of work going on trying to bring Agile approaches and classical design approaches together.

The UX designer is an increasingly important role, which needs to become imbedded into Agile teams — the creative, interaction designer will bring a multitude of new and innovative ideas that will add value to the Agile project. It is best achieved by making the person with UX skills a part of the team, rather than an external expert who is consulted occasionally.

Melinda Ballou

By including User Experience and Ergonomics skills into Agile teams we see a decrease in chaos, and fundamentally better customer/user experiences from the products being built. There is an opportunity to combine experience/interface design with the iterative development world.

The final audience question covered “what do you think are the challenges of Agile development with distributed teams and how are they going to be addressed?”

David Norton

It is vital to enable distributed teams to communicate easily and collaborate effectively. This is one areas where tooling becomes really important — organisations with distributed teams need to invest tools that will allow constant communication and knowledge sharing.

It is also necessary to invest in creating a shared culture, there must be a feeling of being a single team, not “the Indian team” and “the Dutch team”, it’s “the team” whose members happen to be spread across a number of locations — one organisation has gone to the extent of making sure that the furniture and wall coverings are the same in all of their distributed spaces to help create this common feeling and build the team spirit.

With distributed Agile projects you need to accept that there will be a need to travel — spending the time and money to create the shared culture will pay dividends in faster development with less problems. Watch out for the clues about losing team cohesion — the tone of emails, comments about “it was them” and so forth, and when that starts to happen bring the team together to reform bonds.

Michael Azoff

Cutting the travel budget is going to end up being more expensive. You can use technology to enable communication but face to face contact is crucial. Distributed groups could have ambassadors who travel from place to place and get to know all the team members, but face to face contact is needed to foster team spirit and build productivity.

Dave West

Technology can help but face to face is needed to create intimacy — video conferencing helps, but where the timezone difference is such that there is little or no overlap of working time then it becomes really, really hard. Someone is getting out of bed for the 4:00am to have a meeting, which is simply not sustainable. Nearshoring is much more effective where timezones overlap, in this case the collaboration and video conferencing tools help tremendously. Ideally keep people together where possible and be prepared to travel.

Melinda Ballou

As far as possible keep distributed teams within roughly the same timezones so they can communicate relatively easily. Distributed teams are difficult, it is very important to ensure that there is on-site time where the team members get the opportunity to create a shared culture and understanding.

Wrapping Up — each panelist was asked to make a final comment summarising their thoughts on the state of Agile.

David Norton

The Agile movement has tremendous passion, and has made great strides. The Agile community may be experiencing some “teenage angst” as we learn about scaling up Agile and moving into larger enterprises. It is important to ensure that we do not lose the passion and the essence of Agile.

Michael Azoff

Amazing turnout to the conference which is proof that Agile is now in the mainstream. It is very apparent looking at the audience of this conference and comparing it with say TechEd how the gender balance is so different, with a far less male-dominated audience at the Agile conferences. Agile is a far more humanising activity and a more normal activity than traditional technical practices.

Dave West

The energy, passion and belief of the Agile community is affirming and energising. The community is expanding and incorporating diverse groups — “it’s more like a design shop every day“and that’s great.

One area of concern is the absence of an executive track in the conference, the conference needs to address the challenges of the PMO and executives in Agile organisations, include operations and support tracks and embrace the wider IT community beyond software development.

The participants at the conference make this conference special — the passion and enthusiasm and the willingness to share with each other in the sessions and in the corridors.

Melinda Ballou

It’s great to hear the experiences of the participants. This conference, and Agile in general, is an opportunity for human beings to communicate more effectively with each other. This conference opens many communication channels and creates a place to share experiences. I’m looking forward to the evolution of Agile in the areas that it is currently working in, and across the end-to-end lifecycle within organisations.

An area of future growth will be understanding how social media will impact organisations and Agile is poised to take advantage of that. It is also important to extend the conference to include the decision makers and executives.

The session ended with the suggestion by Dave West that participants “bring your boss” to next year’s conference and a suggestion that the conference organisers enable that by incorporating an executive track in the next Agile conference.

Have the analysts got it right? Where is Agile now and where are we headed in the future?