Archives for October2013

Introduction to Ruck (or Loose Scrum) Software Development

Ruck software development system – which is sometimes called Loose Scrum – is an emerging agile methodology that is based on Scrum, but has some features which sets it apart. Ruck methodology was coined by Microsoft’s ALM Rangers team and was called Ruck because in the world of rugby it means “Loose Scrum“. The key principles of Ruck are transparency, inspection, adaptation and collaboration.

Transparency: In Ruck, visibility is key. The methodology was developed by virtual teams that are working on the project only part-time and therefore addresses the challenges of operating in a virtual environment – including having colleagues from different time zones, who are working in a virtual or part-time fashion, and have diverse cultural backgrounds. Therefore, it is important for the project manager to have a well-defined idea of what “done” means so as to avoid any misrepresentations and confusions.

Inspection: With inspection it is easier for mistakes and patterns that will not favor the project to be spotted earlier on. This scenario makes it easy to curb a potential problem before it becomes full-blown.

Adaption: Ruck is a software development system that is still at its early stages. It is essential to be open to changes and adaptations when experimenting with variables and unknown quantities.

Collaboration: Members of the team should be able to collaborate openly irrespective of their time zone. Collaboration and open communication can take place at any time it is convenient for the entire team members.

Ruck is often used by teams operating from different time zones which cuts across different cultures. It is therefore a challenging task right from the planning stage, to the collaboration proper and down to the tracking. Ruck team has some feature areas with the Ruck Master being in charge. The role of feature area lead makes it possible to coordinate team members from different time zones and cultures. This type of team structure makes it easy for the Ruck master to delegate project management and tracking tasks to feature leads. The core team thus has time to focus on tweaking, grooming and refining the Ruck framework and other supporting infrastructure.

A feature lead is the person in charge of the feature area. This person is part of a core team comprising of other feature area leads, project managers, subject-matter experts and of course the Ruck Master. Iterations in Ruck often involve 4 weeks duration – as it might be difficult to have shorter iterations due to resource constraints that usually accompany part-time work.

Unlike Scrum, stand-up meetings may be capped at 30 minutes. This will allow time for more collaboration between team members. Again, stand-up meetings are more of ad-hoc in nature rather than regular.

Ruck development is a work in progress that is empirical at best. It is currently an evolving process that takes into consideration the virtual and part-time team members in a highly distributed environment. It is hoped that Ruck will be a framework that addresses the challenges of virtual teams – and will be reusable, transparent and predictable.

Read More

5 Myths About Agile Development

As Agile development becomes increasingly popular, there are also some myths that often surround Agile. Some of these myths arise from a misunderstanding of what Agile is and how it is practiced – and this post aims to address the most frequent ones.

1. Agile does not use documentation

This is perhaps one of the most famous myths about agile. The most common excuse given for the propagation of this fallacy is the line in the Agile manifesto that says “Working software over comprehensive documentation”. This is probably one of the most misunderstood sentences in the manifesto. The question of how an Agile framework like the Scrum can survive in highly regulated environments like the finance industry without documentation beats the imagination if this myth were to be true. The truth is that Agile processes uses documentation, but only the one which adds value and benefits the project, instead of documentation for the sake of documentation.

2. There is no control in Agile

One of the biggest fears people encounter while dealing with Agile is that of losing control of their teams. The misconception that often arises is that Agile is all about anarchy, because the team is self-organized. This is far from the truth. It is true that the role of the management does change in Agile but they still play a crucial role in within the company. It is the role of the manager to make sure that the goals, visions and constraints of a project are well-defined. When these roles are well-defined, it will be easy for the team to be self-organized.  So in reality, there is nothing to be afraid about in self-organization. In fact, it should often be encouraged as it makes the work of the manager easier and the process more effective.

3. Agile is faster

Naming an iteration a “sprint” does not mean it is faster than other processes. While it may be true that Agile as a whole makes development process faster, the initial process might be anything but fast. Quality takes time to accomplish and it needs time. Agile methodology ensures there are lesser bugs to fix and the software is sustainable. Agile also aims to minimize waste, which helps to make sure that the process is not stuck with the tasks that do not have a purpose.

4. Agile is a silver bullet

While many may wish this to be true, in reality there is no silver bullet in software development. Agile is about the people in a team; you need to have the right people in a team to create awesome products. Even the Agile manifesto said as much “Individuals and interactions over processes and tools”. Agile can make the right team more productive and the process more adaptive, but it will not fix all the problems of an organization.

5. Agile is easy

Finally, it is often said that agile is easy. When a team switches from traditional software development methods to agile, it is sometimes possible to deliver a quality shippable product in four weeks – that was previously done in one year. But it does not mean that software development has now become easy. Agile process eliminates some of the redundant work – but developing an awesome product can take a lot hard work in spite of whether Scrum, Kanban or another agile methodology was used.

Read More

Getting Started With Scrum Task Board

We recently covered how to get started with Kanban boards, and this post aims to help you if you decided to start using Scrum. The first step to getting started with Scrum is to do it with a pilot project. This pilot project will help you get the hang of how it is done and then roll it out to the wider organization. Before you rush out to start trying your hand on Scrum , it is good that you be aware of some organizational problems that may hold you back. Some of the most common issues with using Scrum include lack of training and infrastructure, adoption in silos, and overcomplicating the process. Once you have got these problems out of the way, you are good to start with the Scrum task board.

Below are three basic ideas to help you get your Scrum task board off the ground.

1. Choose the product owner 

Finding out if the product you intend working on has an owner is a great way to help you and your team get organized. Your team needs to determine at the earliest stage whose responsibility it is to make any form of changes to the product. It is also important to know who wrote the first business requirements and this will of course point you to the person who knows the product best and who is speaking from the customer point of view.

2. Get the product backlog organized

Now that the new product owner has been identified, it is time to get together with major business representatives. The purpose here is to plan a workshop that will educate and also help your team prioritize your product backlog. The project requirements should be rephrased into stories. If you are lucky, the product owner may already have the product backlog ready. In case your product owner does not have a story ready, start thinking of how to organize a second workshop to transfer their requirements into stories.  The stories should contain a detailed description of what your clients want and how it will benefit the product.

3. Get a task board

So far, you have succeeded in having your backlog ready and a motivated team to work with, the only thing left is a task board. You may consider a virtual task board, especially if some of your team is located offshore. Alternatively, you can use a magnetic whiteboard for this purpose, which allows most items to stick on it. Or, you can build your boards directly on the wall. To help you choose, we reviewed the pros and cons of virtual task boards previously on our blog.

Enter your vertical and horizontal lines with signs for name tags, columns, team pictures and status tags and you are set with your Scrum task board. Good luck!


Read More