Senior developers 'reject' agile. What now?

Question

I'm about to have my first day as Product Owner at a new job as one of three product owners, and during the interview one of the current challenges that was brought up was the renewal of the processes. My recruiter told me they are using a variation of scrumban methodology, but they are regularly encountering snags with the engineering team.

Half of the developers have 10+ years of experience and apparently assert they do not need agile because they 'know what they are doing'. Some of them have specialized into one specific area of the product and are being exclusively assigned all the stories relating to that area; which might not always be a problem in itself, but makes it hard to grow the team or deal with absences.

I haven't started yet, so for all I know this might be the product team over-reaching and trying to intervene in the engineering's management instead of letting them self-organize. Or being over-zealous with processes and forgetting the people.

But the concerns seem real enough, and the prospect of an uncooperative development team intimidates me as well. What's your advice as to how to approach such a situation? How would you communicate the value of flexibility to engineering? Is it even the product's job?

Answer 1

As a Product Owner or product manager, you shouldn't be too concerned with the details of how the development teams are working on a day-to-day basis. If you believe that certain aspects of the way of working are leading to risks in the ability to build and maintain the product, you should be able to raise those concerns, but you shouldn't attempt to direct the development team on how to work. Doing so would be the path of more traditional, command-and-control project management.

If the team is agile, there should be regular retrospectives - this is one of the twelve principles of Agile Software Development. This is a perfect venue for raising such concerns to the team and having them solve the underlying problems. Ideally, your team or organization should also have an agile coach who can help the team see risks and impediments and devise ways to solve them.

Answer 2

Just don't call it agile.

Often the resistance to agile ways of working is associated with the terminology. It is not uncommon for teams to 'hate agile' when in the past they worked in a flawed agile implementation and learned to dislike it. They now associate the terminology with bad things.

As a Product Owner you can't dictate the way the development team works, but you can demand that they work effectively.

I would focus on making it clear that you expect the team to:

• Deliver working, valuable software frequently
• Adapt well to changing requirements and feedback from stakeholders
• Maintain a good quality standard and not let technical debt accumulate

These are very reasonable demands in any organisation. How the delivery team achieves it is up to them, but realistically they will need to adopt some agile practices.

It is the outcomes that are important, not the terminology. By avoiding calling it agile you can stay away from any existing prejudices the team has and you will also find it easier to get support from the rest of the organisation.

Answer 3

It is hard to say anything without more details. You just mention there is a potential problem with the level of specialisation, but you don't make clear whether that is a real problem or whether it is just a concern that you have. It is also not clear what the typical size of a project/assignment is for the organisation, which can make a dramatic difference in the level of project organisation that is required.

Specialists that are experts in their knowledge area or their part of the product are typically an order of magnitude more efficient and effective than an Agile team with no specialist knowledge.

By blindly introducing Agile into an organisation that doesn't really need the flexibility that Agile offers, you may be deteriorating the efficiency and effectiveness of the organisation.

If the level of specialisation is a concern, then some internal training or cross-assignments could be all that is needed.

In short: don't solve problems where there are none to be solved. Unless there are real concerns that are impacting the effectiveness of the organisation, don't try to change the organisation.

I would say that having a number of experts in the organisation who actually know what they are doing is a huge benefit. Work with them, not against them.

Answer 4

You have said a few things which are legitimate concerns for the development team. Agile teams are supposed to be self-managing but your team apparently is not because developers are having work allocated to them individually. You say that the product team are intervening and apparently your developers don't feel in control. These all seem like symptoms of not being agile enough.

My suggestions would be:

• Management stop allocating work to individuals and tell the team to self-manage.

• Adopt a pull-system: developers decide what to do next.

• Encourage stakeholders to prioritise work but not to allocate.

• At least to start with, adopting fixed iterations (Scrum-style) with delivery at the end of each iteration should hopefully allow the engineering team the space they need to get on with priority work.

• Encourage product ownership. Where you have competing demands, someone needs to take decisions about what the real business priorities are.

These all seem to me like agile practices that could address your developers' concerns.

Answer 5

As a Product Owner maybe a goal oriented approach could lead to change in behavior.

Example goal Reducing time to market: To be able to compete with competitor X we aim for a time to market of less than a week. Delivering a couple of end-to-end features in a week might be a real challenge for a group of hero-coders. The group could now self-manage and adopt the Swarming pattern, measuring to see if this really improves the time to market for them.

Scrum.org's Evidence Based Management guide suggests for four areas (with example metrics) of collecting evidence:

• Current value: Measures value delivered to customer or user today

• Unrealized value: Measures value that could be realized by meeting all potential needs of the customer or user

