Wow! Innovate 2010 opened up with entertainment from Natually 7 and several speakers who inspired the audience of approximately 4000 people, to take innovation seriously.
Author of Gadget Nation Steve Greenberg was the first speaker who talked a bit about the difference between invention and innovation. “To invent is to be the originator. To innovate is to make changes to something established.” Greenberg entertained us with stories of crazy gadgets and told us that to be successful, you need “competitive differentiation.”
Following Greenberg, Vice President, Marketing and Strategy, IBM Rational software, Scott Hebner introduced a theme that prevailed with all the speakers: the complexity of integrated software systems creating a “system of systems” linked by the “invisible thread” of software. “We need to continuously improve collaboration across the solution delivery lifecycle,” Hebner said.
Dr. Danny Sabbah. General Manager, IBM Rational software, spoke next about “econometrics” and the importance for businesses to “balance economic, social and environment objectives.” He tells us, “the world is becoming more interconnected, more instrumented and more intelligent. In fact, it will be 10x more instrumented in a short five-year period to more than one trillion connected devices. The world is becoming smarter. Software is pervasive. It is the building block of smarter products and services. Software is becoming the invisible thread that enables what we refer to as “system of sytems.”
Several examples were given of “smart systems.” Sabbah talked about intelligent sytems in the health care industry. He described implantable heart defibrillators that are being used to monitor cardiac response for patients with critical heart conditions. If medical attention is needed, an abulance is alerted and medical care must be administered immediately. The national standard is a four-minute response time for 90% of all emergencies. A response rate of less than five minutes doubles the chances of patient survival. Software systems are used to help with prioritization, ambulance queueing, decision support, notification, traffic systems to avoid. route optimization with instant integration with local traffic. A typical ambulance uses software with approximately 50 million lines of code and 10,000 interfaces that help to track, update, test, deploy and maintain the functions needed for this system. And this is just one system of many within health care that is part of a system of systems.
Robert LeBlanc, Senior Vice President, IBM Middleware, IBM Software Group, rounded out the opening keynote by talking about how cloud computing was being used as an IT delivery model, reducing costs and improving efficiency with service delivery. “Every single industry is going to be impacted by the change that’s going on. Software is becoming the fundamental driver in every single industry. Think about the grid. Think about how we’ve delivered power for the last 50 years. It hasn’t fundamentally changed. And now we’re starting to see a change in the use of power grids. Every industry’s going to change.”
IBM Innovate has given me all kinds of opportunities to speak with IBM’s top execs and hear the latest news and announcements in their Rational product line. I spoke today with Jack Danahy, Security Executive Office for the Office of the CTO, Rational at IBM.
Danahy was the original founder and CEO of Ounce Labs, sold to IBM in July of 2009. The software developed at Ounce Labs provided the static analysis, “testing from the inside.”
Danahy gave me a bit of history of application security testing to explain the acquisition of Ounce Labs and the value or Rational’s AppScan product to the customer. “Security has always been a niche,” said Danahy. In the Internet’s early years firewalls were used for security. The applications had to step up and test for security. They looked for vulnerabilities and exposures. There are a limited number of folks who are really good at that. And there weren’t enough “good at security personel” to cover everything. Watchfire was acquired IBM Rational portfolio a few years ago and was very thorough in testing as a hacker would, “from the outside,” Danahy explained.
Customers want to know the system is configured the right way and not vulnerable to external threats from the outside. They also want to see the source code and find security gaps that can be addressed earlier in the development lifecycle. “The capacity to look at the software from the inside out and from the outside in” provides the most value for the customer giving them a unique perspective.
In this video, Danahy announces Rational AppScan Source Edition that will enable customers to be able to go to one place for security test results. IBM is also talking about strategies that will allow customers’ applications to be “secure by design.”
The updates to AppScan was one of four anouncements that was made by IBM today related to their “secure by design” initiative. IBM also announced enhancements to Tivoli Access Management, a Source Code Assessment Service and a Secure Engineering Framework.
Collaboration and social networking tools are growing by leaps and bounds, moving beyond social applications and into the business world. Mainsoft’s Social Connector product, announced June 7th in Orlando, brings many of the social networking functions to the enterprise by “connecting” IBM Rational Team Concert and IBM Lotus Connections.
I spoke to Yaacov Cohen, CEO of Mainsoft, and Dekel Cohen, Director of R&D at Mainsoft, who gave me a demo of Social Connector. “It leverages the power of social software in a business context and it speeds up the learning curve of people joining a new project, making people more collaborative and more efficient,” said Yaacov.
Dekel gave us a demo showing how a community can be formed around a project. Features of Social Connector allow for searching for blogs, experts, bookmarks and other resources that might be useful on a project. I asked Cohen about security. I was unclear whether or not these communities were extended beyond the enterprise. Cohen answered that “the primary clients are IBM customers who are using both Rational and Lotus connections. But we also want to give a feel to all Rational developers. Even if they don’t have Lotus connections within the enterprise, they can open an account on My developerWorks for free and then they have access to wikis, communities and activities without making any up-front investment.” I asked if that would be a security concern. “You can open a private community so you’re not necessarily exposed,” Dekel answered.
Yaacov and Dekel demoed various integration points between Rational and Lotus. One example is the ability to publish Rational Team Concert work items as Lotus Connections Activities. Status updates will be published to the project community, allowing for easier communication and collaboration between all stakeholders.
I asked whether Social Connector would be packaged with the IBM offerings. Yaacov described the software as a “joint venture…This is done with a very tight partnership with IBM,” he said.
More about Mainsoft along with a demo of Social Connectior can be found here.
Innovate 2010 began today with a welcome reception for the expected 4000 attendees. The packed ballroom included a live band, karaoke, plenty of food, drinks and people. I spoke with several of the attendees, asking what they hoped to get out of the conference. Most of the IBM’ers were here with plans to gather “voice of the customer” feedback from their Rational clients. Others are here to present or to learn. With over 350 sessions over the next four days, there will plenty of options.
Terry Quatrani (TQ), Regional Content Manager for the conference covering all the technical content, was sporting a uniquely decorated hat, complete with feathers, glitter and topped with a globe. She said she comes every year with a different hat, representing the theme of the conference. This year’s theme? Let’s build a smarter planet.
I spoke with Quatrani about the Rational product, first asking her how many products it included. An anonymous eavesdropper nearby joked, “Two million.” TQ couldn’t answer an exact number, but guessed around 50. I checked the Rational Website later and can understand why it would be hard to answer this question. Many of the products come in various flavors so it might be difficult to know exactly how to count them.
“Of those, how many are available on the Jazz platform?” I asked. Jazz is IBM Rational’s new technology that provides a framework for collaboration and integration of various Rational tools. The anonymous onlooker informed me that I had the terminology wrong. “The proper term is jazzified,” he said, and the answer to the question is “only three,” he said holding up three fingers, playfully expressing impatience. Quatrani said she thought there were more and said that there were “more and more coming.” As a matter of fact, it appears five products have been “jazzified.” According to IBM Rational’s Website: “IBM Rational Team Concert™, Rational Quality Manager, Rational Requirements Composer, Rational Asset Manager and Rational Insight are the first offerings built on or significantly refactored for the Jazz platform.”
Quatrani said that IBM uses a Measured Capability Improvement Framework (MCIF) model to help understand the customer’s pain points. “We give [customers] the Lego pieces to put together a solution that will solve their problem,” she said.
Quatrani will be presenting “Writing Good Use Cases” on Monday and on a panel with Scott Ambler on Tuesday called “Quality in the Trenches Panel: Traditional? Agile? Something Else?” She asked Ambler, a long-time agile proponent, to take the traditional viewpoint on the panel, she tells me with a mischievous smile. It should prove interesting!
I’ve heard a lot of buzz about Kanban, a concept related to lean, recently. At the agile ALM conference I attended last month there was a lot of talk about lean methodologies, and Kanban has been a heavily-discussed topic at the last three Boulder Agile Software User Group (BASUG) meetings I’ve attended. So, what’s the dish on this newly-popular approach?
Jim Reed, organizer and leader of the BASUG, shed light on Kanban terminology and concepts in an in-depth presentation during a recent BASUG meeting.
Kanban is a concept related to lean methodologies which originated in manufacturing. However, these concepts are being applied more and more in software development environments. Kanban is a Japanese word meaning “signboard.” A Kanban Board is a visual display in which the movement of objects, in the case of a development project, user story cards, will trigger action. The idea is that there’s continuous flow as the objects are moved across the board to completion.
Kanban is considered an agile methodology, though more adaptive than most. In other words, there aren’t a lot of rules. A slide from the presentation showed the differences in agile methodologies. Rational Unified Process (RUP), with over 120 rules, was considered the most prescriptive. XP followed with 13 rules. Scrum was next on the adaptive scale with nine rules. Kanban was considered the most adaptive with only three rules:
- Visualize the Workflow
- Limit Work-in-Progress (WIP)
- Measure and Optimize Lead Time
Reed described an example of a development project in which the Kanban board was split into the following groupings:
The Backlog holds all the stories, but these are prioritized and moved first into the Selected bucket which triggers action. If the Work in Progress (WIP) Limit is set to two, then there should be no more than two stories in any of the groups in which work is being done. If a bottleneck occurs in one of the groups, then process rework should be done to alleviate that bottleneck rather than continuing work in earlier phases. This helps to identify bottlenecks and leads to optimization of the whole value chain.
Todd Sheridan from Rally Software, now immersed as a “Scrum Master” at Rally using Kanban, was a voice of experience at the meeting, I asked if his group was mixing Scrum and Kanban, and he said they were using pure Kanban, but that many of the concepts and roles from Scrum carried over. He is acting in the same capacity as a Scrum Master; since there is not a defined role or term in Kanban, they continue to use that term to describe the team facilitator.
Here’s how Sheridan explains the meaning of Kanban:
According to Theresa Lanowitz, founder of IT analyst firm voke inc., the core vendors in the Application Lifecycle Management market are HP, IBM, Microsoft and MKS. That’s not to say there aren’t other vendors that are making strides in ALM. “I see two other types of vendors emerging: vendors with a unique take on the application lifecycle approach and vendors who are delivering tremendous innovation in the application lifecycle with unique product offerings for the dynamic environment that is ALM,” Lanowitz said. Her firm’s research on the ALM marketplace and its players can be found on the voke site’s Lifecycle Transformation page.
I recently moderated a panel discussion on project management challenges and strategies in ALM. Panelists including Lanowitz, Doug Akers of MKS and Richard Knaster of IBM, participated in a panel discussion about project management challenges and strategies in ALM. We discussed popular vendor tools, as well as concepts and questions, starting with one I’d once blogged about: What’s the definition of ALM? The panel discussion was just one of several sessions that took place on May 19th at SearchSoftwareQuality.com’s ALM Virtual Trade Show.
If you missed the live event, don’t despair. The sessions are available on demand for the next few weeks. Tune in to see the following sessions and keynote presentations:
- Session 1: The Evolving Application Lifecycle – Delivering a Competitive Advantage
- Keynote: Innovation in a New Economy – The Business Imperative for Intelligent ALM™: Presented by MKS
- Session 2: Mastering ALM Processes: The Key to Success
- Keynote: ALM as Seen Through an Agile Lens: Presented by HP
- Panel Discussion: Project Management Challenges and Strategies in ALM
- Session 3: Reducing the Cost of Finding and Fixing Defects – Something New, Something Old
The other day I had the opportunity to interview Scott W. Ambler, one of the premier thought leaders of the agile methodology and its implementation. In addition, Ambler is IBM’s leader in agile development practices and has held this title for upwards of a decade.
Ambler has been working with the agile methodology since the early 2000s, when the Agile Manifesto was written, defining the meaning of agile in detailed documentation. “I started working with agile almost immediately right after the original snowbird meeting. Specifically I began modeling and examining the ability to scale agile to fit organizational needs — I wanted to see if the methodology was transparent and would be applicable for larger organizations to use.”
Since the introduction of agile to the software community, Ambler has taken part in, as well as organized, several annual surveys on agile success in business. While a large portion of his findings suggest that agile is a key component in revitalized software success – mainly in deployment time frames – it can be difficult for those using traditional methodologies to transition to an agile environment.
“One of the major problems with agile development that I’ve noticed are ‘self-inflicted’ cultural issues,” said Ambler. Organizations that have become all too comfortable in waterfall-type development have a difficult time finding the groove in agile development — and then staying in it.
“Often the biggest agile failures I see are in data groups and QA teams. These are the groups that have become accustomed to being ‘out of control.’ They are used to being micromanaged and aren’t ready or able to begin thinking for themselves. I look at them and wonder ‘how can any organization could tolerate this kind of behavior?,’ but many do, unfortunately. One of the biggest abusers of power that I’ve seen is in IT governance, but they’ve always been a bit of a challenge for organizations looking to run lean,” said Ambler.
Ambler believes that with a willingness and readiness to transition — any team or organization should be capable of adopting some agile techniques — even in the most unlikely of places.
“I have gathered overwhelming evidence in my surveys supporting agile adoption across the board. It is being used everywhere, even outside of software development and finding success. This economy, without a doubt, is a major contributor to this agile momentum — everyone is trying to lean down the expense of their project and roll out working products in smaller intervals. What is so surprising are the areas outside of IT walls that are using agile without reproach.”
Some of the areas Ambler pointed to were in the defense and regulation sectors, places where agile seemed like a long shot if not completely out of the question. “I’ve heard of airplane and missile manufacturers using agile techniques to engineer fuselages, highway construction – the list is endless. But just because agile worked for them, doesn’t necessarily mean it will work for you.”
Ambler recommends organizations in the manufacturing space interested in agile to check out Real-Time Agility as a reference. But the title is also helpful to strict software developers looking to make their production practice run smoother. The book explains how system engineers and plane manufacturers have been able to bring agile to the physical development industry.
But even with the “across the board” success agile is claiming, Ambler warns “keep in mind, your mileage may vary.”
Just because agile worked in situation “X”, is no indication that it will transcend into other industries, including yours – even if it is a related one. “Many have said to me ‘we can’t do agile development’ and I agree, they probably can’t, but only because there is a self-constructed boundary between their way of working and the way agile works. Agile was never intended to be an overnight fix. And those who believe it is a ‘silver bullet’ often end up shooting themselves in the foot. Agile needs both acceptance and time to work successfully, willingness of teammates and close quarters collaboration,” said Ambler.
So, once again the age old saying fits in patience is a virtue.
Fortify software, a security test and assessment service provider, now offers security testing and assessment for cloud-destined applications. Fortify 360 and Fortify on Demand services are available for cloud applications as of May 18.
“There are two promises the cloud makes to application developers and their consumers; access to a wider range of software resources and utilities, and having them available at a huge reduction in cost,” said Brian Chess, founder and chief scientist at Fortify. Security has been a primary concern in software from the get go. Chess feels that the cloud, though seemingly more secure on paper, will amplify latent vulnerabilities in applications. There are also concerns in the lack of standardization and measurement within the cloud. “Standardization – the standard of computation in [and out of] the cloud is a limiting factor. So far, we haven’t seen a lot published on how security will be provided and ensured. This may force many application developers to hide behind private clouds, or call for a double-scooping of firewall onto their code.”
In the cloud, pre-existing flaws will be easier to exploit and undermine. Problems will become obvious faster and accessible to much a vaster audience. In risk-prone applications, the possibility for eavesdropping on code lacking fortitude, could become a major issue in the future of cloud computing.
“DNS security has always been a security focal point in the Data Center, it is a known weak spot. But because the weakness is well known, with careful monitoring, organizations have made DNS issues manageable. The cloud however, poses some new challenges — not only do you need to be positive that your DNS security is top notch, now you need to be active and aware of who your computer is communicating with on a much larger scale,” said Chess, who borrowed examples from Apple and Microsoft to illustrate his point.
“Apple and Microsoft have been using automatic updates and automatic patches to fix flaws they’ve uncovered. These are prescheduled and normally occur at times users are not in front of their computer. Many of these updates do not require you to click ‘OK’ or accept that an update is being made. Imagine how similar ‘falsified’ automatic updates would work in a public cloud. They could open some rather large doors for your computer to become part of a Bot network or worse.”
Fortify will address these application security issues via two vehicles, 360 and on Demand. Fortify 360 is the full-scale version of the security testing and assessment provision from Fortify. It includes an assessment service, and a round of penetration, static, runtime and real-time testing. On Demand primarily allows just the penetration and static testing. Add-ons available to customize and add depth to your security testing requirements, but these come at a cost increase.
Fortify will use whichever service the customer chooses to test their application for security in the cloud. Upon purchase, Fortify enters into the application and subjects it to monitoring while they attempt to break into it. Through a partnership with White Hat, Fortify does not require that applications be brought in-house, they perform their tests online on their private network.
In the world of software, it’s always interesting to me to find out how closely the real world matches the text books. Many of the people I speak with are authors, educators or vendors and their point of view can often be quite idealistic. But does agile really work the way it’s described in the classroom?
Chris York, a 10-year testing veteran and four-year software developer before that, has his doubts. “I haven’t seen agile work like it’s supposed to; and after working with it for 18 months, I’m wondering if it does really work.” York knows that it’s been successful for others. We chatted in a Denver coffee shop trying to figure out why the agile project he worked on had such trouble. “We never got close to getting everything done in an iteration. There was no plan for what to do when something went wrong. There was no time allocated for fixing defects.”
York gives me more details of the first software project he worked on that was adopting an agile methodology. The team was co-located with about 20 team members, six of them testers. Other than a one-day training, the team members were not experienced in Scrum, except for the ScrumMaster who was brought into the company to lead the project.
York felt that, although the ScrumMaster knew the lingo, he wasn’t effective in leading the team. “I felt like I was in Kindergarten,” York said, explaining that there were one dollar penalties for all kinds of trivial transgressions including such things as being even two seconds late for a meeting, talking out of turn, having a cup of coffee, a cell-phone ringing, sitting during a stand-up meeting or deviating at all from the stand-up script. He said that team members were encouraged to express disapproval if someone didn’t meet their commitments from the day before too often. “It was also encouraged to try and find a way to get someone else to meet your own commitments for you. This happened on one occasion and it was applauded. Then the person who did the other work was chastised a bit for not meeting his own commitments. It just seemed very inappropriate.”
York describes a project that used a methodology that he helped create: a traditional-agile hybrid -and it worked quite well. “The company had a bad reputation with its clients and something had to change. Releases would take an entire weekend working around the clock. And even after that the product would be two to four weeks getting the bugs that the clients found worked out. We developed this iterative way creating a long term project (four to six months). Each iteration would be four or five weeks and it was highly planned out. After a couple of years of tweaking it, our reputation was good, the releases were smooth (only taking four or five hours) and very few bugs were found by the clients. We didn’t know we had created an agile-like development strategy. We just kept working at it until we found something that worked. The best thing we did was to write complete detailed requirements and then to spend time planning everything, even allowing time to fix the defects and retest them.”
York points out that he knows that agile can work, with the right project and with an experienced team. In this video he compares transitioning to Scrum to a developer making a switch from C to C++. Object oriented programming is a completely different mindset. If we aren’t used to it, we’ll fall back into our old structured programming habits. Similarly, those that find themselves thrown suddenly into an agile environment, may have trouble getting the full value of the methodology.
The lesson learned here seems to be the importance of flexibilty. Agile is not meant to be prescriptive, but adaptive. Each project, team and organization is unique. There doesn’t seem to be one right answer for a universal “best” methodology, but one thing seems to be clear: It’s important to consider the needs of the project and not try and force rules that don’t make sense because they are “agile.” That, in fact, would NOT be agile.
Robert “BJ” Reff is the director of Quality Control at Liquent, an organization that creates applications for pharmaceutical companies which enables them to track, research and submit information on FDA approved medications. On Lisa Crispin’s recommendation, I tracked Reff down at STAREast to pick his brain proceeding a session he had just delivered on Theoretical agile practices vs. real-world agile applications. For many organizations, finding new and creative ways to implement agile is welcomed and they are finding unique and intelligent ways to adapt the methodology to fit their needs — even in places where one wouldn’t think agile would be the methodology of choice.
According to Reff, agile can be applied to organizations that are regulated by agencies, such as his. The idea that the agile methodology won’t work in this kind of an organization is a common misconception within the software industry. Regulated industries and similar organizations are usually forced to adhere to restrictions, limitations and intense examination. As a result, these companies often exclusively reside in waterfall territory, but Reff feels there’s a place for agile within them.
Reff describes his session in this video clip from STAREast 2010
“In my experience, one of the major problems with the agile methodology is that people look at the process in line with what they need to accomplish and then they proceed to write it off, they brand it as too drastic a deviation from their organization’s accepted practices.” Management looks at the layout and examines the theory behind agile and decides that the principles are not applicable to what their corporate aim is.
“A lot of times agile is misrepresented as a lean way to create applications. Many believe this sort of construction isn’t suitable for regulated agencies such as the financial sector, government, airlines or medicine. These are all industries that exist in a world built around compliance and strict requirements. What I rarely hear is an organization considering modifications to agile so it can fit into their development.”
Despite often occurring in close quarters, agile and lean are very different. Lean in many cases, is the by-product of well-done agile. Through agile, waste, bottlenecks and other unnecessary hold ups become more obvious and easier to assess and repair. But there is more to agile than meets the eye and regardless of its surrounding hype, agile is not without flaws. There are problems with the methodology and with the people using it.
Reff identifies some of these problems as residing in unrealistic beliefs that many agilists harbor. They believe that agile will solve all of their problems. Others choose to believe that if they can’t facilitate the promise of fulfilled requirements, so the end result (agile or not) will be undeliverable iterations resulting in failure.
Many new agilists get stuck on the underlying principles and frustrate themselves in trying to fit agile into their traditional development process. A process they do everything to avoid branching away from; but that’s just it, agile is adaptive and should be treated as such. However, you shouldn’t just take anyone’s word for it. Qualify it, try it out.
Anticipated success or failure should not be based on what others have experienced, there is no proof without context. Comparisons need to be drawn. Two completed projects, one yielded in waterfall and the other in agile. Examined them side by side, then you can make an educated decision on whether agile is a fix for your organization or just another fad.