SCRUM - Agile Methodology

Initial Experience

I've been intrigued about Scrum since I ran across a research paper describ...
I'm also looking to begin introducing Scrum via local training and speaking
engagements. If you have a project that you'd ...
   •   http://www.podscope....
processes, rewards & recognition, performance review & salary increases &
promotions, performance actions (improvement and...

Do I go ahead and let him measure something to m...
Upcoming SlideShare
Loading in...5

Scrum Experience And Links Abdullah raza lakhan


Published on

This is Agile Scrum Introduction

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Scrum Experience And Links Abdullah raza lakhan

  1. 1. SCRUM - Agile Methodology Initial Experience I've been intrigued about Scrum since I ran across a research paper describing it in the mid 1990's. It seemed that a few folks, Ken Schwaber, Mike Beedle and Jeff Sutherland were experimenting with a new way of operating technical teams for software projects. I was very much intrigued by the process and my perceptions of how it might operate and improve some of the systemic problems I'd been experiencing in my own projects. Fast forward a bit... Around 1997-98, I was working on some challenging software projects. One of them was a project focused on upgrading a great deal of our existing software product architecture and interfaces to be more current and competitive. The target for the project was to demonstrate our efforts at the leading annual trade show for our industry in North America. Of course, this was a "real" fixed date project. We applied some unique approaches to this project effort (at least unique in our domain). For project planning, we leverage a great deal of collaborative planning with the entire team, using sticky notes, team prioritization, etc. We also had a full- time customer (representative) with us for the duration of the project. In many ways we used some of the planning and customer interaction bits that are so effective in XP and Scrum. As we approached building our first "iterations" of software, we began cross team integration of our deliverables. This had a strong testing focus, but included team members from every function. We used a Scrum-like daily meeting with their Q&A format. We also had Agile "information radiators" for issues, next steps, key accomplishments, etc. in our project meeting area. The short version of the story is that (A) we nailed the software for the trade show and blew away the competition with our product future shift. And in the project retrospective, we (B) the team felt that the #1 reason for our success was the Scrum team patterns of daily meetings, team cohabitation for integration, cross team reporting and team collaboration towards a unified goal. I've since completed a book on Software Project Endgames, and these techniques have become one of the powerful tools that I use in as many Endgames as possible to increase our probability of success. Certified Scrum Master I've recently (September 2004) been through the Certified Scrum Master course and am looking for opportunities to begin implementing Scrum practices more holistically within software projects.
  2. 2. I'm also looking to begin introducing Scrum via local training and speaking engagements. If you have a project that you'd like to try Scrum on OR if you'd like to learn more about it, simply contact us - Core References • Agile Alliance • Ken Schwaber's ADM central Scrum site - • Scrum Gathering - • Mike Beedle and o o • Boris Gloger - o • Jeff Sutherland's Scrum log - • Certified ScrumMasters - • Mike Cohn has a wonderful "portal" for Scrum - o • Linda Rising IEEE 2000 article - • Jeff Sutherland (SCRUM) • Bill Wake's "Scrum on a page" - dev.pdf • (SCRUM +XP) • Yahoo group for SCRUM - o (Newsletter derived from the Yahoo group) o o o o • Scrum Tools - o, o o Microsoft Project, Scrum tool - familyid=81daab54-6701-4fbc-b3d0-7f261383f371&displaylang=en o • IBM - RUP article - feb05/krebs/index.html Podcasts & Other References
  3. 3. • • • • (Scrum Podcasts) • (Discuss various methodologies) • Beyond reading any introduction on the above websites and the two books by Ken, I would recommend joining the Yahoo group as a starting point for gathering more information. There are some lively conversations and the discussions normally cover beginner to advanced topics in parallel. It's a safe collaborative learning environment! Scrum Team Collaboration Demo: Share-Point Tiran Dagan from has setup SharePoint prototype for a scrum site located at: for demonstration purposes. If you are asked for a username, enter: guest@6footmedia with a password of demo1234. The overall site is an example of how you can provide scrum information to the team or other "chicken" in the company. To see the team collaboration area, go right into the "SCRUM Room" section (on the top nav bar) or go to: Please use IE 5 or newer. Toggle the "discuss" button (yellow note on the main IE toolbar) to see my comments about the pages, especially when you are in the "SCRUM Room" page. The entire sharepoint site template is available for download from the home page ("Download STP" in the quick launch bar on the left). Use it to create an identical sharepoint site on your company's server. I am working on documenting the web parts you will need to make it work. Comments to - Personal Observations of Scrum There are a few general observations to immediately make. I like the Scrum model and the Agile philosophy of empowered and independent teams. It makes a lot of sense to me - always has and always will. I've not fully deployed Scrum (yet), but I've seen these practices contribute to some of my greatest project experiences and successes. However, Scrum fundamentally changes the management dynamics of software teams. It changes the manager's role and all aspects of traditional management - HR
  4. 4. processes, rewards & recognition, performance review & salary increases & promotions, performance actions (improvement and firing), team conflict resolution, team building, employee development and training, etc. are all basically not covered. It also doesn't cover how to effectively deploy parts of Scrum into organizations. Entry is usually couched into a hypothetical organization that (1) understands and (2) is totally receptive to Scrum. Anything else, and the "literature" provides little guidance. Even when "listening" to the Yahoo group, a great resource BTW, most discussion is Green Field based and not helpful to those encountering resistance or trying to map it into an existing command-and-control organization that will not fundamentally change overnight. I think this is a real shame. While on the one hand, I can understand why folks are so focused on the principles and don't want to compromise, a good dose of reality in deployment can't possibly hurt. I want to use this space as a mechanism, over time, to explore the softer side of Scrum deployment and expanding upon some of the above points. Agile deployment strategies are key to its mainstream adoption and growth. Look for more later... Scrum within a Test Context I've been informally using Scrum within a testing context for a number of years. You'll also see references to it in my Software Endgames book. I find the simple practices wrap quite nicely around testing activity - independent of development methodology used. I've developed a presentation around this and am sharing it at Star East 2005. I'd love to get feedback on the presentation details and drive further conversation. Look for more later... Agile Performance Management These comments are from an exchange in November 2005 between Brad White & Michael K. Spayd. We've been doing scrum for about a year and it is going pretty well. One issue we've had has been compensation. I'm after my boss to increase pay so we can hold onto people longer. In response he wants to implement performance based pay. Pay people a base salary and then on top of that for meeting certain targets. My position has been that there are no metrics that can drive good software. All the things you can measure are objective and quality software is subjective. Now he reads this about Travelocity
  5. 5. Do I go ahead and let him measure something to make him feel better and try to not let that impact the quality of our work? How would you approach it? And Michael's reply... At my current client (large Fortune 500) doing a enterprise-scale Agile implementation they are currently grappling with performance metrics as the end of year approaches quickly. They are quite individually oriented in their ratings system and some of them know that needs to change. If your boss is talking about measuring something like productivity (through points or some measure of velocity) or some supposedly objective thing, that requires caution I would agree. However, most performance management systems have user judgments about someone's effectiveness (I personally do not consider these *subjective* with all the pejorative baggage that implies, but rather individual judgments). If you have a system like that, perhaps the following bullets will help. If ratings were made on the following criteria, that would likely drive the right behavior: • Focuses on delivering business value frequently • Clearly supports the team in achieving its goals; takes personal responsibility for the team's goals • Works collaboratively with others; helps create a team culture of collaboration • Acts as a leader in service to the team as appropriate to their skills without attempting to control others • Makes other team members better through encouragement, support, feedback and mentoring • Proactively solicits feedback from others and uses it to improve their own performance • Provides feedback to others (with their permission) in a constructive and insightful manner • Performs any work the team needs to reach its goals, even outside their area of comfort or expertise • Seeks to gain new skills and knowledge to make themselves more useful to the team • Attempts to see value as the customer sees it I thought this exchange brought to light some interesting points about team management and performance evaluation in an Agile environment. As of late 2005, you see very little