Introduction
DotScrum is a software project management methodology that I developed over the course of time. Simplicity and lightweight with completeness are the ground rules of this methodology. This methodology is suitable for small size startup companies or small independent groups in large companies. This article explains how to execute software projects using DotScrum.
Background
I have been doing professional software development for the past 12 years with 10 years being in lead roles such as technical lead, technical architect and project manager. With this methodology, I am delivering successful projects with satisfied teams and clients for a long time. I have not had a single failed project in years. Recently, I executed a DotScrum project comprising a game server, a game engine, a web and desktop game client and got an awesome raise. :) I hope this article will be of some value to readers. Please post your comments and questions so I could address those issues in the next version of DotScrum.
It is not necessary to understand other agile software development methodologies; however it could be useful if you read an article or two on Scrum and agile software development techniques.
DotScrum Basics
So it all starts with a project with zillions of features, lots of complex UIs and background processes. And those features have be delivered on various platforms from handheld mobile devices, Vista and Windows 7 desktops to Windows 2003 servers and Linux apache hosting PHP pages. DotScrum understands that, so it focuses on project features, timing, team members and positive interactions with client. The following sections list some of the key focus areas of DotScrum.
Release for Quality Assurance Daily
DotScrum project planning is done in such a way that a daily build is released for Quality Assurance. This makes creating and packaging a new release no big deal. We usually release the daily build at 3:00 pm. This makes it easier for developers and designers to straight up everything before release time. Early morning like 11:00 am releases are not as stable as 3:00 pm builds. Similarly late evening releases like 5:00 pm do not give testers enough time to smoke applications and comment about the quality of the release before the day is closed. With 3:00 pm release, everyone knows what to focus on the next day before the day ends.
Sometimes we release two builds daily one at 3:00 pm and another at 5:00 pm. The 5:00 pm build solves issues that could be fixed quickly. But this usually happens twice in every 15 day plan.
Release for Client After Every 15 Days
DotScrum project planning is done in such a way that a build is released to the client after every 15 days. Every release is more mature as compared to the previous one. Either new features are added or bugs are resolved. Obtain client review in the form of PDF or WORD document or may be provide an online bug tracking system. BugTracker.NET is a free and easy to use issue tracking system. Download it from here.
How Analysis Works In DotScrum?
The key is if you understand the problem better, you could solve it better. All DotScrum documentation is based on the grounding principal of "Stay simple. Keep your tone simple". For all complex problems, there is a simple solution. Divide the project and team into manageable groups to achieve this simplicity.
In all DotScrum projects, the analysis continues during the life time of the project. The following documents are used to precisely write requirements:
- Project Specifications Document
- Questions Document
- Feature Specification Document
Analysis Document - Project Specifications
The first document that you write in DotScrum project is Project Specifications document. It is basically an overview, scope and boundary of a project in plain simple words. It has few diagrams that clarify how various parts of a system will be deployed and interact. Please download the document set now to see how the template look likes. It is named Project Name Specifications.doc. This template worked great in web projects, engine development and other complex projects. So do not underestimate its usefulness in the kind of project you are doing.
Analysis Document - Questions
If there is something that you have to ask other teams or clients, don't just throw an email - Write a document. Remember, poorly documented questions are answered poorly! Have page numbers to discuss page number on phone, emails and chats. Have headings for similar reasons. Please download the document set now to see how the template looks like. It is named Project Name.Module Name Questions.doc.
It is important to specify the purpose of the document in the very beginning. Have the Introduction section in all documents even the informal ones to let the other party know what the purpose of this communication is. Documents are like normal conversation, they have a start (grasping attention by saying Hello), middle (real purpose of communication or questions) and an end (a bye not necessary if communication is open).
Few helpful pointers while writing questions. Images are important when asking questions. Explaining questions in accurate terms is important. For example, when asking a question about a Font Dialog->Font Style, use word Font Style and specify where it is on the dialog. Do not assume that the other party knows where it is. It is necessary to be clear to root out confusion. However staying concise, brief and simple should be the number 1 priority.
Analysis Document - Feature Specifications
This document is an input to a developer. It should be short and simple like all other documents. Following are some guidelines to write this document.
- If feature is some User Interface
- Draw UI for example using
- WORD or
- Visio or
- Embed/refer to some HTML page or
- Include/refer some sample application showing form
- Include/embed Access forms
- Explain business logic of each UI element
- If feature is a background process, explain
- How the process will start
- Frequency of background process
- What business logic process will execute
- How it will end
How Planning Works in DotScrum?
While the team is doing analysis, it is also working following planning documents. Planning document list what features are completed, what are in bug fixing state and by which date they will be completed.
Planning Document - Team Member Project Plan
In DotScrum, we do not write one gigantic project plan. We do have a master project plan, however each team writes its own plan for the next 1 or 2 months. A project template is named Employee Name.Project Plan.mpp in document set. It is a Microsoft Project document. In the project plan, a team member lists key activities for a minimum of next 15 days. Consider a sample project plan below.
- Note that a full day is allocated for planning and understand features and bugs in hand.
- Only 100% understood features and bugs are included in the current period project plan. If some feature or a bug requires questions from client or other teams, it should be removed from the current period and pushed down for next releases. Another 100% clear bug or feature should be moved up in the current period. This strategy removes chances of stale time in the current period. Developers could work on completely clear bugs or features while questions about wage areas are being answered. To move things up and down, it is necessary to have time estimates of next 3 or 4 releases are ready. DotScrum promotes notion of planning ahead to have a plan of next 3 or 4 releases ready.
- The most important features should be developed first and most critical bugs should be solved first. A features or bug resolution that delivers the most business value to client is most important/critical.
Planning Document - Project Contribution Sheet
Another aspect of planning is to view "completeness of system" as a whole and contribution that each team member made to bring project to maturity. DotScrum has a Project Contribution Sheet to address this area. A template is named Project Name.Contribution Sheet.xls in DotScrum document set that you downloaded.
Planning Document - Release Notes
A release note lists bugs fixed and new features added in a particular release. This document is sent to the client with every release. Release is a result of all the planning you did so release notes roughly come under the category of planning document. A template is named Project Name.Release Notes.doc in the DotScrum document set.
Planning Document - Resource Sheet
A resource sheet lists key strengths and weaknesses of each employee. It also lists each employee's progress against company values. A template is named Project Name.Release Notes.doc in DotScrum document set.
How Time Management Works in DotScrum?
Accurately reporting time is a key to client satisfaction. Also clearly stating public holidays, short leaves and paid holidays helps employees to plan for vacations. Please see the following document templates to understand time management:
- Employee Name.TimeLog.txt
- Employee Name.Timesheet.xls
- Holiday Calendar.xls
- Leave From.doc
- Your Company Name.Timesheets.xls
How Interviews Work in DotScrum?
Hiring the right people and building a motivated team is a key to successful project execution. Please see the following document templates to understand interview management:
- Designation Name.Job Post.doc
- Email Template Interview Call.txt
- Interview Sheet.xls
- Designation Name.Interview Test.doc
- Designation Name.Interview Test With Answers.doc
- Your Company Name.Values.doc
- Your Company Name.Benefit.doc
Points of Interest
I ran DotScrum projects in various companies both small and large and got a reaction of Wow, outstanding, awesome!!! and salary being doubled. :) Some companies that I worked with have no software development process at all while others were ISO 9002 certified and at CMMI level 3 but they all reacted in the same positive way. Few clients and team members even got a heart attack. :) I wish when you run the show using DotScrum, its magic helps you, your colleagues and clients in the same positive ways as it did for me. Happy coding. :)
