Agile Software Development. Insights from Intellectsoft (Part 2)

February 21, 2017

Agile project management is an incredibly flexible framework. This allowed a number of prominent managers and thinkers to build their own Agile methodologies, like Scrum, Kanban Adaptive Software development, and many others. Some companies prefer to water down an existing Agile method or create a new project architecture from scratch, tailoring it to the existing enterprise environment.

With Agile, there’s truly a lot of space to maneuver, and enterprise software development projects might call for a custom approach. Nevertheless, there are some core basics, and it is better to consider rather than ignore them. They are tried-and-true, they save time, they increase the chances of success. One of these basics is an Agile architecture equivalent to Maslow’s hierarchy of needs, which shows what obstacles stand in the way of a team’s success.

The Five Dysfunctions of a Team

In 2002, team management consultant Patrick Lencioni published a book with an unshowy name — The Five Dysfunctions of a Team. The book, written as a business fable, became both a New York Times and Wall Street Journal bestseller, proving to be as useful to NFL coaches as to IT companies seeking more flexible ways to complete projects and innovate. Like the Forming, Storming, Norming, Performing method (we wrote about using it in Agile development in the previous post), Lencioni’s book provides a simple conceptualization of complex issues in a few comprehensive steps. Thus, project managers are given a solid overview of five obstacles that block the road to successful project completion, and are able to eliminate them one by one.

“Remember teamwork begins by building trust. And the only way to do that is to overcome our need for invulnerability.”

Patrick Lencioni, The Five Dysfunctions of a Team: A Leadership Fable


Agile Methodology and The Absence of Trust  

When a team is assembled for a project, the members don’t know each other well, so trust becomes an issue. Here, the first and most important ally is time. Of course, a project manager should facilitate the process, promoting openness and showing that making mistakes is natural. If a team of developers consists of people who have already worked together, this problem is non-existent in most cases.

Agile Project Management and The Fear of Conflict

A project may stall if team members, while still getting to know and trust each other, avoid even the most insignificant conflicts. In agile project management (and any other challenge, for that matter), teams need healthy conflicts to succeed. They lead to vigorous discussions that, in turn, may give birth to bright, project-defining ideas. Here, a project manager should promote healthy conflicts, tell success stories that involve it, and oversee several brainstorming sessions and team discussions.

Agile Development and Lack of Commitment

If team members do not say their ideas out loud in an open, lively debate, they will not buy-in and commit to important decisions that guarantee a project’s success. This creates a sense of ambiguity within an agile development team and eventually cripples the project.

Agile Software Development and Avoidance of Accountability

The sense of ambiguity within an agile software development project makes even the most passionate and focused team members ignore counter-productive actions of their team members, putting the project under fire. Projects of different scales will suffer equally — whether it’s a small event-focused app or a big enterprise software project.

Agile Architecture and Inattention to Results

This obstacle to successful project completion appears when team members put their individual needs before everything else — the team, the project, or even the division. These include status and ego, career development, or personal recognition, and often a couple of them at the same time. In agile project management, team leaders should react according to the situation. For example, offer a bonus or delineate a prospect of working on a bigger project.