"Well at first you will be blasted with...er...nothing, if you work in an RUP environment off course"
In the past I worked for a company which mainly followed RUP. We were a small Scrum organisation of about 50 people in a large top notch RUP organization. The whole RUP process mixed up with budgeting schedules and bureaucracy can turn into something pretty challenging for a small Scrum Team. Everything moves really slow, until top down command gives a corporate Go decision!
I was playing the Scrum Master role and had a ridiculously hard deadline. We had around 400 hours of estimated work and around 10 days with 3 - 4 resources! These estimates were by no means conservative. There was truly a lot of work to be done!
I had a meeting with a few stakeholders before getting this project started. I remember them saying - "We'll probably get half of the work done based on the estimates, so do your best". Deep down inside I knew that was BS, I knew all of it could be completed :)
First thing I did was met with the PO, did some Agile Release Planning and gathered some user stories and prioritized them. After the priority was clear, I wrote down user stories with the PO, and broke them down into smaller chunks with the Team and estimated them in Fibonacci series complexity points. We used ScrumWorks by Danube, to store all our User Stories and track our Sprints.
Next I did the Sprint Planning with the Team and committed to a bunch of stories for a 1 week sprint. We planned for around 1 hour which is appropriate for a 1 week Sprint. I knew that we literally had 10 working weekdays to get all this work done. I had no idea "How" we would get it done in 10 days days but had a huge amount of hope that using Agile practices like pair programming and smart programming techniques we could speed up productivity.
We started the work with 3 developers. 2 developers paired up on one huge feature and the other focussed on the lower priority features. As the developers paired up they realized that if they designed the system so that it could be reusable, they could save a whole lot of time. Although pairing up took 2 resources' time everyday, within 2 days they came up with a working app with a framework which could be re sued by the other developer working on the lower priority stories.
Thanks to code res-usability, swarming, pairing up and collaboration we realized that our estimated work could be completed in 1/4 of the time. Along with constant collaboration with the PO, we came up with a working app within around 7 days with some extra effort put during the weekend to avoid any disasters.
This over all experience was extremely rewarding and it taught us a simple thing, that "awesome things can happen while being agile".
Observations:
Customer commitment and collaboration was key. A PO ( who was also a SME) was necessary for this to be successful.
Knowing the priority of the Backlog was probably the most important thing in terms of heading in the right direction.
Pairing up helped in sharing of source code knowledge of utility classes and methods written by respective developers. Pairing up helped the developers come up with a reusable solution together sooner than if they had work on this alone.
Managerial support helped as lot. Obstacles were identified as soon as they seemed to appear. For eg. a dependency on the test data generation team was identified earlier on, and a commitment was asked for from them beforehand.
Face to face communication and collocation saved a atleast a weeks worth of time.
No comments:
Post a Comment