Demotivated Tech team? You might be Implementing Agile the wrong way.
Do you often struggle with pushback from your tech team? As a product manager do you write extensive, detailed Product requirements documents, just to have nobody really read it? Do you find it challenging to keep your tech team motivated? You might want to take a deep look into how empowered your tech team feels.
Over 5 years of working with a tech team, I have closely observed different types of project management styles & how the same team has responded to them. And I can say this, Agile is just not meant for all teams. Agile methodology focuses on breaking down large projects into more manageable tasks, which are completed in short iterations throughout the project lifecycle. Usually product managers are responsible for driving Agile within their tech teams. This is probably a great way for managers to hold their teams accountable but it also results in a lot of micromanagement.
Once you lose sight of what inspires people & implement a dry process, no matter how detailed or watertight it is- you are setting yourself up for failure.
In my opinion, Agile is not a comprehensive process and it is about time we modify it. Let me explain why: 1. By principle, Agile methodology doesn’t care about the people actually following it Agile was set up to drive up customer satisfaction- without taking into account the well being & psychology of the developers who actually see it through.
Tech teams aren’t supposed to be ticket monkeys accomplishing small tasks every 2 weeks. They are meant to be an inspired group of individuals that have the power of making your idea become reality.
Apart from retrospectives, there are no guidelines that protect developers from being treated like task rabbits. As a project or product manager, how do you inspire & include your tech team in your vision? Are you making them feel a part of the same cause? Agile empowers project managers to expect accountability but fails ensure that tech teams are empowered & inspired to be an integral part of the vision. 2. The burndown chart is a skewed guideline Jira has a burndown chart that predicts the achievement of a sprint goal. As a developer, if the chart predicts that you are less likely to achieve the sprint goal, you are subjecting yourself to reprimand. Psychologically, this makes developers more conservative for their next sprint. If the chart predicts that you are achieving the sprint goal sprint after sprint, it probably means you are taking on lesser number of tasks than you potentially can. And usually, this is true.
This number game keeps developers always insecure at the time of sprint planning. Assessing sprints through burndown charts takes away focus from actual achievements & impact that developers have had.
3. A lot of Agile practices try to remove trust from the picture The reason why Agile has been popular is because it reduces the amount of risk for product & startups when they are dealing with tech. Whilst this is true & has a huge positive impact in managing expectations; if you are trying to setup a good culture for tech & product, it is always best to have practices that implies trust.
Managers getting involved in story-pointing & sprint planning, assessing developer performance through sprint quality take away power from tech teams to make their own decisions. A powerless tech team will never do more than is just necessary.
4. Retrospectives are a poor substitute for an actual democratic process This might be a controversial thing to say, but I have always felt Retros are a poor attempt to democratize a highly controlled process. Instead of spending time in reflecting on what worked & what didn’t work, why not let tech teams decide how to manage their work? Between manager-led sprint planning & retros, tech teams tend to feel powerless. As a product manager, your time is better spent in inspiring the people who build your product instead of managing their time. Allow tech teams to plan their own retros and at a pace that makes sense to them. 5. Product managers end up getting swamped with process work Between user interviews, reviewing business goals & metrics, writing documentation, usability tests & n number of things PMs have to accomplish, adding tech process management is a huge burden on product owners.
Product managers are expected to ensure accountability from developers; and this is just bad culture. Tech teams should be empowered to own their process & be responsible for it.
6. Storypointing sessions adds to the meeting burden and subconsciously imply a lack of trust in a developer’s estimates
Even though a lot of well meaning managers & teams try to keep estimates fluidic- it inevitably becomes stressful for developers if their estimates are inaccurate sprint after sprint. Not to mention, the time wasted on ensuring accuracy- every 2 weeks!
Providing estimates for tech work is hard as it is. In addition to this, to demand point estimates for each ticket biweekly pushes developers to be more & more conservative. Inevitably developers tend to add buffer time to each ticket.
The one size fits all approach to product building often times leads to confusion in teams on how to handle unique situations, like large tech debts that have multiple dependancies that could never fit within a single sprint. Agile is not all bad. It just lacks the soul of product building. What is good about Agile? 1. Daily Scrum: Probably one of the best parts of Agile is the daily standup that allows teams to be able to raise issues & stay abreast of each others’ work on a regular basis. With a good scrum master, scrum ensures that teams are inspired on a daily basis.It reinforces team spirit & camaraderie. 2. The iterative & flexible approach to product building. Agile has an advantage of allowing iterative approach through its core philosophy of breaking down tasks & ensuring teams are not married to a fixed roadmap.
Though biweekly sprints set up a good foundation to allow iterative approach to product; the core of having a flexible approach to tech is a team that is more committed to the vision than the rigour of tasks accomplished.
By design, Agile gives power to Product managers to assign tickets at regular frequencies & determine tech effort. But the core of allowing iterative product building is a flexible & motivated tech team- not necessarily a power shift towards product. I am not saying that Agile doesn’t work. My argument is that ALL of Agile’s principles don’t fit every team. If you have a trusted with motivated developers, you don’t really need Agile to ensure accountability. In fact, Agile feels counterintuitive when you are dealing with a group of committed intelligent developers.
Agile being introduced as a counterpart of Waterfall seems almost reactionary. From a space of opacity of tech efforts (in Waterfall) to an extreme of micromanaging tech (in Agile).
Instead of adopting Agile methodology as a dictum, try seeing what parts of Agile makes sense for your team. Let us listen to the spirit of our teams and not just the rules of product books.
At Boggl.ai, we are building the revolutionary tool for Product managers to make their lives a little easier. We aim to elevate the way in which feature and product requirements are communicated- one step at a time. Are you a Product manager? Or an entrepreneur managing a tech team? Join our waitlist to try out our free beta version. We are launching very soon!