Here are a few issues and how to deal with them as a project manager for your coding cowboy gone rogue!
Thorny Issue #1: Why do my software releases take 6 or more months?
So let’s say you are working on a software project, defined the requirements upfront, and it still took 6 months or more to get into production. Now how you got here may have varied. You may have expected it to take 6 months, or you may have expected it to take just a few months and things kept getting delayed until 6 months or more elapsed and you’re left wondering what the heck happened.
Whatever the circumstance, 6 months is just too long to get a software project done, I call this the Elephant syndrome. How do you eat an elephant? One bite at a time! Hopefully, you don’t choke…Now this problem may have been caused by staffing or quality issues (we will address those later), but most likely, you bit off more than you could chew. Fixing this is quite easy – instead of trying to deliver a complete software product with all the bells and whistles you can think of, break it down into manageable short releases (no more than 2 weeks in duration) with a specific and pragmatic set of features and scope.
This approach is called an “Iterative” approach to software development, and has been especially made popular by the Agile community. But the truth is that iterative development predates Agile and was first suggested in classic development process work accomplished by Winston Royce in defining the lifecycle that became known as Waterfall. You can also use an iterative approach with Waterfall development (where you fully define all requirements up front, do all the coding, and then do all the testing in a staged approach) or you can use Agile development (where you set a specific time period for your software development and testing and only do the things that fit within that window). In my personal experience, Agile development lends itself nicely to solving this problem (iterations are called Sprints) but it can certainly be done with an iterative Waterfall approach. Its common sense – undertake less work and gets done quicker.
Thorny Issue #2: What things should I attack first when planning an Iteration?
So you’re on board with limiting the work but let’s say you are worried about delivering something that is useful. Well let’s take an example. Let’s say that you are building a Contact Management software that is used to track customer and sales contacts. When you start planning out the software, you can quickly get overwhelmed with all the features and functions needed to pull this off.
I can just imagine your wheels turning. I’ve got to build a security system, contact listing, contact maintenance screens, reports, dashboards, email functionality, import and export features – the list goes on forever. Stop stressing! In the first iteration (or sprint), just build the contact listing and the ability to add or edit a contact. Forget about security, auditing, ability to delete contacts, yada yada -- just focus on the bare necessities. The juicy stuff can come later.
In fact, you may even be inclined to start gold plating the contact listing. You might dream up ways to allow in-place editing, print preview, file attachment capabilities, and lots of other bells and whistles. Those are all cool ideas, but let the features materialize in future iterations. If you are developing this for internal use, your team could actually start using the bare-bones model after the first iteration – allowing you to start getting some im- mediate return on investment and, more importantly, feedback from your customers.
Thorny Issue #3: Why are my programmers always running behind on their deliverables?
This can be caused by many issues; I will talk about the common ones. First off, who is estimating the work, the project manager or programmer? If it is the project manager, that is your first issue. You should always allow the programmer to estimate their work because they are more intimate with the essential things that have to get done for each programming task.
OK, so you say you’re programmers are estimating and they are still running behind. At this point, we need to dig a little deeper. Are the requirements properly defined and did the programmer take the time to put together a design when doing the estimate? If not, they are probably under-estimating because they did not decompose the requirement into low level design tasks needed to fulfill the requirement. The more you know about design, the better you can estimate.
Another common issue is scope creep. You start off with a design, start coding and someone comes up with some cool enhancements to the feature you are working with and you try to fit that coolness into the same schedule. If that happens, you need to re-estimate the work based on the new features to ensure that it will still fit within your time constraints, and if it won’t, you will have to let the cool feature wait.
Finally, some people are not very good at estimating tasks. You have optimists that like to think they can get more work done than they really can (I fall into that category), and some pessimists that sand bag by putting these really huge estimates out there to cover their butts. Both of these issues are detrimental to a project, so you need a way of determining who estimates well and who doesn’t, and find ways to improve their estimating skills.
Luckily, this is easy to solve. Have each team member estimate their tasks and track their time towards it. Then after the iteration ends, do a variance report (estimate minus actual). You will find that on the first go-around most of us will underestimate the tasks.
Then on your next iteration, collect estimates from each team member, but buffer them by the variance (based on the individual team member) from the last sprint. So if John was 25% under-estimated his aggregated tasks last iteration and he estimates 100 hours for his tasks in the upcoming iteration, make his estimates 125 hours. Then in your retrospective, take the same approach (look at the variances in the new sprint and make buffer adjustments accordingly). Over time, you build a much better estimator and more reliable estimates.
Thorny Issue #4: How can we estimate our efforts better?
Don’t you love it when your manager or customer comes to you and says “I need you to create this [insert product feature here], how long do you think it will take?” As a journeyman, you might say, “Well, let’s see… I think it will be a week of work.” Then you start developing the software feature, the complexity of tasks start to become clear and that week of work becomes a month of work. Once a month passes, your manager and/or customer gets frustrated, you are working your fingers to the bone and everyone is pointing the finger at you because you told them a week was plenty of time. Sound familiar? Shoot me now, put me out of my misery!
This is another thorny issue that can certainly be resolved. The real issue is that when someone asks for estimates without a clear vision of what they want, there is no way to provide them (unless you are clairvoyant and if you are you should be playing the lottery and not writing code anyways)! So let’s fix this little issue. When someone asks that question, simply respond with “Not sure, let’s learn how you want it to work and I can give you a much better estimate.”
Then sit with them and let them explain their vision for the feature. Write down the individual components of the feature (screens, reports, fields of data, important behaviors, fields of information to collect, etc.) Then ask them for a few days to come up with a prototype because you want to be sure that you are both thinking alike in what is going to be delivered. Once you deliver a prototype, lots of things will come out. Oh, we forgot this and that, what you are showing me missed the mark, I really like the way you decided to handle this and that, etc.
Then make changes to the prototypes to ensure that it accurately reflects what they are expecting. Drill into what they are expecting in terms of field validations (e.g. can we enter a date from the past, can the numbers on the screen contain commas and decimals, etc.). Ask if they want all data changes to be audited and if there is anything else they are not telling us that is important to them. Then finalize the prototype with all the assump- tions and ask for their approval to create an estimate.
At this point you have a good set of requirements. If you are using Agile, this might be a compilation of user stories, but no matter what you call it, you have defined enough detail to provide a much better estimate. The next step is the most important, roll up your sleeves and figure out every task needed to complete this requirement.
Let’s take an example. Let’s imagine that cool new feature the customer is asking for is a “bare bones” ability to track contacts (customers and sales prospects). During your discussion, you would ask “what does bare bones mean to you?” Does it mean that we don’t need (at this time) to secure the data in any way? Does it mean that we just need the ability to view a list of existing contacts, add/edit/delete contacts? If the customer says yes, then dig deeper. Ask if you need auditing (keeping track of each field that changes, etc). Ask specifically what fields of information you want to collect for a contact (name, email, phone, etc) and if we need to be able to also send emails to each contact during this phase of the project. Ask what types of validations they need on a phone number, email address, how wide the fields need to be, are they required for data entry, etc. Ask if the list of contacts needs sorting or searching capabilities, etc.
Once done, let’s imaging your clients says “No security and auditing in this phase, a standard HTML listing of contacts without searching and sorting is OK, a standard HTML data entry screen that allows entry of these fields (contact name, email, phone, etc) with these field validations (contact name is required and can be no more than 50 characters, etc), and the ability to edit or delete an existing contact.
In this process, let’s imagine you prototyped 3 screens:
- Contact Listing – Shows a list of contacts
- Contact Add – Allows adding of a contact
- Contact Edit – Allows editing or deleting a contact
From here, you can create 3 requirements from this. Once you have defined your requirements, you can then decompose each one into more specific tasks – allowing you to provide a much better estimate.
Thorny Issue #5: Is my iteration going to complete on time?
So you’ve been a good student, you’ve collected adequate requirements and/or user stories, decomposed your requirements into lower level tasks so that you could provide a much better estimate. You’ve also decided to use a “time box” approach to development where you have set the begin and end dates of the project based on the number of people and hours committed to the project and built in a little buffer for things that go wrong. Well done my friend!
So the project starts and each day that passes you get more nervous that things are not progressing as they should. You start to freak out. How can you know whether you are going to get done on time? Piece of cake! It’s called project burn down, and here is how it works.
First, make sure your time box dates are reasonable. Let’s imagine that we are developing the mythical “Contact Management Software” and we figured out that we have estimated the effort at 274 hours of work. You know that each team member can contribute 32 hours of work a week (80% of the work week), so you set your time box to 9 person weeks (274 / 32 = 8.56 weeks with a single person so you round up to 9 weeks). But you have 3 team members that are going to work on this, so you have time boxed it at 3 weeks (9 weeks / 3 people). So let’s imagine your time box begins on 1-Jan and ends on 19-Jan. The way to determine if you will get done on time is to have your team log time towards each assigned task daily and then re-estimate the effort remaining daily. By re-estimating remaining effort daily, you can quickly see if you are on or off track. Here is how it might look if you are collecting this type of information via a spreadsheet:
So each day you are recording how much effort the team members are saying they have remaining to do for each task. We also created a burn down graph that shows daily progress against plan, so in the graph, if the ac- tual line (blue line) starts to creep above the red line (baseline), you are slipping and you should either have your team work more hours, pull back on any non-critical requirements, or get more team members if you want to stay on time with the delivery. Using a spreadsheet for this is not really optimal because it means that someone on the team (normally the scrum master or project manager) has to keep this spreadsheet updated daily.