How many times have you heard the following phrases?
“This software bites.”
“Why is software development always delayed?”
Both sentiments describe the need to design and build software that provides a great user experience (UX) and that is delivered in a timely manner. Luckily, there are two communities focused on both of these goals:
The user experience gang focuses on designing software the users find useful, usable, and desirable.
The Agile camp focuses on delivering working software to expose functionality that users can test.
Everyone heard the news last week of HP making a decision that it wants to emulate IBM rather than Apple by shedding its PC and cell phone businesses. But for Application Development Professionals, what does this announcement mean for HP QC and its newly defined ALM platform?
The bad news
The investment in WebOS and Palm meant that HP was in the mobile platform business, a business that is heavily connected to developers, open source communities, and applications. That connection would have required HP R&D to gain strong relationships to the developer community and be active in making it easier for developers to build on top of its platform. Of course, there were many questions regarding whether HP would be able to connect to developers; after all, it is a hardware company, and hardware engineers traditionally ignore software, considering it an afterthought — but at least the need was there, which is always a good place to start. Now that objective has gone. Mobile developers, who increasingly are becoming the mainstay of the next generation of applications, are not a core community for HP to court. And if IBM is to be copied, then mobile will be dropped from HP’s corporate vocabulary.
The good news
Without the distraction of WebOS, HP will now increase its investment in its applications business, in particular the integrated strategy of IT Performance Suite and its supporting software solutions for IT strategy, ALM, and IT operations. This solution is aimed squarely at IT departments and the enterprise. The potential acquisition of Autonomy will only extend HP’s reach into enterprise IT, and if applied to IT performance management could provide valuable insights into the application environment.
Following the Charles Darwin's statement “To change is difficult. Not to change is fatal,” application development professionals always seem to be in the process of change. Changing technology, adopting new practices and methods, and introducing new organizations are just a few of the things that most application delivery shops are changing at any time. But how is that change being undertaken? How do these change programs get managed? And more importantly, how does all this change fit together? During 2010, Diego Lo Giudice and I asked these very questions and have recently published a report describing our findings. This blog describes our findings at a high level:
Where does change come from?
Having interviewed 75 companies that were in the midst of change, we found that, perhaps not surprisingly, change was being driven from a multitude of sources. Bottom-up change was coming from practitioners. Technology Populism seems to be rampant in most companies, with individuals bringing in their favorite technology or practice. In parallel with this grass-roots adoption model is top-down, executive-driven change. The majority of organizations we interviewed had executive-driven change programs around process, organization, or technology. Rarely did we see the bottom-up change being integrated with the funded, top-down approaches. The result was often confusing, with ideas clashing and change initiatives running against each other. At best, the practitioners ignored the top-down ideas; at worst, they blatantly undermined these ideas because they were different from their own ideas.
Much has been written about the emerging trend of DevOps. Mike Gualtieri, as always, provided sharp commentary in his blog titled “I Don’t Want DevOps. I Want NoOps.” I was very excited to attend IBM Pulse 2011, which is aimed clearly at operations professionals and is Tivoli’s primary event. Over the past year, the Tivoli brand has gone through a management change. Danny Sabbah and a lot of his management team moved from Rational, the developer brand, to Tivoli. So I was interested to hear how Danny Sabbah and his team had introduced the ideas of Jazz and OSLC into the Tivoli mission. And I was not disappointed. The keynotes, track sessions, and analyst and press events were all aimed at vision. They talked about the end-to-end value chain of delivering and maintaining software. They placed heavy emphasis on process and automation, describing a vision of integrated tools and process allowing software to move seamlessly from idea to implementation and beyond. IBM is not alone in this vision; increasingly, other vendors are trying to break down the barriers between operations and development. HP, with its Business Technology Optimization (BTO) vision, is connecting quality, portfolio management, and service management. Microsoft for a long time has described an integrated vision for the .NET platform.
Last week Agile reached the milestone of 10 years. Ten years ago a group of 17 thought leaders met to draw up the original guiding principles and manifesto for Agility. These principles not only define the approach of many Agile methods but are the line in the sand when discussing if something is Agile or not. There is little doubt in my mind that the creation of these principles set in motion one of the most important transformations that the software development industry has seen ― focusing development teams on the things that really matter and challenging ideas of work, processes, and practices that make no sense in the development of software. But the question is, after 10 years, should the guiding principles be updated?
Reviewing the principles
When working with organizations that are introducing Agile methods, conflict sometimes occurs when reviewing the principles in the following areas:
Individuals and interactions over processes and tools. The words individuals and tools usually cause the most concern when adopting Agile. Software development is a team sport, but this principle focuses on individuals. And as Agile grows in use, increasingly tools play a key role.
Working software over comprehensive documentation. The challenge of documentation is often discussed when talking about this principle. As the adoption of Agile grows, so does its use in industries where documentation is crucial and legislated.
Customer collaboration over contract negotiation. This is very true with internal development teams, but when external vendors enter the mix, contracts are important and will form the basis of the engagement.
Responding to change over following a plan. Implementation of this principle often results in lack of upfront planning, which is contrary to most organizations' funding processes.
Dave: Tom Grant and I spent the past week in Orlando at Agile 2010 and thought it would be good to share our observations of a fantastic event. This conference has been running for 9 years and during those years has always tried to both balance content and scale with focus and intimacy. This year I think they got it just right.
Tom: Among many virtues of the yearly Agile conference is its ability to be simultaneously high concept and eminently practical. You find yourself in a conversation that’s down in the weeds of build and test methodologies but then veers into a philosophical discussion of what the term “value stream” really means. You can see how, by entering the mainstream, Agile forces a fresh look at everything from SOPs to values.
Dave: This year’s event featured the now-familiar smorgasbord of sessions, from Agile for beginners to advanced topics like scaling and technology support. In addition to the physical sessions, a lot of discussions moved 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.
Dave: Because of the sheer scope of the conference, there was no one theme, but if I were to pick three, they would be (1) UX design and Agile, (2) development operations (dev ops) and continuous delivery, and (3) technical debt.
During a vendor conference, I sat down with 12 application development professionals and asked them a very simple question: "What will be the biggest themes for application lifecycle management be in the next 5 years?" The resulting debate and discussion highlights some key areas that application development professionals should look to when building their ALM strategy.
Who owns the code?
The reality of open source, partner-developed code and vendor value add-ins was not lost on the group. The overarching theme from this discussion was that customer organizations not only need to own the overall supply chain but also are responsible for ensuring its quality. That means, as writing code decreases, inspection, validation, and testing increase. The result is that traceability, workflow, and reporting are inclusive of customer code but also supplier code. For example, defects with an open source project need to be captured, shared, and tracked in a similar way to internal defects. The difference is that, unlike with internal development, those defects will also feature in the open source project and be fixed by people outside of the customer's organization. The implication of licenses and IP ownership was discussed, with one in the group painting a very bleak picture. He described a scenario where because of the result of one massive IP infringement a company is forced to stop operating, with the resulting fallout being a massive, wholesale movement away from open source software and associated complex IP and licensing issues. Though this example was extreme, the group agreed that licensing should be part of the governance for any ALM solution. This increased complexity of code ownership will require ALM solutions to:
As I fly to IT Forum in Las Vegas, I am reading with interest the latest copy of Wired Magazine. Within the normal collection of interesting geek-fest, I stumbled upon a story about Pixar.
It appears that making films is a bit like software projects. They tend to be late, cost too much money, and the value of the project is hard to determine. There is one picture company that does not follow this trend. Since their inception, Pixar has gone against the Hollywood Norm, delivering nine films and nine massive hits. Wouldn’t it be great for application development professionals to be as successful, delivering fantastic projects that are both successful and of high value? So what can application development professionals learn from Pixar?
Pixar have built a fantastic company with great people working on very creative and imaginative projects. But four things stand out as things app dev pros can learn from:
After almost a year of work, Jeffrey Hammond and I finally published the Agile Development Management Tools Forrester Wave™ evaluation. So I thought I would share some of the observations from this report. Agile has changed the way in which development teams work, and this changed motivated the Forrester Wave. A change that has meant not only new ways of working, but also new vendors have entered the traditional application life-cycle management marketplace. The Forrester Wave focused on the following main areas:
Today Collabnet announced the acquisition of Agile PPM vendor Danube. As an Agile PPM vendor Danube are farmous for their support for Scrum, with their offerings ScrumWorks and ScrumWorks Pro. With this acquisition, Collabnet has taken a significant step in merging the disciplines of Agile project and portfolio management with ALM. Collabnet has traditionally stayed away from supporting any one-process model, describing themselves as process agnostics. This started to change at the end of 2009 with the TeamForge 5.3 release, which provided simple support for Agile projects. Now with the purchase of Danube Collabnet will continue to extend their support for Agile projects. So, why should Application development professionals care?