So, you want to become agile. Why? That’s the question asked by Stephen Mellor, independent consultant and Agile Manifesto signatory. “It may be a peculiar question because people don’t want to be heavy and lumbering, but you need to know what you are looking for,” he added.
“Is it for better quality? Customer relations and feedback? Or delivering stuff faster?” Mellor asked. Not knowing this ahead of time causes “you to just take on the word and not the underlying ideas,” he said.
Not only does an organization (and its developers) need to ask why it wants to become agile, but the idea also needs to be embraced by everyone in that organization, insisted Ivar Jacobson, founder and CTO of consultancy firm Ivar Jacobson International, and also one of the “Three Amigos” behind the Unified Modeling Language.
Once agile is embraced and understood, those at the top will need to see evidence that being agile works and that they have the people within their organization to execute it, Jacobson explained. This can be accomplished through small projects that use low-hanging-fruit approaches, such as continuous integration and iterative development, he added.
“When first adopting agile, we also need to know what we mean by being agile,” Jacobson said, because “it’s valuing working software over documentation and interacting with the people involved in a project.” Also, “how many requirements you have written is not nearly as interesting as saying things are done and executable,” he added.
Mellor finds it fundamental that an organization asks, “What is my culture? What is it that you think you’re making?” This asks what is the overarching goal and what is important, he said. “If an organization finds its culture is ‘code-y,’ then they’ll have to institute certain practices first, like testing and pair programming,” he added.
Andrew Watson, vice president and technical director of the Object Management Group, said, “Agile is a reaction against traditional approaches that generate a lot of paper, and also emphasizes machinery input to check, execute and verify [code].” And “if traditional development shops are using paper or PowerPoint for documentation, they have to move forward using tools that interpret that documentation,” he said.
Translating code so a machine can understand it creates an extra step and a “verification gap,” which agile modeling can eliminate, Watson added. This means using tools that stay in step with changing requirements, “because capturing requirements is an imprecise art” and upfront documentation inhibits this needed flexibility, he said.
In 2008, Mellor wrote a white paper called “Agile MDA,” and in it he discussed both Model Driven Architecture and the verification gap, which he defined as “The gap in time in saying something and knowing if it is correct or not.”
“This gap comes when we write documents that cannot execute,” Mellor said.
To make this transition, “We need a highly abstract modeling language that can more easily represent the content of interest to the customer, and yet is concrete enough to enable a modeler to specify an executable model,” he added.
Mellor understands that executable models already exist, but they become agile in how they are approached, whether following a timed process or when things are tested.
However, Scott Ambler, chief methodologist for agile and lean within IBM Rational, finds free-form diagrams or sketches to be the first step toward becoming agile. It’s an approach to “understanding just enough to get started,” he said, “and often the focus on being just efficient enough for the situation at hand freaks people out,” especially those that follow a “self-inflicted standard” through heavy, upfront documentation.
