So just one of the benefits from agile is that it has a tendency to bubble up existing issues in your software development process and make them glaringly visible. My opinion is that it does this by focusing your entire development life-cycle into small incremental windows. When you increase the velocity of your development life-cycle into such a short period, you leave no room for inadequate processes. The scrum process we adopted at Mercury Payment Systems, for example, started with two week sprint cycles. This allowed visibility of an entire development life-cycle within just two weeks. We quickly identified several areas of our development process that could stand improvement.
One of the mistakes we had made at Mercury was to start our agile process without the dedicated role of a product owner. We thought we could just multi-task key staff members to function in that capacity without the training and passion that a true product management focus can bring. Without the authority of just one person to call the shots, so to speak, product decisions quickly got tied up into group debates. This slowed down our velocity and also introduced conflicting requirements that sometimes clashed with the greater picture of the overall company vision.
It didn't take us long after implementing a product owner role to see the benefits of a more highly focused product vision. We had a clearer overall picture of where our product was intended to evolve and what the user looked like. This helped tremendously with solving conflicting requirements and made decisions easier but somehow still did not improve our scrum velocity.
We found that epic user stories were coming into sprint planning sessions and with very little design or architecture discussed. Software engineers spent a fair portion of their sprint capacity acting as business analysts (BA). While I'm sure some agilists will profess that this is the beauty of agile and that it is more advantageous to put each developer directly in front of the customer for BA type functions, we found the consistency to be greatly lacking. What was also uncovered by having these epic requirements being architect-ed in the sprints, budget roadblocks were often stopping the sprints as IT purchasing needs were uncovered. Or worse case scenarios were sometimes occurring in that technical debt was being chosen as quick solutions to get around budget or time constraints.
What agile bubbled up to us next was the discovery that not all software developers make good business analysts. While one team produced good velocity and rock solid design and architecture, others spun their wheels almost an entire sprint to get requirements designed and clarified and even then sometimes missed the conformance. For those of us with experience in waterfall methodology, we remembered the benefit that came from a strong business analysts. In my experience, the ones that I found the most successful were those that came up from a development background and had strong design and architectural skills. It was never an easy task to also find those skills coupled with a strong business understanding and capability to translate business needs into technical specifications and vice-versa. But how do you bring these roles into an agile scrum methodology?
Keep following and that is where we will pick up next.
No comments:
Post a Comment