• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What is the reason to have non technical project managers or non technical scrum masters?

 
Ranch Hand
Posts: 440
4
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have been working in managers who were technical earlier in their career and now they manage and guide the team. However now I have come across a manager who will be acting as our scrum master and also as our project manager. He is totally non technical person.What is the reason to have non technical project managers or non technical scrum masters instead of technical ? Also, how should the daily interactions with non technical managers or non technical scrum masters be like ?
 
Saloon Keeper
Posts: 7585
176
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Neither project mgmt nor scrum mgmt is inherently technical. While an understanding of the technical issues involved would of course be helpful (and will come to him over time, I'm sure), they're not required. I think it can be helpful to have someone who has no preconceived notions of "how things should be done"; such a person can bring a fresh perspective, and could act in a neutral fashion in any technical disagreements.

I don't know that the interactions would be any different. Obviously, you'd have to explain technical stuff more frequently to such a person.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Scrum Master is a coaching role. As long as the PM or SM can understand what is going on at a high level, it seems fine. Some projects are more technical than others. A non-technical PM or SM would probably do better on some projects than others. Just because some vocabulary is so technical it would require training to follow the standup.

Also, remember that projects don't have to be technical. For example, moving an office from one building to another is a project. And requires a project manager!
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What can be an example situation where a non technical scrum master or a non technical project manager can do better than the technical ones?
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:What can be an example situation where a non technical scrum master or a non technical project manager can do better than the technical ones?


When the non-technical person has better PM or communication or facilitation skills. Remember that being technical is just one skill.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My understanding is that for technical projects,  a good PM or Scrum master is the one who can get the team to complete the work faster and with good quality and that he would be able to get work complete faster with good quality if he has some technical idea of how they are doing it as compared to when he does not have technical idea of that.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Typical misconception of the scrum master role. Scrum master, as Jeanne mentioned, is partly a coaching role. They coach people on how best to collaborate and organize. There's a bit of irony there because agile teams are supposed to be self-organizing. In reality, there have been very few, if any, teams I have come across that are truly self-organizing. Most teams need help in not only their structure and communication but in their engineering practices as well. It is not the Scrum Master's job to get things done; it's the whole team's job. A good SM inculcates that idea on their teams. With collective ownership comes collective responsibility.

In reality, upper management often looks for that one neck to wring. This again is an anti-agile mindset that rolls downhill. So you get these anti-agile ideas that it's the SM's responsibility to crack the whip and keep developers in line. Bad, bad, bad.

A true SM protects their team from outside pressures. They coach their teams on how to organize. They protect the process and keep the work being done aligned to the process boundaries and parameters. If they are non-technical, they find a good technical coach for the team. The SM is a problem solver. They help the team deal with impediments, like upper management bugging for "just this one little feature" or pressuring to meet some arbitrary deadline. The SM is not a PM. That is another anti-pattern if they behave like one.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeanne Boyarsky wrote:

Satyaprakash Joshii wrote:What can be an example situation where a non technical scrum master or a non technical project manager can do better than the technical ones?


When the non-technical person has better PM or communication or facilitation skills. Remember that being technical is just one skill.



If someone is taken as non technical manager because he has better PM or communication or facilitation  skills,  still it would be always possible to have a person who has these PM or  communication skills   and facilitation skills as well as he is technical then why choose a non technical person .

A has good PM, communication, facilitation skills.
B has good PM, communicating, facilitation skills plus technical skills.

Then would one not choose B?
 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:

Jeanne Boyarsky wrote:

Satyaprakash Joshii wrote:What can be an example situation where a non technical scrum master or a non technical project manager can do better than the technical ones?


When the non-technical person has better PM or communication or facilitation skills. Remember that being technical is just one skill.



If someone is taken as non technical manager because he has better PM or communication or facilitation  skills,  still it would be always possible to have a person who has these PM or  communication skills   and facilitation skills as well as he is technical then why choose a non technical person .

A has good PM, communication, facilitation skills.
B has good PM, communicating, facilitation skills plus technical skills.

Then would one not choose B?



Yeah, more can be better. If C is a person who is Jeff Bezos, Martin Fowler, James Whittaker and Tom Cruise all rolled into one, then I'd hire C over B. If you have a need and budget for C, then go for C.

PS - Are you seeing any issues in working with a non-technical manager? If yes, then mention those problems and how they affect you. Otherwise, every discussion is vague and theoretical.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:
A has good PM, communication, facilitation skills.
B has good PM, communicating, facilitation skills plus technical skills.

Then would one not choose B?


The way you ask this question makes me think you're in a less than ideal situation made worse by a misunderstanding of what the Scrum Master role entails. Some of the best SMs I have worked with were non-technical. This allows them to be totally detached from the problems the team has to deal with and able to objectively facilitate a solution.

I'm curious, what/why do you think being a good PM has anything to do with being a good SM? Teams making the transition from traditional waterfall to Agile usually default to having their former PMs take on the SM role. Sometimes this works but often it doesn't because the person continues to act like a PM rather than an SM. I'd encourage you to understand the difference between a Project Manager and a Scrum Master
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:A has good PM, communication, facilitation skills.
B has good PM, communicating, facilitation skills plus technical skills.

Then would one not choose B?



There are less B's in the world. Many of them don't want to be a SM/PM. Why not have an A who is more likely to be happy in the role?
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:. . . good PM, communicating, facilitation skills plus technical skills.

Then would one not choose B?

As Jeanne said, such people probably prefer to use their technical skills.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeanne Boyarsky wrote:

There are less B's in the world.



Is having good communication, facilitation and management skills so difficult for a technical person to have?  I used to think developing skills to manage developers who have lesser experienced than one is a natural skills for a more experienced member of development team (technical person).
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:. . . Is having good communication, facilitation and management skills so difficult for a technical person to have? . . .

That isn't what Jeanne said.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:Is having good communication, facilitation and management skills so difficult for a technical person to have?  I used to think developing skills to manage developers who have lesser experienced than one is a natural skills for a more experienced member of development team (technical person).


This is the kind of mindset that leads to thinking that PMs with technical skills will make good Scrum Masters.

Leading is different from managing. Coaching and mentoring is different from managing. A senior technical person on a good agile team is a leader/coach/mentor, not a manager.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A good manager of an agile team spends most of their time looking outside of the team, finding opportunities and work for the team, making sure that the team's work stays aligned with the larger business/organizational strategy and direction. A good agile team will only need their manager's help when it involves setting vision/strategy/direction, when they need facilitation to collaborate with other parts of the organization they are not in direct contact with (and when the Scrum Master can't facilitate those collaborations), to make sure budgets are sufficiently appropriated to team to meet their needs.

Good agile teams should be able to manage their own work. If a team needs someone else to manage their work for them, then they need more coaching on how to self-organize and self-manage. This is when a good Scrum Master and/or a good manager will step in to get the team to where they need to be.
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:Is having good communication, facilitation and management skills so difficult for a technical person to have?  I used to think developing skills to manage developers who have lesser experienced than one is a natural skills for a more experienced member of development team (technical person).


In any case, I wasn't talking about skills. I was talking about interests. I turned down the "opportunity" to be a manager a number of years ago. I don't want to have managing people replace the more technical aspects of my job. I like mentoring and leading, but that's not management as Junilu mentioned.

Note: I am a Scrum Master for my team as 25% of my job. So I am a technical SM. It's not the ideal arrangement and it isn't easy to make it work.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeanne Boyarsky wrote:
In any case, I wasn't talking about skills. I was talking about interests. .



OK. Understood that it is about intrest too.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Leading is different from managing. Coaching and mentoring is different from managing. A senior technical person on a good agile team is a leader/coach/mentor, not a manager.



Thank you. that was a useful basic point for me to understand.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:A good manager of an agile team spends most of their time looking outside of the team, finding opportunities and work for the team



Thanks.Understood it .
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:A good manager of an agile team spends most of their time looking outside of the team, finding opportunities and work for the team



,

Thank You.I understand that he would be spending time outside team interacting lot with the customer and also with higher management. For 'finding opportunities and work for the team' , is it not the work of sales team rather than manager?
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote: I'd encourage you to understand the difference between a Project Manager and a Scrum Master



Sure. I will read that.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:
Leading is different from managing. Coaching and mentoring is different from managing. A senior technical person on a good agile team is a leader/coach/mentor, not a manager.



Understood this. Are there ways to practice and develop some of these skill of leading/coach/mentor on our own without anyone asking us to be in that role and giving that chance?
 
Tim Moores
Saloon Keeper
Posts: 7585
176
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote: i understand that he would be spending time outside team interacting lot with the customer and also with higher management. For 'finding opportunities and work for the team' , is it not the work of sales team rather than manager?


I think you misunderstood "outside of the team" to mean "outside of the company", but that's not what it means. Inside of the company, for the team - clearing away obstacles, working with other departments, improving working conditions etc.
 
Ranch Hand
Posts: 271
1
Android Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Project management is not a technical role in the sense that it requires the person to code or set up a network. It requires a lengthy course to become an accredited PM. Typically the PM liaises with management and multiple stake holders in the project to solicit business related detail, as well as with CIO for team building, skillset requirements etc. This is where the projected requirements for skillset, contractors and consultants are identified. One of the most important output is an agreed-upon, top-down project plan, and money is made available based on phases and deliverables. Again, here is where the PM recommends hiring contractors, outsourcing or not. The PM is responsible to management for the implementation of agreed business functions for each phase of the project, based on the aforementioned project plan.

The PM, however, should have a good understanding of the business e.g. investment banking - capital markets or supply chain - automotive. In this context, PMs will have to liaise with business analysts. Many PMs are hired based on their experience in the industry. An important criteria is the ability to interact with senior management  and I have seldom ever found technical people, particularly coders, able to talk indepth with business, let alone senior management. Remember, PMs are part of the team that identify the needs (what business advantage would it give us) and put a cost on the project. Some projects have tangible benefits, others are defined by regulatory requirements, again PM are involved in that, coders less so.

Based on pass experience, a lot of work and reports, agreements and accounting would have been done before coding starts. I found that the business side is often frustrated with technical people, particularly coders, and rather not interact directly, which can have unintended results. So, yes, it's helpful if PMs have some technical skills, at least to the extend they can communicate their requirements to coders and developers.

Also, PMs should have much closer contact with data architect to create data models of the business to be automated, as well as DBAs and the system architects because they have to operationalize the product with the hardware and network at their disposal. Again, decisions on cost and hiring contractors or not.

Those are my experience. I am not a professional coder.
 
AhFai Chan
Ranch Hand
Posts: 271
1
Android Eclipse IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

What if I require a PM to implement a project based on Basel III framework for compliance with global financial stability, with emphasis on capital market; capital adequacy ratio and liquidity. Prior exposure to repurchase agreements highly regarded. The will have to be comfortable interacting with senior management from bank, regulatory commission, with SEC and Treasury. Some interactions with EU counterparts required.

Would that result in an I.T. project? Oh yes, a few, they may even have project plans that report to a master project plan

Would you be comfortable sitting in a conference room meeting with these people, talking a language you probably don't understand? Would you be productive writing reams of project reports?  If not, then leave that to the PMs.

That said, what you want is a technical PM specializing in I.T. projects. That may be the career stream you are looking for, and I have seen quite a few of those. Yes, it helped that these PMs understand tech, perhaps was a techie. But you still have to deal with people, talk with them, communicate.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you. There are differences between all roles and I will read more about that. I understood  experienced members will be having leadership not necessarily manager skills.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Found the below link useful for understanding the differences between the roles of manager,scrum master ,leader.

https://aimconsulting.com/wp-content/uploads/2015/10/infographic_team-work_design_8.pdf
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:Found the below link useful for understanding the differences between the roles of manager,scrum master ,leader.

https://aimconsulting.com/wp-content/uploads/2015/10/infographic_team-work_design_8.pdf


You might want to cross-reference that document with the information found here: https://www.scrumguides.org/scrum-guide.html

Some questionable/debatable statements in the document you cited:

The product owner protects the project team from external stakeholders that want their requirements implemented.


This is something the Scrum Master is supposed to do, not so much the Product Owner

From the Scrum Guide:

The Scrum Guide wrote:The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.


The product owner is responsible for documenting requirements and their priority.


The Scrum Guide has something slightly (but I think significantly) different:

The Scrum Guide wrote:The Product Owner is ... responsible for ...:
* Clearly expressing Product Backlog items;


How all that is documented and who documents it is not prescribed. Ideally, the requirements are discussed by the Product Owner with various members of the team and all important information captured somehow by someone involved in the discussion. It could be as simple as a rough sketch on a whiteboard that someone takes a picture of and keeps in a shared directory. Another way to do this is by creating executable specifications like Gherkin feature specs and then using Cucumber to generate and execute tests. This is what Behavior-Driven Development (BDD) is about.

I could go on but you can read the Scrum Guides yourself and see where it differs from what that document you cited claims.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:Found the below link useful for understanding the differences between the roles of manager,scrum master ,leader.
https://aimconsulting.com/wp-content/uploads/2015/10/infographic_team-work_design_8.pdf


The more I read of that document, the more I find myself saying "No, not really." This is the kind of stuff that usually leads to "Dark Agile"
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Moderator note: long quote deleted]

Thank You for the good reference link.
It talks about the scrum master and product owner in addition to the information on scrum practices.

Although , it talks about scrum master and product owner I am also looking for a reference which talks about other members too and in addition to these talks about project manager ,team leader ,business analyst ,architect all at one place .Although the link I had shared had all these at one place ,but he content as incorrect at some places as you had pointed out .

In the link which you shared ,it is written about development team that Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
What does this mean ?
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
What does this mean ?


It means that Scrum doesn't care about specific titles. If you're on the development team, you're on the development team. The other implication is that a development team is cross-functional and that its members have multiple skills. In some places, they call this being "T-Shaped". In other places, they refer to this as being "Full Stack". Essentially, the framers of Scrum don't care about the distinctions between DBA, Developer, Front-End guy, Back-End guy, etc. The team is expected to collaborate on the work and each member brings his or her own set of skills to bear on the problem. In other words, it takes the Whole Development Team to solve a problem and each team needs to self-organize so that team members work effectively and collaboratively with each other.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Satyaprakash Joshii wrote:Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
What does this mean ?


other places, they refer to this as being "Full Stack".Essentially, the framers of Scrum don't care about the distinctions between DBA, Developer, Front-End guy, Back-End guy, etc. The team is expected to collaborate on the work and each member brings his or her own set of skills to bear on the problem.



Not sure if I understood this completely .For instance if it is known that someone's title is DBA, then he would not be given say front end coding work and DBA work. If title is not looked into he may be given say front end coding work and he may waste time during the sprint as he may not have that skill .

Or does it mean that each and every member of development team needs to be a full stack developer. But then not every developer in the industry is a full stack developer ,only a fraction are so.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:For instance if it is known that someone's title is DBA, then he would not be given say front end coding work and DBA work. If title is not looked into he may be given say front end coding work and he may waste time during the sprint as he may not have that skill .



Well, no. Junilu said "The team is expected to collaborate on the work." Your question seems to be based on the idea that there's somebody higher up who is distributing the work, which is not the same at all.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's where there's a disconnect: you are looking for a prescriptive formula for how work should be divided up. Scrum doesn't care. Scrum is a framework. All Scrum "prescribes" is that The Team should be self-organizing and they should collaborate to get the work done. That's it. Many people, however, don't seem to be satisfied with that. They don't get it because they want Scrum to fit their world to the letter. They want to map the purposely vague "Self-organizing team" to "We have distinct roles and responsibilities for BA, Analysts, Designers, Front-End Developers, Back-End Developers, Tech Leads, DBA, Architects, etc."

There's no way Scrum or Agile can be that prescriptive. Anyone who says otherwise is trying to sell you something that ISN'T what Agile was intended to be. That's why I said it's the sort of stuff that leads to Dark Agile, Fake Agile, Faux Agile or whatever other name you want to assign to something that claims to be Agile while going against the principles and values of the Agile Manifesto.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
While the work will be assigned by development team itself, but within development team a front end coding work cannot be given to a DBA.For this would the dev team not require to know that one of their team member's  title is DBA.?
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let me give you an example of the team I was on where I learned most of what I know about being Agile.

There were more or less about six of us on the team. I was the tech lead. I was also a developer. I also did DB stuff. I also did production support. I also did UI stuff. I also did documentation. I also did requirements gathering. I also did architecture and design. The other developers on my team also did a lot of the same things I did. We had one guy who did only testing. We taught him how to automate the testing. We developers also did a lot of testing. That's because we did TDD. We did mob programming before mob programming was even a thing. We also had a guy dedicated to doing DB stuff. His official title was DBA. He was still part of our team.

The thing about our team was that even though we had official titles like Technical Leader, Senior Developer, Developer, DBA, Quality Assurance Engineer, we really didn't let those titles bind us to specific jobs. We just organized around the work based on what each of us was good at as well as what each of us could contribute to. This is what self-organization is about. Our manager didn't have to hover over our shoulders and tell us what to do every day. We just saw work and decided amongst ourselves how we would divvy it up. In fact, our manager hardly ever had to do anything apart from approve leaves and requests to go to conferences or training courses, and doing our performance reviews once a year. Our manager was out there trying find us more work to do. Ok, once in a while we'd also ask her to help us when we were really stuck and couldn't resolve a problem by ourselves.

THAT is the kind of self-organization that Scrum/Agile expects of teams.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:While the work will be assigned by development team itself, but within development team a front end coding work cannot be given to a DBA.For this would the dev team not require to know that one of their team member's  title is DBA.?



The question is not whether team members have specific titles or whether or not team members have specialties. The questions is "Does Scrum/Agile care about these?" The answer is a big fat NO. Scrum/Agile assumes that people have enough common sense to decide how to divide up the work they need to get done. Each team will be different. That's why there's no way Agile/Scrum can prescribe specific roles like that document you cited did. That's not for Agile/Scrum to decide. That's for each team to figure out themselves, according to their own particular circumstances. Don't look to Scrum/Agile to tell every single thing you need to do. Use your common sense. In Scrum, there's only the Development Team, the Scrum Master, and Product Owner. Those are the only specific roles that Scrum has because those are the only roles it cares about with regard to how the framework works. That doesn't mean, however, that you can't have DBAs, BAs, Front-End Developers, etc. That's up to you and your team to decide. If that's how you want to organize yourselves, that's fine. But as far as Scrum is concerned, it doesn't really matter.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Think of Scrum as an interface. It defines a "contract" -- well, in the case of Scrum it defines a framework. But think of "contract" as an analogy for "framework."  Each particular team is an implementation. When you program to an interface, you really don't care about what the implementation does underneath, as long as it adheres to the "contract" defined by the interface.

Likewise, Scrum as an interface/framework only cares about defining the roles of Development Team, Scrum Master, and Product Owner. How your particular team implements that is up to you, as long as those roles exist in some form or fashion, it's fine with Scrum. Underneath the "contract"/framework, you may have an implementation that includes a Tech Lead, a DBA, QA, front-end, back-end, coffee boy, pizza delivery guy, plumber, pilot, whatever. These specific roles have nothing to do with Scrum. Scrum doesn't care, just as the List interface doesn't care if you use a linear sort algorithm, quick sort algorithm, or a random sort algorithm behind the sort() method. Again, it's up to you to decide those kinds of details. Just as List only cares that an implementation provides some kind of sorting capability, Scrum only cares about the three roles and not the forty-seven different titles your team might actually have.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your line of questioning strongly suggests to me that you and your team either
1. Don't have enough all-around experience to have a holistic view of your work or
2. Your project is bigger and more complicated than what an ideal two-pizza sized team can manage by themselves or
3. You come from a traditional development background where work is very siloed and where "crossing the streams" is an unimaginable thing to do or
4. You and your team are so used to being told what to do or working in silos that you're left completely at a loss when told to "go figure out how to divide the work amongst yourselves" or
5. Some combination of one or more of the above.

A couple of things you can do about this:
1. Hire a coach to guide you or
2. Try something. If you fail, try something else. Keep trying something else until you find something that works. Repeat this process every time you do something that doesn't work. And if you're not failing, then you're not doing it right. The road to continuous improvement is paved by failure.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic