skip to main |
skip to sidebar
This will be my last blog-entry for at least a couple of weeks. I'm going in for surgery tomorrow to have my kidney removed and transplanted into my sister. It will take me about two weeks to recover to the point where I can sit in front of the computer for any length of time - and another two weeks before I return to work. (Well wishes and prayers for both my sister and me will be warmly welcomed :-)
I received two pretty cool books from O'Reilly the other day. They're not your normal fare. And I havent finished either of them yet. But I'm leafing through them and they both look waaaayyy cool and extremely useful:I'm looking forward to making my way through the rest of these two books and learning more about how my mind works and how to make better use of it (and better "maintain" it :)
I published a bunch of entries with numerous resources on different aspects of Scaling Agility. I wrote most of them several days apart but many of them got "pushed out" (published) together in sudden bursts. Here they are again:
Feel free to post a comment with other links are anything you feel warrants a new category (e.g., melding Agile with any of Lean, TOC, or Six Sigma)
There has been a really great discussion thread on the Lean Development YahooGroup on the subject of "How do I find bottlenecks?"
I particularly liked a reply by Alan Shalloway that linked things back to W. Edwards Deming's 14 points for management from his Theory/System of Profound Knowledge. Allan's translation has a bit of a "Lean" slant to it, and doesn't explicitly mention eliminating/reducing variation quite so much. Here is how he summarized it:
Re respect for people, the best place to start, IMHO, is Deming. Here are his fourteen points (Chapter 2 of Out of the Crisis, by W. Edwards Deming, MIT Press, 2000; originally published in 1982.):
- The world has changed and managers need to adopt a new way of thinking. Delays, mistakes, defective workmanship and poor service are longer acceptable.
- Quit depending on inspection to find defects and start building quality into products while they are being built. Use statistical process control.
- Don't choose suppliers on the basis of low bids alone. Minimize total cost by establishing long term relationships with suppliers that are based on loyalty and trust.
- Work continually to improve the system of production and service. Improvement is not a one-time effort; every activity in the system must be continually improved to reduce waste and improve quality.
- Institute training. Managers should know how to do the job they supervise and be able to train workers. Managers also need training to understand the system of production.
- Institute leadership. The job of managers is to help people do a better job and remove barriers in the system that keep them from doing their job with pride. The greatest waste in America is failure to use the abilities of people.
- Drive out fear. People need to feel secure in order to do their job well. There should never be a conflict between doing what is best for the company and meeting the expectations of a person's immediate job.
- Break down barriers between departments. Create cross-functional teams so everyone can understand each-other's perspective. Do not undermine team cooperation by rewarding individual performance.
- Stop using slogans, exhortations and targets. It is the system, not the workers, that creates defects and lowers productivity. Exhortations don't change the system; that is management's responsibility.
- Eliminate numerical quotas for workers and numerical goals for people in management. [We add: Eliminate arbitrary deadlines for development teams.] This is management by fear. Try leadership.
- Eliminate barriers that rob the people of their right to pride of workmanship. Stop treating hourly workers like a commodity. Eliminate annual performance ratings for salaried workers.
- Encourage education and self-improvement for everyone. An educated workforce and management is the key to the future.
- Take action to accomplish the transformation. A top management team must lead the effort with action, not just support.
These go back 60 years. And (I can't help myself) these principles are in the context that process causes 94% of the errors - so work on the process to support the people! (people and process, people and process, people and process, ...) ;)
Alan Shalloway, CEO, Sr. Consultant
Net Objectives, Gold Level Sponsor of Agile 2006.
Integrating people, process and technology through training, coaching and consulting.
Alan's website also has some really great articles, papers, presentations and resources on Agile, Lean, Scrum, XP, Design Patterns, and all things related to Agile development and object-oriented design.
For some slightly different interpretations and summaries of Demings 14 points and Seven Deadly Sins, see the following:
There has also been a thread on another discussionlist (sorry - the name escapes me at the moment) on the relevance (or lack thereoff) of Deming's writings and philosophies in the world of today.
What are your thoughts?
There are a few good books about conflict resolution & leadership that use Aikido style/philosophy throughout. I highly recommend them for anyone interested in the connection between leadership and martial arts philosophy:
There must be some of you out there who have some other links to share on this topic! Leave a comment with your favorites!
Current issues of IEEE Software, CACM, and ACM Queue have articles related to agile distributed development and release management ...
The Sept/Oct 2006 issue of IEEE Software is about Global Software Development. It has several Agile-related articles (like A Practical Management and Engineering Approach to Offshore Collaboration)
This months CACM theme is "Flexible and Distributed Software Processes" with articles on distributed agile development (which are currently available online), including:
ACM Queue an article on Agile/Iterative Release Management entitled Breaking the Major Release Habit.
Other resources on Distributed Agile Development:
- an Agile 2005 presentation on Introduction to Distributed Agile Development
- DistributedAgile.com
- Vince Massol's May 2004 Case Study on Distributed Agile Development
- a July 2004 Forrester Report on The Total Economic Impact™ Of Using ThoughtWorks’ “Distributed Agile” Approach, Single Company Analysis — Financial Services
- Distributed Agile Development, by Dafydd Rees, April 2004
- Agile Alliance articles on Distributed Agile and Offshore Agile Development
- Stickyminds.com article, Going the Distance: Five Tactics to Compensate for Distance on Distributed Teams, by Esther Derby
- 2004 SpiderLogic presentation about an Experience report on Distributed Agile Development
- Knowledge Management for Distributed Agile Processes: Models, Techniques, and Infrastructure from KMDAP2003 (and related paper)
- MKDAP2003 presentation on Proactive Knowledge Distribution for Agile Processes
- Martin Fowler's Using an Agile Software Process with Offshore Development
- Managing Commitments and Risks: Challenges in Distributed Agile Development
- Dependency forecasting in the distributed agile organization
- Briefing of Starsoft Development Labs related to Distributed Agile Development
- the Agile Journal back issues on Globally Distributed Development (April 2006) and Collaboration and Reuse (Sept 2006) [the latter has a few articles about distributed collaboration/agility]
- Jeff Sutherland's Distributed SCRUM paper from IICS'06 on Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams
- Aug 2005 Stickyminds.com article on Building an Effective Test Team for Distributed Agile
- Malcolm William's 2004 Master's thesis on Distributed Extreme Programming: Extending the Frontier of the Extreme Programming Software Engineering Process
- Follow the Sun: Distributed Extreme Programming Development from Agile2005, by Monica Yap (also see the powerpoint presentation)
- Naresh Jain's Offshore Agile Maintenance (summary, presentation, and experience report all available from this link)
- Distributed Agile, a 2004 presentation by Christoph Steindl
- Internationally Agile, 2002 paper by Matt Simons
- Summary results of March 2003 USC Workshop on Large-Scale Distributed Agile Development
- Support for Distributed Extreme Programming by Frank Maurer et. al., XP2002 (also see a related paper on the same subject)
- eXtreme Programming in Open-Source and Distributed Environments
- Follow-up paper to the above (same authors): Distributed eXtreme Programming paper from XP2001 conference
Also, although it's not specific to Agility, the book Software without Borders appears to have some good reviews by several folks who are well-respected in the Agile community (also check out the online references section of the book.
Over the past months I've come across a bunch of good links & papers on the topic of "Going Agile" at the program-level:
Michele Sliger (of Rally Software Development) has several good articles and presentations on Relating PMBOK Practices to Agile Practices
On using Agile methods in organizations with a stage/gate approach to program management, see some of Per Runeson's work in this area:
Murray Cantor has some good papers on Governance and Variance as it applies to Agility:
Some other papers & resources:
Those interested in some advanced agile planning concepts should look at Jeff Sutherland's paper on Scrum II - The Future of Scrum: Parallel Pipelining of Sprints in Complex Projects (and the presentation slides that go with it)
There are several REALLY GOOD whitepapers on Adopting & Scaling Agile at Rally's Agile Knowledge Portal, including the following in particular:
There's gotta be some other good stuff out there and Agile Portfolio, Program and Multi-Project Management! If you know of any - please add a comment and hyperlink or URL!
Over the past months I've come across a bunch of good links & papers on the topic of "Going Agile" at the program-level for large systems and systems of systems. Some of these relate to Agile program Management and others are more about Agile Systems Engineering (and some relate to both). I'll mention the ones on Agile Systems Engineering in this blog-entry and leave the ones on agile program management for a subsequent entry:
That's the best I came up with. If you know of other good links on this topic, please send me a comment!
Here is a list of resources I've found that I feel are applicable in figuring out how to scale Agility for a large organization and project. (On the subject of metrics and values, I personally find Sam Guckenheimers work to be of greatest interest):
Additions and corrections are welcome!
David Anderson writes about the recent Agile2006 conference in his blog-entry Thoughts for Agile2006:
Scaling Agile. The BIG issue for this year is scaling agile across a whole organization. I see this as having three parts - program or multi-project management and the rollup of schedules and resource plans to a Director or VP level; architecture and enterprise level modeling of a domain and data center; and finally configuration management including build, integration, branch and merge strategies, and work-in-progress batching and related communication.
Ive been dealing with this topic a LOT lately in my own organization as part of efforts to spread amd adapt Agile methods across a large distributed enterprise working with large systems and teams. Ive been researching and collecting lots of resources, including some earlier blog-entries on Agile CMMI and Dancing Elephants and Agile Adoption across the industry.
My perceptions of where the "seams" of the enterprise are that are hardest to introduce Agility into are the close collaboration and alignment required across organizational (lifecycle discipline) boundaries and geographic boundaries (and I find the former to be more difficult to surmount than the latter.)
If I try to categorize them as different areas or aspects that each require the ability to be agile, I come up with something like:- Process - Adapting Agile to the Organization (making processes responsive to change)
- Product - Agile Systems Engineering/Architecture (making the requirements & architecture be responsive to change)
- Project - Agile Program Management & Governance (making the project be responsive to change)
- People - Distributed Agile Development (collaborating across multiple sites, teams, and timezones)
- Organization - Agile Metrics/Reporting, Governance, and Organizational Design
- Environment - Agile CM, deployment, operation/support, etc.
I'll be blogging separately with lists of resources of found for several of the above.
I've been thinking about a metric that might elicit Test-Driven behaviors in my organization. As a first step to TDD, we definitely want folks to create automated tests as much as feasible and execute them frequently. Once they get that, I've been thinking about what sort of metric might encourage them to actually work in short, test-driven cycles, where requirements are elaborated test-by-test (given a use-case or story, write the first test, write the code to pass the test, refactor, rinse-lather-repeat).
Some of these folks are very much ingrained in a systems engineering V-model lifecycle that does a lot of big-requirements up-front. So ensuring they work to automate tests and execute them frequently isn't enough to enourage them to use an interative approach of fine-grained TDD-style elaboration. An idea I had for what to measure is something I chose to call Test-Execution Availability Time, or TEA-Time (I figure if nothing else, my friends in the U.K will like the name :-).
As proposed, Test-Execution Availability Time (or TEA-Time) would be defined as the mean time between when a system requirement description is first baselined, and the time at which a "sufficient" number of automated tests for the requirement were implemented and ready (available) to be executed.
I was thinking that if a group was measuring this and wanted to behave in a way that minimized TEA-Time, it might encourage them to elaborate requirements in an iterative and incremental fashion, in smaller and smaller "functional slices". One thing I'm not sure of is what "a sufficient number of automated tests" should be in the above.
Any thoughts or comments?
As mentioned in an earlier blog-entry, I have created an Agile CM Yahoo Group. The description is:The agile-cm group is for the discussion of ideas relating to Configuration Management for Agile development and of applying Agile concepts, methods and tools to the practice of Configuration Management itself (and CM "Patterns"). This includes aspects of CM that relate to agile development, refactoring & design patterns, agile project-management, Lean, Theory of Constraints (TOC), even SixSigma and CMMI to the extent that they can help CM and related practices to be more "agile".
As I wrote earlier, I hope this new agile-cm group will have a healthy balance of both SCM folks and Agile development folks so we can have some constructive multi-faceted discussions.
Some of you may have wondered what the heck happened to my blog during August and the first half of September. Well - I lost some write-access to my website for a lot of the summer (while my host was recovering from a denial of service attack) and I couldn't login and update it.
I had several blog-entries "queued up" simply needing some final cleaning-up before I made them live, and that got interrupted, then I couldnt access them, then I had some vacations/travel, then I needed to "catch up" when I got back to work, and so on ...
So over the next week or two I'll be "pushing out" the entries I wrote-up in August, using the date they were originally written. I'll also be making available the talk I gave in July at Architecture & Design World 2006 on the subject of "SCM Patterns for Agile Architectures."
In October/November I may not be blogging much at all as I'll be trying to recover from major surgery (I'm giving one of my kidney's to a family member).
Our August Agile SCM column in the CM Journal is about Relating SCM Patterns to SCM Principles. The article is pretty flimsy, barely a skeleton, and that's pretty much entirely my my fault. I meant to write more "meat" about how certain principles are the underlying forces behind several patterns. I wanted to show how the principles are strongly related, much the same way patterns in a pattern language are related. And I wanted to show how that structure shaped the relationships between the patterns as well. Rob did a really good job trying to put together what I had with what he could come up with, but I didn't really give him enough and couldn't easily convey it in a way that made it easy for him to "run with it!"
It's not that I don't see those relationships, I do. And I'm not lacking for words to describe them either. I'm having trouble describing them clearly and concisely. A big part of that is because I still don't like the names of the SCM Principles as I've described them so far. Their names currently relate to the OOD Principles they were derived from. I think that might speak to programmers, but not to folks trying to do version control (even if they also wear "developer" hats). I really want to go back and rework the names of the principles to be more simple and direct.
This is something Ive been working in my mind on and off for alkmost a decade now. To me, it is of profound important - perhaps even the most significant contribution I'll have made to the field of SCM to date. THe interest level doesn't seem to be so high on the scm-patterns list and the cmcrossroads.com forums (but that hasn't deterred me - yet :). I really do think it's not a coincidence that principles of object-oriented design also manifest themselves as fundamental principles of SCM solution design (because I think both are all about architecture - and minimizing and managing dependencies).
I'd really like feedback. On this stuff so if you've had a chance to read thru the June, July and August Agile CM columns, I'm going to create a new YahooGroup about Agile-CM for discussing these and other Agile CM issues. Hopefully this new agile-cm group will have a healthy balance of both SCM folks and Agile development folks so we can have some constructive multi-faceted discussions.
Some more SCM books have come on the market in the past 6 months or so. Several of them are worth a look: I realize Practical Perforce isn't new - I just can't stop gushing about how great it is! Laura Wingerd really has a gift for elegantly and simply stating important (and sometimes profound) insights about SCM, particularly when it comes to component/container-based SCM and codeline branching and management.
Global Outsourcing with VSTS looks interesting - not really sure if I like it enough to recommend it just yet. It certainly has an attention grabbing title.
The 2nd edition of Pragmatic Version Control using Subversion is just as outstanding as the first edition. It is my first choice for an introducitory book on Subversion and Version Control.
Kevin Lee's book on using ClearCase, ANT and CruiseControl is nothing short of outstanding. If you're a Java-shop using ClearCase and want lots of practical tips and tactics for doing automated builds and accelerating the build process, this book is a MUST HAVE! Kevin's website is also a great resource. Now that IBM/Rational has acquired BuildForge I imagine their will be updates at his website (and eventually a 2nd ed?) about using Clearcase with BuildForge (and maybe some stuff regarding Maven2?). He apparently has some new (online PDF-only) book out called The BuildMeister's Guide from a new series/publisher called Buildmeister books.
Pulsipher and Buckley did a great job in their earlier book The Art of ClearCase Deployment. Now they have a similar book about ClearQuest entititled Implementing IBM Rational ClearQuest: An End-to-End Deployment Guide. So far it looks very good. It's also the only ClearQuest book I know of - so If youre using ClearQuest for anything but a small or informal project you probably should get your hands on this book in a hurry!
I had a posting on Scott Berkun's project management (pmclinic) list that was rather well received. I thought folks here might be interested in it ...
Someone else had written:
> I've found that powerful people respect people who do not back down from them. Make your point forcefully.
I responded with:
That could backfire really badly! That might work with some, for others it will only make things worse. Either way, what they are looking for is respect for their perspective. They want to be LUVed:- Listened to,
- Understood, and ...
- Valued.
Making any assumptions about what it means to them to be LUVed and what behaviors they feel demonstrate LUV could easily be jumping to conclusions down a very wrong and unconstructive path.
Chances are the "annoyance" is because, somewhere, somehow, the two people involved have different notions of what it means to feel respected and to be treated respectfully and be LUVed. What you regard as disrespectful and disruptive may seem just the opposite to him. He may feel that by giving what you say substantial thought and vocalization on multiple sides to be an act of mindfulness rather than dissension.
I would suggest getting together one-on-one for an open, honest, and candid yet compassionate discussion about what each of you need and what you should/can expect from one another. Dont attribute feelings/motives/intent to him, instead describe his (or her) actual, factual, observed behavior and how it makes you feel, what that makes you think, and its consequences/impact on you and others.
Something is certainly out of alignment between the two people in question, but it may not be objectives or intent, but rather differences in values and belief as to what constitutes respect, progress (versus disruption) and what things are most/more important for overall success.
So in terms of advice, I would add an 'E' to the end of the LUV acronym to make it LUVE: Listen, Understand, Value/Validate, Empathize:
- Listen attentively to what the other person has to say
- Understand it to the best of your ability (you don't have to agree with it, just "seek first to understand")
- Value/Validate what was said. That doesn't mean agreeing with it; It does mean finding the value in it and validating that value to the speaker.
- Empathize with the speaker. Try to identify the feelings they are experiencing and demonstrate your understanding of it, and that it is okay for them to have those feelings.
I wish it was as easy to do habitually as it was to write about. If I could develop the above habit, I would be 10X more effective in both my personal and professional life!
I've been needing to do some research into the apparent state of Agile adoption & usage across the industry. For those who are interested, here are the URLs I have gathered (some of them are pointers to excerpts or abstracts that you have to register and/or pay to read the entire article - but I found other URLs that summarized the information in them).
Agile Survey Results
Other Articles and Reports on Agile Adoption:
[updated 14 Sept with articles from AgileJournal.com and VersionOne.net]
I've been trying to keep-up with what's going on in the scripting world. Perl6 still isn't out yet. And Ruby and Groovy seem to be the hottest and most popular & promising.
Groovy is still trying to win support and evolve to a JSR implementation, and achieve a big following. Not clear yet if it's going to succeed or if it has stalled out. The attempted revival of the "Practically Groovy" series at IBM developerWorks suggests maybe it's still alive and kicking.
Ruby is positively on Fire! And Rails is a big part of the reason for that (though there is a similar "Grails" project for Groovy). I've been wading my way through books on Ruby. The best ones were from the PragmaticBookshelf, but now O'Reilly has a some good Ruby books too. So now my Ruby reading list is as follows (I'm about half-way through it):
So far, it seems like Ruby and Rails is an amazingly hyperproductive language and fraemwork that takes what many feel are the best of Smalltalk, Python, and Perl, makes it fun and elegant, and makes web development and enterprise integration for simple to glue together production-quality stuff in less than half the usual time.
So right now I would say that Ruby (and Rails) seems to be winning out over Groovy, and some (including Bruce Tate) even think it's beating out Java. I guess we'll see. Right now Ruby (with Rails) appears to lay claim to the title of scripting language with the fastest growing popularity and user-base.
I've been needing to "brush up" on my SQL and RDBMS skills (let's just say it's been a while :-). I found the following books from O'Reilly and Addison-Wesley to be extremely useful, in order of increasing usefulness:
The first two above are from Addison-Wesley. I found them to be good for a "quick review" for someone who used to do SQL and RDBMS extensively 10+ years ago but whose knowledge is a bit rusty and outdated.
The second two books above are from O'Reilly. I really like the two O'Reilly SQL books! I refer to them the most right now. The SQL Cookbook updated a lot of my existing knowledge and added to it, and the Art of SQL is fantastic! I just love the way it uses Sun Tzu's "Art of War" to apply to winning the "war" on DBMS and DBM complexity!
One thing I particularly liked about my presentation of "SCM Patterns for Agile Architectures" at the Dr Dobbs Architecture & Design World 2006 conference in downtown Chicago...
I offered up several definitions or perspectives of SCM, including a traditional description, an Agile one, and an architectural one. I liked my architectural definition (I hadn't used that one before - I had used the other two in previous definitions). I said that, from an architectural perspective:
"Configuration Management is the Architecture of the Evolution of your Architecture!"
I rather liked that! I sort of used that to justify the title of the presentation, and presented an IEEE definition of architecture, along with Kruchten's 4+1 views model of software architecture. I then used that to justify my 4+2 model views of SCM/ALM solution architecture. I updated my drawing of the 4+2 model a bit. I think the addition of the Who+When+When+Where+Why+How shows how it may be a possible "bridge" between the Zachman Framework and the 4+1 views model.
Once again, the presentation is here. Feedback is welcome!
