Conversations with Andrew

My Second Blog: tomlooy.wordpress.com

2008-05-24T07:33:00.000-07:00

Good morning Andrew. Just thought I would let you know that I have started a second blog at http://tomlooy.wordpress.com/. I'll keep ConversationsWithAndrew going, continuing to focus on ideas that I think are relevant to share with you. It will start to become a little more personal and range beyond just what I am learning as a PM and more into matters of being successful life in general.

The new blog will be focused more on software development process. I'll continue to talk about Agile project management but I will also write about what I am learning about Lean, Theory of Constraints, Servant Leadership, Deming and others and how it relates to organizations in general.

Lessons for Corporate Leaders from the New Testament Local Church

2008-04-19T11:10:00.001-07:00

Hi Andrew. I have been reading a lot of books on Leadership as I am motivated to becoming a better Servant Leader. You can see many of these books on our bookshelves at home like:

These are all great books and I would recommend you read them regardless of whether or not you choose to be a manager or corporate leader. Somewhere in your lifetime you will become a leader and you will find these books to be of value to you.

I recently finished a leadership book that I found to be very helpful and enlightening: Spiritual Leadership. The book covers a lot of the leadership principles from the books I have listed above and it confirmed for me that even in a spiritual context they are valid principles. The author does go one step further by defining how spiritual leadership extends beyond corporate leadership. You can read my review of the book on Amazon to see what I mean.

But rather than seeing how secular leadership principles apply in the functioning of a local church, I would like to show how the organization and leadership principles defined for the local church in the New Testament 2000 years ago are the principles that are making today's great corporations great. I believe that the local church, when operating at its fullest potential, is the most effective organizational structure in history. Therefore, we have much to learn from highly functioning New Testament local churches.

Let's start by looking at five leadership tools that we are instructed to use to serve members of the church in assisting them in become more mature Christians. Although they might seem very similar, they are significantly different. We need to understand these differences and effectively implement each, whether in the church or in our corporations if we are going to have great organizations.

(Please scroll down to the table below. Blogger is inserting excessive line breaks into the HTML, creating this big gap in the posting.)

Leadership Tool	Purpose in the Church	Purpose in the Corporation
Preaching
Teaching
Training
Mentoring
Discipling

In my next several postings I will fill out this table and expand on each of these tools of leadership, starting with Preaching.

Preaching? In corporate America? You'll see what I mean...but I don't mean anything that resembles Steve Balmer's 'Developers Developers Developers Developers'.

My Book Shelf from Shelfari

2008-04-10T13:14:00.000-07:00

Hi Andrew - I just added the My Book Shelf widget to our blog. These are books that I have read recently that I have found great value in. I would suggest reading any of these books, even if you don't become an Agile PM.

Enjoy!

Agile Project Management: Working Within Complex Adaptive Systems

2007-11-09T17:33:00.000-08:00

Hi Andrew. If anyone asks you what I do for a living you, it's pretty simple: I'm a Project Manager, an Agile Project Manager to be a little more precise. The Agile part of the title is important in that it lets people know that I choose to manage projects differently than other more traditional managers. It's also important to note this distinction: I don't manage Agile Projects - I am an Agile Manager of projects.

So what is the distinction in being an Agile Manager? Let's start with this premise: software development is hard to do well. We know this because our success record for projects is pretty dismal and this is not because we haven't put our best people on it. Great developers and analysts and managers and architects have been working on software development efforts for years and we still have a dismal record of success.

One of the reasons that software development is difficult is that software is complex and the development process is equally complex. So in trying to manage the complexity of software and software development one of two approaches can be taken.

The first approach to managing complexity in a software development project is to try to control the complexity in the project by keeping things as static as possible. This is one of the fundamental tenets of the waterfall approach to project management that results in the following practices:

Get the requirements right from the start so they won't change during the course of the project;
Define your architecture up front and try to anticipate anything that the application may be required to handle in the future;
Commit to the estimates that your team makes at the beginning of the project and stick to them throughout the project;
Establish standard methodologies in your organization to assure that each project is done the same way.

This approach did have some success early on in bringing 'cowboy' software projects under control. But software development has become much more complex and volatile with rapid changes in technology as well as changing business requirements and demands for faster times to market. These new conditions have strained the waterfall approach beyond its limits.

So a new approach to software development has emerged - Agile Project Management. Agile does not attempt to keep things static but rather embraces change. Agile manages complexity by keeping things as simple as responsible and by constant learning and adapting to the changing conditions surrounding the project.

As an Agile Manager of projects I attempt to create environments where complex systems can adapt as the organization, customer and development team learns. Agile uses the following practices in managing these Complex Adaptive Systems:

User Stories are gathered just-in-time during development of the software so we get the freshest requirements for the system
The highest priority User Stories are developed first so we don't over-complicate the software with features that are not really needed
Architectures emerge through coding, not by big upfront design
Working software is delivered early and often for feedback from the customer
Development teams self-organize around what works best for their team

So Andrew, at the heart of what I do as an Agile Manager of projects is attempt to optimize the work being done in Complex Adaptive Systems. This involves recognizing the systems involved in software development, understanding their complexities and interdependencies, and allowing for teams to adapt their processes to optimize their results. This is a lot more fun than the old command and control oversight of projects I did before becoming an Agile Manager of projects.

Not making much sense to you yet? Maybe in a couple of years...

Martin Fowler May Have Slept Here

2007-10-26T16:46:00.001-07:00

Andrew - a little lesson in Physics for you today. Trust me that this will eventually lead to another favorite subject of mine and the theme of our blog - Agile Software Delivery.

Let's say you have an environment that is really cold, potentially at Absolute Zero. You decide that you want to measure the temperature of the environment to see if it really is at Absolute Zero. But you quickly realize that if you introduce a measuring device into the environment, the warmth of the measuring device actually affects the temperature of the environment because it will transfer some of its heat into the environment. Your conclusion - you cannot accruately measure something that is really cold without affecting its temperature by trying measuring it.

This same problem occurs in other areas of Physics, most noteably in the area of quantum Physics. The Heisenberg Uncertainty Principle states that there is an observer effect on the measurement of the position or the measurement of the momentum of a sub-atomic particle. Stated differently, you can know either the position of a particle or its momentum but you can't know both. Measuring one affects the other. (The Heisenberg Uncertainty Principle has led to the most famous of all Physics bumper stickers - "Heisenberg May Have Slept Here".)

This Observer Effect also has a place in software development. The following is a quote from Scaling Software Agility by Dean Leffingwell:

