Archive for the ‘Events’ Category
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…
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.
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.
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.
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:
What are we waiting for – a similar photo from a demonstration against Wall Street?!
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.
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!
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