Tag Archives: Software Development methodologies

Recently, in one of the Project Management conference, i was asked "which agile management tool would you recommend?". As per wiki, Agile Project Management is an iterative method of determining Requirements for Software and for delivering projects in a highly flexible and interactive manner. It requires empowered individuals from the relevant business, with supplier and customer input. Agile methods are becoming increasingly popular among software companies today. Agile Methods have proven that the best way to develop various software projects with accelerated software development. Increased productivity, reduction of off-shore risks due to customer collaboration and ability to absorb changes in requirements are only some of the important benefits of using agile methods. SCRUM is one of the several software methods derived from Agile Management. SCRUM is all about direct communication and fast, creative decision and control. Lean software development is a translation of Lean manufacturing and Lean IT principles and practices to the software development domain. More info on Kanban in the upcoming posts.

Well, the answer depends upon size, complexity, team location and budget of the company/organization. For each project type, or business environment we need to adapt or choose the tool that best fits our needs. I think the best tool encompasses different tools, for example white board, a software and a couple of templates, or even more. It is important to take into account who is going to use the tool, who is going to provide the data, who is going to use this information to take decisions during the project lifecycle. Acquiring an Agile program management tool should be a team and management’s choice which is projected to add value.

For local teams: We used physical boards, because they are visible in the office and promotes interaction between team members. And besides a whiteboard which holds current Sprint Data, all you need is a spreadsheet for storing all Scrum data.

We used physical boards and excel sheets for about 1.5 years, and then transitioned to JIRA with GreenHopper (as we became a large and distributed development team) which we’ve now been using for about a year. It takes a little getting used having everything in an electronic format, but its flexible and gives you a board in a browser which mimics the physical one you’re used to and the ability to collaborate with dispersed teams. It allowed us to build up an extremely integrated tool chain with JIRA as central platform and customized Dashboard for the different stakeholders. One key advantage is, that JIRA is quite flexible and can be used in different area’s in an organization. We’ve implemented JIRA for Scrum, Incident Management, Issues Management, Time Management, Action List tracking in meetings, and so on. We’ve integrated Version Control, Code Review, Continuous Integration, Automated Testing, etc. It allowed us a very high level of transparency in different processes.

Summary: In Summary, the needs should dictate the solution, and one should understand the true need before choosing the tool solution. One person’s amazing tool is another’s waste of bytes. This is SCRUM, and should not be overly elaborate or complicated, it’s towards the far end of the Agile spectrum, i.e. more adaptive rather than prescriptive. But saying that, JIRA plus GreenHopper gets a tick from me! Jira’s flexibility has allowed our different teams to create a planning and story boards that meets each sprint team’s unique requirements. The tool has provided an effective way to manage stories in both co-located and distributed (global) team scenarios. Projecting our digital story boards has allowed transparency throughout teams and across the organization.

Thinking bottom-up: Sometimes, the "recommended agile tool" depends on the management view and attitude of the people using it, as opposed to size, complexity or budget of the project. Sure, there are some basic principles that we need to adhere to, but you should consider the abilities of your people, their ability to communicate, their capability to make decisions, and then on that basis choose a tool that helps them achieve amazing results.

“Leaders aren’t born, they are made. And they are made just like anything else, through hard work. And that’s the price we’ll have to pay to achieve that goal, or any goal.”

In the last 14 years, I had seen myself moving from waterfall methodology of software development to Iterative and then to Scrum and finally to Scrum-ban. I will explain a bit about the different methodologies and then move to Scrum Process. Below is the pictorial representation of the Waterfall, Iterative and Scrum software development process. More info about Kanban and Scrum-ban will be posted in my upcoming blogs. In this article, i would like to demo on how to use the Microsoft Visual Studio Scrum 1.0, process template built specifically for Scrum teams

The waterfall approach is highly risky, often more costly and generally less efficient than more Agile approaches. It requires the creation of up-front documentation before any real business value is created. i.e. You don’t realize any value until the end of the project. This is confounded by the fact that product development is started downstream, or much later in the project’s expected timeframe. This has the obvious disadvantage of delaying the point at which business value can be realized.

Remember the 80-20 rule, 80% of a product’s value comes from 20% of its features. With this in mind, can we conceivably build a software product that provides 20% of the feature set? Yes, We can deliver "version 1" with 20% of the features, then, a little later, "version 2" with a further collection of features and later "version 3". The beauty of this approach is that development of 20% of the features should not take 100% of the project’s expected schedule and budget: we can realize business value much earlier in the cycle.

Iterative Waterfall Development focuses on delivering a sprint of work as opposed to a series of valuable/shippable features. In my experience, The most commonly occurring issue in this type of process is you deliver loads of code and leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing. Another common symptom of this type of approach is over-commitment. It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way. You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined. For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases. It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.

Scrum Development focuses on delivering fully-tested, independent, valuable, small features. As such, we diversify our risk – if one feature goes wrong, it should not impact another feature. With that said, we still plan our work in iterations and we will still release at the end of each iteration.

For Example, if we run two projects for identical requirements, same time period (For ex: say 1 year) with same team, but one in waterfall Software development process and another in scrum. Assuming you know how scrum and waterfall both work, if you look at the project delivery after 6 months, it would be very interesting output. In the 6 months, the waterfall project might have reached a stage where the requirement analysis is fully complete, design is complete, programming has started and half way through. If I am a customer, how much business value this stage would give me, think about it? At the same time, the scrum project team would have against prioritized product backlog and started delivering shippable product after every sprint (say of 4 scrum cycles every 2 month). Scrum focuses on shippable product in small iterations, and that not only gives the best business value at certain moment in project life cycle but also allows change during the development process that can be taken up in future sprints.

Microsoft Visual Studio Scrum 1.0 Process Template

Last week, Microsoft announced Microsoft Visual Studio Scrum 1.0, a process template built from the ground up specifically for Scrum teams. Below is the step by step guide to Downloading, Installing and setting up the Scrum process for the Project Teams.

Step 2: Launch the Process Template Explorer in Visual Studio 2010

If you already have a connection to the Team Foundation Server, please ignore the Steps A to D and go to Step 1.

Prerequisite: The following process requires a connection to a Team Foundation Server. In my scenario, i Installed Microsoft Team Foundation Server 2010 locally on Windows 7 PC. Below are the steps to connect to a Team Foundation Server (team project collection).

Step A. In Visual Studio, on the Tools menu, click Connect to Team Foundation Server.

Note If you do not see this option, you have not installed Team Explorer. You must install Team Explorer before you will have the option to connect to Team Foundation Server.

Step B. In the Connect to Team Project dialog box, in the Select a Team Foundation Server drop-downlist, click the server that contains the team project collection to which you want to add your team project.

Note If the drop-down list is empty, click the Servers button to manually enter the server connection settings. Contact your Team Foundation administrator or team project administrator to obtain the connection settings.

Step C. Click the name of the project collection to which you want to add your team project from the Directory list

Step D. Click Connect. The Team Explorer displays the team projects that you selected. Following is the screenshot of my Team Projects.