Waterfall

Agile vs. Hybrid Approaches – Which Will Stay On Top

Agile-vs-hybridLast week I introduced you to the hybrid WaterScrumFall model that merges the Waterfall and Scrum practices in order to create a happy medium of both worlds. While it is not the likeliest of merges, many companies out there find it to be a viable option for their situation and happily use it. However, there are also those that claim this model is ineffective and faulty therefore this week I want to dive into their side of the story.

According to a recent study by TechBeacon, Agile projects are more successful than hybrid ones. This is a bold statement to be made, especially when keeping in mind that most companies deal with different processes, situations and in general are very diverse. However, the study focused on development and IT professionals show substantial results in favor of Agile.

Amongst the interviewed companies, both Agile and hybrid approaches are widely used as project management practices. The difference between their numbers is not really significant Agile taking the first and Hybrid approaches the second place. Where a difference does come in though is the satisfaction level. Agile users are generally happy with the project outcomes all around, while the hybrid users seem to have issues with six important metrics – Quality and performance, Time to market, Speed of delivery, Scope, Security & Cost and use of resources.

All of these metrics show over 50% or 60% success rate with Agile practices and only around 30% success rate with hybrid methods. So while WaterScrumFall seems to be great on paper, does it fail in reality?

Where the hybrid fails

We can easily find the answer to this question, by actually looking at the metrics themselves.

  • Quality and performance talks about product that fits the client requirements and is produced effectively. Agile practices with their iterative approach and work organized around the product are built for this. The hybrid method on the other hand keeps the design first, build later attitude and can fail to reach that changing expectations of the client.
  • Time to market is also much shorter with Agile not only due to design on the go, but also because the practice focuses on the minimum viable product and can release it much sooner.
  • Speed of delivery is much simpler to achieve with Agile. While both methods hold review meetings with clients, hybrid teams’ product is not yet tested and not ready to be used contrary to Agile teams’.
  • Scope. By keeping with the waterfall planning approach, hybrid methods lose the ability to plan on the go and thus may miss some of the client requirements that may have been miscommunicated at the beginning or only arose during the course of the project.
  • While Security satisfaction rate reaches 45% with hybrid and just under 60% with Agile users, this is still a significant difference. Which could be explained by the more control Agile projects have during the course of the product creation compared to the hybrid approach.
  • Lastly, the Cost and use of resources is undoubtedly lower when everything is planned on the go, according to the projects needs instead of preplanning and blindly following the course.

 

Which to choose?

So while WaterScrumFall aims to merge the best of both worlds it still falls short in comparison to pure Agile methods. In the midst of two different approaches merging and mixing, it is hard to keep track of all the processes and ensure that the most effective path prevails. Nonetheless, for cases where pure Agile adoption is not a viable solution, it may be a better choice to choose a hybrid instead of not innovating at all.

 

Read More

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!

Startup-infographic5

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