skip to main |
skip to sidebar
I promised to say something about how I think all this stuff about globalization, innovation and extreme competition will impact CM and Agility. But first, a refresher on the books that I blogged about throughout most of March and April:
- The World is Flat: A Brief History of the 21st Century, by Thomas Friedman
- End of the Line : The Rise and Coming Fall of the Global Corporation, by Barry C. Lynn
- Three Billion New Capitalists: The Great Shift of Wealth and Power to the East, by Clyde Prestowitz
- Extreme Competition: Innovation And the Great 21st Century Business Reformation, by Peter Fingar (also the paper The Coming IT Flip-Flop, Rajesh Jain's "Tech Talk" on Extreme Competition, and Human Interaction Management)
- The Only Sustainable Edge: Why Business Strategy Depends on Productive Friction and Dynamic Specialization, by John Hagel III and John Seely Brown (also see the Edge Perspective's blog)
- Whole New Mind, by Dan Pink (also see Dan Pink's blog)
- The Design of Things to Come : How Ordinary People Create Extraordinary Products, by Craig M. Vogel, Jonathan Cagan and Peter Boatwright (also see Fanning the Creative Spirit and Innovation at the Speed of Laughter)
My blog entries on the subject thus far have been as follows:
So here are my jumbled thoughts on what I think it all portends for Agility and CM ...
- Extreme Globalization will continue to drive the need for Extremely Distributed Development teams and team members.
- Extreme Collaboration will increase the trend for needing human-interaction management over workflow enforcement. Tools will need to be less prescriptive and predictive and more enabling and empowering (particularly of "rich" virtual communication where face-to-face is not possible).
- The Internet as the new personal computing platform will meld deployment CM with development CM and with ITIL. It will also make managing dynamic dependencies of components and services an absolute nightmare, especially for Service-Oriented Architecture. But it will be a necessary nightmare to face.
- All of the above, plus regulatory compliance and accounting (such as Sarbanes-Oxley) will combine to make issues of security and fine-grained access control of electronically stored assets and business-intelligence (and processes) an even bigger concern than it already is, which tools will need to do a better job of addressing.
- The collaboration and innovation process will itself need to be "Agile", and agile practices will need to extend from "delivering software" to "delivering innovation." Applying principles of Agile, Lean, Theory of Constraints (TOC), and even SixSigma to the "innovation supply chain" will become increasingly important. We'll need to struggle to understand what refactoring, test-driven (trust-driven), continuous integration, pairing, and being adaptive/responsive to change mean in this new context.
- All of the above will also make automating extreme traceability an even bigger concern. But a more agile-style of development that is task-based and event-driven, will help to automate extreme traceability as pragmatically as possible. Extreme "big brother" environments that know and log everything we are doing, in the appropriate context (with the appropriate privacy/security levels) will be an increasing trend in properties of the IDEs and ALM tools we use.
- All of the above will also make for "extreme configuration identification." We'll have so many things to try to track, it will be almost intractable to try and identify and track them (and their dependencies) in the usual ways. Search engines will help us out here with "tagging and searching" rather than "capturing, filing and sorting", with multiple views and scopes and transparency/trust levels.
- Extreme time-based competition and focus on the customer-experience will bring "Lean" and TOC (particularly "Lean") methods even more prominently into the limelight. Creating and managing baselines will be more challenging as signficant CM events (such as baselines) blur closer and closer together (what I term the 'collaboration-dilation' effect) and transform discrete events into continuous flow. The logging and tagging+searching capabilities previously mentioned will need to help us with this.
- Extreme Visualization for how to conceptualize these things in our heads and share those concepts with others, will be another important focus of the next generation of "extreme" ALM tools and services to assist us.
What else? I know I'm missing something else that I thought of earlier but am drawing a blank now. There's gotta be more than this!
The following two articles of mine appear in the April 2006 issue of CM Crossroads Journal (the month's theme is "Agile Development Practices"):
If parts of them look familiar it's because these articles evolved out of multiple entries from this blog over the past year :-)
The more I look at FDD, the more I really like it as an agile method suitable for a large projects and companies, especially those striving for CMM/CMMI. I also really like the work David Anderson has done tying FDD together with Lean, TOC, and SixSigma.
I'd be real interested in any work on melding FDD together with many of the project management practices of Scrum, and some of the programming practices of XP (e.g., continuous integration, TDD, collective ownership, and refactoring).
Another a follow-up to my previous blog-entry about Peter Fingar's book Extreme Competition ...
In the book, Fingar talks about 5 "unstoppable" drivers/transformers, 16 "new realities of business", and 13 "strategy patterns" to consider. Rajesh Jain, who wrote the foreward to the book, has a very well-written series of blog-entries collected together in Tech Talk: Extreme Competition.
I've already blogged quite a bit about this book, so I wont go into detail about each of the items listed below other than to simply list them. For more details, I recommend looking at Rajesh Jain's Tech Talk: Extreme Competition and also the numerous materials available from the homepage for the book Extreme Competition
The Five Unstoppable Drivers Transforming Competition- Knowledge as Business Capital
- The Internet
- Jumbo Transportation
- Three Billion New Capitalists
- The New IT
The Sixteen New Realities of Business- Extreme Customers
- Extreme Innovation
- Extreme Individuals
- Extreme Customization
- Extreme Business Processes
- Extreme Teams
- Extreme Supply Chains
- Extreme Experiences & Self-Service
- Extreme Industry Blur
- Extreme Education & Learning
- Extreme Government
- Extreme Health Care
- Extreme Time
- Extreme Change
- Extreme Specialization
- Extreme Branding
Thirteen Strategies for Extreme Competition- The Time to Act is Now!
- Be Slavishly Devoted to Your Customers
- Think Globally, Act Globally
- Be a Superspecialist
- Connect with the Superpsecialists
- Be a Brand Master, Fight Brand Bullies
- Embrace Time-Based Competition
- Grok Process!
- Embrace The New IT
- Offer Process-Powered Self-Service
- Offer Product-Services and Experiences
- Systematize Innovation
- Be a Good Citizen
I gave the following response in a March 24 posting to the extreme programming list on the subject of XP-style traceability:
dsrkkk wrote:Whatever process we use, we need to track requirements, user stories to design and test cases. The traceability provides obviously many benefits. Why don't we automate traceability? How can we humanly track these complex relationships? If we do manually, we may miss something.
I responded . . .
The less you work in a waterfallish-way, and the more you work in an agile fashion with very short feedback loops, the less necessary it becomes to make additional efforts to track/trace requirements.
If I first do lots of requirements, then lots of design, then lots of code, etc., I have to "put the pieces together." The task I performed to write requirements was different from the one that did the design which was different from the one that did code, tests, etc.
If I work in very short cycles (particularly using test-driven development), then an individual development task looks something like:- write a single test
- write the code to pass the test and no more
- refactor the code
- commit my changes (Note I might commit my changes before refactoring too).
If, when I commit my changes to the repository, I associate my "commit" with the name or id of the story the test was for, then I have a single, fine-grained change-task that went thru the complete cycle of specification, implementation/design, verification all in a matter of minutes for a single "commit" and user-story.
Working in such fine-grained full-lifecycled tasks automatically associates all the elements that were created & updated as part of the task, which in turn is associated with a user-story. Ta da!!!! Traceability comes along for the ride almost automatically.
From Extreme Locality, in the Feb 2004 "Agile Times", pp.37-40In Agile methods, we often hear a lot about the importance of simplicity: simple design; do the simplest thing that could possibly work; simple tools; minimal documentation ... Much of the documentation and artifacts created in larger software development methods is for the sake of capturing historical knowledge: the rhyme and reasons behind why something is there, or is designed a certain way.
The desire for such information is often used to justify the need for formal traceability and additional documentation for the sake of maintainability and comprehension. Some very powerful and sophisticated tools exist to do this sort of thing. And yet, there are basic fundamental principles and simple tactics to apply that can eliminate much of this burden.
WHENCE FORMAL TRACEABILITY?
The mandate for formal traceability originated from the days of Department of Defense (DoD) development with very large systems that included both hardware and software, and encompassed many geographically dispersed teams collaborating together on different pieces of the whole system. The systems were often mission critical in that a typical “bug” might very likely result in catastrophic loss of some kind (loss of life, limb, livelihood, national security, or obscenely large sums of money/funding).
At a high level, the purpose of formal traceability was three-fold:
- Aid project management by improving change Impact Analysis (to help estimate effort/cost, and assess risk)
- Help ensure Product Conformance to requirements specs (i.e. ensure the design covers every requirement, the implementation realizes every design element and every requirement)
- Help ensure Process Compliance (only the authorized individuals worked on the things [requirements, tasks, etc.] they were supposed to do)
On a typical Agile project, there is a single team of typically less than two-dozen. And that team is likely to be working with less than 10 million lines of code (probably less than 1 million). In such situations, many of the aforementioned needs for formal traceability can be satisfactorily ensured without the additional rigor and overhead of full-fledged formal requirements tracing.
Rigorous traceability isn’t always necessary for the typical Agile project, except for the conformance auditing, which some Agile methods accomplish via test-driven design (TDD). A “coach” would be responsible for process conformance via good practices and good “teaming,” but likely would not need to have any kind of formal audit (unless obligated to do so by contract or by market demand or industry standards).
Agile methodologies turn the knob up to 10 on product conformance by being close to the customer, by working on micro-sized changes/increments to ensure that minimal artifacts are produced (and hence with minimal reconciliation) and that communication feedback loops are small and tight. Fewer artifacts, better communication, pebble-sized change-tasks with frequent iterations tame the tiger of complexity!
For more then you ever wanted to know about the why&wherefore behind traceability, see The Trouble with Tracing: Traceability Dissected
The January 2006 CMCrossroads Journal came out a few months back. Each January issue of CMCrossroads Journal usually tries to make some predictions about SCM in the coming year (or years).
My predictions on The Future or Agile SCM (from the January 2005 CMCrossroads Journal) actually tried to project thru 2008 (and even 2010 and beyond for one particular prediction). This year we scaled it back to just looking at 2006 (and possibly early 2007).
There were several recurring themes that I noticed among the half-dozen or so articles. No big surprises of course, but the degree of concurrence among the different contributors was very noteworthy (at least I think so):
- Globally Distributed development is the new "normal"
- Globalization is kicking into high gear in the "flattened world" (see Thomas Friedman's The World is Flat and Barry Lynn's End of the Line : The Rise and Coming Fall of the Global Corporation). The trend of globally distributed development is increasing at a rapid rate and will be a more important focus (and more frequent "buzzword", along with "collaboration").
- ALM is the "new" SCM!
- Application Lifecycle Management (or ALM) is becoming the new/trendy term for the full-spectrum of Software CM. Vendors have spent the last 6 years or so buying-up individual tools to provide "full-lifecycle" suites to enhance an IDE: modeling tools (that do their own versioning), requirements tools, version control, test management, change-request tracking, and others are all being offered as singly-packaged suites of integrated tools. And the vendors are using the term "ALM" for the result.
- TeamSystem, and Eclipse ALF & Corona are the new "Vision"
- Microsoft's new Visual Studio Team System (and Team Server) will make a huge splash! Look's like the splash already started, with TeamSystem winning a "Jolt" award (tho not in the SCM category). The fact that it's Microsoft and integrated with VisualStudio is enough, by itself, to warrant other vendors "taking notice." With a single integrated tool-set running off the same server and integrated with the IDE, you can do all sorts of amazing things with automated logging and traceability (especially if it's web-services enabled, or the .NET equivalent).
In order to compete, other vendors are aligning with the Eclipse ALF project, which just recently had its "proof of concept demo." ALF is the Application Lifecycle Framework, an under-development set of web-service and interoperability standards for vendor-independent integration of tools in the ALM space (version control, change/defect tracking, requirements mgmt, test management, project tracking, build/release mgmt, and even IDEs and modeling tools). And at EclipseCon 2006 the Eclipse Corona project was announced as a recent "spinoff" of ALF. According to a March 20 InfoWorld article:
"ALF addresses the issue of integration and communication between developer tools across the lifecycle; Corona enables Eclipse-based tools to integrate with ALF, according to Eclipse. Also known as the Tools Services Framework, Corona provides frameworks for collaboration among Eclipse clients."
Other related Eclipse projects are BIRT (business-intelligence & reporting tools), the Data Tools Platform, the Test & Performance Tools Platform and the SOA Tools Platform.
- Integration of CM with ITIL is the new "Enterprise CM"
- More and more SCM services departments are having to deal with many of the same issues of IT (and even being lumped together with IT) as they support not just the functions for CM, but also provide deployment, training and support for the corresponding ALM tools, repositories and servers. The integrated CMDB is also useful for both traceabilty and accounting/accountability (think Sarbanes-Oxley).
Also, more and more folks are needing to extend CM into their deployment sites at their customer's operations to help them handle field-issues and upgrades, even monitoring, service-tracking/licensing/monitoring and possibly some CRM functions.
So it makes sense that CM professionals who need to deploy, develop and support "the whole shmeer" are having to learn and understand CM, ALM and ITIL. Word has it that integration of CMMI with ITIL is coming soon.
- SOA, BPM and TCO are emerging priorities on the horizon
- There wasn't quite as much mention about these, but it seems clear that they will be growing more important this year. Service-Oriented Architecture (SOA) will be important to the extent that TeamSystem and ALF are important, and some vendors are already using SOA-based integration for the tools within their own suites.
As the integrations between ALM tools and with the IDE become more seamless, Business Process Management (BPM) and Workflow will become a bigger concern as folks try to more readily define and automate their processes, particularly for deployment to multiple distributed sites.
And Total Cost of Ownership (TCO) is becoming an increasingly more prevalent factor in selection of CM/ALM tools. The spiffy features and functionality are nice, but just as much weight (if not more) is being given to business issues of global licensing and upgrade/support, administration/maintenance, along with total cost of ownership.
So where does that leave us today? And how does this relate to the subject of last month's blog-entries about globalization and the resulting business imperatives of continuously connecting and collaborating to create, innovate and dominate?
This book, by Craig M. Vogel, Jonathan Cagan, Peter Boatwright, sort of naturally follows from previous blog-entries "connecting the dots" from globalization 3.0, to continuous collaboration + innovation, to the sets of right-brained skills Daniel Pink says will be essential to prepare us to move from the information age to the conceptual age.
The Design of Things to Come : How Ordinary People Create Extraordinary Products, is about "people-focused" innovation and how to use the skills Dan Pink describes to create a new breed of innovation that forges an emotional connection to the customer to provide a thrilling customer experience in the various forms it may manifest itself for business.
Throughout the book, the term Pragmatic Innovation is used, enough so that it hopes to become a new "catch phrase" (time will tell if it succeeds). Much of what it describes, including its focus on people and pragmatism, seem very well aligned with the values described in the Agile Manifesto.
Put this book together with the previously mentioned works from Peter Fingar (Extreme Competition), John Hagel and John Seely Brown (The Only Sustainable Edge) and Dan Pink (A Whole New Mind), and you may very well have a blueprint for both strategy and tactics on how to connect, collaborate and innovate and in what areas (and in what ways) to attempt it [such as focusing on "the customer experience" and Human Interaction Management while companies like Google transform the internet into our ubiquitous personal computing platform].
Add a dash of Fanning the Creative Spirit and Innovation at the Speed of Laughter, and maybe we'll get a solid picture of what the ideal future workplace may look like: agile, lean, connective, distributed, collaborative, pragmatic, people-centered, innovative, and dominating the competition.