"We also discovered an even more pernicious aspect of providing software solutions: delivery of a new system changes the basic requirements of the business and the behavior of the system, so the actual act of deliverying a system causes the requirements of the system to change." (The Italics are the author's.)

Agile's preference for early and frequent delivery of working software allows for the requirements of a system to emerge and the business process to evolve as the system is being coded and delivered incrementally. In Agile Software Development we are constantly asking the question "What can we code next that adds the most business value?". In contrast, complete up front gathering of requirements for a new software solution is more an exercise of the memory, not the imagination. "Let's make sure we don't forget anything" is the mantra of Functional Spec contributors.

So let's complete our analogy: in Agile Software Development the Observer is our Agile enabled development team (aptly portrayed by Martin Fowler here); the thing that is measured is business value at the end of each sprint/iteration; the thing that is affected by our measurement is the backlog of story cards as we re-prioritize and add or remove (yes remove!) story cards based on feedback from our users. Also affected by our measure of business value is the user's business process - it will become better optimized as the software is continually optimized for greater business value.

In contrast, in the Waterfall approach the Observer is the keeper of the project plan (or occasionally a requirements traceability matrix); what is measured is progress to the plan; what is affected is...hmmm...this is interesting...what is effected is quality. A poor quality software solution will have an effect on the business process but negatively as the business process must adapt to deal with the shortcomings of a badly designed and buggy software solution rather than adapting to provide greater business value.

The Information Age Is Keeping Me Stupid

2007-09-22T14:16:00.000-07:00

Good afternoon Andrew. Sorry for not posting in awhile. Let me explain why.

About 6 months ago I read The Contrarian's Guide to Leadership. In the chapter "You Are What You Read" the author suggests that a leader should read the classics, great books that have passed the test of time (i.e. Plato's Republic, Machiavelli's The Prince, as well as the texts from the major world religions). He also suggests that a lot of books that we read today may not be relevant in as short as a couple of years so he encourages selectiveness in what we read. As a result, I have become more selective in my reading, especially when it comes to blogs. This has also made me much more selective about about my own postings.

But that was also a wake up call for me that I have lost focus of what this blog is about. I have been too concerned about what my colleagues think about my postings, forgetting that this blog is really about sharing with you, my son, about what is important in life. So now that I think I am back on track I am ready to focus on more important things, like passing on worthwhile advise to you.

On to the topic at hand - The Information Age Is Keeping Me Stupid.

The book that I am currently reading is The Leader's Handbook by Peter Scholtes. The author is a disciple of W. Edwards Deming whose work in resurrecting the Japanese economy after World War II has stood the test of time so I figured learning from Deming would be worthwhile.

In the The Leader's Handbook I found an interesting diagram that I have recreated below. The diagram illustrates that from 1800 to 1950 the average time that a person worked was approximately 25 years due to a short lifespan of approximately 40 - 45 years. At the same time technology was not changing at a very fast rate. Therefore, a person was sure to learn their craft at an early age and not have to learn anything new to stay employed. But in the middle of the last century something interesting happened - life spans doubled and the rate of technology changes began to accelerate. In essense what has happened is that in the duration of our new working lifespan of 40 - 45 years, we will have several significant technology changes of which we have to stay current with. Scholtes point is that now more than ever, we are compelled to learn how to learn to stay gainfully employed.

For me this is fine because I enjoy the learning of new technologies and new ideas in Project Management. But this also means I don't have the time to read the classics as suggested in The Contrarian Leader. I may be staying technically viable but am I getting any wiser? Am I equiped to discuss the most significant matters of life, things much more relavant than the merits of Ruby on Rails or Agile Project Management?

What I really don't want is to be satisfied with what are culture considers a dialog on ideas. Today we see the shouting down of each other on TV in what is supposed to be debate. I don't want to rely to getting my political views from comedian talk show hosts or Hollywood stars. I also don't want to resort to such simplist arguments as 'Flying Spagetti Monsters' in rebuttal of ideas related to important topics such as orgins. I don't want the pre-thought thoughts of the media, conservative or liberal, to shape my thinking or the 15 second sound bites from our politicians to influence my vote.

Charlie Munger of Berkshire Hathaway gave the Commencement Speech at the USC Law School in May of 2007. Here is an excerpt from his speech:

"I have what I call an iron prescription that helps me keep sane when I naturally drift toward preferring one ideology over another and that is: I say that I’m not entitled to have an opinion on this subject unless I can state the arguments against my position better than the people who support it. I think only when I’ve reached that state am I qualified to speak."

Charlie Munger also said "Nothing has served me better in my long life than continuous learning." Somehow I don't think he was referring to staying current in technology.

Has the demands of staying current in technology left me with no time left for learning from the classics? It's time for a shift in my priorities.

Andrew - make time to read important stuff. Learn to respect others and their ideas, even if they are different than the ideas that you formulate. And then find good people that you can have deep meaningful conversations with. Learn to articulate your ideas in the company of these good people.

I have been fortunate to be around good people with whom I can have these kinds of meaningful discussions regarding the important things in life: Matt Gelbwaks of Globant, Chris Andrasick, my CEO at Tacit Knowledge, Amit Rathore of ThoughtWorks, and most recently my good friend Jay Padinjaredath, also from Tacit Knowledge.

Read important books, make good friends and discuss important ideas.

Servant Leadership is great, but does Ricardo Semler go too far with it?

2007-04-07T20:38:00.000-07:00

Hi Andrew. As you will recall, I have been talking to you about Servant Leadership for a long time now. Its principles resonate well with me and have validated my preferred leadership style.

One of the fundamental principles of Servant Leadership is to 'Upend the Pyramid' and is described nicely in The Serving Leader by Ken Jennings. Essentially 'Upend the Pyramid' says a Serving Leader is to invert the hierarchy within an organization - put the executive leadership of an organization at the bottom of the pyramid, focusing on serving the management layer above them. The management layer is to be focused on serving the layer above them, the people within the organization that are actually getting things done - the factory line workers, software developers, etc. All great stuff which I heartily embrace.

Lately I have been reading about Richardo Semler as several friends have suggested I read his books including Maverick and The Seven-Day Weekend: Changing the Way Work Works. In my research I have learned that Semler embraces the concept of upending the pryamid to a degree far beyond my wildest imagination. I found this on CNN.com's profile of Semler: "Workers set their own salaries, share company profits and hire and fire their own managers. " (Emphasis mine!)

Is Ricardo Semler going to far with the empowering of his employees to fire their own managers? If you look at his results at Semco SA you would have to say 'No'. How do I feel personally about being a manager working in an environment where I could be fired by my own development team? Well, if the development team is made up of the caliber of developers that I get to work with today at Tacit Knowledge or those that I had the priviledge of working with at ThoughtWorks, I'd say I'm fine with it. Their focus is on adding value for their customer and not their own personal agendas. If I am not doing my job of creating an environment where they can be successful in adding value, then I want them to let me know it, but hopefully before it gets to the point where they would be handing me a pink slip.

ADD (Accountability Driven Development) - The Original Software Development Driver

2006-12-16T14:18:00.000-08:00

Hi Andrew.

Lately the Agile community has been inundated with acronyms and abbreviations describing what should be driving software development or design. First it was TDD (Test Driven Development), then FDD (Feature Driven Development) and BDD (Behavior Driven Design). My favorite is ATDD for Acceptance Test Driven Development which I learned from Richard Watt at Thoughtworks. Most recently Alistair Cockburn has introduced us to XXD, pronounced Dos Equis Driven, for eXecutable eXample Driven Design.

I really don't get annoyed by these variations on a theme as I learn something from each one of them. I just hope that they don't create confusion for those that are trying to embrace Agile in their organizations or cause schisms within the Agile community. But what is yet to be acknowledged is the granddaddy of them all, a driving principle of software development that has been around for decades and continues to drive software development in many organizations today: ADD or Accountability Driven Development.

With ADD, you make sure you have someone to be held accountable during each phase of the software development process. You get someone to be accountable for getting the requirements right from the start. And then you have someone who is held accountable for getting the architecture of the software right before development begins. Accountability is then thrust upon the Project Manager and developers for delivery of the software and eventually onto QA for testing it. I call this Role Based Accountability.

Tell me Andrew, doesn't it seem like a reasonable thing to hold people accountable for getting their job done? Actually son, Role Based Accountability isn't a reasonable thing at all. Let me explain.

First of all, Role Based Accountability is based on the mistaken notion that specialization of skills is a good thing, that somehow it makes the process more efficient. Agile software development has learned from Lean Manufacturing and from the Theory of Constraints that specialization does not improve quality or time to market or even profitability. Specialization leads to Local Optimization which creates unnecessary bottlenecks within the system. Global Optimization or Systemic Thinking should be the goal. (We have already talked quite a bit about Local Optimization so I won't go into more detail here. I will direct you back to Eli Goldratt's book The Goal or Peter Senge's The Fifth Discipline if you need a refresher on the subject.)

Secondly, Role Based Accountability makes people hesitant on moving the development process along. For example, Business Sponsors will want to spend weeks reviewing a requirements document before approving it to make sure that every possible feature they may want is included in the document. Software Architects will want to research new technologies and design architectures for the application before they let developers proceed with development. QA will not want to start testing until the software is at a 'code complete' state.

Third, Role Based Accountability tends to create 'contracts' between Roles, the kind of contracts that are designed to protect an organization from a self serving vendor or a vendor from scope creep from its customer. The contracts between customer and vendor are understandable as the two organizations typically don't have the same goals. But within an organization, having a Functional Requirements Document as a contract between the business and IT often does not foster a trusted relationship between business and IT and it definitely does not promote development optimization.

Finally, Accountability Driven Development is often not about getting software into production but about making sure that there is someone to be held accountable in the case of failure, someone that is either downstream from you in the development process or below you in the org chart. Read Machiavelli's The Prince and you will see this medieval principle that is applied throughout business today.

All too often IT projects are not organized around getting quality software quickly into production that adds value to their customer. Even as organizations try to adopt Agile principles I see them getting too fixated on defining Roles within the Agile process. Agile is not about Roles and creating a process around these Roles. Agile is about maximizing throughput – the right requirements to code as fast as possible. Therefore, any Role that gets between the customer and the developer will diminish your throughput.

Follow Up on Agile and Trust: My Strengths Test Results

2006-09-30T19:15:00.000-07:00

Andrew and Chelsea on a beach in Ft. Bragg, CA

Andrew, as a follow up to my earlier posting I thought it might be appropriate for me to share the results of my strengths test:

Learner - You love to learn. The subject matter that interests you most will be determined by your other themes and experiences, but whatever the subject, you will always be drawn to the process of learning...

Connectedness - Things happen for a reason. You are sure of it. You are sure of it because in your soul you know that we are all connected...

Positivity - You are generous with praise, quick to smile, and always on the lookout for the positive in the situation...

Includer - "Stretch the circle wider." This is the philosophy around which you orient your life. You want to include people and make them feel part of the group...

Restorative - You love to solve problems. Whereas some are dismayed when they encounter yet another breakdown, you can be energized by it. You enjoy the challenge of analyzing the symptoms, identifying what is wrong, and finding the solution...

Agile and Trust

2006-09-28T23:26:00.000-07:00

[Updated - corrected name of the book referenced in the first paragraph.]

Andrew, you may recall that the other night I told you I was in the process of taking an online test and I could not be disturbed. Sorry about not being able to hang out with you but the test was something important for me to do. It was a test to help me determine my core strengths. It is based on the book Now, Discover Your Strengths, a book recommended by a good friend of mine, Adam Monago.

After I finished the test I was given my results - they were interesting but pretty much what I expected. I immediately sent my results to Adam and he confirmed that my strengths assessment results were dead on. And then he sent me his results. That’s when my results really got my attention. You see, Adam’s results were completely different than mine and he is also a ThoughtWorks project manager (and a very good one at that). Fundamentally, the difference between Adam’s results and mine is that his strengths are very goal oriented and mine are very relationship oriented.

Comparing Adam’s results to mine was a very tramatic moment for me. My first reaction was that if I were a client I would want Adam as my PM rather than me. I would want someone goal oriented and driven in managing my projects to successful completion. I wouldn’t want some relationship building pansy going around giving hugs and trying to make everyone feel good. There’s work to be done so everybody get to work!

But as I reflect back on my career as a somewhat successful project manager I now see that my management ‘style’ has always been based on relationship building. But this is not the kind of relationship building of going out after work with the guys, but rather the building of relationships based on trust. Let me explain further.

There are three different groups of people that I interact with as a project manager: my team, my peers, and my customer or boss. Each requires me to build a level of trust in the relationship in order for me to be effective.

For the team I want to build a trusted relationship where they know that they are empowered to do good work and that I will be fair and honest with them;

For my peers (other PMs) it is a trusted relationship that I will be supportive of their projects and be globally focused on what is best for the organization and not what is only best for me or my project;

For my customer or boss it is a trusted relationship of transparency into the health and status of my project.

I have recently recognized that when I do not have the opportunity to establish these kinds of trusting relationships that I resort to a different type of project management, one that is more goal oriented and less personal. But this is not where my strengths are so I am not as affective a project manager and I find my work much less satisfying.

Knowing this now, it’s not at all suprising that my preferred software development methodology is Agile where one of the cornerstone principles is ‘People over Process’.

So Andrew, you may not end up being a project manager and you may not even have relationship building as one of your core strengths. What is important is for us to discover your strengths and build on them. I'm looking forward to it.

Agile versus Stubborn Methodologies

2006-08-24T20:40:00.000-07:00

I was reading the Sept 2006 issue of Dr Dobb’s Journal today, especially interested in seeing what Ivar Jacobson has come up with in his new and improved Essential Unified Process. The article starts out pretty well with an acknowledgment that his “Unified Process has become too heavy”. But two paragraphs later he says his new process “must provide agility with discipline”. That very statement tells me that Jacobson does not get Agile. Agile is the most disciplined software development process I have used to date. (There is enough material out there regarding the disciplines of Agile that I won’t spend the time here discussing it. If you need further details check out Jim Highsmith’s excellent book Agile Project Management.)

So if I believe that Agile is disciplined, more disciplined than the heavyweight processes like the Unified Process, what word would I use to describe these heavyweight waterfall processes? The word I came up with is stubborn. Here’s why:

Waterfall has the project’s requirements defined up front. A request to change a requirement during the development phase can be an arduous and slow process of change requests and approvals. Heavyweight processes do not promote change but are designed to stubbornly resist it.

Waterfall projects have delivery dates set up early on in the development process, often by people too far removed from the actual software development and without the scope of the project well defined. Then the project is stubbornly managed against those early and ignorantly derived dates, even when scope increases.

Waterfall projects often spend a significant amount of time in ‘Big Upfront Design’. Then this design is stubbornly enforced by the architecture police, even if it is proven to not add any business value and causes delays in delivery.

Discipline means you do what you say you are going to do. On many of the waterfall projects that I have experienced in my IT career, the early rigor (stubbornness) applied to the development process got abandoned when it was realized that the project was in trouble. Specs were left incomplete; testing time was traded for more development time; quality was sacrificed to meet the schedule. I have seen waterfall projects too often end up in this undisciplined state. Is more stubbornness to adhering to the waterfall process the answer? I don’t think so because this stubbornness is a big reason that waterfall projects get into trouble in the first place.

I have found the adaptability of Agile and the disciplines of XP (test driven design, continuous integration, relentless refactoring, early and often delivery of working code) to be a much more satisfying solution for effective software development. And so have my customers.

The Failure of Rotisserie Baseball Logic

2006-06-30T08:36:00.000-07:00

Andrew -

I recently completed reading two books that before I started reading either of them I had no idea how profoundly related they were. The first book was The Logic of Failure. It has been on my reading list for quite a while, recommended by Rob, a former colleague and now friend. The second book, Fantasyland (about Fantasy Baseball), I picked up on a whim at the recommendation of a friend (Michael) while riding home with him on the train. (You’re smart enough to already see the connection between these two books, aren’t you…)

The Logic of Failure is a clinical study into the psychology of why people make bad decisions that ultimately lead to catastrophic failures. The disaster at Chernobyl is one example that he uses in the book.

To study people’s decision making processes the author created a computer simulation game of two complex adaptive systems (a village in West Africa and a small town in Germany) and asked the study participants to try to improve the lives of the people in the simulation through decision making. More often than not, the simulation ended up with the people in worse shape than before the participants ‘started meddling’. Poor goal setting, focusing on incidentals, not addressing problems soon enough, lack of experience in the domain and cynicism are among the reasons for failure identified and discussed at length for the bad decisions people were making.

The Logic of Failure was a hard book for me to read for a couple of reasons, the first being that it is a very clinical study of why people were making bad decisions that ultimately lead to failure. But it was also difficult to read as I clearly saw several patterns in my own decision making processes that have not served me well.

Well, after beating myself over my poor decisions making skills I decided that I wanted to pick up something to read that would be just for fun - try to lighten my mood a little. I needed something to read that was not work related, not a self-improvement book, not technical - just something for pure entertainment. Well, I hit the jackpot with Fantasyland.

Fantasyland is the story of a sportswriter’s first attempt at playing Rotisserie Baseball during the 2004 Baseball season. Sam Wallace from the Wall Street Journal joined Tout Wars, the premier Rotisserie Baseball league, for his inaugural season of Fantasy Baseball. With his in depth knowledge of baseball, ready access to players and coaches for their insights (using his press pass to get into each team’s club house) and two full time advisors he put on his personal payroll (and an occasional consult from an Astrologer) he was convinced that he could outdo the others in the league. It’s compelling reading as he takes you through the months of his decision making process in preparation for selecting his team during draft day and then toiling over managing the team through trades during the season. (And, it is a very funny book. My favorite line from the book is how he described feeling after being taken advantage of by a seasoned Tout Wars competitor in a lopsided trade: “He worked me over like a drunken chiropractor.”)

Well, with me associating The Logic of Failure with Fantasyland in this blog posting you probably have already concluded that Sam Wallace didn’t do well in his first season in Rotisserie Baseball and you would be correct: eighth place out of 12 teams. The same patterns in decision making documented in The Logic of Failure that led to failure were being made by Sam Wallace in Fantasyland. But the real brilliance of Fantasyland is the epilogue, on the last page and last paragraph of the book:

"Sam Wallace returned to Tout Wars in 2005 to draft a second incarnation of the Streetwalkers Baseball Club. With only two nights to spare on the evaluation of American League ballplayers, he arrived at the draft in New Your fully expecting to be thumped like a traffic cone. Six months later, he won..."

Andrew - once you get some experience in a domain, whether it be Baseball or Project Management, don't over-analyze the problems within the domain. Apply the sound fundamentals that you have learned and trust them work for you. Always be passionate about your domain and never become cynical over the effects of your decisions. Love what you do and success will follow.

"It's all about Version 2.0"

2006-06-03T09:34:00.000-07:00

Andrew - don't take shortcuts, they don't payoff in the long run and often not in the short run either. That is what Dave Stanton, my CTO when I was at Sage IT Partners, was conveying when he said that good software development "is all about Version 2.0".

We have a phrase in my business for taking shortcuts. We call it technical debt. A software development project goes into technical debt by borrowing time by not allowing for quality work today in hopes of getting more functionality completed for the impending release. But we eventually will be forced to pay back the time, the technical debt, if the project makes it into production (and therefore into maintenance mode) or if the business chooses to invest in a Version 2 of the application. There is no getting around it. We either have to take the time to fix the stuff that has been done hastily in Version 1 or we will struggle with modifications to the application because of a fragile code base. Each takes time. This will result in either fewer features in the next release or a delay in releasing Version 2. Payback is a bit...oops, sorry, I'm your dad and I shouldn't talk like that in front of you.

I think we (IT Project Managers) have done a poor job of communicating the concept of technical debt to our business sponsors. We continue to get asked to accelerate schedules, add scope without changing deadlines, work longer hours or even stop writing tests for our code, all of which incurs technical debt. All we seem to do is complain about having to work harder which falls on deaf ears as our business sponsors are also being asked to work harder by their bosses.

But what if we were able to quantify technical debt? Can we put a dollar amount on a decision to increase scope in an upcoming release? Can we quantify how much it will cost by not having a suite of unit tests and functional tests supporting our code? Our business sponsors most likely have gone through a cost justification for the project so costs rather than effort would mean more to them.

The best metric that I have seen to date has been the waterfall methodology's quantification of the costs to a project by introducing changes in requirements late in the release cycle of a project. The graph below illustrates how the cost of a change request grows exponentially throughout the Software Development Lifecycle (SDLC).

This chart illustrates how a change request during Pre-Production can cost as much as 100x more to the project than if it would have cost the project by introducing it during requirements gathering. This high cost of change requests comes from:

Needing to update documentation
Needing to update acceptance tests
Complexity of the change within an established code base, therefore needing more time
Time to fix defects introduced to the code base as a result of changes
Needing to re-run acceptance tests after the change has been implemented

In a waterfall managed project, it is seen as a success to defer a change request to a subsequent release. But one thing that is hidden in the chart above is that the cost of the change request that has been deferred to Version 2 in a waterfall project can be as expensive as incurring the cost late in the initial release. The only difference in Version 2 is that you have more time to put in the change. But it is still costly. All the things that make change requests costly late in a project are still there during development of Version 2. Therefore, Version 2 is often delayed or reduced in scope because of incurred technical debt inherent within the waterfall approach.

The Agile community has come up with a solution for technical debt - don't pay it. Keep your documentation light and write tests first. Continuously refactor and build/test the application early and often. What we haven't done well is quantify or document our successes to show how effective these practices are in releasing subsequent versions of an application.

One of the development teams at ThoughtWorks that I had the pleasure of serving as Project Manager and Iteration Manager (along with some talented folks from the client's IT staff) has recently delivered Version 2 of a successful application for a Fortune 50 company. With Version 2, the team went through a significant refactoring of the object model, added a significant amount of new functionality and kept the code base approximately the same size as Version 1. There were virtually no defects found during testing of Version 2. In other words, technical debt was not incurred during Version 1 and therefore the overall quality of the code was allowed to improve during Version 2 development. The client received the functionality they expected when they expected it. We owe this to the team's diligent application of XP development practices of test first, continuous integration, simple design, well written story cards, constant collaboration with the customer and fearless refactoring.

How Long is a Piece of String?

2006-05-06T11:47:00.000-07:00

Good morning Andrew.

So, how long is a piece of string? Do you remember when Mom asked you that question last week? Your response was pretty funny - that quizical look with your head cocked to the side and your response of 'huh?' was rather amusing.

It's a pretty silly question, isn't it? But would you believe that questions like that are asked all the time regarding IT projects? And what is even more amazing is that people actually give answers to such vague questions and then they make important business decisions based on them.

Getting back to the string for a minute, if I show you a piece of string and ask you how long it is you can give me a pretty good estimate because you can see the string. If you want to do just a little more work you can get out your ruler and measure the string and give me a pretty precise answer. The frustration of the original question is that there is just not enough information to give a meaningful response.

So how does this question about the length of a string relate to me as a Project Manager? Well, in this analogy the string is my project and the length of the string is the cost and/or duration of my project. There is always an original estimate for the cost and duration of a project and as a PM it is my job to mitigate the risks of the project overrunning these estimates and to validate the accuracy of the original estimates. It is pretty well documented how inaccurate original project estimates are in my business so I won't belabor that point here. But the real problem is that we often don't know how bad our estimates are until way too late in the project.

So how do I know how my project is progressing if estimates can't be trusted? What I have learned as a Project Manager is to stop estimating and start measuring progress on my projects as soon as possible. How soon? Within weeks of the project start date.

The problem with using measurements rather than estimating is most projects are not set up for adequately measuring progress. For example, it is extremely difficult to get meaningful progress measurements during a requirements gathering phase of a project. How do you know when all requirements have been captured? How do you know that requirements won't change? Most often a project will have a requirements gathering phase that is timeboxed, say 3 or 6 months. But 100% complete of the requirements phase does not necessarily mean that all requirements gathering is done. If you end the requirements gathering phase on time just to statisfy the estimates or the project plan, your developers will end up burning their cycles during your development phase chasing down missing requirements, something that you probably did not include in your development estimates.

Another example of what some people think is a measurement is the 90% complete status on a task. This is rarely used as a measure of work complete but is just another estimate of work required to complete the task. And I have seen in my years as a PM that 90% complete often equates to about 50% work left.

Here are some suggestions on how to start measuring a project's progress and stop relying on estimates:

- Start measuring progress as soon as possible. Gather just enough requirements to have developers start coding and continue to gather requirements in a just-in-time fashion to keep developers productive;

- Prioritize requirements so you can work on the most important stuff first and get feedback from the users on the most important stuff right away. Don't wait for months to get their feedback and find out you have missed the mark. That will really blow your original estimates;

- Use working software as the only measure of the progress on a project (no more 90% completed tasks);

- Measure using smaller sized tasks. Smaller tasks give you better measures than larger ones and will also give you a larger sampling of measures that can be used for meaningful statistical evaluations. Smaller tasks are also completed sooner and therefore give you measurements sooner that you can begin to use to extrapolate to a meaningful project complete date.

Just remember this Andrew - estimates are predictions, often with a lot of unknowns and nobody gets all their predictions correct. Completed work is real and measurable and should be used to validate original estimates and then to adapt the plan to reality.

Love is like oxygen...

2006-04-07T04:01:00.000-07:00

Andrew, Chelsea and my wife Susan at Sequoia National Park.

Good morning Andrew. Let's talk about what we learned on vacation last week about building and managing a camp fire. There are some great lessons in life that can be learned from that experience (like staying upwind of the smoke).

Do you recall what I spent most of my time doing as I was managing that fire? Was I busy managing the matches? No, we effectively used 1 match to get the fire start and then I safely put them away. Did I spend a lot of time putting wood on the fire? Not really. Once we set up the kindling and started feeding larger branches and logs onto the fire, I didn't really spend too much time with the wood. As you may recall, I spent most of my time managing the oxygen around the fire pit by blowing on the hot coals under the fire.

Oxygen is vital in a fire. It is one of the three elements required for a fire along with heat and fuel. Not enough oxygen available to a fire will cause the fire to never get to that raging stage that we were all expecting. Here's why our expectation for a raging fire to toast our smores was extinguished. Do you recall how the fire pit we used was actually below ground level? This made it difficult for oxygen to get to the fire so I had to occasionally blow onto the hot coals under the fire to provide enough oxygen to keep the fire going. A better situation would have been to have a ring of rocks on top of the ground to build the fire in. This allows for cooler air (more oxygen in cooler air) to be pulled in through the sides of the fire ring, between the rocks, rather than having heated air (heated from the fire itself) pulled down into the fire pit.

As people stand back and admired a good fire, what is it that they are most impressed with - what do they notice and comment on? It's either the intense heat generated, the height of the flames or the amount of wood being consumed by the fire. Nobody is saying 'Wow, look at all the oxygen that is being consumed by the fire!'

So you may be asking, how does this relate to being a Project Manager? Well Andrew, I like to think of an effective development team as a well oiled machine or, to continue with the theme of this posting, a raging fire. The fire (developers) consumes the fuel (requirements) to generate heat (value to the customer). And just like nobody noticing the oxygen in a fire, you probably won't notice the Project Manager on a highly effective development team.

Let me give you a couple of real world examples of effective project managers to help bring home this point:

Marjorie is one of my two favorite ThoughtWorks project managers. She is insightful, articulate and fun to talk with. Marjorie refers to herself not as a project manager but a Utility Infielder. By this she means that she is willing to fill any roll in order to get a project completed. She can step into any position and perform effectively to keep the team moving forward. And if all positions on the field are filled she won't be just sitting idle on the bench, she will be keenly watching everything that is going on at all positions as she may be called upon to fill one of those positions at moment. She is also constantly cheering on her teammates and providing insights of the game to her teammates.

Mark is the best project manager from any client that I have ever worked with. He is tenacious at removing roadblocks that keeps his developers from working optimally. As a result, developer love working for him. Mark is so good at optimizing his team's efforts that two of his developers have been recognized and rewarded within the company for their tremendous contributions. All the while Mark is getting average ratings on his reviews from his manager.

Many project managers don't really understand what I am teaching you here because they get into project management for power or recognition. Empowering others is not on their agenda. But these concepts do resonate with some. These are the project managers who either consciously or intuitively know how to be Servant Leaders.

So Andrew, why do you think there are so few Servant Leaders in project manager roles? It would seem like project management would be a great place for Servant Leaders to migrate into. The reason is that Servants Leaders must have a 'credible, just cause' (Great Boss Dead Boss by Ray Immelman) we are working for. We must be 'running to great purpose' (The Serving Leader by Ken Jennings). Servant Leaders love project management but we also love the reasons for doing the projects in the first place. A 'great purpose' is the oxygen for the fire within a Servant Leader.

Slight of Hand in IT Measurements

2006-03-18T08:25:00.000-08:00

Hi Andrew. That was a fun magic show we went to see the other day. The marvel of 'How did he do that!' is a great experience to share. I still don't know how these guys do their magic even though I know one of the fundamental tricks of their trade - slight of hand. What they do is get your attention on one hand while they actually are staging the trick in the other hand. In other words, they misdirect your attention away from what is really happening.

What has been really interesting lately is that I have found this attention misdirection stuff happening at work. It's not intentionally mind you, but it causes people to spend a lot of time and energy focusing on the wrong things. For example, I see people making decisions on what appears to be reasonable measurements, but these reasonable measures have misdirected their attention away from other measures and actions that are more meaningful and impactful. The most recent case in point I have seen is IT Efficiency Ratings. Let me explain.

The Goal for any corporation is to manage itself in such a way as to earn bigger profits. The following statements illustrates one way the banking industry often measures profitability:

"It takes the bank $.60 expense to earn every $1.00 in revenue. We need to get this down to $.45 where our competitors are."

So Andrew, did you notice a misdirection of attention in the statements above? Don't feel bad if you didn't catch it - I didn't catch it the first 100 times (that's a hint) I saw this either.

Okay, so take a closer look to see where your attention went. What numbers are you focused on? I'll bet you are looking at $.60 and $.45. The $1.00 seems to be there just for convenience sake, to make the other numbers into a consistent comparison of expense against revenue. And notice how the $1.00 eventually disappears from the second statement above. As a result, you don't even consider the $1.00 as significant and therefore you don't focus on it.

But what is wrong with focusing on the $.60 and $.45 numbers? These numbers are operating expense related numbers and you do get a greater IT Efficency Rating by reducing your operating expense.

Well, maybe. Let's say you reduce your operating expense by 10% without adversely affecting your revenue. This will result in the following IT Efficiency Rating:

($.60 - 10%) / ($1.00) = $.54 / $1.00 or an IT Effeciency Rating of $.54

That looks like greater profitablity so let's cut expenses even further! Let's say we reduce expenses by 25% now. But this time it affects our ability to generate revenue by 25%. This is what it would look like:

($.54 - 25%) / ($1.00 - 25%) = $.405 / $.75 or an IT Efficiency Rating of $.54

Ouch! That was a lot of cost cutting and it didn't have an impact on our profitability. If you continue with further cost cutting you will get to a point where your cost cutting will eventually 'cut into muscle' and you begin to have a detrimental affect on revenue generation. The biggest problem with this is you don't know that you have cut into muscle until it is too late, when your quarterly corportate reports show your profitability going down. And rebounding from this mistake will take more than a couple of quarters to fix.

Okay Andrew, take a deep breath and let's get back to the original statements above. What is the number that we have been misdirected from? That's right, it is the $1.00 of revenue. So, what if we thought of the IT Effeciency Rating like this:

"How can I optimize my $.60 per $1.00 revenue to generate more than $1.00?"

Using this new approach, let's say that we find a constraint in our software development processes and breaking this contraint allows us to increase revenue by 20% through optimization. That would give us an equation that looks like this:

($.60) / ($1.00 + 20%) = $.60 / $1.20 or an IT Efficiency Rating of $.50

That's a pretty nice improvement. Now, let's cycle back through the software development process again and find the new constraint that has popped up. We break that constraint to get us an even better IT Efficiency Rating. And then we cycle back again...you get the point.

As you can see from this example, it is easy to get misdirected to numbers that drive you to cost cutting. It takes a little ingenuity to applying the principles of Lean, Agile and Theory of Constraints to software development and a lot of disciple to stay focused on optimization but the gains are much more significant.

My Listmania! on Amazon

2006-03-03T23:08:00.000-08:00

Andrew - take a look at what your Dad has been reading the last couple of years. I just created my list of recommended Lean and Agile Project Management books on Amazon. It can be found here.

Many thanks to my friends and colleagues at ThoughtWorks for their recommendations. Special thanks goes out to Matt Gelbwaks for his recommendations and mentoring. Thanks also to Amit Rathore for our many interesting conversations that always leaves me inspired to read more.

Great Boss Dead Boss by Ray Immelman

2006-02-03T15:28:00.000-08:00

[Updated: I changed the name of this posting. 'Michael Chiklis as Roy Singham in ThoughtWorks the Movie" was kind of lame and even though there was a connection far down in the posting, it didn't really address the intention of the content.]

Good morning Andrew.

Isn't it cool when you get a tool (or toy) that you can really use. Your Mom has learned early on in our marriage not to get me handtools as a gift as it would be a complete waste of money. And worse yet it would be a huge disappointment for me as I typically savor for weeks in the anticipation of getting some cool electronic thing to use (play with).

Well, that PSP your Mom got me for Christmas has been one of those tools (toys) that I have been getting good use out of. For example, this morning on the train I watched the latest episode of The Shield that I downloaded from Tivo last night. (I can't watch The Shield at home anymore - too violent for you and Mom doesn't like it. So I have to sneak it out of the house and watch it on the PSP on the train.)

So there I was on Amtrak watching The Shield and I notice myself using another tool that I recently acquired from the book Great Boss Dead Boss by Ray Immelman. This is a fabulous book as it has given me tools to help understand people's behaviors. The book explains how people respond to their boss based on their individual needs for security and value. (This comes from Maslow's Hierarchy of Needs that I'll share with you other time.) But the book goes beyond individual needs for security and value by talking about how people often respond based on the groups (or tribes as Immelman likes call them) that they belong to and the tribe's need for security and value. Some interesting attributes of a tribe include:
- Tribes are groups of people that are often not just organizational groups.
- Tribes, like individuals, have needs for security and value.
- When a tribe's security or value is threatened, the people in the tribe will behave in predictable ways that differs from when their individual needs are threatened.
- Tribes will go to war with other tribes if their tribal security or value is threatened. Often these combating tribes are in the same organization.
- Individuals will abandon the tribe if their need for security or value is not provided by the tribe.
- Tribes with that have a strong sense of security and value have strong leaders.

So, having read Great Boss Dead Boss has made watching The Shield even more interesting. I can see how the tribal attributes really apply in so many different directions: gang warfare, Vik Mackey's Strike Team, Internal Affairs, rookie cops trying to get accepted, and on and on.

I encourage all of my colleagues to read the book and to be sure to get all the way through it. The last 20 pages are the most enlightening, at least for me. I won't go into the details here, you need to read it for yourself to get the full impact. It did help me understand why ThoughtWorks is unique and what makes most TWers highly effective. (There is more than just the bald head that Vik Mackey, the cop in The Shield, and Roy Singham have in common. )

The book, and especially the last 20 pages, has helped me realize what I must do to become a more effective project manager / leader. It is such a joy for me to see that you are on that growth track already, 40 years ahead of me.

I'm grateful and honored to be your Dad.

Conversations with Chelsea, too

2006-01-23T21:28:00.000-08:00

Hi Andrew. This weekend your sister informed me that she would like to be a Project Manager when she grows up and that she wanted training - right away. She plopped herself on the couch with notebook and pen in hand and waited for me to start teaching her about project management.

I must admit that my first thought was of the Monster.com ad during the Super Bowl a couple of years ago with the kid that said he wanted to grow up and be a middle manager. Aspiring to be a typical Project Manager is a pretty sorry thing.

So where do you start teaching a 7 year old about project management? And how do you do it in such a way that she will still be interested? Surprisingly, two things happened as I started explaining about project scope and risk. First of all, I really enjoyed talking about what I do as a project manager. (It's easy to enjoy your work when have a good client and a great project team.)

Second, I was surprised at how much she was getting. She asked such great questions like 'Why does the client get upset when you tell them that the extra work they asked you to do will take extra time?' Or 'Why can't the client think really really really hard before they tell you what do so they don't have to come back and tell you later that there is more stuff they want you to do?' A great lead in to Agile!

I wish all my clients can be as smart as your sister.

Local Optimization - bad. Global Optimization - good. Universal Optimization - huh?

2005-12-18T14:26:00.000-08:00

Hi Andrew. I want to share something important with you that I learned this week.

I have already shared with you how Theory of Constaints teaches about Local Optimization - pactices within an organization that may appear to be effective but in the bigger picture of the organization, they are really ineffective or even detremental to achieving the overall goal of the organization. In contrast, processes that focus on the overall goal of the organization are referred to as Globally Optimized processes. The Principles of Agile software development such as early and often delivery of working software help me as a PM to focus on Global Optimization.

But is there such a thing as Universal Optimization? Are there processes and a goal that can make Corporate profits, an individual's happiness or some political ideology another instance of Local Optimization? These questions proach on the subject of one's 'world view' or their religous beliefs because you have to begin with defining what is the Univeral Goal. (In most places this is a difficult subject to discuss, but at ThoughtWorks, where we embrace a diverse culture, I can share my ideas and be challenged to think clearly and rationally. There are many bright people at ThoughtWorks who have well thought out world views that are in contrast to my world view but they have helped me formulate and clearly share my ideas on such subjects.)

So let me share with you what I have learned this week regarding Universal Optimization.

I have been reading from the Book of Job in the Old Testament. I have known about the story of Job for a long time but I never really understood it. To summarize the story, Job was a righteous man. He knew it and God affirmed it. But the Evil One asked God for permission to mess with Job in hopes that Job would eventually curse God. God allowed it with the condition that he spared only Job's life. Until today, this never seemed fair to me.

The Evil One took everything away from Job - his wealth, his family, and eventually his health. Several of Job's friends then tried to council Job about why this is happening to him. Their council was amiss though, in that they told Job that God was judging him because of something he must have done wrong. Job never curses God but continues to assert his own rightousness and therefore wants to question God about why this is happening to him.

God eventually steps in and lets Job's friends know that their council was bad. God then talks with Job and essentially tells Job that he may be rightous but he does not see 'the bigger picture'. Job repents and says 'My ears have heard of you but now my eyes have seen you'. He has come to an understanding of Universal Optimization - Job learns that life 'is not about me'.

So Andrew, I believe that there is a higher purpose or ultimate goal in life: 'You shall love the Lord your God with all your heart, with all your soul, and with all your mind. This is the first and great commandment. And the second is like it: You shall love your neighbor as yourself. On these two commandments hang all the Law and the Prophets.' (Matthew 22: 37-39)

I Plan, Therefore I Am

2005-10-14T22:10:00.000-07:00

Andrew, this is a pretty good synopsis of my PM development over the last 10 years:

Beginner PM
1) I plan
2) Things don’t go according to the plan
3) I beat up myself

