Just for Show

Dallas Team System User's Group Meeting

2008-08-05T01:48:00Z

I'll be speaking at the Dallas Team System User's Group on Tuesday, August 5th (that's tomorrow) about Managing Software Quality with Team System. My hope is to demystify how to use Team System reports and software metrics to assess and manage the quality of a software project. Also, I intend to dive into some of the development tools including Code Metrics, Static Analysis, the code profiler, and using build to assess code quality. Improving Enterprises is graciously hosting the event, Notion is paying for the food, and we'll get the party started at 6 PM. I'll see you there!

Dallas Team System User's Group - June 3rd

2008-06-02T18:56:00Z

Team System junkies and interested parties are invited to this month's Dallas Visual Studio Team System User's Group Meeting on Tuesday, June 3rd at 6:00 PM at the Notion Solutions office in Irving, TX. My friend and colleague Vince Blasberg will be speaking about Reporting in Team Foundation Server. Reporting in TFS tends to be a difficult topic to get one's head around and Vince intends to demystify some of the complexities about how reporting works and how to write your own custom reports against Team System data.

Dallas Techfest

2008-05-02T16:43:00Z

I'll be speaking at Dallas Techfest tomorrow, May 3rd at the Addison Conference and Theatre Center, just north of big D. I'll be covering Silverlight in a talk at 10:00 AM in the Emerging Technologies track. I promise it'll have a bit more meat than the powerpoint beatdowns you've seen before and if it doesn't, then be sure to complain and let me know. I think this Silverlight thing is going to be a big deal and am really excited about it.

Big thanks go out to Tim Rayburn and all the others who poured so much energy into putting Techfest together. There's a great lineup of topics being presented by great speakers coming in from all over and best of all, it's free.

Dallas VSTS User's Group Meeting - Thursday April 10th

2008-04-08T20:20:00Z

I'll be speaking at the Dallas Visual Studio Team System User's Group delivering a presentation titled Scrum and Team System on Thursday, April 10th at 6 p.m. at the Notion Solutions office in Irving. Here's the abstract:

Scrum is an iterative incremental process of software development commonly used with Agile software development. Scrum is a process skeleton that includes a set of practices and predefined roles. Microsoft Visual Studio Team System has an active community of users that have used Team System to manage their Scrum projects and has a set of mainstream process templates that are Scrum-based . Join us for an examination of the process templates available for Team System that implement Scrum (including Conchango Scrum for Team System, eScrum, and Light Weight Scrum) and for a discussion the merits of using Scrum to manage your software projects. This topic is intended to be accessible for people who are new to agile software development and intended to be informative even for the most seasoned Scrum advocate.

More details about the group and the meeting (including directions) can be found at the Dallas VSTS User's Group web site. Feel free to join us!

Work Item Customization: Set a Field Value That Cannot Change

2007-09-26T01:38:00Z

I was doing a bit of work item customization today when I ran into an interesting, but common problem. The client wanted a field, specifically the 'Work Remaining' field on a Sprint Backlog Item, a work item in the Conchango Scrum template, to automatically be set to 0 when the work item state is set to Done. Easy enough.

But really, they wanted to make sure that the value is both set to 0 and read only so that the value never changes when the work item is marked as Done. If the work is complete, there should be no remaining work and if any additional work is identified, the item should be set to be In Progress. So the obvious choice is to add <READONLY /> or <FROZEN /> inside the FIELD tag. As obvious as this seems, it won't work. The result of the COPY doesn't stick or doesn't happen, depending on which you do. Either way, it's not what was ordered.

The get around this problem, I needed to duplicate a situation where I could set the value for the Work Remaining field to 0 and create a situation where the value could not be changed, so I just turn the Work Remaining field into a drop down when the work item is in the Done state and allow only a single value, 0!

It's a hack, but it manages to overcome an unfortunate limitation.

Beat Analysis Paralysis: Don't Let Good Projects Go Bad

2007-09-14T05:29:00Z

Prepare yourself, this one is a doozy.

In a world where software projects commonly suffer from poor requirements, the very idea that a project team can "overthink" requirements sounds absurd. Hey, if it didn't happen would I be writing about it? Very interesting projects with very well-intentioned aspirations have outright failed because it never even got off the ground.

The proper term for this is analysis paralysis, a state in which a project suffers because the planning and requirements elicitation phase is more expensive than the benefit that is derived. This might be because planning takes too long and the opportunity for the project has passed, the personnel cost of the requirements phase exceeds the budget allowed, or some team members are under-utilized waiting for the planning activities to finish.

In the 'real world', what does analysis paralysis look like? Let's see if this scenario rings a bell. So someone super important greenlights project X and the subject matter experts are organized into a team. A 'first' meeting is planned, but the most important planning team members (i.e., the really good ones) are busy because they are wanted in a million other places. Important people are in demand! They decline the meeting and thus, it is rescheduled for a few days later. Planning is a little behind schedule now, but nothing that can't be made up through diligence and hard work.

Eventually, the 'first' meeting actually takes place (yay!) and half of the meeting is spent reviewing some document everyone was supposed to have read before they showed up (boo!). The second half is spent producing results and the citizens rejoice. That said, one important team member, let's call him bigwig A, can't show up because he's really, really busy. Some crises at some client site caused some horrible failure that required his full attention. While everyone else is warm and fuzzy because the team is making progress, bigwig A finally gets around reviewing what was accomplished and identifies all sorts of issues. The 'first' meeting is then held again, rehashing what went wrong in the first...er…I mean second 'first' meeting.

So yeah, I'm sure all sorts of bells are going off. This project is already thrashing and if the trend isn't drastically improved, the project will be paralyzed. So how does this affliction come about? It usually comes in one of two ways, each of which sends a cold chill up my spine.

The first is common in smaller organizations. Most projects have poorly understood requirements. A few of these types of projects demoralize good teams and leadership swears it will never happen again in order to prevent a mutiny. They place a lot of emphasis on the planning process and project managers say absurd things like "My team won't start until we have all of the requirements!" I live in a glass house, so don't worry about the flying rocks. Anyways, now everybody that's anybody is now required to fully participate in some elaborate planning process (in addition to all of their other responsibilities), and the nightmare begins.

The second is common in larger organizations where projects have inter-organizational dependencies. Management and teams are set up in a matrix, and teams are expected to provide resources and expertise to other teams that have specific needs. Some large software project comes along that is being managed by team A, and some manager in team B is asked to provide a resource to help team A. Said manager looks over his roster and identifies a really good resource that will do a great job. But wait! That resource is needed to satisfy team A's responsibilities. After all, he or she is really good at what they do, and team B simply cannot afford to lose them Another resource is selected instead, one team B can live without, and that resource doesn't have the expertise, capability, and maybe even time to provide team A with quality help. Planning starts, team A realizes they have the wrong resource and they have more work to make up for the poor help they've received from team B, and the nightmare begins.

Some champion the idea that bureaucracy is to blame for analysis paralysis, but I think that's just a cover for the real catalyst: poor leadership. Now let me qualify by saying poor leadership can be blamed for all the evil in the world. It's an easy target that makes the masses happy. So we throw more process and more bureaucracy down to cover for this poor leadership, and we find ourselves in a situation where we blame the bureaucracy instead of the reasons that bureaucracy blocks our way.

So how do we prevent analysis paralysis? Do a better job of leading our projects! But that copout isn't enough, so let's concentrate on three major components that can help your project team avoid analysis paralysis.

First, you must manage the resources involved in project planning. Major projects usually require a large number of people to be involved in the planning process, and many of those resources are not owned by the team responsible for leading the project. This situation is precarious because a resource whose time you don't own is a resource you probably don't have. It’s impossible to have the full attention of all necessary resources, so the person managing the requirements phase of the project must clearly communicate the expectations of how these individuals will be involved and, most importantly, there must be real consequences if any resources are not providing adequate value. This can mean different things in different organizations and you can figure out the details.

Even the smartest, most well-intentioned people can be very busy and their priorities may not be in line with yours, so it isn't necessarily only a matter of battling incompetence. It's just that a resource that is unavailable or distracted is no better than a resource that is outright incompetent. In either case, you aren't getting what you need.
Second, someone must lead the planning and requirements elicitation process. Managing the requirements phase and leading the requirements phase are two different things. Managers simply have to handle logistics, track progress, and make adjustments if the project is off track. But some measure of quality must be met, so someone who truly understands what needs to be built should lead planning and elicitation activities.

This person needs to be capable of making hard decisions and mediating conflict. People will have different opinions on what types of things are important in a project and how those things should defined, and many times they will have strong opinions. I'm of the opinion that this type of disagreement can be a good thing for a project, as the end result is usually strengthened by this haggling. In fact, you should probably be worried if this isn't the case, or at least get rid of the redundant resources. You need different points of view, not several people with the same point of view.

A strong leader will foster this type of discussion while making sure the team stays on task. A strong leader will also be able to make a sound, well-reasoned decision if a conflict does not resolve itself in order to move the process forward. Without a strong leader, teams get bogged down and their schedule slips, and this is the first sign of numbness.
My last recommendation is my most specific: teams should employ a Scrum-like model to managing requirements. I've participated in a Scrum project from end-to-end, and some I'm not exactly the biggest Scrum fan in the world (a topic for another day). That said, the model Scrum uses to manage requirements is genius. It is simple, effective, and really hard to screw up if you follow the rules.

In Scrum, requirements are kept in a list, called the product backlog. The product backlog lists the requirements with the most important at the top and the least important at the bottom. Each requirement has some weight, being the resource cost expected to implement that requirement. Before each project iteration, take the requirements from the top of the list and drop them into your iteration until you have consumed all of the available resources in that iteration. It’s just like shopping. Things have a cost and you have only so much money, so you have to be selective about what you buy so that your money is well spent.

The hard and fast rule in a Scrum project is that once a requirement finds its way into an iteration, it should not change. If it needs to change, that change should be dropped on the product backlog as a new requirement and managed as such. The requirements team, or anyone in the organization for that matter, can add requirements to the product backlog at any time. However, only project principals should be able to prioritize the product backlog, and this prioritization should take place before the beginning of each iteration.

To manage requirements using the same model that Scrum employs, you must be develop your software using fixed-length iterations and you must right-size requirements so that they are always smaller than the total resource allotment for an iteration. That's it.

How does this prevent analysis paralysis? I'm glad I asked.

Managing requirements in a product backlog prevents analysis paralysis by creating a situation where the design and construction phases of a project can move forward before requirements elicitation is complete. The most important components of a software project are the easiest to identify and define. It's the peripheral components that tend to send a project on a tangent. Once enough work has been identified to cover an iteration, the development team can cut loose.

The Scrum requirements management model keeps the requirements and planning teams, and all stakeholders really, involved in the project from start to finish. The waterfall model of requirements gathering that so many organizations insist upon will be gone and you will now have a project that is effectively agile, in that it can effectively accommodate change

That's enough of a drubbing for one post, so I'll conclude things there. Just know that how one manages the requirements and planning phase of a project is critically important to the success of a project. I wouldn't prattle on about it if I didn't think so. If you want to learn a little more about scrum then you can find a lot of great sources out on the great interweb. To keep this relevant to Team System, there are a couple of Scrum-based process templates available:

Conchango Scrum Template - I've worked on a project that employed the Conchango template and while there were a few things I didn't like, they were a lot more about Scrum than about the Conchango template. One warning, the process guidance teaches you a lot more about Scrum than it does about the process template that is provided.
Microsoft eScrum Template - I haven't taken a look at this Microsoft-provided template yet but I have heard good things from people who know what they are talking about. I'll take a look soon and give my thoughts in this space.

Tracking Project Status - Quit Making This Difficult

2007-09-07T17:44:00Z

"What is the status of the current project?" This question haunts the dreams of project managers. We give answers like "we are on track", "we are 60% there" or "hold on I'll go find out". Too often, these statements translate into "the team will work ridiculous hours to make up it look like we will ship on time", "here is a number I just made up that 'feels' right", or "I will go ask the developers to make up numbers that I'll pass along, but I'll pass them along confidently". As a whole, project teams are not very good at tracking progress in a meaningful way and, in turn, we aren't very good at managing software projects. As the great Steve McConnell points out in his book Professional Software Development, at least 50% of software projects are late, over budget, or under scope while 25% fail outright, and one of the chief culprits is the inability to identify project challenges until it is too late.

The rate of project failure is really astounding if you think about it. The primary purpose of a project manager is to track progress and handle the logistics that promote and impede that progress. If we can't adequately assess project status, we aren't doing our jobs. Yet, we get caught up with all of the other rat killing implicit with managing a software project and take our focus away from the primary initiative. Projects are challenged and we don't figure this out until those challenges have snowballed. The result? Projects fail.

But hey, tracking the status of a project in a meaningful way is hard, right? I don't buy it.

The key to managing the status of a project lies in how each individual project task, some unit of work that has a well-defined output that contributes to project completion, is managed. A project is simply a collection of tasks. These tasks have to be well understood so that we understand the impact the completion of an individual task has on project completion. Unfortunately, this never seems to be the case. Let me give you an example of what I mean.
I've worked on projects where it was not uncommon to get three tasks for a month's worth of work. Task 1 would be something pretty small. It might require a couple of days to finish if I loaf, or a day to finish if I hustle. Task 2 would be something a bit bigger, maybe requiring a week's worth of work, but it would still be fairly well understood. Then there would be task 3, a blob of a task so poorly defined that no one could reasonably say when it could be done and often it would be impossible to say what 'done' even meant. I could say 'this will take me a month' or 'this will take me 2 hours' and nobody would even bat an eyelash.

So a week later, I might report to management that task 1 was complete, task 2 was 90% complete, and I'm about 25% of the way through with task 3. With task 1, one could reliably assume that a contribution to the project's overall success had been made. It was done. I had washed my hands of it. The ball is now in someone else's court.

With task 2, 90% is obviously made up, but it's a number that adequately expresses that the bulk of the work has been done. Sometimes that last 10% can really stretch out, but when I say I'm 90% done, I'm at least putting my own neck out there to say task 2 will be wrapped up soon. If I don't deliver soon, I'll look bad and I definitely don't want that.

And now on to the albatross that is task 3. What does 25% mean? In Trent-speak, it means I've looked at it and maybe even created a few stub classes. However, don't bother assuming I'm anywhere near being done, as I still have a lot of waffling room in that remaining 75%.

So it's reported up the chain that I'm almost done with 2 of my 3 tasks and that the last item should be done 'soon'. When pressed, 'soon' is usually explained with a made up date optimistically based on the perceived quick completion of the first two items. When this occurs, the project is already in disarray.

Experience has probably bludgeoned most of us with this scenario more than once, so it has to be more than a unique phenomenon. So what do we do to get out of this hole? It's simple: put together a plan for tracking status and follow it. Be disciplined. Notice, I did not say run out and buy some snazzy tool. A tool is not a solution. A hammer doesn't do anything unless you swing it. It's not that great project management tools don't help, it's just that a project can be managed with the best tools money can buy just as poorly as a project managed using no tools at all.

The key, as hinted in the example I gave earlier, is in how we track individual tasks. This involves being methodical in how we break down tasks and in how we assess task completion. Your project can be vastly improved if you just follow this set of guidelines

Tasks should be broken down into units of similar 'weight'. This means that the effort required to complete tasks should be as similar as possible. If tasks are all similar in size, the effect of completing a task will be universally understood in terms of how it affects the status of a project.
Tasks are either done or they are not. The idea that a task is 'half done' should be stricken from your organization. It's all or nothing. A task that is not fully complete does not contribute to project completion, so quit pretending that it does.
Tasks should be small. I strongly recommend that tasks be expected to require no more than a day's worth of a given team resource. This will allow you to get a day-to-day understanding of the current status of a software project. Additionally, breaking tasks down to a more granular level improve estimates and make sure developers are somewhat detailed in their design.
Tasks should always represent a unit of work. Never break tasks into a sequence of steps. This means no tasks like "Implement feature X - day 1" and "Implement feature X - day 2". I've seen trolls like these before and they are utterly useless. How does one know when the first task is complete? It's usually when the estimated time given to that task has elapsed instead of when some meaningful work has been done. Avoid this at all costs.
People should not do any work that isn't fully described in a task. This will help the team clearly understand why a project might be challenged because you will have immediate visibility to whether new work is being introduced and what kind of work is being done. Is a project challenged because our estimates were bad? Is it because the problem was poorly understood? Is it because work external to the project keeps stealing resources? You will be able to clearly answer these questions with hard evidence.

These guidelines are simple and effective. They just usually require a level of effort during the design and planning stages of software lifecycle that most haven't been disciplined enough to invest. They are in too big of a hurry to lay down code for fear that every second someone isn't coding is a second the team is behind schedule. It's just a thorny problem (affectionately coined by McConnell as WIMP, or Why Isn't Mary Programming?) we have all fallen prey to it at least once.

