"Developers can't think! they need to be told what to do, they are mostly Junior, they do not know the application, it's the first time they work here !"...
I still have to see a developer that found use for an analysis done before the beginning of a sprint.
If you were using any waterfall approach to projects before introducing Scrum, there are chances that you have been submerged by analysis.
Analyst love to create large amounts of lengthy documents with a lot of fancy screen shots and things that they thing business (might) want.In a very small number of cases, you even get to see some UML modeling, diagrams, charts and whatnot. In most cases the analysis were simple "copy + paste" of the business requirements with 2-3 added details.
How do the old fashioned analyst become an "Agile Analyst"?
First of all, by dropping the amount of documents written upfront.
There is no need to have huge documents that finally say nothing, get rapidly outdated, and that at the end do not reflect exactly what the application is doing.
As you know, user stories must express what business wants, and the acceptance criteria should sort out any doubts that the title of the story might bring, usually, if well written, user stories are enough to start working without any previous analysis.
So, why not involve the analyst in the creation of the stories? Some of you might disagree, but I found that having an analyst helping the Product Owner in writing stories has an extremely important added value: The analyst knows the application and/or the enterprise context, (s)he can guide the Product Owner buy telling what is possible, what is complicated, and what is not feasible in the way intended by the PO. The analyst can also make the Product Owner avoid pitfalls for what he thinks is the "perfect" solution or because he might have forgotten important things that the application must have to provide the highest level of user experience.
We have the stories, so what does the analyst do during the rest of the project? Easy: ease developers' work!
In most of the large corporations you are bound to find very complex architectures, with a lot of interconnected systems, back-ends and whatnot. The analyst can play a vital role in clearing the way for developers, by finding out where they need to go to find the information they need for the application, by finding out how to call it, and even taking care of administrative tasks, such as requesting access for these back ends for example.
The time the Analyst is not busy doing this "research" work, could be spent by writing documentation, but not the usual documentation, instead, writing relevant documentation, such as what other systems your application is connecting to, why is it connecting to these, etc... As the analyst is writing this as the sprint progresses, you are much more certain to have adequate and realistic documentation than if it was written up front. Also, application manuals could be written by the analyst at this moment, something that the users will certainly appreciate!
Scrum holds a place, a very important one, for the analyst. Using her/him wisely might make the difference in delivering the story points you committed to at the sprint planning or not reaching your goals.
No comments:
Post a Comment