How to Start a Large Software Project With an Agile Development Team

How not to introduce a development team onto a large project

When beginning a large-scale software project, a common mistake for SMBs is having the agile dev team accept a very broad and loose scope for a project which then is translated into user stories by the engineers themselves (wrong) then break those into technical tasks and define UAC. This is backwards from the way it is supposed to be done if they are practicing true agile development, but many times engineering has to fill major gaps in the specifications in order to continue moving forward on a project.

What agile development should look like at the start of a project

Product develops the epic stories (components of the site) and then prioritizes them. Product then takes the top epic stories and works with stakeholders to create the user stories. Engineering can help with this but it's imperative that product & stakeholders see a project as easily definable user stories which describe pieces of functionality. Stakeholders develop UAC (or a checklist of things that need to happen in order to consider a story 'done') and these details are attached to each story. Product prioritizes these user stories in the backlog and then explains them to the development team. From this prioritized list, the engineers begin developing technical tasks and delivering features in normal sprint iterations. Product maintains the priority on user stories and development continues to churn out features. 

With regular grooming, a backlog of technical tasks is built along with story points that the dev team will use to take a stab at estimated delivery of features based on velocity. Product is with development every step of the way to help clarify requirements, make concessions based on feedback from dev, readjust priority, and communicate back to stakeholders & management, etc. They are part of stand-up, retrospectives, grooming, & demos.

The dreaded 'D' word - Deadline

Notice above that only when list of features has been defined and the scrum team has achieved a reasonable team velocity can they start to think about deadlines (I understand this is tough for the business to accept, but think about it.... how can you apply anything but a Super Wild Ass Guess to a deadline until the team has a well-defined understanding of the features of a product along with working knowledge of how quickly the team is proceeding.) 

Agile should be viewed like this: as long as the user stories are in priority order, the business begins to benefit from the first sprint because those features committed to are completed every iteration. This is why the final deadline isn't as important as the team is always working on the most important features to the business. Yes, this is a big deviation from traditional project management, but one which is worthwhile to pursue because you transform from the business holding onto a fictitious and unrealistic deadline which was barfed out to some far away future time towards one which embraces the next features in the pipeline that are instantly usable upon release every two weeks.

If this process is not followed, there will be lots of confusion by the business on what is actually being done, when things will be done, etc. Typically small to mid-sized businesses find it easier to take a large nebulous scope and have people set deadlines based off a gut or hunch and then hold them to it. They deliver a 4 page document along with some unfinished mocks and then "leave engineering to it." This leads to frustration on everyone's part and degrades the quality of the project considerably. Product should not unload a multiple page general scope document on development only to disappear and have expect them to start being "agile", much less provide a deadline. The whole business needs to see the project as iterative development.

Note: I'm not saying that you need every component of the project to be fleshed out in painstaking detail up front. This is a tenet of old-school waterfall project management. All I'm saying is that there needs to be enough clarity by the engineers on how the top priority features should function. Bear in mind that most projects end up looking quite differently than originally intended by the product team. Not only is this fine, but it's actually a good thing. This is how agile helps us meet quickly changing business needs.

For a project to be successful, everyone from the top on down should understand this process and allow it to run its course. I'm confident this can be done even in the most complicated organizational structures, but not without a considerable shift in the way the company looks at product development and execution. The ScrumMaster plays a vital role in the adaptation and evangelism of this process

How Not To Use Velocity

In the agile world, there can often times be nothing more misunderstood than team velocity. As most of you know, velocity is the average output of the team based on the number story points completed across a series of sprints.

For those who are new to agile, all development requests are broken up into deliverable features, called user stories of which each have an associated point value determined by the team. For example, if the team delivers 10 points of work in the first sprint, 15 points during the second and 12 during the third, the velocity of the team by this point is 12 (always round down).

Different teams have different values for a point, so let's not dwell too much on the actual definition of a point, but for the sake of the discussion our teams use:

• 0 pts: trivial task, just pound it out
• 1 pt: uninterrupted half day
• 2 pts: uninterrupted full day
• 3 pts: uninterrupted two days