Novice PM
1) After learning how to play the estimating game, I plan
2) Things don’t go according to the plan
3) I beat up the developers

Journeyman PM
1) After learning about Waterfall and SDLC, I plan
2) Things don’t go according to the plan
3) I beat up the customer

Expert PM
1) After realizing that a plan is based on estimates of the unknown, I plan
2) Things don’t go according to the plan
3) I adapt the plan
4) Nobody gets hurt

I am not an animal...I am a man...ager!

2005-09-30T08:47:00.000-07:00

I have been pretty excited lately about the synergy of ideas in the diverse books that I have been reading. I have enjoyed discovering the synergy between Peter Senge’s systemic thinking (The Fifth Discipline) and Eli Goldratt’s global optimization in his Theory of Constraints. And the parallels in Agile’s ‘People over Process’ with the concepts of Servant Leadership from the Greenleaf Institute lets me know that being an Agile PM at ThoughtWorks is a great place to be.

Now Andrew, I hope that you have noticed that there seems to be a common theme emerging from my postings - integrity in project management. So you can imagine how blown away I was this morning as I saw the synergy of ideas related to integrity that I found while reading on the train to work:

“Dee Hock has a unique perspective on the responsibilities of a manager. The first is to manage self, which he defines as “One’s own integrity, character, ethics, knowledge, wisdom, temperament, words, and acts.””
Jim Highsmith, Agile Project Management p. 207

