The power of ownership

I happen to be working simultaneously on two projects at the same time. One is a close to a classic project with a project manager, a MS project plan and the traditional dynamics between a project manager and the resources working on the project. The other is a team that is taking a more agile approach with user stories and sprints and so on. This provides a real interesting learning opportunity to contrast the different approaches to getting things done.

It is a bit of an apples to oranges comparison, today I was really struck with an benefit for the agile approach that haven't really appreciated. On the classic project there is a distance or an understanding gap between the formal project plan and the people doing the work. On the classic project many people just don't have the time or care to become familiar with the schedule or the project plan. If they do, they are primarily just looking at the end date and maybe what is on the critical path to the end date. It is a project manager's job to drive the planning process and make the team aware of what is in the project plan. But most of the time they really don't care beyond the success of the project. They have developed some kind of understanding what what needs to be done and that's what drives them. Especially in a matrix organization, the project manager is often some one running ahead of or along side the project trying to keep the plan aligned with the reality of the performing team. In a matrix organization the resource manager will have language and vocabulary for talking about what needs to be done, it should be but it is often not exactly how it is described in the project plan. A good project manager will have some standards for describing tasks or doing the work brake down structure. This may be very professional and orderly but it is often not how the resources would typically describe the work to be done. IOn top of the semanict and vocablary issues the plan may be captured in a tool that not every person has due to license cost or just convenience. Consider a team of 12 where on the only the project manager and the resource manager have a tool like MS Proejct Professional and their dest top. The other 10 on the project get PDF reports, PWA access, or get to watch the project manager use an overhead projector to display the plan on the wall.

Some resources may passively resist the regimentation and structure that comes from working on a formal plan maintained by a professional project manager . I believe that all of these factors contribute to the gap between the plan and the resources.

On an agile team we have user stories that are written by a variety of people on the team. There is a template "As a I'd like so that " People tend to more or less follow the template but for the most part it is written in their own words or at least there is a more level or democratic opportunity for someone to edit the user story before it is agreed to and acted upon. If the team has tasks related to the implementation of the user story it is very likely that the tasks are written by the person performing the work. They may use a tool designed for agile teams, a Sharepoint list, sticky notes or a spread sheet. Key is that all team members are more often in the same position when it come to tools used to author the user stories or tasks. This seemingly more chaotic way of specifying what needs to get done does have it's draw backs. The big one is that we may miss and important piece of work that needs to get done due to the lack of uniformity in the specification and assumptions among the multiple people contributing to the tasks and user story definitions. We try to mitigate that risk by review and discussion of the user story list that doesn't happen as often as it should.

So in the end there are two alternatives each with their Achilles heal. A coherent professionaly maintained work break down structure that is some what distant to the resources doing the work. Or, a more chaotic structure that the resources doing the work readily understand. Generally I prefer the latter. I'd rather have a looser "plan" with inconsistnecies that people really follow than a really tight comprehensive plan that people doing the work have not internalized or even do not readily understand. In the end it is the outcome of the project that matters. On top of just understanding, there is the ownership issue. By far and away I believe that people work harder when they feel they own the plan and they have personally contributed to its creation. This ownership feeling is fosterd much more when they actually press the keys that make the plan artifact what ever form it happens to take. A perfect plan can never be achieved, however a team fully comitted to a successful out come is much more valuable than a perfect plan. In the end it is the outcome that matters. I'll trade almost every thing to get a team that owns the plan.

Wedding Agility

On occasion I judge and critique projects done by college students as part of outreach by the SW Ohio PMI chapter. It seems more often than not a wedding comes up as one of the “projects” done by a group of students. A wedding is perhaps one of the first and largest projects that most amateur project managers attempt to undertake. Some couples hire professional wedding planners, I suspect the vast majority do not. Hence a wedding is a prototypical project management experience for many people regardless of what their profession may be.
I am very close to two very important people who will be getting married latter this year. I could offer my project management services to this couple the way a photographer or a florist may contribute. They have been busy planning and it seems that they have a good handle on the tangible aspects of the day. I worry still that all of this planning may ironically become an obstacle to that perfect day they both so richly deserve. Rather, I think a more valuable offering to my son and his future wife and any other couple planning a wedding is this adaption of the agile manifesto.


A wedding is a momentous event where family and friends gather to witness the vows of the bride and groom and the start of a new life together. It clearly needs a lot of preparation and planning. This is especially true when there are out of town guests and considerable financial expenditure is involved. All that planning, especially when the bride and groom are in the center of it all can take on a life of its own and over shadow the really important things that day. Through my wedding and being a guest at many other weddings over the years experience over the years I have come to value:

• Family, friends, hugs and tears over reception hall/church guidelines and “The Knot “ check list

• Precious memories of a happy day over hours spent posing for photographs

• A multi family & multicultural celebration over a party planned by a few people

• Being present in each moment over worrying about what has to happen next

That is, while there is value in the items on the right, I value the items on the left more.


