Archive for the ‘Events’ Category
“Big Agile”
On January 30, 2012 12:00 pm EST, colleague and friend Hubert Smits and I will be doing a Cutter webinar entitled “Big Agile” is More than Just a Software Method. We will follow on in February with a “Big Agile” issue of the Cutter IT Journal [CITJ] for which I am the guest editor. Coming April we are likely to discuss the topic some more in the Cutter Summit.
The heart of the webinar can be summarized in the following words:
Small is beautiful in software. While big software might not be beautiful, more often than not, it’s in the nature of what needs to be accomplished. This contrast between the beauty of small and the requirements of the big generates systemic tension in many software projects, organizations, and companies. Resolving this conflict is the focus of this webinar.
Discussing the webinar and the follow-on CITJ issue with various folks in the Agile, Lean and Kanban movement(s), I became painfully aware of the very many interpretation folks associate with the the term “Big Agile.” Hence, I would like to say a few words on what it means to me. I am taking the very pragmatic view of a client on the subject. A VP of one department or another is chartered to implement an Agile roll-out at scale. The roll-out might not include all the teams. Nor might it include all functions within the company. The roll-out, however, affects a significant number of folks. Focusing the roll-out at the team level is not sufficient.
The typical VP that I run into under such circumstances is not an expert on software methods (and usually acknowledges it). He/she, however, is smart enough and experienced enough to understand that scale matters. He/she knows or feels intuitively that Big Agile is akin to Big Data. Data is data is data, but when it is Big Data you need to address various aspects that do not manifest themselves in dealing with ordinary amounts of data. Likewise for Agile IMHO.
We plan to make the webinar very interactive. Anne Mullaney will start with a few ‘warm up’ questions to enable us to ‘dig’ into the subject, thence turn it over to questions from the audience. We plan to take the discussion to wherever the participants might want to.
I hope you will join us whether you love, hate or indifferent to the term “Big Agile.” We are expecting a lively discussion…
When Technical Debt Meets “Life”
I will have the distinct pleasure of leading a roundtable discussion on the subject in the forthcoming Cutter Summit. Here is the general direction we will jointly explore:
A technical debt assessment is often relegated to the “strictly for geeks” category. Supposedly, no sober executive wants to hear about metrics like Afferent Coupling or Distance from the Main Sequence, let alone learn and track them. Right? Wrong! In this round table discussion, Israel Gat will lead a discussion about the “life-view” that technical debt assessments reveal. Time and time again, we find technical debt readings reflect a broader truth than just the way software is produced. Here, we’ll discuss the measures that you could, and perhaps should, apply to tie process, code and outcome together to create a sustainable equilibrium between development, operations and the business.
Agile 2.0 in the Cutter Summit
I will be presenting on the Agile 2.0 subject in the forthcoming Cutter Summit. The premise of my presentation is that markets nowadays are vastly different from those we used to compete in ten years ago. The changes in the markets pose new challenges to software methods. Insofar as Agile methods are concerned, we are starting to see a new generation methods. I perceive these methods as Agile 2.0.
Here is the abstract of my presentation:
Agile, the software method that was conceived as a way to cope with change, is itself dramatically changing. What we are now witnessing is the emergence of Agile 2.0.
Three rapidly converging trends are driving the emergence of Agile 2.0:
- Markets are becoming hyper-segmented;
- Markets are also becoming fleetingly transient; and
- The value chains that serve the markets are dramatically different from yesterday’s value chains.
Traditionally, the Agile movement responded to change by “merging” two strands – development and testing – at the team level. Agile 2.0 extends this single-level approach by simultaneously applying Agile principles at three tiers:
- The tier at which development, testing and operations merge
- The tier at which strategy and delivery merge
- The tier at which problem and solution merge
Agile 2.0 addresses the key challenge posed by “change is changing”: how to solve a problem when it is not understood well enough to produce a viable solution. Rapidly interlinked iterations at all three levels make it possible to substitute learning for planning. It’s through tight feedback loops in and amongst the three levels that the pace of learning accelerates to match the speed of change.
In this presentation, Cutter Fellow and Director of Cutter’s Agile practice, Israel Gat, will divulge the details you need to know about how to implement Agile 2.0 in your organization/company. You’ll get a blueprint for assessing and responding to the new realities of the competitive environment — without compromising the tried and true Agile tenets.
Flashbacks from Boulder, CO and Kent, OH
I was on some business trip to the lovely city of Boulder, CO. My gracious host took me to dinner at the Q’s Restaurant in the classic Hotel Boulderado. We talked about our kids, software, soccer and classical music. And we talked about the University of Colorado campus in Boulder, CO.
Q's Restaurant, Hotel Boulderado
According to my host, as part of their orientation, students in Boulder, CO get lectured on the need to abide by the law. He mentioned a student in his class (or maybe it was his son’s class) who got a citation for driving his bicycles on the wrong pavement, or wrong direction or something like that. We laughed heartily about this episode – it seemed so trivial. And, even such triviality seemed very remote from the bliss of downtown Boulder.
This long-forgotten dinner came back to me this weekend, triggered by the videos from UC Davis. I simply could not believe that in something like ten years from the lovely dinner I had in Boulder we mutated from giving citations to students on bicycles in one gorgeous campus to pepper-spraying students in another. The dissonance between the beauty/tranquility and the brutality overwhelmed me.
As a young man I served in the paratroop corps of the Israeli army and fought in both the ’67 and ’73 wars. I experienced violence and brutality. They are not new to me.
Yet, this weekend I could not help recalling this classic photo of the demonstrations against the Vietnam war – the Kent State shooting:
Kent State Shooting, May 4, 1970
What are we waiting for – a similar photo from a demonstration against Wall Street?!
I Never Even Spoke with Anyone from the Occupy Wall Street Movement
Full disclosure part I: a month ago, while on my way to a business meeting, I saw a few OWS folks “camping” in front of the Federal Reserve Bank on Market street in San Francisco. I did not even have the time to take a picture with my iPhone, let alone chat with someone. This is the closest I ever got to touching, or being touched, by anyone in the movement.
So, I do not even know whether folks in the movement will agree or disagree with my simple interpretation of their overarching message:
- Our financial system is badly broken.
- Rather than letting it continue with business as usual, the Federal Reserve Bank should take over the banking system.
- Many of the services provided today by banks can be provided (once the Fed takes over) through devices such as iPhone just as they do in rural India.
- Substitutes could and should be developed for the services that can’t be carried out through iPhones or similar devices.
- Developing such services is no different from developing alternative sources of energy or health care services.
- Once the government puts in the appropriate policies (to encourage development of such services), a ton of entrepreneurs will jump at the opportunity.
I have no doubt that there are zillion details that I am not aware of that need to be figured out. I am a software engineer, not a banker.
But, I believe that at a very high level bullets 1-6 above capture some aspects of the message folks in the Occupy Wall Street movement are trying to get across. Hence, I am really surprised at the question I see cited so often “But what do they really want?!” IMHO they simply want a major reform of the financial system. The details for so doing are better left to experts.
Full disclosure part II: I have to admit my blood boiled today when I saw the videos from UC Davis. As I said in a tweet an hour or so ago, it starts feeling like the brutality inflicted on the Bonus Army in 1932. Tim O’Reilly goes one step further in his post in which he brings up the loaded topic of Banality of Evil.
So, I might be writing this post with some strong emotions. But, I think the thesis I pose is directionally correct.
You don’t need to take my word for it. Just read Technological Revolutions and Financial Capital by Carlota Perez.
Technical Debt: Assessment and Reduction
Below is the detailed outline for my August 8, 1:30-5:00PM Technical Debt Workshop in Agile 2011. I look forward to meeting you and interacting with you in the conference before, during and after this workshop!
Best,
Israel
Technical Debt: Assessment and Reduction
Part I: Technical Debt in the Overall Context of the Software Process
- A Holistic Model of the Software Process
- Two Aspects of Output
- Three Aspects of Technical Debt
- Six Aspects of Software
Part II: What Really is Technical Debt?
- What’s in a Metaphor?
- Code Analysis
- Time is Money
- Monetizing Technical Debt
- Typical Stakeholder Dialog Around Technical Debt
- Analysis of the Cassandra Code
- Project Dashboard
Part III : Case Study – NotMyCompany, Inc.
- NotMyCompany Highlights
- Modernizing Legacy Code
- Error Proneness
Part IV: The Tricky Nature of Technical Debt
- The Explicit Form of Technical Debt
- The Implicit Form of Technical Debt
- The Strategic Impact of Technical Debt
- No Good Strategy Following Prolonged Neglect
Part V: Unified Governance
- How We View Success
- Three Core Metrics
- Productivity, Affordability, Risk
- What is the Real ROI?
Part VI: Process Control Models
- A Typical Technical Debt Pattern
- Process Control View of Scrum
- Integration of Technical Debt in the Agile Process
- Using Statistical Process Control Methods
Part VII: Reducing Technical Debt
- A Framework for Thinking about and Acting on Technical Debt Issues
- Portfolio Governance
Part VIII: Takeaways
- Nine Simple Takeaway
- Connecting the dots
Surfing Technical Debt
The Second Workshop on Managing Technical Debt will be held on May 23, 2011 in Honolulu, Hawaii. It is part of and co-located with the 33rd International Conference on Software Engineering (ICSE2011). Between the workshop and the conference you can rest assured any aspect of software engineering known to mankind will be amply covered.
The workshop is quite unique in its strong emphasis on rigorizing the foundations of technical debt and unifying the ways in which the generic concept is being applied. The reason for so doing is quite straightforward. The term ‘technical debt’ has, no doubt, proven intuitively compelling. The various intuitive interpretations, however, differ in various subtle nuances. The Overview of the workshop points out:
Yet, it leaves many questions open, such as
- How do you identify technical debt? What are the different kinds of debt? What are its parameters that help projects elicit, communicate, and manage it?
- What is the lifetime of technical debt?
- How is technical debt related to evolution and maintenance activities?
- How can information about technical debt empirically be collected for developing conceptual models?
- How do you measure and payoff technical debt? What metrics need to be collected so that key analysis can be conducted?
- How can technical debt be visualized and analyzed?
As readers of this blog know, I love the combination of intellectual challenge with pragmatic utility that characterizes technical debt. Doing technical debt in Hawaii adds a dimension of pleasure to the mix. The mental image I have for the workshop is ‘Surfing Technical Debt.‘
On a more prosaic note, the due date for submitting a paper to the workshop is January 21, 2011. Please do not hesitate to contact me or other members of the program committee for any questions you might have on your paper.
Agile Enterprise Forum 2011
Charles Handy, Chris Potts, Don Reinertsen, John Seddon and I are the featured speakers in the Agile Enterprise Forum 2011. The Forum will be held on March 10, 2011 in the Chandos House at the Royal Society of Medicine, London. Attendance is limited to 30 CIOs.
The theme for the forum is Agility for Complex Organizations. The overarching message is nicely captured in the following summary by James Yoxall:
There are two strands of interest for a CIO: strategy and delivery. The Agile/Lean message can be summarised as “merging” the two, so that delivery can start before strategy is complete, and delivery informs strategy through feedback loops. This leads to a faster/earlier delivery and a better end result.
My own workshop – Agile Governance: Tying Delivery to Value – builds on this message by describing a specific strategic initiative which is not achievable without the use of advanced delivery techniques. Here is the abstract for my workshop:
This workshop will explore mechanisms for unlocking the full potential of existing software through the combination of Agile/Lean methods with technical debt techniques. These mechanisms apply to complex organisations that rely on in-house development teams as well as to third party delivery partners. Israel’s approach emphasizes the need to continuously monitor and mitigate the decay of software that more often than not had been developed over many years. Most importantly, it shows how well-governed software can become the enabler for unleashing the synergistic power of cloud, mobile and social.
You can think of the workshop as linking past, present and future. The “sins” of the past require technical debt reduction initiatives today. These initiatives utilize the classical Agile/Lean techniques of continuous measurement and tight feedback loops. Without such initiative, the value of existing software cannot be unlocked in the future. In particular, competing in the hyper-segmented markets that cloud, mobile and social generate will be next to impossible for legacy software that has not been modernized.
The Agile Executive 