• Time to market: Measures the ability to quickly deliver new capability, service, or product

• Ability to innovate: Measures the ability to deliver a new capability that might better serve a customer or user need

The latter two are about organisational capabilities to deliver a product. If you can create evidence that the current way of working prevents growth in those two areas you might have the proof to convince the developers to experiment with new ways of working.

I have seen companies were developers with strict responsibilities in a small area of the product worked for their context, changing it just slowed them down significantly. So there is no single way of working that is a silver bullet.

Also maybe you should not try to break things in your first month, because what might be chaos to you might be order to someone else. Changing it might lead to more chaos.

Answer 6

Welcome to the real world - I have seen what you are describing to a higher or lesser degree in all agile or not-so-agile teams I have ever come in contact with.

The thing is - and devs can be awfully short-sighted about this - that with good people, this will just work splendidly. Too splendidly, in fact.

All is well until one of your key persons (and eventually, all of them will be a key person for one topic or another) goes away. People do tend to take vacations eventually; they do get ill; they do leave companies or eventually die.

Yes, Scrum and other agile processes often are sold to dev teams with the reasoning that they protect the team from outside harm (i.e., stakeholders telling them directly what to do), but that is not the only reason they are there. Knowledge sharing is a big other aspect. This is achieved by:

• Tracking stories in a meaningful way, with lots of details in written form in the story-tracking system.
• Keeping meaningful DODs which include a strong "documentation" aspect (either in the form of significant amounts of tests which then serve as documentation-as-code; or in the form of exceptionally well-structured code in itself; and/or in the form of written documentation in a CMS separate from the stories).
• Very importantly: not having stories assigned to individuals all the time, but having a meaningful rotation capability - i.e. it should be the norm that each story should have more than one person in the team who has a reasonable chance to implement it.

In a team of senior experts as you describe, these three points tend to nil.

In my experience, these teams either continue happily like this until something happens to one of them, and then lamentation ensues. Or a product owner or Scrum master (or however the role is called) appears who puts a strong focus on the process.

I would suggest this:

• Pick one agile process that you like and which fits the product or service you are responsible for. I use Scrum for this answer just as an example.
• Step by step, pick "artifacts" from that process, and implement them on top of whatever you have - if applicable, replacing whatever is in place now. The following is the usual aspects you are used to if you are familiar with agile, just a little reframed for the issue at hand. For example, if you pick Scrum:
  • Create a daily standup if you do not have one yet. If you already have one, and if it is the usual half hour where just "anything" is discussed with no measure whatsoever, focus on changing it to the 30-45s per person, "have done - will do - impediment" format, postponing all further discussion to separate sessions afterwards.
  • Introduce weekly refinement sessions with the team separately from the Sprint Review / Sprint Planning artifacts, to work on speccing out the stories for the next sprint.
  • Tighten down review/planning sessions; i.e. if you had sprints before, and if the planning session was just a random mess, order it in a way where you do all the review in the first half - then consciously close the current sprint - then focus on the planning part.
  • During planning, really make sure that everybody who even is in the slightest technically able to takes part in estimations, to avoid individuals just "owning" their stories right from the get-go.
  • It may be OK to have names next to stories in the planning meeting already; but make sure that the implication of this does not necessarily mean that this person is the one implementing the story, but that it only means that this person is responsible for it - they must either implement it by the end of the sprint, or they must take care that someone else does it. If this does not useful, then leave the names off.
  • For each story, ask yourself or the team who can implement it, and if it is only one person, consciously find ways to bring at least one other person up to the task. This will drop overall speed, but this is to be accepted - know-how-sharing is sacrosanct and trumps basically everything else. Make sure that the product owner protects the team from outside influence (stakeholders complaining about reduced speed).
  • Really stress that the team focusses on finishing things at the end of the sprint; and don't regularly let uncompleted tasks slip through. This is an indication that stories were not cut correctly; which then makes it harder for other people not that familiar with the topic to jump in.
  • Use formal Pull Requests and enforce that the code reviews actually happen (a good metric is to look for any comments - a PR with no comment at all is a bad PR...).
  • Make sure to occasionally do retrospection meetings. In my experience, I would not even start to do them right at the beginning if your team is not used to them. Give it about 2-3 sprints, and then do a retro, so they have something to think about.
• Having a professional Scrum master can be incredibly powerful. They should know how to do these sessions (especially retros) in a creative, thought-provoking an efficient way. They are also out of the power hierarchy, so can really focus on moderating meetings if things get out of hand.

