Team meetings for agile process

scrum meetingPlanning is a foundation of all works. Especially it’s important for project’s implementation. Team must set the main aim and to plan actions step by step. As Antoine de Saint – Exupery said “A goal without a plan is just a wish.” That is why planning is compulsory if you want to achieve the final result. Scrum teams always optimize the estimation and execution of work. Team uses short periods of time known as sprints. The sprint helps you not only to find the right balance in work but also if team faces with some problems sprint allows to change the scope or direction of the project at any point. Scrum has four kinds of sprint meetings: planning meeting, daily meeting, review meeting and retrospective meeting. Teams who prefer kanban than scrum know well about meetings called kaizen.

Read More

Why should one apply Agile or Lean practices?

Have you ever wondered if Agile or Lean practices are any good? Have you searched through web and read dozens of whitepapers, videos and slide shows? Still not convinced? We challenge you to watch this 3 minute video and get a quick grasp how you can benefit not only by applying agile and lean but also empowering tools for project management.


Read More

Agile Tool Eylean Introduces a Free Personal Edition

Agile Tool Eylean FreeIt is Cyber Monday and there are a lot of deals in the market. But we have something special for you. How about a 100% discount for unlimited time? Yes, you understood it correctly – starting from today Eylean is free for your personal use!

Since our start in 2010, hundreds of companies have chosen Eylean for their enterprise projects, including giants like British Petroleum, Hitachi, Velux and others. Using Eylean helps them implement Scrum, Kanban and Scrumban, and stay agile in the world of ever-changing requirements. We think it is time for everyone to have an opportunity to take advantage of Eylean and make their development process faster, easier, and more transparent. Therefore, we are making a personal edition of Eylean agile task board free of charge.

Personal edition of Eylean includes a fully fledged task board, reporting, and analytics. You will be able to download the software and manage your personal projects with a highly visual, Scrum– and Kanban-optimized task board. Personal edition also includes time-tracking functionality, as well as export to Excel and Outlook, so that you are able to use the agile tool in the most productive way and stay on top of your personal projects.

So get the new Eylean Personal Edition now – and get things done!

Read More

5 Reasons to Adopt Agile in Your Company

The concept of agile is not a new one. Its origins come from the 1990s, but some organizations still have not adopted agile despite its many inherent benefits. Agile believes in the faster adaptation and iterative life cycle, and brings the beauty of constant refinement of the goals, requirements and solutions during the development process.

However, if you are still undecided on whether to choose agile as your preferred method of software development, or if you need a few arguments to convince your colleagues, perhaps these five reasons will help you make a quicker decision:

Agile adapts well to changing priorities. Implementing agile ensures that your software development is up to date. Unlike the traditional software development methods, you do not need to spend a number of years in the development process only to realize that the world has actually moved past the original project requirements. With agile, your company will be better able adapt their portfolio to meet the ever changing business priorities. In agile, working software is delivered on a regular basis. The high value features are prioritized first against lower value features. With Agile you do not have to wait years to discover you have built an obsolete product.

Agile responds quickly to customer needs. Unlike in traditional software methodologies, the customer changing his priority midway does not affect the entire project drastically. Agile makes use of iterations so that the customer can access the progress of the project at any given time. Agile helps the project development team deliver products based on the feedback they receive from the customers.

There are fewer defects with agile. There far fewer defects associated with agile than with traditional methodologies. It is far preferable to test software in smaller installments as it is being developed than develop a whole project and test it at the last stage. Iterations make it possible for the defects and errors to be detected earlier and corrected. This makes it possible to have products with zero defects.

Marketing is faster with agile. It is possible for products made though agile to reach the market faster than those made through traditional methods. Research shows that there is a 37% chance of products developed using agile reaching the market faster than using traditional software development methods. In a competitive environment, it is essential to get the products to the market faster than the competition. Agile leads to better productivity as well as having the right scope delivered at the right time.

There is greater transparency with agile:  The use of agile inherently leads to great transparency between the team members. This is because of the improved communication between team members. Communication can take place daily in which each team members update on deliverables and make commitments to better quality products. Through communication, problems are discovered, discussed and resolved faster, hence bringing higher transparency to the company.

Do you know other ways how agile benefits organizations? Share them in the comments!

Read More

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

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

5 Common Mistakes When Adopting Agile

Agile methodologies offer companies a lightweight framework to execute their software and other projects. It is therefore not a surprise that companies are increasingly looking to adopt agile as their preferred method of software development. Although the benefits to adopting agile are numerous, during the process some of the drawbacks emerge as well. In order to make sure that you do not make one of those mistakes when adopting agile, below is a quick rundown of some of the more common pitfalls that arise when adopting agile.

1. Lack of proper training and education

This is probably the most common mistake made by organizations hoping to adopt agile. The teams sometimes believe that they can cut corners by saddling the internal team with the responsibility of learning scrapes of agile and passing on the information to the members of the team. It is important to take into account that the team members are busy with their daily jobs, and might not have the time to ensure smooth adoption of agile. It depends on the situation, but it often makes sense to invest a bit of time into learning agile methodology of choice, or bring in experienced agile coaches and consultants.

2. The Silo syndrome

The Silo syndrome occurs when the evolvement of Agile is out of sync with what is practiced in the rest if the organization. The result is that different teams in the company are trying out and developing different methodologies and standards until there is outright confusion. While it is fine to start with a pilot team in an organization when adopting agile, the processes in the rest of the organization should not be ignored as well.

