Agile 2007 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.
[As with other posts, this one is a combination of my own notes and comments from other people whose names I am ashamed to say I no longer completely recall as I have combined and edited these notes in the past.]
This was my 5th agile methods related conference. I was a speaker at ADC 2004 (Agile Development Conference, Salt Lake City), then again at Agile 2005 (Denver) and 2006 (Minneapolis) as well as at XP 2006 (Oulu, Finland). I had planned to speak at XP 2007 (Como, Italy) but was unable to attend. And, while I was not a speaker at Agile 2007, I, again, chaired meetings of the IEEE 1648 Working Group, which is developing a standard on the agile customer-supplier relationship [which, as I have noted before, never came to fruition].
Agile methods have been characterized as having a “sweet spot” in small project groups (7–10 people) and there has been concern expressed about how well such methods “scale” in larger organizations. This year’s Conference — the largest so far at over 1200 attendees and more than 300 sessions — showed how agile methods are finding their way into more “traditional” organizations. Such organizations usually have an official methodology largely based on a waterfall-like approach and may also have various internal and external “standards” for assessment, auditing, and regulatory compliance.
One valuable aspect of agile conferences is that nearly every major figure in the field is present every year, including those from outside the US. Consequently, it is almost always possible, sometime during the week, to engage them in direct conversation about their opinions and work outside their formal presentations. [Unfortunately, all these people no longer seem to find the conferences of value to them and only appear if invited to speak.] There is also, still, a clear sense of the agile values and principles underlying most of what goes on at the conferences. [Unfortunately, as the conferences grew in size, more and more attendees new to agile methods have their understanding shaped by specific practices of one or another framework.]
Customer Role and Collaboration
Though working collaboratively with a customer certainly sounds like the relationship to pursue, organizations can find this hard to do. A workshop at XP2006 (“Developers are from Mars; Customers are from Venus”) presented results of research on the customer role in agile (XP) projects. The results that, though customers (e.g., program or product managers) appreciated a closer relationship with development teams, the more “traditional” the organization as a whole was, a greater burden was placed on the customer. Regardless of the increased time spent with development teams, the rest of the organization expected the customers to continue to perform all their other duties as well. Such customers were already fully occupied in sequential waterfall-like projects, so increased “face time” with teams wore them out due to opposing pulls from agile project involvement and traditional project/product management tracking, reporting, etc.
Do We Need an On-Site Customer?
It so happens that the first session I attended during the week was a workshop that used a simple simulation to emphasize how much more effective it could be to communicate directly and frequently with a customer as opposed to through written “instructions,” i.e., extensive requirements documentation.
The exercise divides people into teams of two: a developer and a customer. The customer is given a sheet of paper with a variety of lines (straight and curved) drawn on it and, during the first phase, they are expected to write detailed “requirements” so the developer could reproduce this “vision” without interactive feedback from the customer. During the second phase, the customer is given another drawing, but sits with the developer and can direct the developer’s drawing by describing and pointing to, though not actually tracing on, the paper. As one might expect, the is significantly greater in the second phase than the first. There were, however, other lessons in the exercises:
· In the initial phase, either the developers or the customers sat around with nothing to do, while the other did their work, waiting for that work to be done and presented to them. In a waterfall approach organizations typically overlap project scheduling so people are “kept busy” and not idle waiting for work from others. The second phase, kept everyone busy and reduced the overall time to get a result by significantly more than half.
· Those in the customer role much preferred the second phase where they could communicate directly with the developer and work out an misunderstandings directly rather than trying to anticipate possible issues and write more detailed specifications to cover such contingencies. As customers, we all used terms in written descriptions that we hoped/assumed the developers would understand, e.g., draw a “crescent moon,” rather than describe in detail what that meant. In the real world, this would relate to commonly understood domain knowledge, which is always considered a project value. More direct communication with developers would allow reduction in translation from needs to specifications to architecture to detailed design to coding implementation since each “translation” can introduce error.
· Everyone in the customer role noted how much effort it took to try to think of and pick the right things to say to convey the “business vision” to the developers. When working directly with developers, we could see right away if we were communicating effectively or not and could try an alternate explanation. [An interesting variation in this simulation might have been asking developers to write down their questions, hand them back to customers who then have to write some new way to specify what is needed back to them, delaying progress toward the desired result.]
The overall lesson was not that we need close collaboration with the customer but what we can do to make it happen despite obstacles in doing so.
Introducing/Scaling Agile Methods in Large Organizations
As noted above, agile methods have been associated for many years with success in small teams. Several people spoke this year about their experiences and approaches for making agile methods more effective in larger organizational contexts.
Experience Reports on Agile Methods for Large Projects
Three speakers took a 90 minute session and spoke for 20–25 minutes each on their experiences. The first was from Microsoft’s Visual Studio Tools for Office product unit (one of 15 teams involved in the overall Visual Studio product). The second was the Senior Director of Software Engineering for BMC Software. The third was from the University of Calgary and was involved in a gas and oil production accounting system development with a staff of some 80 people.
The Microsoft speaker (Ade Miller) described their efforts in automating unit testing, doing build-and-test cycles of 10 minutes (to achieve a continuous integration capability), and instituting daily stand-ups. As these practices had worked elsewhere, if their implementation became difficult, they took the approach of “if it hurts, you should try to do it more often.” Because of the size of the overall product, the integration and testing was needed to bring the work of all 15 teams together went far smoother since there were significantly fewer problems in each individual team’s work. Miller also noted that having “slack” was important so teams could incrementally improve their methods and tools rather than hope to find time between releases to make this happen. (Speakers from Rally software in a later talk noted that “padding” a schedule is not the same as “slack”: the latter is explicit in the schedule so what Miller describes can occur openly while the former is hidden often to make up for inadequate estimation and commitment capability.)
The speaker from BMC Software (Paul Beavers) admitted that the biggest issue was changing “how people are led” and not the method changes. Thus, as I have noted many times in the process improvement work I have done over the years, the issue is not getting project teams to change as much as it is to get management to change how they handle people and projects under agile methods. Experience is a plus in technology areas but can be a minus for methodology and process improvement. This can be especially true in middle-management areas where creating change goes against the very things, quite often, that brought those managers to the positions they now occupy. What would be in it for them to change? Would self-organizing, self-managed teams mean their role would not need to be needed? [Over the years, the role of managers in an agile environment has often been given little attention. Indeed, some of the early proponents of agile methods suggested managers would definitely no longer be needed.]
BMC’s lessons from their agile implementation experience were to
(1) “establish a simple organizational structure … with direct lines of communication”;
(2) trust your teams and your intuition, acting quickly to remove impediments from development progress;
(3) pay more attention to qualitative measures of progress (which you can trust if you trust your teams);
(4) be an involved team member, but not try to direct the process;
5) handle requirements in an agile (prioritized) manner;
(6) invest in automation for (at least) a nightly build-and-test capability;
(7) maintain the software in a continuously release ready state (i.e., with no known defects);
(8) break the provider/consumer barrier.
The final speaker, from Calgary (Frank Maurer), noted that a key selection criterion for the people on the teams was interpersonal relationship skills. Technical skills were expected, so interpersonal skills became “the discriminator.”
Among techniques to manage a larger agile project, test-driven design seemed critical to “prevent chaos” and “keep the codebase stable.” It is far easier for a large team to move ahead expeditiously if they do not have to fear the impact of new work on existing, stable code because they have a way to test new code quickly and efficiently against the older functionality. (One of the challenges introducing an agile approach into legacy systems is the lack of full regression test suites so that whenever a change occurs, running tests inspire confidence that changes have not broken existing functionality. Another issue is how design integrity has eroded during many cycles of change leaving what the agile community calls “technical debt,” i.e., code that is difficult to understand and change without introducing, or uncovering, errors.)
Another approach this project took was to address cross-architectural design refactoring through a single team of senior developers who were to look out for and maintain overall design integrity. Having an architectural refactoring team was something a bit new tried on this project and seemed to work successfully. [Back in 1989, when I worked for the Bell System, I interviewed many different organizations about quality practices. One large insurance company noted they devoted 1% of their many hundreds of IT staff to a team that addressed such design integrity issues (in their COBOL code base). People were rotated off each year so people could take back what they learned about improving design integrity to their individual product areas. Such learning was also captured in document form.]
One caution that Maurer mentioned was how much customer alignment with the development team occurred. This could be troublesome for business sponsors who see the role of their program or product owners to be more one of oversight than collaboration. (As all speakers noted, matters of “logistics and culture” caused some of the more serious barriers to getting things started effectively using agile methods.)
Transitioning to Agile Project Management (Sanjiv Augustine)
Another area of difficulty for organizations moving to agile methods is the significantly changed role of the project/program manager to a customer representative/liaison, rather than a project directing one PMs must shift from managing things to leading people, letting the people on the teams manage things.
With the move to more iterative (process) and incremental (product) cycles, the “cadence” or “rhythm” that an agile project develops is far more visibly active and demanding of everyone’s attention. However, there is great value in the predictability and risk management benefits such an approach provides. Augustine noted that the key objective of agile project management is to “empower and enable project teams to rapidly and reliably deliver customer value.” For an agile project, this value is expressed in terms of working software functionality. Typical Earned Value approaches based on work breakdown structures do not measure progress in the same way.
Augustine covered three points:
(1) managing the flow of value rather than activities;
(2) creation of integrated teams who collaborate with customers and continuously improve, during the project;
(3) coordination of project success through helping people meet commitments rather than commanding performance.
Regarding throughput, Augustine defined lead time as work in progress divided by average completion rate. To decrease lead time, it is necessary to either decrease the work not done at any given time or increase the rate of completion (i.e., “velocity” in agile terms). Augustine asked people to consider which one they felt they were currently able to do most easily.
Finally, regarding leadership and commitment, the approach should be to get project staff to commit to the work that needs to be done rather than telling them what they have to do. For many organizations, this change will be one of the more difficult to achieve since it will so visibly affect the broader organization more than development teams choosing to implement group-level practices like stand-up meetings, test-driven design, pair programming, etc.
Agile Enterprise Rollout (Jean Tabaka and Ryan Martens of Rally Software)
The purpose of this presentation was to highlight things that would help an organization move toward a more agile approach to development.
The first step is to institute a “time-boxed rhythm of delivering value” through short development iterations focused on providing the customer with new, useful functionality at the end of each iteration. This will cause other things to naturally have to change, such as how projects are tracked and managed. A second step is the development of empowered, collaborative decision-making, allowing decisions to be made as much as possible at the team level. A third step is the amplification of learning through frequent feedback and adaptation of behavior. A fourth step is making quality no longer “negotiable,” i.e., sacrificing [lowest value] functionality instead to meet cost and schedule.
Test-First Practices in Regulated, Safety-Critical Environments (Brian Shoemaker)
This presentation addressed use of test/design practices as “documentation” of requirements and requirements traceability in a domain covered by Food & Drug Administration (FDA) regulations. However, much of the presentation addressed what “safety” means in an FDA context and how iterative approaches to validation can help emphasize the ongoing hazard analysis needed in safety-critical applications. Safety resides in the whole system, not some specific function: no single element truly resulted in his examples of failure since it usually took several failures to bring about the dangerous results that occurred.
Validation of safety-critical systems, like hazard analysis, “benefits from iteration and user feedback” throughout the development process. Of course, considering safety (or security or a variety of other software product characteristics) up front is an important head start. However, effective safety analysis produces new knowledge that must be acted upon as design is refined. Knowing that requirements are testable and can be validated immediately upon design being implemented is very important. Test-driven design expects that test cases for requirements are written before design and coding such that little to no time passes before validating that any change to the (presumably stable) codebase works correctly and does not disturb existing system stability.
During the discussion at the end of this session, one attendee from Australia stated that what agile projects seek to produce is “sustainable” documentation, which contrasts with the archival documentation many organizations have become used to producing. In contrast, “sustainable” documentation is documentation that people willingly keep up to date and accurate because they find it useful in progressing the development of the software and communicating, in real-time, with others about what the software does and how it does it. (Barry Boehm, at XP2006, described his experience at one aerospace company where he was taken to their “CMMI® Memorial Library” where all the documentation was kept that nobody but the auditors and assessors ever looked at.)
Agile in the US Federal Government Arena (Rolland Cueller and Jim York)
This presentation focused on higher level issues compared to the FDA talk which largely addressed system validation. The goal of the speakers was to highlight what they felt were factors making agile introduction difficult in government contracting situations:
(1) the compression of the typical waterfall lifecycle due to an iterative (and incremental delivery) approach;
(2) the alteration of the “engagement model” which changed resource utilization planning from multithreading over a long period of time, with people coming in and out of a project, to a short cycle, fully engaged resource usage.
What I have often heard is that the procurement and contracting process itself can make agile implementation difficult since contracts are often awarded to one organization to do the system engineering, several others to do implementation pieces, another to do independent verification and validation (IV&V), another to do user documentation and training, another to do integration and delivery, and then yet others to do longer-term maintenance (or “sustainment” as some call it). Given this and the fact that the contracting is competitive, the only way project participants can (or may be allowed) to communicate with one another is through large, archival documents. (Research has shown that large, text documents passed back and forth are one of the least effective ways to communicate information, though very effective for long-term archival recording. Despite their low effectiveness during actual delivery of project value, they are the most highly regarded form of communication in traditional methodologies since they are the easiest for relative strangers to the work to audit and assess.)
Other audience members noted how a feeling of “political capital” became invested in building a large project structure where career rewards could depend more (or at least as much) on staffing size and number of projects managed, not value of results. This often led to great difficulty in stopping admittedly failing or unnecessary work. The speakers noted experiences where it had taken months to actual close projects out after it had been determined they were not being successful.
Many people in the room advocated forming a local (Washington, DC area) group of people interested in promoting agile methods in government projects. This group took form and a consultant working for the CIA indicated that her company would offer to host the first meeting(s) of such a group. [I was not from that area of the country but left them my email address so they could let me know what progress was being made since one of the people interested in the IEEE agile methods standards work was Joe Jarzombek then Director of Software Assurance in the Cyber-Security Division of the Department of Homeland Security. I don’t recall ever hearing from the group if, indeed, it ever formed. I did work with Joe on IEEE and ISO standards for several years before the agile standard effort.]
Specific Agile Methods
Crystal Methods
Alistair Cockburn gave a half-day session on Crystal which is his approach to methodology “fitting” based on project size (in numbers of people) and system criticality (from loss of comfort to loss of life). His view is that no one methodology is right for every kind of project.
Therefore, he advocates building a methodology up and adding formality as the situation demands. As one moves along the horizontal axis (size), an increase in coordination and communication is required. As one moves along the vertical axis, an increase in verification and validation becomes necessary. This approach contrasts with large, robust methodologies with rules on how to “tailor down” for less demanding situations. (Unfortunately, what this often does is engender a culture of “How can we make the case for skipping/not doing things?” rather than creating a culture of “What do we need to add/improve to do a better/proper job?”)
Cockburn stated that software development consists of “making ideas concrete in an economic context.” Much invention and communication occurs. Everybody on a project is making decisions, large and small, which have economic consequences for the project. The speed of a project, therefore, “is the speed with which ideas move between minds.” One consequence of this is how people respond to ideas and knowledge and how they develop new skills based on that knowledge. Some people, Cockburn said, want to be taught “a technique that works,” i.e., they need to follow what someone else has already done. As people become more experienced, they “break away” from the limits of a given technique and “learn to shift from one technique to another.” Finally, they leave the conscious following and trading of techniques and invent/adapt in the moment, often unable to describe what “techniques” are being employed because they have melded many together.
Cockburn does have some “sets” of techniques and practices that he feels address certain intersections of size and criticality such as Crystal Clear for less critical applications and Crystal Orange for somewhat larger more critical efforts. But across all of the combinations there are some common properties (or what Cockburn calls the Crystal “genetic code”):
(1) software development is a “resource-limited cooperative game of communication and invention”;
(2) “frequent delivery, close communication, and reflective improvement” all help reduce project risk, especially frequent delivery;
(3) fewness of rules increase the likelihood of project success and adaptability;
(4) development efficiency (e.g., build-and test automation) and process “habitability” (i.e., tolerances in how lower level tasks are performed to increase willingness to use the methodology in more critical areas;
(5) face-to-face communication (as people will be disinclined to travel more than about 30’ or want more than a few minutes to get an answer if they are engaged in a productive flow of work);
(6) team discipline, skill and understanding as more critical than process, formality and documentation, though not to the latter’s exclusion.
Cockburn stated that his key indicator of whether people are following Crystal is whether they are doing the elements of (2) above, which he stated are “musts” for Crystal. Without frequent delivery (and the associated feedback when the customer/user works with the software) the risk becomes too great that the project may be headed in the wrong direction. Without close communication, the risk increases that people will be working at odds with one another, both personally and technically. Without reflective improvement, the project cannot adopt better ways of working to increase current project success. On this last point, lessons learned at the end of a project don’t do that project any good while reflection during a project helps that project as well as carries over in the next ones.
[Today, Alistair is promoting The Heart of Agile which removes the “cruft” he feels has attached to agility by encouraging people to Collaborate, Deliver, Reflect, and Improve. He says people know if they are doing these things or not.]
DSDM Atern
Since the Dynamic System Development Method (DSDM) is hardly used in the USA at all, I wanted to find out more about it from folks from the UK where it started (and then spread to many places in Europe). DSDM is a consortium of, generally, large IT organizations in commercial companies, local governments, and universities. In the past, material about the methodology was usually available only to members of the consortium, but, with the new release of the methodology, called Atern (yes, “a tern,” the bird), more information is freely available on their website (www.dsdm.org). For organizations more comfortable with a more comprehensively defined methodology, a more robust set of project roles, and connections to recognized project management approaches like Prince2™ and PMI, DSDM, and now Atern, offers a more appealing entry into agile methods that eXtreme Programming, Scrum or Crystal.
However, DSDM still adheres to the basic ideas behind agile methods: (1) a focus on business needs; (2) timely delivery; (3) collaboration; (4) never compromising quality; (5) iterative development; (6) incremental creation of functionality “from firm foundations”; and (7) continuous, clear communication. An eighth principle, demonstration of control, seems less agile and more traditional from a project management perspective. But, in general, Atern seeks to do this through an “appropriate level of formality,” plan visibility, progress measured in product delivered not activities completed, and continual assessment of project viability.
[In October 2016 DSDM rebranded as the Agile Business Consortium a not-for-profit organization for the DSDM framework.]
The Enterprise and Scrum (Ken Schwaber)
This presentation focused on what it means to transition Scrum into the larger organization from its use on individual projects. For a number of years, people have talked about scaling up Scrum through a “scrum of scrums” where the daily stand-up meeting is raised one level and representatives of individual Scrum projects meet daily after the project-level (team) meetings. Schwaber suggested this can work well as a “proof of concept” approach in introducing Scrum to an organization, but once there is some acceptance of Scrum’s effectiveness, initiating a more top-down approach is more advisable for enterprise adoption. At some point, organizational culture as a whole must be addressed. [It should be noted that Schwaber and Scrum.Org have formalized Scrum-of-Scrums into Nexus.]
But what does it mean to transition an organization to Scrum? Schwaber suggested that it was fundamentally the application of Scrum to any project/activity in the company, not just software and not just at the lowest product team levels. From a “vision” perspective, this involves asking what you want to be different at the end of any project that was not so at the beginning and applying this to more than just the product/service in question. For example, what would you like the organization to learn and how would you like it to improve as a result of the project. To do this requires continually applying regular reflection on what is happen and being open to change (adapt) to improve things that are not happening as you would like.
Schwaber cautioned that “if you only partially succeed [to implement Scrum] and then abandon further change…you end up with a more frequent, iterative ‘death march’ environment.” Schwaber listed some of the “fallout” from implementing Scrum (and, indeed, agile values and principles in general) more broadly:
(1) some people may leave because they won’t like the change;
(2) months 3–6 will be particularly hard;
(3) there will be more visible conflict;
(4) the customer/product manager role will change and get harder;
(5) development will be held accountable for retaining quality;
(6) compensation and reward policies will change (bring HR into the effort);
(7) management must shift from command-control to leadership;
(8) adding more people to a project will no longer be acceptable as a solution to cost and schedule problems [which Fred Brooks, back in 1975 in his book The Mythical Man-Month, said would only make a project later];
(9) change will occur throughout the enterprise.
Finally, Schwaber reiterated two points he makes in many of his talks and, specifically, in his Scrummaster training:
(1) don’t modify Scrum to make it more comfortable for people to act as they always have;
(2) most of the change has nothing to do with Scrum, but Scrum will point out the organizational dysfunctionality which must be changed.
Agile “Cultural” Topics
Leveraging Trust on Agile Teams (Diana Larsen)
“The First Thing to Build is Trust” since trust is a critical component of agile teams:
· between team members,
· between the team and the larger organization’s management, and, not the least,
· between the team and its customer(s).
Larsen’s talk generally supported my view of how trust is built through having shared, positive experiences. She called it having “mutual history.” If people are too distant from one another, they can hardly be expected to have real trust in one another. The close collaboration and communication advocated by agile methods is intended to address this project risk. Indeed, Larsen stated that “more communication (alone) will make things better.”
Larsen offered three views on what she called “professional trust.” It is:
“1) …the confident expectations of team members (and leaders) about each other’s behavior and intentions;
2) …a quality that team members extend to others who offer them basic support and value their ways of contributing to the team’s effectiveness;
3) …comfort with being as open to one another about failures, weaknesses and fears as about competencies, strengths and achievements.”
Trust within the team makes it easier for the team to demonstrate commitment to the work (because of their confidence in one another). Having trust and commitment then makes it easier to deal with conflicts that may arise. And, in a strong team, conflict, channeled appropriately, can lead to more innovative, creative results.
Simple Steps Toward Excellence (Ron Jeffries and Chet Hendrickson)
Ron (one of the authors of the Agile Manifesto) and Chet have many years of development experience and, most recently over the past decade, with eXtreme Programming. [If you want to actually see them demonstrate XP ideas live take a look at this talk they gave some years ago.]
The goal of the session was to address their view of how a team and/or individual can incrementally improve through “small steps of continuous improvement.” Improvement, they stated, begins with “believing you can make small steps” and “assuming there is always a better way.” “If you [continuously] improve a little,” they said, “often, it will appear, externally, that a lot is improving.” [This is very similar to the Lean admonition that “improvement does not come from satisfaction.”]
Two things Jeffries and Hendrickson suggested to start the process of improvement are to:
(1) get up from your work so you can “look around and sense your environment” and ask yourself “what’s really going on here”;
(2) consider what you can actually do about something that needs changing compared to all the things you can complain about that aren’t right.
They then said something strange, at least in comparison to a lot of process improvement wisdom: “If we can measure it, we’re not doing it right.” They explained that they meant, if we are doing an activity right, it is so much a part of the nature of how we work that we probably cannot effectively measure it without interrupting the flow of doing it. (Many years ago, when I worked at Bellcore and was involved with some expert system development looking at the traits of expert software designers, it was noted that expertise is often something the expert cannot explain unless they stop doing it as smoothly and effectively as they do and become more self-conscious about the activity, which sometimes reduces their effectiveness at it.)
At a very practical level, they suggested a developer should set a goal of writing a test to validate a requirement, then get it to work by writing the code to implement it, all within about 20 minutes. This would force one to work in small increments and allow development iterations of as little as a couple days. That is, useful new functionality would be implemented and demonstrated to work (and not break existing functionality) every two days.
Someone from the audience asked how they defined “legacy code” and they responded that it was “code I do not have the tests for to feel confident about changing it.” Having effective validation that changes do not harm existing functionality (as well as work properly themselves) is a key element of agility in development. Without such tests that one can run to validate new code, it will be hard to feel secure and trust that the changes are correct. This is one of the great problems when introducing agile methods into a legacy code environment: one of the significant quality measures agile methods advocate, effective build-and-test automation, is missing in most legacy code environments.
Another audience member asked about alternatives to pair programming since this is often a contentious eXtreme Programming practice. Interestingly, Ron Jeffries stated that he had come to believe this practice was one that could be left out as less essential than others, though he has in the past been a staunch defender of it. However, he did suggest that developers could pair across the table from one another with each person having their own machine but sharing the view of the same work through Virtual Network Computing which allows one machine to view and interact with the desktop on another machine anywhere on the internet. There are commercial versions such as at http://www.realvnc.com/what.html.
Another interesting audience question had to do with how to handle people who like to micro-manage, i.e., who seem to “hover” around the development group asking for various kinds of information that changes day to day. Jeffries said to ask why they are there: what do they want to know? Then, figure out a way to give them the thing(s) they need without project interference. Often, Jeffries said, what they really want is confidence that things are proceeding effectively. If a group is using the agile technique of having an “informative workspace” where progress can easily be seen from visual displays on the walls and in the halls where they are accessible for anyone, then it is just a matter of showing management, and others, how to read the displays. Thereafter, such people can just look at the changes, day by day, to see where the project is and where it is headed, generally eliminating the need to ask people on the project for their time to answer questions.
A final question focused on using agile methods in distributed environments. Jeffries answered that the finest example he has seen of this working is what Jeff Sutherland (one of the co-founders of Scrum) does at his company (Chief technical officer of PatientKeeper, Inc in Newton, MA). Jeffries stated that Sutherland has distributed agile development occurring with high performance teams, so it is possible, and others are doing it, but Sutherland’s example is perhaps the most effective anywhere, according to Jeffries.
What We Learned and Didn’t Learn at the Agile 2007 Conference (thoughts from Liz Barnett)
[I ran across Liz Barnett’s notes some years ago and kept them, so I feel having another specific person’s view of the conference could be interesting especially in comparison to today’s agile landscape.]
It’s still an insular, fairly technical community.
Agile 2007 still feels to me like the OOPSLA conferences of the late 1980s: really smart people generally in violent agreement, but evangelizing subtly different approaches to the same overall concepts. The landscape of Agile methods is crowded. The OO community finally converged on a small set of simple(r) notations. I don’t see this level of convergence on the Agile horizon.
It was also disappointing that the conference was dominated by ISV experiences. Of course, these folks build software for a living, so we’d expect their processes to be the most mature. Is it that corporate IT shops are unwilling or unable to share their experiences? Or just that their experiences are not rich enough to merit sharing in this type of forum? In addition, while people talked about the need to scale their projects or run them globally, most of the discussions were quite technical and too few of them tackled the tough management issues associated with global initiatives. [I think the lack of interest by early main figures in agile thinking is, at least partially, due to the more “corporate” nature of many presentations and ISV interests at the conferences.]
The people issues dominate.
Numerous sessions shared experiences in how to staff projects, collaborate among team members, obtain adequate customer/product owner participation, and measure and communicate results. Many of these stories centered on seemingly simple, yet important practices: maintaining a relentless focus on removing obstacles on a daily basis, strictly managing the backlog size and priorities, focusing on team versus individual productivity, and insisting that the entire team be accountable for quality. In addition, the importance of expert training came up again and again — and not by those selling training services!
The commercial tools market isn’t sufficient.
Companies don’t have the necessary Agile tools at hand. Few organizations cited the use of traditional (i.e., legacy) lifecycle management tools for their Agile projects. Experience reports, such as those from Salesforce.com, Weyerhaeuser, DTE Energy, and the British Broadcasting Company (BBC), noted the need for teams to obtain additional and/or enhanced tools. Some invested in custom tools for Scrum iteration management, metrics and management reporting, and collaboration wikis. Others turned to open source tools such as JUnit, FitNesse, and CruiseControl for specific Agile development tools.
Agile project management is the hot space. Teams have turned to open source tools that address specific Agile metrics. From the commercial perspective, Rally and VersionOne have enjoyed their leadership as early entrants in this emerging market. [Since this conference, other tools, especially Jira and Azure DevOps have emerged as more widely used tools of this kind.]
Getting management support is still a big hurdle.
Unfortunately, too many presentations and papers discussed teams’ struggles to attain management attention, support, funding, and general commitment to their Agile initiatives. This is one area where the Agile conference community could really grow — emphasizing the use of Agile practices at management levels, and not just elaborating in different technical areas.
Large-scale Agile implementations are hard to find.
Overall, I was frustrated by the discussions of “large-scale” and global Agile projects. Some touched on issues of distributed tools, collaboration among large teams, using Scrums of Scrums to manage large initiatives, and dealing with time-zone disparities. But these are just the tip of the iceberg for teams tackling complex distributed projects. [This has definitely changed as agile ideas have “crossed the chasm” into more traditional environments where hundreds of people engage in agile ways of working. Scaling approaches such as SAFe, LeSS, Nexus, and DAD have become frameworks that larger organizations pursue especially in government and financial services.]
Keep On Learning
The Agile community has become much more sophisticated and continues to grow. With that growth, the plethora of approaches creates confusion and there aren’t too many signs of Agile methods coalescing. Product and services companies pour out new offerings and have broadened their sights beyond just the project level. “Lean” is the new buzzword, so now we’ll see this term over- and mis-used, as has been the case with all things “Agile.”