I find it relatively easy to teach and mentor people about the classic aspects of project management what I struggle with is imparting the wisdom I have gained over the years about what is really important. That seems to be true for a wedding as well as many other endeavors. How to find the right balance is the central question.

Tailor at your own risk

I signed up to speak at the next Cincinnati SPIN meeting next week. I plan to talk a bit about adapting agile methods such as SCRUM to work in distributed environments. Or just tailoring your current methods to introduce some agileness. I have a fair amount of anxiety on this topic.
What I fear is encouraging people to pick and choose from a set of Agile methods and then get in deeper trouble or further spread misconceptions. I believe processes like Scrum are the result of considering a particular development scenario and then putting it through a lean process filter. The outcome is a small tight set of processes where nothing is optional. (retrospectives, user stories, close customer collaboration, etc. ) Where some one to cherry pick a few of those processes and then claim to be doing Scrum it could be a big problem. Hence I think the difference between SCRUM and agile is like the difference between a set of values and a coherent integrated set of processes. Values are more abstract and processes are more concrete. It is like democracy and the government system of a particualr country. Agile is to democracy as Scrum is the the UK system of government.

On the other side of the coin I consider the multiple places I have worked or served as a process mentor and despite what ever label they apply: RUP, extreme programming, FDD or scrum there are still considerable variations among groups the profess to be following the same process. I believe that we tend to believe that things are more alike than they really are for groups who profess to be following a certain process. We under appreciate the tacit and implicit customizations that each group adopts. These adoptions are critical success factors.

Bottom line there is no magic bullet best practice. The art and science is in the tailoring and adaption of the broad range of best practices as identified by SEI or PMI with a values foundation as expressed in the Agile Manifesto. People over process, working software over extensive documentation, etc. Think like an agilest but make sure you have a story for dealing with scope management, risk etc.

I thought I was pretty smart 10 years ago when I had 20 years of experience. Now that I have 30 years of experience I realize how difficult this is and I have even less confidence. What I do appreciate is the wisdom I draw from all schools of thought and bodies of knowledge. Comming up with the most appropiate development and project management process is a very challenging endevor. The good news is there is now a lot of wisdom to draw from. Good Luck.

It's not "lite"

I worry that some folks support agile development because they dislike process and consider this a way to get by with doing less stuff that they don't enjoy. Take for example a discussion with a team on a agile journey. Developers indicating some push back when the code stops working due to some changes in progress. They voice the position that there is extra work to make the temporary changes necessary to keep the code working for the periodic builds. They could use that time to create extra value or function. At the same time the testers don't seem very enthusiastic about testing the latest build and reporting bugs. As the mentor for this team I worry that we are getting off track.
My best response is that we choose not to reduce the risk of undertaking a complex software development effort by writing detailed specs and requirements documents. Instead we choose (or I believe we choose) to reduce risk by incrementally create function and create frequent builds of working code. That is our risk reduction strategy. It is a corner stone for our plan to deliver a successful end product. I acknowledge that their is some extra work to keep things working - perhaps with some temporary scaffolding or temporary code. This enables us to demo the code and learn from it over the life of the project and not have a big crisis at the end and a long difficult to predict period of instability.
Next time I'll ask do you want to write specs and that start or keep the code always running and fix the bugs as they come up. You can 't have your cake and eat it too. We are all on a journey...

bugs and credit card debt

I've got two challenges that seem totally unrelated but have some striking parallels. One is credit card debt and the other is bugs on software projects. I have to say the idea of considering a bug list as a debt was first introduced to me in the book "Waltzing with Bears". These days with a new found awareness and sense of fiscal responsibility I wonder if I can leverage that into a better quality practices.
In a "traditional" project teams often work away according to a plan. Very often things don't go as expected and one of the places that suffer is any time planned for bug fixing. Or there is an accepted sentiment that "...they are just bugs and we can fix them at the end after all the hard work is done" we've got to stay on schedule. (In my experience more often than not a significant design flaw or requirements snafu is uncovered in the process of bug fixing and these issues are really harder than building new function. These are dirty problems people tend to avoid unless pushed by an experienced manager or agile mentor. )
Some teams even may have a bug review with the customer or product manager near the very end of the project. These are often difficult as during this review the only choice the customer has is to extend the schedule to fix the bugs or accept the bugs as known issues to be fixed in the next version. Hence they tend to want to avoid these sessions as they only present dilemmas not an opportunity for active decision making.
Some teams consider it OK to build up a large bug count. They also probably consider it OK to keep their charge balance at or near the credit limit. I recently pointed out to my lovely spouse that despite payments of a 100 dollars a month the balance of on a certain credit card had only decreased by 60 dollars in the last three months. In my minds eye that's almost 80 dollars a month wasted that could have spent on other things on tangible goods rather than interest payments.
The team that runs with a big bug back log faces the same waste. Granted there is the "cost of quality" analysis. We are not going to have a perfect product and fix every bug. But if in the course of doing business we make accommodation like:

