22

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?

12
  • 9
    Not an expert on the topic, but I see a few things that don't add up. As a Product Owner, you don't have (and shouldn't have) ANY repercussion over the dev process, so if one of your challenges is to "renew processes", those should be operative, not engineering ones. If they are using some form of scrum, and the devs are recluctant to follow such framework, then that's the scrum master's responsibility, not yours – Josh Part Jul 6 at 17:44
  • 7
    @JoshPart I wouldn't be so quick to dismiss the OP's issues. As product owner, he is the "customer", and he certainly has input on what should be delivered and when. He can set expectations that product increments be delivered at specific intervals and that the team participate in sprint review and sprint planning meetings. If they cannot deliver, because their processes do not allow them to deliver finished software in regular increments, he can put the onus on them to adopt those methods. – workerjoe Jul 6 at 18:58
  • 11
    @allad: If you go in thinking things are broken, you will have a tendency to also go in with some solutions to fix them. But realistically speaking, you didn't form your own opinion on the matter. You were provided with the opinion of your recruiter. That opinion might be accurate or it might not. You should wait until you start work to see what the situation really is. Then take it from there. And as others have mentioned, as a PO, whatever this is, isn't for you to fix. The SM has a great responsibility as well as everyone else. – Bogdan Jul 6 at 19:12
  • 1
    @workerjoe I'm not "dismissing" his concerns, I'm just saying he should double-check what his role really is (or what his role his recruiter expects to be). If the recruiter/project managers/bosses are the ones trying to make the POs tell the engineers/devs how to do their job, that might be where the real problem is. I agree with you: his job as a PO should be define requeriments and expect increments per the delivery schedule; what he shouldn't do is tell the devs what PM tool should they use, how long their sprints should be, etc. – Josh Part Jul 6 at 21:33
  • 1
    @workerjoe: Yes and no. The customer's demands are a strong incentive, but they are not equivalent to having the authority to dictate the dev process. If the developers are able to meet customer expectations using whatever dev process, then that's fine. If you are tailoring your customer expectations specifically to manipulate them into agile being the only possible way, for no reason other than to make them do agile, then you're overreaching as a PO. – Flater Jul 8 at 11:17
33

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.

5
  • 1
    I dont understand this. Its said in the title that the team has rejected agile, so why would you even float the possibility that they are agile in your answer? – Steven Penny Jul 6 at 21:27
  • 1
    @StevenPenny If "they are using a variation of scrumban methodology", that implies that the organization is attempting to use Agile methods, even if the team has rejected that. If the organization is truly trying to use the Agile methods, then they should have agile coaches and have retrospectives. – Thomas Owens Jul 6 at 21:32
  • 21
    People also react negatively to "agile" due to its (frequent) improper implementation. It is vital that whoever brings up "agile" actually knows what they are talking about, is doing it properly, and actually benefits the engineers instead of making it worse. – Nelson Jul 7 at 2:55
  • 3
    @Nelson a thousand times yes. I have seen to many "agile" projects which implement all kinds of shitty ideas and name it agile. When I quote the agile manifesto, I get labelled a fundamentalist. That thing isn't that big, it's worth it to read it firsthand to know what you are talking about. Very often, people reject the bad baggage non engineers try to add to agile. Most frequent one: Transforming dailies into status meetings. – Benjamin Jul 7 at 7:59
  • Comments that are not pertinent to the question and answer are removed. I'd suggest to raise a separated question about it to raise more value to the community. – Tiago Cardoso Jul 10 at 9:16
12

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.

2
  • 4
    Excellent answer right here. Whenever I encounter resistance to Agile as a coach I simply use the term 'feedback loops' instead. No one ever stands up in a group and says I don't like receiving feedback on our customers, code, working practices or decisions. – Venture2099 Jul 7 at 8:11
  • 1
    I just read a book with agile short stories and one story basically is about the issue of the OP. The agile coach in that story had the exact same solution. Agile/Scrum was rejected, so he just called it "the way of baby steps" (not sure about the English translation) and did agile without calling it agile. – Feroc Jul 13 at 20:31
7

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.

5
  • Thank you. Could you expand more on how project size can affect the need for specialization ? – allad Jul 7 at 6:54
  • 1
    @allad If projects are typically 3 man-months in size, then a single person can do the whole project on his own, and you can run multiple projects in parallel. If a project is 30 man-year in size, then you need a separate system architecture phase in the project where a small architecture team works out the changes to the architecture of the system, and divides the project into separate implementation chunks that can be run in separate sub-projects. – fishinear Jul 7 at 9:50
  • 1
    @allad Specifically for specialisation: for large projects there is usually a large enough part of the project in the specialisation area of the experts, and so they can work just in their specialisation. For example, you can have a dedicated UI team. For small projects, the developers typically need to be more universally schooled. – fishinear Jul 7 at 9:54
  • 1
    @allad By the way, that also reflects back on you as a product owner. With small projects, you need to do all the architecture work yourself. That makes you not only product owner, but also systems and software architect. If they run larger projects, there is typically a separate lead architect who takes on that role. – fishinear Jul 7 at 10:00
  • 1
    @allad To provide an example, I design embedded software at an electronics manufacturer. We have projects that have multiple man-years worth of effort required in several different specializations including, but not limited to, complex analog RF/microwave circuit design, complex digital circuit design, FPGA gateware design, driver development, GUI development, IPC (including protocol development and implementation,) operating system/platform setup, mechanical design, etc. Could I write the gateware and our FPGA guy write the driver? Probably. But both will be a lot faster the other way around. – reirab Jul 7 at 18:39
5

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.

1
  • You're right that them having work allocated individually is in itself an issue. I think the allocation is done by the engineering leadership, but a pull system would be ideal. I'll keep it in mind. – allad Jul 7 at 6:58
3

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.

1
  • 1
    Thank you for your comment. Your first link is exactly my greatest fear increased tenfold. I'll keep swarming in mind depending on what is exactly going on in the company. – allad Jul 7 at 6:52
2

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!

2
  • The big thing are merge requests. Each line of code should be understood by at least two people, one who wrote it and one who approved it. If you have that, and people accept it, many of the benefits fall into place. The reviewer must understand the requirement as well as the implementer, test coverage should be on the checklist, etc. – o.m. Jul 7 at 18:04
  • Excellent point, @o.m. – AnoE Jul 8 at 7:02
1

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.

1

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.

0

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.
8
  • 1
    I could be wrong, but it sounds like you're suggesting that people who use Scrum terminology are incompetent and try to make themselves appear smarter than they are? If that was not your intent, you should edit to clarify. – Sarov Jul 8 at 18:54
  • @Sarov. There are all sorts of business practices in the world. Some companies have employees pair-up into two-person teams having one experienced software developer and one less-experienced computer programmer. I do not know if is so-called "pair programming" is effective or not. However, I do know that if pair programming is effective, it will at least as effective if described using language which employees are more comfortable with. If you can adopt SCRUM practices without abusing the English language, then use SCRUM. – Samuel Muldoon Jul 10 at 18:12
  • 1
    While I don't agree (using proper terms can be used to both avoid confusion and for convenience - which is better: "hand me the thing with a handle, a long metal shaft, and four nubs on the end" or "hand me a Phillips screwdriver"? Sure, it's more confusing if they don't know what a Philips screwdriver is, but that's why you need to know your audience. To suggest to never use the term 'Philips screwdriver' because some don't know what it means is absurd), that's not what I commented about. There's nothing wrong with posting an answer others may not agree with. – Sarov Jul 12 at 13:37
  • 1
    My concern is that your answer appears to run afoul of the be nice guidelines. I don't mind you holding a different opinion than me, but as someone who uses Scrum terminology, I don't appreciate the statement that I am "[probably] incompetent, [with] nothing [to] say [that] is actually insightful". As such, my earlier comment. If that was not your intent, please edit to clarify. If it was your intent, your answer may be flagged for deletion as 'rude or abusive'. – Sarov Jul 12 at 13:37
  • 1
    As an aside, Scrum is not an acronym, thus there's no reason to put it as 'SCRUM'. – Sarov Jul 12 at 13:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.