“If I speak in the tongues of men and angels, but have not love, I am only a resounding gong or a clanging cymbal. If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing. If I give all I possess to the poor and surrender my body to the flames, but have not love, I gain nothing. Love is patient, love is kind. It does not envy, it does not boast, it is not proud. It is not rude, it is not self-seeking, it is not easily angered. It keeps no record of wrongs. Love does not delight in evil but rejoices with the truth. It always protects, always trusts, always hopes, always perseveres. Love never fails.”
I Corinthians Chapter 13

The synergy of Agile project management with my personal belief system is very cool. But please note that I am not saying that you have to subscribe to my personal belief system (Christianity) to be an effective Agile project manager. I work with a lot of wonderful people at ThoughtWorks whose belief system is very different than mine. But I would challenge anyone to make sure that there is synergy and consistency between their personal belief system and their approach to their work. If there isn’t, then either their work is not worth doing or their belief system falls short.

(OK – so the title for this posting has very little to do with the content. The title is one of my favorite quotes of all time, from the movie Elephant Man. So I extended it a little to try to get it to fit into the theme of this blog. Yeah, I know - big stretch.)

90% of the beer on the wall, 90% of the beer...

2005-09-23T21:40:00.000-07:00

Andrew - you wouldn't think it but software development is a very emotional occupation. Just watch people reading Dilbert. They either laugh uncontrollably or get really angry because Scott Adams has beatifully portrayed the madness of my industry.

