Digicorp

This is something I have learned while working for so many years as Project Manager. It is not as important to know how things are done but it is important to know how to get things done. Scrum is an Agile Software Development system which helps developers to get project done in reasonable time and with superior quality.

The most important elements of Scrum are. These are presented below.

Scrum is organized around the following roles:

• Product Owner – Determines what functionality is needed
• ScrumMaster – Leads the Scrum and is primarily responsible for making sure the Scrum process is followed and removing impediments that keep the Team from working
• The Team – Those who do the actual work that translates what the Product Owner has requested into usable functionality

The following is a synopsis of the Scrum process:

• The Product Owner creates the Product Backlog (List of Desired Functionality in the System)
• A meeting is held with the Product Owner, the ScrumMaster and the Team
• The Team commits to getting x number of items from the Product Backlog done in 30 days. This 30 day block is known as the Sprint
• The Team makes a Sprint Backlog (List of items that must be done to turn the Product Backlog items into shippable items during the Sprint)
• The ScrumMaster meets with the Team daily and asks each member three questions:
  • What have you completed for the Sprint in the last day?
  • What will you complete for the Sprint tomorrow?
  • Is anything impeding you from getting your work done?
• The Daily Scrum causes the Team to reveal exactly where it is, or where it isn’t
• The ScrumMaster keeps distractions away from the Team
• The Team self-organizes and keeps the Sprint Backlog up-to-date
• An item on the Sprint Backlog is done when code is well-written, well-structured and thoroughly tested
• At the end of the Sprint, a Sprint Review meeting is held
• Items not completed during a Sprint are allocated to a future Sprint

Other important notes to keep in mind when utilizing the Scrum process:

• Scrum makes a project’s progress and problems constantly visible
• Every Sprint produces an increment of potentially shippable functionality
• Scrum must be put into place before it can be fully understood
• Scrum focuses on what can be done
  • It instills the “art of the possible” and allows work to go forward before things are “perfect”
  • You will never achieve perfection, no matter how much planning you do
  • Sprints are time-boxed to keep the team from searching too much for perfection
  • Focus efforts on a small set of pressing problems
  • Define work that will allow concrete results
  • Planning doesn’t have to be extensive for a Scrum project to get going
  • The minimum is a vision and a Product Backlog
• Scrum is anti-sequential
  • Get going on what can be done
  • Help each other out
  • Collaborate
  • Sequential tasks divide a team
• In Scrum, an estimate is not a contract
  • Scrum expects exceptions to the plan and doesn’t fear them
  • Adaptation is a normal part of the process

Reference : Pinal Dave (http://blog.SQLAuthority.com), Comments from Scrum Team Members, Many Online Resources

One of the inspirations for creating this blog is a wonderful book called “Peopleware” by Tom DeMarco and Timothy Lister which I am reading right now. The book is about creating and maintaining Productive Projects and Teams.

Yesterday I read an interesting chapter called “TEAMICIDE”. It is about making teams jell at your company.

The authors could not come up with “Six things you can do to make team formation possible” so they tackled the problem by the trick called “inversion” described Edward deBono’s Lateral Thinking.

“Inversion” is a technique to achieve your goal by looking for ways to achieve exactly opposite of your goal. This helps in clearing brains cobwebs which keep you from being creative.

So they focused on six things which will keep them away from creating jelled team. They came up with following

• defensive management
• bureaucracy
• physical separation
• fragmentation of people’ s time
• quality reduction of the product
• phony deadlines
• clique control

I would not go into details here but I can say these are some of most commonly found techniques in all the companies.

I don’t deny that we are not affected by any of the above techniques but fortunately the effect is less and manageable. My personal target is to make sure above techniques are completely removed from Digicorp.

My first target should be to remove phony deadlines from the projects if there are any. This is the most prevalent technique in most of the companies today and I do feel that it kills the motivation of developers to do well.

I would encourage my development team to write something more on this and what we can do it remove this.

I would love to hear from you more on this. What other techniques you think can hamper creating jelled teams?