• Skipping that error when it is reported again and again in the automated test run.
• Talking to one another via speech, email or instant messenger,or what ever about bugs that hang on for months.
• Some one else rediscovering the bug and attempting to report it only for the bug report to be deemed a duplicate.
• Reading past the old bug in the bug report when looking for new bugs. Considering what other bugs might be resolved by and open fix. A large open bug list makes the incremental cost of every new bug larger as the database grows.
• Writing up the bug as a known issue for the read me or release notes when we finally complete the project and didn't get time to resolve it.
• Not discovering other bugs that are masked by the bug due to people avoiding that functional area where the known bug was reported.

All of these things sap the productive energy of the project team like the 80 dollars a month lost in my family budget.

How do I cope.

1. Be vigilant and visible with test results. Keep them visible and on going.
2. Raise the threshold for what is considered a bug. Sure it would have been better if it worked that way.... but that wasn't in the user story and never discussed till now. Can we plausibly just make that part of user story backlog.
3. As part of the post sprint review, consider the new bugs that are still outstanding. Decide now if we can ship or put the product into production with these bugs. Don't be a fence sitter. It is OK to have up to 20% as "maybes" but if the customer/product manager can't accept certain bugs recently introduced then they get fixed before new user stories are added. This is part of what it means for each sprint to produce a potentially shippable product.
4. Remind the team what a crunch they use to have at the end of other projects. Use that as a motivator to not put things off and not be overly optimistic.

If I'm not running my credit card debt near the limit. I can be agile and make a decision to take advantage of great sale on new patio furniture or I can redo the basement the way I'd really like to after suffering from a flood. If I'm agile I pay as I go and I have choices. I have head room to respond when the unexpected happens. I can take advantage of business opportunities arise because I'm always just weeks, not months away from shipping or going into production.

Sometimes there are dark days

Maybe all the grim economic news has me down. The thought occurred to me yesterday that possibly some of the people on my team are attracted to and proclaim support for agile due to a mistaken belief that it is just project management lite. They don't see a lot of paper and ceremony and they think "gee this is a lot better than the place I use to be where we had to write all those software requirements specifications and fill out all those change request forms. I can just do what I enjoy - writing code....." And there in lies the central problem for someone promoting an agile development model. It is easier to give someone a check list to fill out or a template to complete than it is to shift their values or beliefs. If one is truly faced with some one who is so ego centric that they are primarily motivated just doing a private intellectual exercise - code writing you've got an up hill battle facilitating agile adoption. Maybe a hopeless one.

Going back to the Agile Manifesto, it is primarily a values statement. If you don't buy in to the values you'd really be better off with a cook book approach. The teams I've met and worked with that are truly practicing agile have been and are very driven by process. Ironically this is the opposite perception of those who don't understand agile and speak negatively about it. I met one of those people the other day. He started the conversation with "I hate Agile it cost our company x dollars on a project we did using that some time ago." He elaborated "when we got to the end nothing worked and there was lots of finger pointing. " Our conversation on Agile was tangential to our primary discussion and it wasn't the place to start evangelizing about agile. I should have been quick enough to key in on the "got to the end nothing worked part" My gut feel is that perhaps it was one of those loose type processes that masquerade as an agile project. Instead I said well "Agile isn't appropriate in every situation." That is also true.
And here's the part where I make my self feel better. What I needed to do in that situation was build a new relationship, not get on a soap box about Agile. So I was living the values statement of putting people ahead of process. In the end I can only hope that if I can influence people by being genuine and living the values I profess. And, throw a few hardballs like I did today when I called our team on letting the bug backlog build up.

On of the primary challenges we have with our distributed organization is creating that interpersonal interaction that comes so easily when the team is located in one place. There is nothing like being there and this is probably the central constraining factor inhibiting our Agile adoption. None the less I'm happy to be working with a team that wants to push the envelope. With out the Internet we wouldn't even be trying to build a product on 3 continents spread across 10.5 time zones.

We've tried a few way's to make up for the daily scrum. Communication is really our big challenge. One of our first attempts was to hold a virtual daily scrum via a customized share point message board and a recurring Outlook appt. This worked well enough that we got good participation and people were itchy to improve it. The idea was that every day as close as possible to 8am Eastern time every one was to post a message to this share point discussion board under the root item of the current day such as 14 Jan. I figured that the folks in India would participate at the end of their work day and the folks in US would participate at the start of their work day, the folks in Europe well they could pick a time in the middle of the day. Well I was really rather ego centric. I didn't realize how self centered I was being based in the US Eastern time zone. This model of communication we really best for the US participants. It didn't make sense to be almost at the same time.

A thought I had for a while was what about all this social networking stuff. Can't I apply some of that technology to make my distributed agile team more social? One of my first thoughts was to use Twitter to host our virtual daily scrum. One our managers, rightfully so raised security concerns with twitter messages disclosing sensitive "intellectual property". So when we discovered Yammer it was something to get excited about. Yammer.com is like a Twitter for people at work. We've been using Yammer now for about a month. I've seen some discusions and disagreemetns arise from Yammer posts so I believe it is working. Very nice tool and thanks to the folks behind Yammer.com.