Lithuanian Startups on Project Management

After looking into how Lithuanian startups use Agile practices, we were intrigued and decided to dig a little deeper. So we went out again and asked startups what project management practices they know, use and why. The results are presented below in our brand new infographic.

Enjoy and share your experiences with us!


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

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

PassAlong Founder: Agile Is Not a Panacea

Today we are talking with Gedas Mitkus, who has worked with a number of projects, big and small, and has recently founded a word of mouth marketing start-up PassAlong. Gedas shares his views on managing development projects and when agile is the right choice for a project – and when it is not. 

You have a lot of experience in managing various IT projects, can you tell us a bit about yourself and what projects have you been involved in so far?

I have done a number of agile projects ranging in duration from 3 months to 3.5 years as technical lead/architect or as project manager with budgets from £20K to £5M.  Most of projects were about launching new or building on top of existing web platforms, many with ongoing refactoring. The team sizes ranged from 3 to 40, with teams located in different time-zones. I have worked both with start-ups and established corporates.

What are the most typical problems or challenges you encounter in organizing the work?

As long as technical team is competent and with enough experience in technologies the product is being built on, I found the biggest challenge to be in aligning the Big 3 in a company – key business stakeholders, product, and technical teams. In many cases I found that inherent ambiguities in High level business requirements tend to translate into broad or unclear Product requirements, thus making technical development decisions and work challenging. This especially becomes a problem when due to business forces High level requirements change with ripple effects on Product and Technology development during a project. I saw lots of miscommunication arise within teams or even between team members when large portions of Product requirements change in midway. This can be further complicated when team members are not geographically collocated, work on different platforms, or team cultures vary.

Can you tell us what project management approaches did you use to solve these issues?

Different project management methodologies prescribe their own approaches. Waterfall and Agile have their own pluses and minuses. Agile is not a panacea, especially in big organizations, where multiple vendors and teams are involved in building complex projects. I think Agile is more appropriate for development of what is called Existing Evolving Assets in an organization – usually company’s main Product and closely related platforms, and usually built internally over a long period of time.

So you do not agree to the opinion that agile will help to deal with most project management problems?

Read More