Takeo, one of the Developers on the team, recently got married and he sent the following e-mail announcing it to the team:
Subject: After a few days on vacation ...........
Body: I have a wife now.
Congratulations to Takeo and his new wife!!
All the best
KDiddy
Tuesday, November 27, 2007
Saturday, November 24, 2007
Scrum Adoption Cycle: Getting Started
The Challenge
My guess is that adopting Scrum for us went a lot smoother than one would expect. We had our Sprint 1 even before the product development team was formally trained on Scrum. To most observers there was nothing wrong with our current process - at least there was nothing obviously wrong - after all, our last products shipped on time with acceptable quality. So why the change? Well we had our own share of challenges:
- We could not help the Sales team close deals in a timely manner. To get any new feature implemented, in response to the competition, they simply had to wait for the next product cycle since we locked down on the feature set for the current cycle.
- The big bang upfront planning we did meant we wrote functional specs, cost’ed the features, prioritized and dropped features based on priority/cost, updated our project schedule and finally on to implementation. Can you spot the problem with this process? Lots!!
- Most people outside the product development team had little visibility into the software until much later in the cycle, typically during our bug bash therefore we got little or no feedback until late in the game.
Change Agent Prepare Thyself
During the sprint I learned as much as I could about Scrum:
- Read articles on ScrumAlliance website
- Attended the two (2) day Certified ScrumMaster Training
- I read more books, the three listed below where most valuable to me
(Agile Retrospectives: Making Good Teams Great by Esther Derby, User Stories Applied: For Agile Software Development by Mike Cohn, Agile Estimating and Planning by Mike Cohn)
My guess is that adopting Scrum for us went a lot smoother than one would expect. We had our Sprint 1 even before the product development team was formally trained on Scrum. To most observers there was nothing wrong with our current process - at least there was nothing obviously wrong - after all, our last products shipped on time with acceptable quality. So why the change? Well we had our own share of challenges:
- We could not help the Sales team close deals in a timely manner. To get any new feature implemented, in response to the competition, they simply had to wait for the next product cycle since we locked down on the feature set for the current cycle.
- The big bang upfront planning we did meant we wrote functional specs, cost’ed the features, prioritized and dropped features based on priority/cost, updated our project schedule and finally on to implementation. Can you spot the problem with this process? Lots!!
- Most people outside the product development team had little visibility into the software until much later in the cycle, typically during our bug bash therefore we got little or no feedback until late in the game.
Change Agent Prepare Thyself
During the sprint I learned as much as I could about Scrum:
- Read articles on ScrumAlliance website
- Attended the two (2) day Certified ScrumMaster Training
- I read more books, the three listed below where most valuable to me
(Agile Retrospectives: Making Good Teams Great by Esther Derby, User Stories Applied: For Agile Software Development by Mike Cohn, Agile Estimating and Planning by Mike Cohn)
My goal was to help my team to be successful by educating myself so I could deliver the Scrum training they needed and also mitigate our adoption risk. In retrospect, I should have gotten an Agile Coach to get us started.
Get Stakeholders on Board: That is if you want to be successful
In addition, I did a number of presentations to our stakeholders (CEO, Sales, Marketing and Partners) on what they stood to benefit from our Scrum adoption. Also I wanted to highlight their roles this new framework. I believe the key selling points to these group were the promise that we could realize the following benefits:
- Better visibility into the progress we are making in development
- Better responsiveness to Sales requests
- Delivering products that address the key problem areas for our customers today
Ready your team for the change
At the end of the Sprint and before we jumped to Sprint 2, it was time go get the team formally trained. I delivered a half day long training on Scrum to the product development team. The training was largely based on what I learnt from the Certified ScrumMaster training.
Going ahead with Sprint 1 without formal introduction/training to Scrum was an easy call in this case, we used the MSF team model which laid the foundations for our Scrum Adoption. Our feature teams (Scrum Teams) were a team of peers and self managed for the most part so our culture didn't need a significant jolt to get us to adopt Scrum. We pretty much just substituted key Scrum terms for the MSF ones and we were on our way.
Thursday, November 22, 2007
The Memoirs of a ScrumMaster
Weclome to "The Memoirs of a ScrumMaster" (credit for the title goes to Mike Sherman one of the developers on my team). After years of using several different software development methodologies and finally settling for Microsoft Solutions Framework (MSF) and the Microsoft Product Development methology, I discovered Scrum. I had read about Agile software development but never came up against a challenge that MSF did not solve, for the most part, until I came to Vorsite (http://www.vorsite.com/).
The challenges we faced at Vorsite led me to re-examine my thinking about software development. At Vorsite, we actually managed to release our products on time and with acceptable quality (eventually!!). However, I questioned if the final product actually delivered value to customers and the company, did we deliver what customers wanted today versus what they told us they wanted six months ago? How do we make our progress more visible to our stakeholders instead of the status reporting mails we send out?
Eventually, I read "Agile Project Management with Scrum" by Ken Schwaber. I've had the book since 2005 but never had the time to read or just didn't care enough to read it. What I read made sense, so off we go, we implemented Scrum and six sprints later we shipped the first version of our products using Scrum. In the next couple of posts I will chronicle our journey to becoming an Agile software development shop, the lessons learned, how it has changed software development project management at Vorsite, some of the challenges that still remain and how we are addressing them.
The challenges we faced at Vorsite led me to re-examine my thinking about software development. At Vorsite, we actually managed to release our products on time and with acceptable quality (eventually!!). However, I questioned if the final product actually delivered value to customers and the company, did we deliver what customers wanted today versus what they told us they wanted six months ago? How do we make our progress more visible to our stakeholders instead of the status reporting mails we send out?
Eventually, I read "Agile Project Management with Scrum" by Ken Schwaber. I've had the book since 2005 but never had the time to read or just didn't care enough to read it. What I read made sense, so off we go, we implemented Scrum and six sprints later we shipped the first version of our products using Scrum. In the next couple of posts I will chronicle our journey to becoming an Agile software development shop, the lessons learned, how it has changed software development project management at Vorsite, some of the challenges that still remain and how we are addressing them.
Subscribe to:
Posts (Atom)
Posts