Nothing can get much more emotional in my business than the 90% status report. I have been on both sides of the 90% complete status. As a developer I was frustrated in having to give that status for a second and even third time in a row to a manager that I knew wouldn't understand why my status didn't change. Or I was embarrassed that I was so naive to believe that last week I thought I was 90% complete, and that there were so many things that I should have considered in my original estimates but didn't. Or worse, I was angered that my manager so easily forgot that the scope of my task had increased but I was not allowed to re-estimate the effort.

And I have been a PM that has had developers that have repeatedly given a 90% complete status for the same line item in my beautiful project plan. I felt completely un-empowered as the PM. I could not report status on my project with any confidence. I also felt a lack of integrity in passing on that status, rolled up into the overall project status along with all the other developer guesses, to my managers.

It was bad enough that I was ready to quit this business a few years ago and go back to teaching. But then I was introduced to Agile software development and in particular Extreme Programming. One of the most glorious things about Extreme Programming is the practice of breaking tasks down in size to stories that should be accomplished in a couple of days. So when status is reported on a story, it is either done or not done. Nothing in between is ever tracked or reported. No more 90% complete. Welcome back integrity.

Don't Let Your Strengths Become a Weakness

2005-09-09T07:42:00.000-07:00

Good morning Andrew. I just got done reading a posting on ravi mohen's blog about his ideas for a criteria that can be used in judging project managers. One of the points that he makes is that each of the really good project managers he has known have had great skills in other areas besides project management. He gives examples of great athletes, musicians and writers that are also effective project managers. It made me think that if I am a good PM, what might be something else that I am good at that could translate into being a good project manager? Well, the first thing that came to my mind is that I have been (and still are) a successful teacher and coach.