We know there is no such thing as an uninterrupted day for engineers, so points are just indications of general size. How does one task measure up with previous tasks which the team has encountered? Is it smaller, larger or about the same? 

After a few sprint iterations, assuming your team's criteria for sizing remains constant, your velocity will be a decent indicator of how much work it can commit to for the next sprint. 

Naturally, it appears as though there is a direct correlation with points and time so your management group will likely correlate team velocity to efficiency (or lack thereof). This is a very slippery slope that a seasoned ScrumMaster must avoid. Here are some tips to help avoid common pitfalls around people's interpretations of velocity:

Manager: "Why did the team's sprint point output come in lower than the average velocity?"

Remember, velocity is an average and it sometimes takes numerous iterations to get to a useful number. As with every average, there are numbers above and numbers below this line. There are also outliers. It is not unusual for teams to have sprint outputs lower than their velocity. Now, if nothing has changed in pointing the stories or in your team's contributors and you only complete half your velocity you may want to investigate what has happened, but you should be catching these things early and make adjustments as you go.

Management should not be nickle-and-diming the team's velocity, though those who don't come from an agile background will most likely do this at some point. Many from the old school are used to seeing billable hours of work summarized weekly to account for productivity. They like to see where every minute of work is being spent. Beware. This could lead to more questions which don't jive with agile.

Manager: "How can we increase the team's velocity?"

This is a pretty loaded question. For starters it implies that the team isn't doing enough. While that may be a caused by lack of transparency (which is another topic), you must remind them that points are an arbitrary number that are not directly indicative of productivity. If the team catches wind that management feels that they aren't getting enough points completed, guess what they'll do? They'll pad all of their estimations so next sprint they'll come in way ahead of their velocity.

If your process is sound and roadblocks are being navigated efficiently, outside of increasing team resources, there's not much you can to meaningfully increase velocity.

And this is really the entire essence of software development. What do points mean to a customer or internal stakeholder? Nothing. They only care about features and improvements. All that points and velocity do is help us best understand how much can reasonably be committed to. Points give us a general size for a task while velocity provides us a view into how many of these tasks we can complete per iteration. If we're working on the most important features and delivering these every iteration, what does a number mean? Very little.

Manager: "Let's make sure the team commits to the exact of number of points which match velocity."

When a manager approaches the team like this it is another attempt to make sure that developers aren't leaving effort on the table. This is dangerous because it can lead those outside the team providing input on how to best play what I call "Point Tetris" in an attempt to group stories together equaling the velocity.

Remember, the number of the velocity doesn't matter to the end-users; features do. If you are delivering features in top down priority order, nobody is going to complain that the team came in 5 points short of their average velocity. It's imperative that as ScrumMaster you and your business are thinking about software development in terms of features delivered, not story points completed.

Pitfall: Don't ever leave a sprint planning meeting by grabbing stories with just the right amount points matching the velocity and saying "that's it." 

You're forgetting the most important part of each sprint which is the team's commitment. While velocity can guide the team into making an educated decision, it shouldn't force commitment. Perhaps the team feels they can accomplish more features than what matches average velocity. Or maybe less. Either way, it's the commitment agreed upon by the team which provides real value and buy-in. If you try to force the team to commit to something, you've already ruined the sprint. This isn't totalitarianism; there are no executive orders that work in agile. It's freedom of assembly and the right to decide how much the team can do.

If you trust the team to commit to their work load you'll find (as long as they aren't held to the number of points they complete) that they won't sandbag the estimates. Their commitment will mean something to them and they will focus on owning up to their word. 

Velocity is indeed important in helping to estimate how much the team can complete in a sprint as well as how many sprints it will take to finish a project, but velocity is just an average based on estimated arbitrary units of relative measurement. It should never be used to micromanage a development team or worse, individual team members. As someone who has experienced all of the above problems and more in my career, I can assure you that this is a legitimate challenge. It's up to you, as the ScrumMaster, to prevent that from happening.