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
No comments:
Post a Comment