That's the "what". As to "how" to do all this: just do it. Tell them that this is the way it works now. Of course, if you are more of a lenient, cooperative person, which it looks like by your question, you can help matters by picking the easier measures first. Order does not matter that much, in the end. But still be firm about it. They will get used to it; if you do it right (assuming you have your agile process down correctly yourself) they will eventually see a benefit, or at least grudgingly take part. Feel free to optimize everything as much as humanly possible, don't waste their time with useless meetings; a long meeting which is chaos will be more useless than a shorter one which is strictly moderated.

Try to have a bit of fun too, and good luck!

Answer 7

By all means, the very first thing that I would do is to "talk to them." They are developers with a not-insignificant amount of experience working with the very thing that you are now going to be managing. If they are objecting, why are they objecting, and exactly what are they actually objecting to?

Using a minimum of "Agile terminology," talk about what you'd like to achieve, how you think the team might achieve it, ask them what they think, give them time to think it over, and then: listen.

You can't approach such a situation by "fiat." You have to use "persuasion." Knowing, however, that they are the well-seasoned "subject matter experts" and you are not. (Neither are you expected to be.) If you think that you have better ideas, you're going to have to sell it to them and get them on-board.

Answer 8

Beware of falling into the "We are doing Agile and we are doing Scrum" trap! Far too many people think that rigidly following a set of procedures is (1) the only allowable form and (2) means they are achieving the intent and goal of Agile. I recommend reading all of "Joel on Software" end-to-end, and also thecodelesscode .

Now, it's quite possible those senior folk are operating in a way which meets most of Scrum's intent except for those IMHO useless daily standups. Try to observe and evaluate how they are getting stuff done, and consider a compromise consisting of fewer meetings and more realtime interaction when blockers arise.

Answer 9

I like the idea behind Barnaby Golden's answer, "Just don't call it agile"

However, I want to go into more detail.

A lot of proponents of agile development use language that might not be understood by those unfamiliar with agile. The secret to getting co-workers to adopt agile development practices is to implement everything in terms of every-day English.

For example, avoid "I hope you will attend the Daily Scrum later this afternoon." What you call a "Daily Scrum", other people could refer to as "a business meeting."

The following words and phrases should also be avoided:

• Sprint
• Backlog
• Scrum Master
• deliver value
• servant-leader
• Burn-down Chart
• velocity (nothing to do with the physics of airplanes or baseballs)

If you want the engineering team to embrace agile development, you are going to have to translate all of the vocabulary words from agile terminology into plain English.

There are two types of people in this world:

• people who make information easier to understand.
• people who make information more difficult to understand.

When people use agile methodology to make information easier to understand, they are being productive. When agile methodology makes information more difficult to understand, you are adding friction to the system.

The goal is the produce better better products (better websites, better video editors, better cellphones, etc...). If you speak to engineers in a language they do not understand, then the engineers will be reluctant to work with you.

General	Instead of	Consider
Replace terminology from agile-development with plain English.	During the next sprint, we will focus on on replacing literal color specifications. Instead of making blue buttons we will have the code inherits from a parent color scheme.	During the next couple of weeks, we are going to focus on on replacing literal color specifications. Instead of making blue buttons we will have the code inherits from a parent color scheme
It is difficult to get rid of completely, but at least try to reduce the likelihood that people will ask, "what is an X?"	Bob: "The Marketing Manager will provide guidance to cross-functional partners." Jill: "What is a cross-functional partner?"	The Marketing Manager will provide guidance to co-workers who do a very different kind of work (e.g. people in human resources and logistics)
If a sentence can be split into two shorter sentences, then do it	The conversion of former US investment banking giants Goldman Sachs and Morgan Stanley into commercial banks (which have tougher capital requirements) had the unintended consequence of squeezing funding to hedge funds – which in turn has exacerbated their dumping of assets across world markets.	Goldman Sachs and Morgan Stanley used to be giants in US investment banking. They were converted into commercial banks, which have tougher capital requirements. This had the unintended consequence of squeezing funding to hedge funds. In turn, hedge funds began dumping assets across world markets.
Avoid the use of acronyms and initialisms	During the coronavirus epidemic all employees must wear appropriate PPE	During the coronavirus epidemic all employees must wear a doctor's mask
Use bullet points instead of paragraph style lists which separate items by comma characters and the word "and"	Our Company develops a best-in-class customer experience, drives sales, guides business decisions and meets financial goals.	Stack Exchange does not allowed bulleted lists inside of tables. As such, the following bulleted list will look messed-up. However, this bulleted list would be fine somewhere else. Our Company     * develops a best-in-class customer experience     * drives sales     * guides business decisions     * meets financial goals.