Success stories with Agile are not as common and as consistent as you would expect them to be, considering that Agile implementation has been around for a while now. While there are many reasons for this, one less talked about reason relates to addressing the concerns of all the relevant stakeholders such as developers, testers, Scrum Masters, Product Owners (POs), first line and middle level management and so on. All of them need to be convinced on “Why Agile” and “What’s in it for me” before you expect a complete buy-in, which is needed for an effective agile implementation.
Before I get into other roles, there are a couple of important stakeholders that I did not mention – the Customer and the Leadership team. What’s in it for them? Your customer being knowledgeable and convinced on Agile (and in some cases even better, driving your agile working) is a huge plus when you embark on your agile journey but I have often seen them buy into Agile, and do what they need to do to support you, only when they have seen and experienced the benefits of your agile deliveries. As for the leadership team, what’s in it for them is a no-brainer – it’s about competitiveness, survival and bottom line results while keeping customers delighted.
Developers
With traditional development, developers get a respite up-front till design completion but more often than not end up burning the midnight oil during the testing and bug-fixing phases. With agile, you have the following characteristics:
- Avoid the burn-out at the end, but there’s still need to maintain a steady pace throughout an iteration / release.
- Need for more transparency and responsiveness
- Need for better communication and collaboration with everyone involved in the delivery
And all these come with rewards and benefits
- Timely gratification for delivering on customer outcomes on a regular basis
- Sense of purpose and continual accomplishments
- Constant customer communication and feedback
More often than not, most developers (with a few exceptions such as those carrying the baggage of traditional way of development before) feel a greater sense of energy and enjoy working in such an environment. I have personally seen young and fresh engineers demonstrate greater passion and initiative in agile teams. And these should be leveraged by the Scrum Master (SM) and/or the concerned manager(s) in energizing the team.
Testers
With mature agile and engineering practices such as TDD in place with full-stack engineers in the team, there are no generally no separate testers in an agile team. However, where organizations still depend on specialized testing skills and agile maturity is relatively low, there is a tendency for most teams to work on a mini-waterfall mode with developers delivering most stories towards the end of an iteration leaving very little time for testers to actually qualify deliveries.
However, once the teams move to true agile working
- There is better collaboration with developers and the PO on an on-going basis throughout
- Continual development, testing and qualification happen right through the iteration.
- Testers don’t need to sweat it out towards the end of an iteration or project
- There is instant and timely reward for work completed.
SMs and POs
The role of the SM and PO has been discussed in many PM Power blogs before. If the roles are implemented in spirit, true leadership skills are needed for them to succeed. The SM role is mis-implemented in most set-ups assuming it is purely a co-ordination role. Dedicated SMs may be desirable in large set-ups, but this may not be feasible in most organizations. What I would recommend from my own personal experience is for technical leads who have the ability to work with people to be asked to play a SM role for one to two years before moving them into a managerial or leadership role. This develops leadership skills in them with training on the job and as a result both the individual and organization benefit from such an approach.
Managers
This is where the biggest challenge lies. Most managers have been used to driving both delivery as well as people / competency development functions. With separation of delivery from competency development/support and staff management, only some managers can move into delivery roles while others are expected to support delivery with the required competency development and staff management aspects. Some managers could become redundant in this process. And those who move into the competency development role often feel a sudden dip in their responsibilities and a concomitant dip in their motivation levels. Some even get into a sense of despondency over the transition. This need not be the case if
- there is an understanding that delivering on customer outcomes is the ultimate goal for the organization and each role has an important part to play in accomplishing that.
- Managers who are not on a delivery role directly
still need to support the goal of accomplishing customer outcomes through
- developing staff to be able to do their roles effectively
- help in reviews of deliverables (design / code / test suites etc.)
- resolving bottlenecks that delivery teams face and can’t resolve by themselves, and
- helping in driving the roadmap for the products or solutions that they are responsible for.
These are in addition to handling other staff management responsibilities such as career development, rewards and recognition and so on. A good balance between delivery management and staff development / management is key to succeeding with Agile and an alignment across the organization on this goal is crucial.
JV
