Beyond Agile Software Development Methodology

Thinking outside of the box – what happens after Agile?

As more and more companies use the Agile Software Development Methodology, we are finding that while the concepts are neatly woven into proven strategies, there is much more to be gained from its use. This is a brief overview of how the Agile Software Development Methodology can and should be expanded to address not just the software development processes leading to a marketable end product, but should share some of its focus on developing the developers. This gives them the chance to grow, learn, and know that they are intellectually contributing something valuable to the world of software development.

The Agile method can and does cease to benefit development teams in spite of the fact that they may follow the system perfectly. They lose motivation, they lose perspective and they lose in the market. Other companies, however, work far beyond the time or far beyond the due date on which they should deliver their products. Their team members, however, are inspired, their goals are clear, and they are reaping success in the market.

So let’s look outside of the proverbial box. Agile seems to be one little block among the blocks of sprints. It is simply a method to ensure that the client and the development team are on the same page. While the bottom line is usually assumed to be financial, aside from that goal sprouts knowledge and fulfillment both professionally and personally. Programmers can easily get stuck in the Agile sprint cycle and spin their wheels unless something else is replacing financial motivation. By holding so tight to the Agile methodology, developers are quickly left behind as more up to date methods are established and new developers join the team (or on a broader scale, the entire employment market). They never become aware of what is happening beyond their scope of knowledge and expertise. They go to work, they do their job, they get paid, and that’s it. They want to do the things they already know and call it a day. Theoretically, these developers could soon be replaced by machines, much as physical laborers and assembly line workers have historically been phased out of various industries. Without staying ahead of the game – or by staying stuck in the Agile Sprint cycle – professional and personal stagnation occurs. Experienced developers are quickly replaced by each new generation of developers who have the benefit of knowing the most up to date methods. Unlike ancestral generations with many years between groups, each single year brings new graduates into the market to replace the old. It seems developers have an expiration date unless they are willing to move beyond their scope of knowledge with each passing year!

So how do we ensure that advanced and up to date knowledge is brought into the agile methodology which will, in turn, impact the financial bottom line later? The best way to ensure this is to appoint someone to gather and learn the most current knowledge and then bring it to the team. Rather than leave the individual team members to enhance their knowledge base alone, an appointed individual must take on the responsibility to learn, then teach the new knowledge to the team. By taking the time to incorporate one sprint as a learning sprint, the end result will mean a better product and a more successful company.

There is another important part to the way software development is happening. When agile methodology was first introduced, the goal was to have a team that could self-manage. The faulty reasoning behind this not only adds stress to each team member with pressure to complete each task on schedule, but more time (usually overtime) is needed in order to meet these arbitrary deadlines. This kind of self-management is really like someone being lashed on the back with the pressure to get the job done quickly and the end product suffers. It turns the developer into a machine so the missing element is the human aspect of the development process. The single most important aspect of this is to give developer the freedom to brainstorm and innovate. To be sure, the human element consists of giving people the chance and complete autonomy to innovate and this is why many programmers have moved toward open source coding. Money is not the ultimate motivator as it has been historically. Open source and self-guided innovation represents who and what the developer is at his core – not just the pay he receives from his job. No one can successfully expand if he is only worried about tasks and deadlines. The very thing that makes each developer different from a machine is this free innovation. Rather than being told what to do, developers need to be given the broad goal and the chance to figure out for themselves what is the best and most inventive way to get the job done.

As much as we make agile sprints that focus on user requirements and the steps in development, there must be sprints for knowledge. By spreading knowledge and equalizing the chemistry of knowledge on the team, everyone is on the same level so there is consistency in the code. Unbalanced code, some advanced, other lacking, creates a mess of an end product and chaos among the team. By brainstorming the overall fulfillment of the end user requirements, the team members can find the best way to reach those end goals while not being tied to micro-managed time and creativity constraints.

When team members are set in learning (not necessarily formal education) sessions will be exposed to the latest technologies and team members will relate to how these technologies solve some of their current problems. It definitely means that tasks will get done faster, products will get delivered sooner, and the team will keep evolving. Incorporating learning sessions/learning sprints shall assure the infinite growth of knowledge which prepares the team members to make the best of their decisions.

I hope that I have shown that when developers are "developed" they are more likely to use better communication skills and make best estimations for the tasks they are expected to get done in the agile environment. Allowing investments in the developers and not just in the tasks, projects, or processes, the communication among team members opens the door for broad shared experience and the team can act as a holistically empowered organism.