Requirements Make My Head Hurt

2007-09-06T04:19:00Z

In my experience, when challenged to improve the quality of their software development efforts, so many software companies put excessive focus on software process methodology. They read about Agile, Scrum, or some other flavor of iterative development and convince themselves that implementing some specific methodology is going to 'fix' their problems when their primary problems aren't process at all but instead center around their inability to manage requirements and track project status.

For now, let's focus on requirements. Every software project, no matter how large or small, is catalyzed by a need. This need is elicited, described, and organized formally or informally into requirements. Then those requirements are communicated to a development team responsible for actually producing something tangible via a specification. Unfortunately, a specification usually is a set of documents that read like a drunken stream of consciousness or a set of vague statements someone threw onto a paper to check off the 'we have a specification' box.

I'm nice in saying that this specification inadequately describes software that needs to be built or the modification of existing software, but improving the specification itself is a subject others have written about more intelligently than I ever could. My focus is on what the development team does with that specification once it has been inherited. Typically, development teams just run with whatever they receive regardless of quality (because taking the time to fix things would take too long/don't fit in the schedule/insert lame excuse here), confronting this lump of a specification in one of two ways. Should the schedule be tailored to fit the requirements as they are? Or should requirements be right-sized to fit the iteration plan (you do have an iteration plan, don't you)?

Resources are finite by definition, so it is imperative that requirements be structured in a way that lends them to be managed. This means the project team should work with the person or team responsible for the requirements and mold them into bite-sized chunks. Bite-sized chunks can be scheduled, tasked, monitored, tracked, and managed. This process of organizing requirements is given far too little attention, and I would argue, at least where the development team is concerned, it may be the most important part of the requirements phase of a project, and potentially the most important part of the project altogether. Without properly organized requirements, a team has very limited means by which to manage the scope and quality of a software project. If the project scope and quality cannot be managed, odds are the project will fail.

I believe a few rules of thumb of how software requirements are organized can go a long way towards properly managing a software project:

Requirements should not be too technical or architecturally focused. Many software projects will have requirements such as 'Create Data Access Layer' and 'Create Business Objects'. This is inappropriate. Requirements should illustrate a business need.
Requirements should be relatively comparable. Ideally, you should be able to say some requirement X is more important than requirements Y and Z. This is critical when it comes to scheduling work and managing scope.
- Requirements that are tightly-coupled should be combined into a single requirement. Resist splitting a large set of tightly-coupled requirements if at all possible, and only split them if the methodology being employed provides no alternatives.
- A large requirement that, when analyzed, is really a laundry list of needs should be split. If a project team is forced to trim scope, it will be easy to figure out what can be trimmed if requirements are organized into a reasonable level of granularity.
Requirements should not, in my opinion, be separated by type (as some Agile pundits might argue). Consider the MSF for Agile process template that ships with Team Foundation Server. There are two requirement-like work items: Scenario and Quality of Service. A Scenario might be some business need 'Do X' and a Quality of Service would be 'Be able to do X one thousand times in an hour'. Those requirements are implicitly coupled, so I think the simplicity of managing one requirement makes more sense. Ditch separating qualitative requirements that are tightly coupled with a quantitative requirement. Instead, have qualitative and quantitative descriptions for a single requirement.
To borrow Einstein, requirements should be described as simple a manner as possible, but no simpler than is necessary. Don't get bogged down in describing a requirement in every detail imaginable. You'll never get it completely right up front, so don't be completely paralyzed by the fact that you don't know everything there is to know before you start laying down a design and code.
You should be able to estimate requirements to some level of comfort. If your requirements are so vague that the estimation process would be more accurate if estimates came out of a bingo hopper, you need more detail and more granularity.

A software project that doesn't start organized will never get organized, so give your project a fighting chance by investing in the elicitation and organization of requirements. Your project will be easier to manage and the overall goals will be transparent to everyone involved. This makes for a happy software company where smart people want to work.

For more on software requirements, check out the following reads:
Software Requirements by Wiegers
Managing Software Requirements - A Unified Approach by Leffingwell and Widrig

The requirements phase of a software project is often a combination of sophistry and blind trust, and there is certainly no 'right' way of doing things. I'm sure you have an opinion, so let me know whether I nailed it, I'm off my rocker, or I'm somewhere in between.

So you might be asking, "I get all of that, but where does Team System enter the picture?" We'll get to that in this space before I'm done.

It's about time I got the ball rolling...

2007-09-05T02:19:00Z

I've waited long enough to get things going here, so I figured it's time to say hello and properly introduce myself. My name is Trent and I'm a Software Process Consultant residing in Dallas, Texas. I work for a company called Notion Solutions in Irving, Texas and we specialize in assisting companies all over North America with improving their software process and quality initiatives through Microsoft Visual Studio Team System.

Now that might give you the idea that it is our job to know Team System and TFS backwards, forwards, and sideways, and you'd be right. However, the real value we like to think we bring to our customers is great deal of knowledge and experience about how to manage a software project and really, expertise in all facets of how software is made. My colleagues and I witnessed how a lot of companies manage (or don't manage) their software projects and how they utilize tools and process to improve both how they manage projects and how they write software.

I intend to use this blog to share and explore what I've learned about software project management, software process, and Visual Studio Team System. So if you are interested in any of those things, you should find something of value if I've done my job.

In addition to software process and Team System, I'm also interested in web development and emerging technologies in that space. I'm also into a lot of other stuff, so feel free to wander over to my other website if you want to take a look at what that might be. If you have any questions, comments, or flames, then by all means let me have 'em!