Forums

By posting to our forums you are agreeing to the Forum terms of use.
Dealing with wide domain gap?
Last Post 29 Aug 2012 01:55 AM by Dominik Maximini. 1 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
per.fagrell
New Member
New Member
Posts:1
per.fagrell

--
28 Aug 2012 07:49 AM
    My company has an issue I've never heard anyone talk about or address directly, which I feel is inhibiting our ability to really get the most out of scrum. That is how do you handle a wide technology domain gap? We design hardware in verilog, keep a C++ simulator thereof and have a tool chain mainly written in python. The issue this causes is that the software developers (especially the python devs) can't really help the hardware developers in any meaningful way (hardware design is nothing like software design). This has caused stories to be divided into a specific hardware team (bad) or they have fallen on the hardware developer(s) in a cross-functional team - effectively creating a subteam (also bad).

    What kind of strategies are useful for helping the teams work together as much as possible and finding ways of helping each other even when some of the developers don't have the skills necessary to implement a story? And perhaps more importantly, am I asking the right question?
    Dominik Maximini
    New Member
    New Member
    Posts:64
    Dominik Maximini

    --
    29 Aug 2012 01:55 AM
    Hi Per,

    And perhaps more importantly, am I asking the right question?


    I am not sure. Scrum just showed you that you have a major issue outside of Scrum, which you might want to address. Maybe you can sit together with your Team and find out if there are other ways of creating the product you are dealing with. After all, you most likely don't want Python, C++ and so on, but you want a working product at the end of the day.

    This has caused stories to be divided into a specific hardware team (bad) or they have fallen on the hardware developer(s) in a cross-functional team - effectively creating a subteam (also bad).


    If you can't solve the underlying issue right away, think about the following: You will always have specialities in your Team. This won't change. However, the vision and goals should be the same for everybody. Now think about a Product Owner who makes sure everybody can grasp the vision with their hearts and heads: Would all of your teammembers then work together to achieve it? May there be a subteam or not, they would all follow the same goal. It could be possible that your "User Stories" are actually not horizontally cut right now.

    In the past, I have had several Teams dealing with Hardware, Firmware and Software at the same time. They all ended up having their special skills and dividing their tasks accordingly. However, the good Teams self-organized this and always stayed on track. We just had to look out for the creeping waterfall: This happens if some people have to wait for other people to finish something ("I do the hardware this Sprint, you take care of the firmware next Sprint and the one after that we start with the Software..."). The Sprint goals, and most often the Product Backlog Items as well, were cross-functional and allowed the Teams to form around them.
    By the way: After some time, the Teams always started to share skills, so non-experts could support the experts if there was a bottleneck. But again, this was something the Teams figured out themselves.

    Hope that helps

    Dominik
    You are not authorized to post a reply.


    Feedback