Let me give you a little more background about my teaching and coaching. Last weekend your mom and I moved some furniture around. In moving the hope chest down into the guest room I came across an old trophy I have been holding on to. It is the team trophy for winning a high school midwest regional basketball tournament that qualified our team for a national tournament. I was the coach for the team. This trophy is very special to me because it reminds me of a great bunch of kids that I had the chance to work with. But this is not the trophy that I am most proud of. In that same tounament the team also won the sportsmanship award. We were winners and we were disciplined.

So, going back to the theme of this posting, what could be the weakness in my strength of being a good teacher and coach? If I am hired to be a teacher and coach there really isn't an issue with it. But as a PM there could be. Here's how: being a teacher, I believe that I can teach anybody anything (given enough time) and being a coach, I believe that I can motivate anyone to do great things. (I can't seem to motivate you to clean your room, though.) But, you might ask, isn't it my job as a PM to build a team, and to teach and motivate? Yes, it is part of my job but it is not The Goal. My goal as a teacher is to build character and instill wisdom and knowledge. My goal as a PM is to deliver projects.

My abilities as a teach and coach are effective tools in my PM toolbox but they can also get in the way of delivering projects. The problem is that I sometimes continue to try to teach or motivate an under performing team member longer than I should. This can become detrimental to the morale of the team and detrimental to the delivery of the project. In the past I have had to let developers go and intuitively I know that I have done what was best for the team and the project. But each time I am left with a sense of personal failure.

The point that I am trying to make here is that if I continue to play to my strengths of teaching and coaching it can become a weakness as a PM. I constantly need to remind myself to stay focused on the goal of delivering business value by delivering working software into production.

One last point I want to make for you, Andrew: In this posting I am talking about strengths of abilities, not strength of character. Strength of character will never be a weakness in anything that is worth doing well.

Some men are born to accountability...some have accountability thrust upon them

2005-09-07T13:24:00.000-07:00

As a project manager, managing accountability is a cornerstone of my work. Because I am paid to assure that things get done there is an expectation that I will get things done. So, as the PM on projects, it becomes my responsibility to pass this expectation on to the developers, the people who actually get the work done.

In becoming an effective project manager of software development teams, I have learned that there are two sides to accountability. One side is empowering, the other is paralyzing. Knowing the difference between these two sides will help you effectively manage accountability and can ultimately affect the success or failure of your projects.

Tell me if you can see the difference in the following two statements regarding accountability:
- I will hold the development team accountable for getting thing done
- The development team takes accountability for getting things done

In each of the two statements above, where does the accountability originate? With the first, the accountibility is externally imposed on the team. With the second, it is internally imposed by the team on itself. Is this a significant difference? Let's look a little deeper into each.

Holding the Team Accountable
Often, holding a team accountable is not about assuring things get done but is about having someone to blame if things don't go well. This is the blame game and this is how it is often played out in project management:

Business envisions a project
Management estimates costs and dates for the project
Development team is given the project to complete without opportunity for input into the project estimates
Project scope creeps
Project delivery date slips
Management finds someone to blame, most likely the development team (they were the last ones doing anything on the project so they are fresh on people's minds)
Management puts the Big Bad Methodology in place on next project to hold people accountable
Management starts to measure project progress against the Big Bad Methodology
People start to focus their efforts only on their tasks in the methodology so they won't get blamed
The process becomes locally optimized and not globally optimized*
The delivery of projects gets worse
Good developers leave the company because they are being micro-managed
The remaining average and below average developers require micro-management
Management gets more serious about the Big Bad Methodology because it provides a way to get average and below average developers to accomplish something
Project delivery slows to a crawl (but nobody is getting blamed! They are all doing their part in the Big Bad Methodology.)
The organization cannot hire great developers to increase productivity because great developers don't want to be a part of a micro managed organization

*Here is an example of why local optimization is bad: in the Big Bad Methodology someone is responsible for gathering requirements. When they finish putting together their Big Bad Requirements document, they say "Whew! Thank goodness that is over with. I'm not gonna get blamed if this project is successfully!" as they throw the requirements document over the cubicle wall to the developers. But is the document sufficient to code against? Documents never are no matter how much time you spend on them. The requirements gatherers have finished their part of the methodology and are long gone to the next project and are not around to support the developers in getting working code into production. Therefore, the coding effort takes longer and is often missing the intent of the project vision because of poorly communicated/understood requirements. (See Theory of Constraints by Eli Goldratt or The Fifth Discipline by Peter Senge for discussions on Global Optimization.)

The Team Holds Itself Accountable
Being accountable should mean that you take responsibility for getting something done. You don't worry about blame but rather are committed to adding value to the organization. You are empowered and trusted to deliver.

So how to build a team that will take accountability? Here are some things to keep in mind as you build an accountability taking team:

Hire great developers that are passionate about delivering value to an organization and not just passionate about writing cool algorithms
Empower the team to self organize (see Artful Making: What Managers Need to Know About How Artists Work by Robert Austin)
Empower the team to estimate projects (how can you possibly expect developers to commit to estimates if they had no part in deriving them)
Make sure the team sees the vision of what is trying to be accomplished by the project
Think globally, not locally, even within the development team's processes
As a manager, be a Servant-Leader (see The Serving Leader: Five Powerful Actions the Will Transform Your Team, Your Business, and Your Community by Ken Jennings)
Be adaptive - don't be rigid in establishing methodologies (see Agile Project Management: Creating Innovative Products by Jim Highsmith)
Have a plan but be will to adapt as you learn

Tom on "Joel on Software" - BUFD Part 2: The Rest of the Story

2005-09-02T22:43:00.000-07:00

It really pays to ask questions, to discuss ideas, to put yourself out-there. Learning starts to accelerate when you begin to articulate your thoughts and feel free to ask questions.

Case in point: in sharing this blog with Rob, a friend and colleague at work, he read my earlier posting on "Joel on Software" and he was able to answer a couple of the questions that I had posed to Joel. Of most interest, Rob was able to answer the question I have for Joel's project: Are your requirements stable? The answer was suprising (but if I had done a little more research I would have found the answer myself).

As it turns out, Joel is not only the architect for the system but he is also the customer! That means he is responsible for defining his own requirements. Well his requirements had better be stable then! Can you imagine how embarassing it would be for the customer and architect of the system to change requirements in the middle of development and have to do rework because of something he forgot or didn't consider?

So now that we understand the context of his argument a little better, let's ask Joel some more questions. If you had to work with a user/customer that was not able to articulate their requirements as well as he can, would you be able to do BUFD even if he wanted to? How many times have we as system developers worked with customers that, when we give them a demo of some working software, they essentially say "I don't know what I want but that is not it"?

Software requirements on most projects change, either because the user begins to understand the problem better as working software is delivered or the needs of the business changes during the project. At the heart of Agile is creating an environment where the project team can embrace change.

So I may agree with Joel that BUFD is appropriate for his project. I said I may agree - I still have a few more questions that I would ask of him. For example, what is the experience of his development team with the technology being used? Is there a need to do some exploritory / deep slice prototypes early in development that would give insight as to how the system architecture should evolve?

I am disappointed that Joel uses his project as support for his argument against Agile and for BUFD. His project is not representative of projects that should consider Agile. Let's focus the debate on this question: Would you prefer to use BUFD or Agile on a project where the requirements are likely to change late in the project?

Tom on "Joel on Software" - BUFD: Big Up Front Design

2005-08-29T19:36:00.000-07:00

Yesterday I read a posting on Joel on Software about Big Up Front Design (BUFD). Joel Spolsky, the namesake for Joel on Software, contrasts BUFD to Agile and states his preference for BUFD. I must admit that I was a little disappointed with how he presented his argument in the posting but I don't want to draw too many conclusions about him or his ideas based on this one posting.

Joel's point is that by doing BUFD you will save yourself from problems later in the project. According to Joel, not doing BUFD will undoubtly lead to rework that will cause delays in the project.

Rather than engage in a Holy War about software development methodologies at this point, my prefererence is to try to understand Joel's perspective a little better before I draw any conclusions about him or his ideas. Holy Wars tend to polarize people and ideas and I don't think that the question of BUFD vs Agile is battle that one has to take sides on. There are times when BUFD makes sense and times when Agile makes sense. There are even times when Agile and BUFD make sense on the same project.

So, in my opinion, the real question should be: In the context of the application, the customer, the technology being implemented and the makeup of the development team, does BUFD make sense?

Here are some questions that I would ask Joel about the project to help me determine if I would choose to do BUFD:

What role are you, Joel, playing in the project you were referencing? (If Joel is filling the role of Software Architect on the project I can understand his preference for BUFD. Software architects are usually the smartest, most experienced and most strong willed people on the project team. They see there job is to architect things and so they diligently get to it right away on a project. But I have seen (and have been) the software architect over imposing themselves/myself on a development team by establishing architectures that a development team is forced to comply with.)
How much time has been scheduled on the project for the Big Up Front Design phase? (BUFD can take months - it can also be never ending. You have to stop designing and start building at some point. Joel's point is that spending time on BUFD is intended to mitigate the risk of re-work. But re-work is an inevitablilty in our business. So we should not try to mitigate re-work but learn how to most effectively deal with it. But BUFD actually introduces an even greater risk to a project - project cancellation because of too much money spent on things that don't return business value. What returns business value? Working software in production.)
How stable are your requirements? (If your requirements are stable then you may have a case for BUFD. But we all know that requirements change and often these changes require changes to the applications architecture.)
How well does the development team know the domain of the application? (Eric Evans, author of Domain Driven Design, has been quoted as saying that a development team really doesn't know the applications domain model until the application has been in production for a year. Changes in the domain model as a team better understands the domain can have a big impact on the systems archtitecture.)
How experienced in the development team in the technology being implemented? (BUFD for a development team that is new to technology often leads to rework as the team better understands how to work within the constraints of the new technology.)

So Andrew, here is what I would like for you to take away from this posting:

Don't be quick to take a position on an issue
Ask good questions to get to know what the real issue is (the real issue here is not BUFD vs Agile, but should BUFD be used on the project in question)
Ask even better questions to understand the context of the problem
Ask your best questions to get an understanding of other person's perspective on the problem

Don't argue your point in hopes that you will be able change the other person's mind
You will find that arguing with someone rarely ever changes their mind. They may concede your points, but most likely because you have worn them down with arguing or out skilled them in debating. But in reality you will not have won them over. Will they get behind you and actively support your decisions? Or will they will most likely get behind you and stick their tongue out at you?

Don't assume that the person that you are talking with understands your perspective
People may get the impression from Joel's posting that Agile means no design up front. But Agile does value doing up front design, but just enough design to get started and no more. Make sure that you are talking about the same thing - define your terms and state your position clearly early in your discussion so as to not waste time talking about your apples vs their oranges.

It is still worth the effort to discuss differing ideas with people
Even if you most likely won't convince someone to embrace your perspective through debate, it is still worth the effort to intelligently articulate your ideas with them. This is an important point that merits it's own posting. I look forward to telling you more about it...

Why is asking good questions important? Good question!

2005-08-26T22:00:00.000-07:00

Andrew - I have a really good developer that I have been working with that is stuggling with some new things that he is trying to learn so I sent him this email today to encourage him to ask good questions to help him in his learning process. I thought you might like to read it.

"Mike - I have been wanting to catch up with you about some more stuff that I think may be of interest to you. I have been reading a lot of stuff by Eli Goldratt lately. His most significant contributions have been with his ideas in his Theory of Constraints (TOC). His first book, The Goal, where he first introduces TOC using the forum of a business novel, is becoming required reading in most business schools.

"There are three things that I really like about Goldratt's work. First is his Theory of Constraints which parallels a lot of what we are doing with our Agile software development. TOC comes from the manufacturing world but the principles can apply to software development too. We can chat more about TOC later but it is not the main idea that I wanted to share with you now.

"The second thing I really like about Goldratt is that he uses the Socratic method to teach his concepts within his business novels. Check out The Goal to see how he does it. If you really like the book, then pick up Critical Chain, another of Goldratt's business novels, which is more project management oriented than manufacturing. These books will give you some insights into Agile that many people even in the Agile camp don't get.

"So in using the Socratic method in The Goal, Goldratt has Jonah, the mentor, asking leading questions to his student (Alex Rogo) to get him to draw the conclusions/solutions himself that Jonah wants him to draw. Thus Alex Rogo ends up with a sense of ownership of the solutions that he would not have if the solution would have been handed to Alex from Jonah. In using the Socratic method Goldratt shows how to use influence rather than the wielding power to get things done. This is the third thing that I like about Goldratt - his teaching on how to create change in an organization.

"So, Mike, how does all this relate to you? Well, one of the things that Goldratt teaches is the thinking processes that can be used to create meaningful change. In the beginning of any change/thinking process you have to start with articulating the problem that you are trying to solve. In your case, learning a new technology or more importantly making a paradigm shift to Agile and Object Orientation, it is important for you to ask specific questions as to what you don't understand. Gaining understanding of Agile practices and OO is the problem that you are trying to solve. So articulate what you don't understand, not just that you don't understand. Then be disciplined in asking questions. Right now you are in a good environment, working with a team that encourages questions - take advantage of it.

"So don't let something that you don't understand get past you without asking about it. Don't just say you don't understand - think through what you know and what you don't know and craft a good question to ask.

"I know this process works. It has worked for me. Sometimes just coming up with an insightful question will give you what you need to answer your own question. And sometimes not, so don't hesitate to ask.

"Let me know if you have questions. Meaningful, well crafted questions, that is...

Tom"

Why do I think I have anything worth teaching my son?

2005-08-26T07:44:00.000-07:00

Andrew with his Dad on the right and Dan Beaver, lifelong friend of Andrew's Dad on the left. (I think that is Martin Fowler sneaking up on Andrew from behind. Nope, he has too much hair on the top of his head to be Martin.)

Andrew, I don't think I am any smarter or wiser than the next guy. I don't have anything to share with you that I have figured out on my own or earned based on my own merit. What I do have is the extremely good fortune to have had some really great teachers in my life. So all I want to do is pass down to you those things that they have taught me.

My first great teacher has been your Grandpa Looy. Even before I was your age I was watching him work hard and I saw in him the joy of working when he was doing what he loved and when he was working with people that he liked and respected. As you and I continue with our conversations you will see that I have followed his example in choosing to work with people that I love and respect. Your Grandpa Looy has also been a great dad to me and my love for you comes from knowing how to love a son through his example of loving me.

My second great teacher has been your Uncle Mark, probably the smartest and funniest guy I know. As a big brother, he taught me though his example to set and meet the highest standards of integrity. But it his passion for the most important things in his life, his family and his ministry, that I find to be the most remarkable and inspiring. I am fortunate to have a big brother that, like our father, loves what he does and loves the people around him.

As we continue with our conversations I will share with you my experiences with some of the most wonderful people who have taught me so much. I look forward to reminiscing as I gather my thoughts to share them with you.

So who is Andrew?

2005-08-25T21:56:00.000-07:00

Andrew is my son, age 10 at the time we begin this blogging experience together.

My intent with this blog is to share with Andrew those things that I am learning about work, family, faith and purpose in life. Some things he is ready to learn now and others he will have to wait before he will be able to grasp the lesson. So as I go forward writing in this blog it will be in the voice of me sharing my life's lessons and experiences in the form of Conversations with Andrew.

I love you, son...

Dad