{"id":513077,"date":"2020-03-12T09:28:20","date_gmt":"2020-03-12T08:28:20","guid":{"rendered":"https:\/\/www.devoteam.com\/expert-view\/agile-the-best-project-management-process\/"},"modified":"2020-03-12T09:28:20","modified_gmt":"2020-03-12T08:28:20","slug":"agile-the-best-project-management-process","status":"publish","type":"expert-view","link":"https:\/\/devoteam.info\/en-nl\/expert-view\/agile-the-best-project-management-process\/","title":{"rendered":"Agile: the best project management process?"},"content":{"rendered":"

In the afterglow of the <\/span><\/i>Frontend Developer Love Conference<\/span><\/i><\/a> in Amsterdam last month, our development team got inspired to share with you some insights. Every week we\u2019ll post one article, in a series of 5. So stay tuned for more!<\/span><\/i><\/h3>\n

\"\"<\/span><\/i><\/h3>\n

In this first article we\u2019ll zoom in on Sander Hoogendoorn\u2019s talk. He is an independent software craftsman.<\/span><\/p>\n

“How thinking small is changing software development big time.”<\/i><\/p>\n

\n

Sander Hoogendoorn<\/strong><\/p><\/blockquote>\n

The world is changing fast and with it, technology is evolving at a crazy pace. The market is diversifying and competitiveness is higher than ever before. The last couple of years, we saw many companies entering markets that were not their base ones. Think about Facebook introducing its new <\/span>Libra <\/span><\/i>cryptocurrency or Apple creating a credit card.<\/span><\/p>\n

But what does that mean for the IT world and for us developers? It means that we must deliver faster to implement new features all the time. More and more companies are consequently migrating their waterfall projects to agile projects.<\/span><\/p>\n

The real question is, how do we cope with change in IT then? Well, badly. There\u2019s always something we need to refactor, migrate or change in the code. Scenarios weren\u2019t foreseen, time was lacking, the pressure was high and deadlines were short. We\u2019re busy with features that, most of the time, are not really needed. As we\u2019re almost all working in agile projects and teams, features are picked up and implemented asap because that is what agile enables. But at what cost? You\u2019re sacrificing quality over quantity. It is how the fast market and evolution makes our code go obsolete, faster than ever before.<\/span><\/p>\n

Where did it go wrong?<\/span><\/h2>\n

The description given above hits close to home for many developers. Sander Hoogendoorn calls it \u201c<\/span>Product Owner Driven Development<\/i><\/b>\u201d and it’s the main reason why we\u2019re not producing sustainable code. It seems that organisations automatically assume that just by going agile, Scrum, Kanban or other similar approaches, applications will be built in less time. It\u2019s an overoptimistic approach. There are many factors that can cause trouble and aren\u2019t rare. In fact, they happen in every single project: under or overestimates, weird bugs resulting in delays and changing requirements.<\/span><\/p>\n

How do we fix it?<\/span><\/h2>\n

At this point, you might be thinking why do we still do agile projects? It is important to realise that simply not all projects are fitted for the agile methodology.<\/span><\/p>\n

\"\"
Cynefin framework.<\/em><\/figcaption><\/figure>\n

We\u2019ve learned about the <\/span>Cynefin<\/b> framework, a simple yet effective method to check whether your project is fit for agile development. There are five decision-making contexts and agile is suited best for <\/span>Complex<\/b> <\/span>situations. You can also use it for <\/span>Simple<\/b> <\/span>projects, but it will surely be an overhead. <\/span>Complicated<\/b> <\/span>projects can sometimes be fine with agile, but the deadlines need to be flexible as that type needs a big part of expertise, sometimes not foreseen in advance.<\/span><\/p>\n

However, the problem is still there. How to <\/span>improve<\/b> the existing agile process? Sander tells us that it comes down to <\/span>a couple of very simple points<\/b>.<\/span><\/p>\n

 <\/p>\n

<\/h4>\n

Deliver smaller features<\/span><\/h3>\n

What we need to do is to be able to <\/span>deliver as soon as a feature is finished<\/span> in order to be in a real <\/span>continuous delivery model<\/b>. Even more, the features need to be broken up into smaller parts and seen more like problems, in a mathematical way. Solving one problem per day is a good milestone to have in that context and gives more satisfaction to both the teams and clients.<\/span><\/p>\n

Work in shorter cycles<\/span><\/h3>\n

In \u2018waterfall\u2019 times, it was common that it could take several years to complete a whole project. Problems remained undiscovered until very late in the process and failing projects, therefore, cost a lot of money. Then, scrum and agile arrived and introduced two-week <\/span>Sprints. <\/span><\/i>It was an improvement but what would you say if that period was even shorter? Impossible?<\/span><\/p>\n

You don\u2019t need to put a fixed amount of days for a set of features or estimate every task in hours. Estimates are almost never met and result in a \u201c<\/span>red-spring anti-pattern<\/span><\/i>\u201d.  Sprints as we know them don\u2019t add any value and often end up in burnouts, loss of developers\u2019 motivation or other issues.<\/span><\/p>\n

How can we speed up the process without having too much on our plates? The answer is <\/span>automate<\/b>.
\n<\/span><\/p>\n

\"\"<\/span><\/p>\n