Technistas

When you work for a company, it’s important to align your goals with the company goals. In software engineering firms, that often means setting a goal to be adept at your coding job while following the company practices and development processes. If one of those processes happens to be agile development, strange things can happen when engineers try to ‘get with the program’ (coding pun intended!) Engineering managers at software companies, read on to  learn how to help your team adjust to agile.

I think there’s a good reason why engineers can sometimes have a hard time adjusting to and adopting agile. The truth about agile as applied at software development companies is that it is not a software development process. It is a product management process, fundamentally designed to feed prioritized, must-do requirements to engineering teams. Once an engineering team has these requirements in front of them, individual engineers may find it hard to distinguish life before from life with agile. Someone, a manager or scrum master, asks the engineer to commit to doing some work. If the team is using scrum and doing short 2-week sprints, then engineer gets to give the most tried and true answer in software development: yup, it’ll take about 2 weeks. And then they put their heads down and start coding. Every morning they stand up at the daily scrum and say ‘yup, it’ll take till the end of those two weeks I told you about yesterday and the day before…’. From an engineer’s point of view, this interaction can be indistinguishable from their behavior under older methodologies like waterfall, and therein lies the rub.

For engineers to really commit to agile, they need to be told another truth. The hard truth in the software business is that it is market driven – and thus the real goals of a company from a product perspective are and should be defined and socialized internally by the marketing department. What agile really does for a company is to force marketing – product management, specifically – to constantly engage with engineering at a fine-grained level. Reviewing requirements, crafting stories, building a global, prioritized backlog. In other words, doing real work to ensure that requirements are understood and that new information on customer needs and market direction is properly reflected in the backlog priorities.

To successfully socialize agile within engineering, there are three things a manager must communicate to their team:

1. Priorities change

2. Team and individual commitments do not

3. Our process moves as fast as the market

The good thing about agile is that it is self-reinforcing with respect to these three points. By doing short sprints, changing priorities become an evident norm. Unlike waterfall, where an incoming course change forces developers to drop what they’re doing and work on something new, agile maintains current commitments until the end of the sprint, reinforcing point number two. When a course change comes in in agile, the next planned sprint can immediately reflect this, highlighting point number three.

Agile isn’t hard or easy. But it is different. By communicating clearly to your team about how priorities are reached, holding them and yourself to commitments, and adeptly shifting gears as your customer and market priorities change, you will improve your success with agile and win over even the most process-skeptical engineers on your team.