3. Abandoning other aspects of the business

This mistake in evident when the company ignores other areas of their business and focuses too much on their technology teams. While agile is often about software methodology, it is also about a shift in corporate culture as well as the building of infrastructure for the overall wellbeing of the company. Shift in corporate culture should not take place on Agile teams alone, it should also happen in other departments and offices in the company.

 4. Over-complicating the process

Agile adoption is a simple process that need not be complex. When there is an inclination to the introduction of new policies, additional process and extra layers of management, it can easily cause block adoption or at least decrease the adoption speed. When adopting agile, it makes sense to cut out the extra processes and policies, and make the process as simple as possible.

5. Failure to have proper infrastructure in place

Finally, when the company does not take into account the infrastructural changes needed to support scaling agile processes, it might be difficult to establish agile as the project management methodology for the organization. The infrastructure, including agile tools and the work processes, might have to be adjusted, especially as agile becomes the methodology of choice for the whole organization.

Therefore, if you are looking to adopt agile, make sure you do not make these mistakes – and good luck!


Read More

Setting Up a Kanban Board

So, you have decided to start using Kanban. Since there are often a lot of questions on how to get started, here we provide a simple set of tips for someone just starting out with Kanban:

1. Decide whether you want to use digital or physical board

First of all, decide if you are going to use a digital or physical board. Digital boards or software – such as Eylean – have a lot of advantages over physical ones, but you should decide which one is best for you. If you need additional help, we have covered the main aspects of choosing the right board in this blog post on electronic vs. physical task boards.

2. Prepare a simple board structure

Once you decided on the right board for you, prepare a simple task board which consists of three columns: “To Do”, “Work in progress” and “Done”. This is the basic structure of Kanban you will use to sort your tasks and items. If you have a multi-stage process – for instance development and testing – you might split these processes into separate columns later on, but for now just start with a simple board for one stage of your process.

3. Set a work in progress (WIP) limit

One of the key aspects of Kanban is that the number of items in progress is limited and therefore no other item can be started until the existing items are completed. Therefore, you need to decide whether you want to allow some multitasking or not. If you decide to go without multitasking, you should add the WIP limit that is equal to the number of people on your team. If you want to add a bit of flexibility (most teams do), you should add the WIP limit by several items higher than there are members of your team.

4. Embrace the pull principle

The next important concept to grasp is the Pull principle. The idea behind the Pull principle is to make sure that the team members can choose the items to work on. It works in the following way. You put the task cards on the board, but you do not assign them to anybody. The team members pull the tasks which they would like to work on and are capable of working on, and start working on it.

5. Set up prioritizing and planning processes

Finally, make sure that you develop a process for item selection and prioritization on demand. One of the approaches to that is doing small planning meetings, when the team discusses and decides which of the items are the most valuable and should be done next. The planning meetings can be done when the number of items in the backlog reaches a certain number – for example, less than three. This will make sure that you will not over-plan – but will also not run out of the items in your backlog.

You can always evolve and adapt your board when you master the basics – but this checklist should help you started with Kanban. Good luck!

Read More

Busyflow Co-Founder & CEO: Our Development Process is “Chaotic Agile”

BusyFlow integrates cloud applications into one dashboard, helping teams collaborate and work together more efficiently. The company works with numerous APIs, codes in Python and has just launched their Android app. We are talking with their CEO Jaro Satkevic on their development process – and how they adjusted it to make developers happier.

Tell us about yourself. What does your company do and what is your role?

I am the CEO and co-founder of BusyFlow. Busy Flow is app that integrates different productivity and collaboration tools, like Dropbox, Trello, BaseCamp, Google Drive and other tools into one workspace where people can see the changes, act on them and collaborate together. I am a co-founder and I manage the developer team.

Are you a developer yourself?

Yes, I am. But at the moment most of the time I am doing other activities in our start-up.

Can you tell us how big is your team? How many people and how is it organised?

At the moment we have four people. We also have two more people related to our company – a designer and an iOS developer – who help us when needed. So actually it is me and three other developers in our team.

Can you tell us about your development process? How does it typically work?

Read More

Screach CTO: Do Not Be Afraid To Change Things

Screach is an award-winning Newcastle-based company that delivers interactive experiences between digital screens and mobile phones, such as a trivia quiz in a pub or an awesome mobile-controlled game on a digital billboard. We are speaking today with their CTO David Challener on how the team manages its development process.

Tell us about yourself. What does Screach do and what is your role?

Screach delivers interactive experiences with digital screens. The easiest example is the following: Imagine an interactive quiz running on a screen in a pub, and people using a mobile app to answer the questions in real time. We set up that interactivity between the mobile app that we call Screach, and the digital screen. We have done quizzes, crowd voting and interactive games, to name but a few. We did one experience for insurance firm SwiftCover in which a course was shown on a big screen, and passers-by were challenged to steer a car along it using their phones as a joypad.
We’ve also built a hardware product called ScreachTV, which allows venues like bars and restaurants to put targeted, relevant and engaging smartphone-compatible experiences such as quizzes, messages, offers and games on their TVs. They’re in around 100 UK venues already as well as some in New York, and that’s increasing all the time.

And you are the CTO of the company, right?

Yes. So anything technical basically goes through me and my team.

Read More