Forums

By posting to our forums you are agreeing to the Forum terms of use.
Struggling against questions not Scrum
Last Post 05 Nov 2013 06:03 AM by Ian Mitchell. 15 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
Illya Pavlichenko
New Member
New Member
Posts:36
Illya Pavlichenko

--
26 Oct 2013 03:59 PM
    After attending PSMI class with Gunther at Brussels I tried the PSMI again and scored only 94% (I had 96% before)

    This result pissed me off. But more than that, I understood that I was really fighting against the questions, and not my Scrum knowledge leaks. Some of the questions were SO not clear that I could hardly tell what they really asked. Maybe that is due to the fact that I'm not a native english speaker and maybe I don't get a full range of tiny details in questions, maybe something else. But this is really annoying. Let me give a few samples:

    1)A very simple question:

    During Daily Scrum, the scrum master's role is:

    teach the Dev. Team to keep the time box
    facilitate discussions
    other options...

    The questions is extremely easy, BUT from Scrum Guide we learn that SM is optional for Daily Scrum.
    So both facilitating discussions and teaching to keep the time box would be right options IF SM attends the Daily Scrum. In case he doesn't - only teaching to keep the timbox is valid. So what would be a right answer?

    2) The question:

    The purpose of the Sprint is to have a working increment of product done before the Sprint Review.

    From Scrum Guide we learn that it's "potentially releasable increment" that Dev. Team has to deliver by the end of the Sprint. Does it mean that we can't call it just "working" in a question and thus it's wrong or? There's some strange ambiguity here.

    3) Another question:

    The primary reason one might choose a four-week Sprint is when the work is too large for a two-week Sprint and cannot be decomposed further.

    Again, strange formulated questions... the work PRIMARY. Who has the statistics available for validating this? Is there any research showing which is the primary reason for choosing 1 month Sprints. I don't think there's anything like that available. That's why I put false, though I understand it often happens. But what the bias behind this questions - no idea.

    4) As quality assurance work does not occur as part of the development work in Sprint, which benefits are lost?

    QA is not about testing, controlling and validating, but about Process and improving. Thus, QA is performed during Retro each Sprint by the Scrum Team. On the other side- Quality Control is about testing and controlling the quality of the Product (not the Process). Looking at the possible answers - I could say that the answers really meant Quality Control (testing) and not Quality Assurance. That really confused me.

    5) Can a team deliver a single document by the end of the Sprint if this it's what the PO asked for?
    What if DoD is compatible with it and so this is the releasable increment of Done product. Again, I was confused with this question and it doesn't say anything about what the DoD is for this team. Behind that, I guess that the Development Team should only deliver the releasable potentially shippable increment of Done product by the end of the Sprint. And SM is to remind about this to the PO.

    6) A Sprint Review is the only time the stakeholders and the Scrum Team meet together? Again, formally yes, because "during Sprint review the Scrum team and stakeholders collaborate about what was done in the Sprint"

    Any thoughts on this?




    Derek Davidson
    New Member
    New Member
    Posts:6
    Derek Davidson

    --
    28 Oct 2013 05:07 AM
    Hi Ilya

    (Disclaimer: Ilya and I attended the same course with Gunther)

    It's been a year since I first took the PSM I and what I've learned in the intervening year is that Scrum is not black and white. It has many shades of grey. This makes it more difficult, in my view, to answer some questions as they require the fundamental knowledge of Scrum, without experience clouding the question.

    To address some of your points:

    1. "The questions is extremely easy, BUT from Scrum Guide we learn that SM is optional for Daily Scrum.
    So both facilitating discussions and teaching to keep the time box would be right options IF SM attends the Daily Scrum. In case he doesn't - only teaching to keep the timbox is valid. So what would be a right answer? "

    To me, of the two options you propose, the right answer would be "Keep the timebox." The reason is that I don't think the ScrumMaster has a role in facilitating discussion at the Daily Scrum at all. Quite the contrary. We often have to remind ourselves to NOT get engaged as the Development Team update each other. But then, this could be my experience clouding the question :)

    2. I think the phrase "potentially releasable" simply means that the Development Team have met the Definition of Done. That there is no other work remaining. That the PO could release the product if they chose to do so. Therefore, the phrase from the question: "working increment of product done" seems to me like it means the same thing.

    I'm unclear on what you're asking in the paragraph about QA?

    3. The question "Can a team deliver a single document by the end of the Sprint if this it's what the PO asked for?" I think the answer is "Yes" (especially if the question makes any reference to delivering value to the organization). I don't believe the DoD is intended to apply to every Product Backlog Item that may be worked on, especially when we recall that PBI's can refer to Functionality, Defects, Non-Functional Requirements etc.

    4. "A Sprint Review is the only time the stakeholders and the Scrum Team meet together?" I wouldn't agree with this. There's is nothing to stop the PO, for example, from requesting stakeholders to attend a Product Backlog Refinement session where doing so would aid the Development Team.

    Hope the above helps and I'd be very interested in reading anyone else's views on the above and Ilya's initial questions.
    Illya Pavlichenko
    New Member
    New Member
    Posts:36
    Illya Pavlichenko

    --
    28 Oct 2013 06:03 AM
    Derek, I also don't believe that DoD should apply to every PBI in a Backlog. DoD is applied to the Increment.
    But I'm convinced that each Sprint the Team should bring at least a small piece of functionality - otherwise you won't have any Increment.
    I you bring only document by the end of the Sprint - the question is "where is the Increment"?
    Derek Davidson
    New Member
    New Member
    Posts:6
    Derek Davidson

    --
    28 Oct 2013 07:44 AM
    Hi Ilya

    I think it may have to do with the perspective of the document.

    If the product under development was a complex legal reference title, then it's easy to see how a document produced during the Sprint would be an increment.

    But equally, one of the requirements for a piece of software could be a complete help / guide document so again, this would be an increment of the product.

    At least, that's the way I'm looking at it.
    Wallace
    New Member
    New Member
    Posts:4
    Wallace

    --
    28 Oct 2013 09:04 AM
    Hi, I'm a Scrum newbie, but I found this discussion interesting.
    Here's my take:

    1) The question is written in a way ("During") that implies for me that in this particular case the SM is attending. But should he "facilitate" discussion? I'm not a native English speaker but they way I've understood it is it means he helps keeping discussion flowing without actively participating with it (regarding content) so the answer would be correct. But the timebox is definitely more important.

    2) I'm with Derek here. "working" can mean the product can be released.

    3) That's awkward for sure. There's a similar question in the open assessment where the correct answer is "false" but the word "primary" is missing there AFAIK. I guess this was part of research work done by the Scrum heads and could be documented somewhere, maybe in "Software in 30 days" which I haven't read.

    4) To be honest, the phrase "quality control" is new to me. I've always used "QA" for what you described as quality control: writing and documenting tests, making reports of their outcome. The questions doesn't seem to be very Scrum oriented to me, it's more about the software development process. Eventually they want to emphasize that the sprint includes all SW development tasks (from design to testing) in a single iteration.

    5) Well, If the product is the document itself, it makes sense. The question sounds like it (the team delivers the document, apparently nothing else). I don't find this particularly clear, though.

    6) The PO belongs to the team and he can be in permanent contact with the stakeholders..., so "no". Actually I think that's part of a whole series of questions that want you to answer "inspection and adaption can happen anytime", only adapted to different cases.
    Wallace
    New Member
    New Member
    Posts:4
    Wallace

    --
    28 Oct 2013 11:33 AM
    Hi Ilya,

    I just took PSM I and promptly ran into your 1), so I want to make additional comments. The presented answers forced me to reconsider because one of them was "ensures every dev team member answers the three questions" which would mean the SM has a more active role as I was willing to allow him. So I finally settled on the "timebox" answer instead of choosing "all answers", because it was that prominently placed in the Scrum Guide.

    However, I don't have 100% so that could've been one of the questions I answered wrongly.
    Prabhu Missier
    New Member
    New Member
    Posts:26
    Prabhu Missier

    --
    28 Oct 2013 11:04 PM
    One irritant is that there was no feedback at the end of the test which would give me a list of my wrong answers. Quite unlike other certification bodies for Scrum
    Gunther Verheyen
    New Member
    New Member
    Posts:26
    Gunther Verheyen

    --
    29 Oct 2013 02:54 PM
    Fortunately there is more to Scrum than only what is literally described in the Scrum Guide. And, still, the Scrum Guide does describe important behavior and principles and is therefore quite a rich document, despite the limited #pages.

    Think also in terms of how Scrum respects and implements the principles of the Manifesto for Agile Software Development. One of them says that the primary measure of progress of working software. Where would we end up if we start accepting again that a document is enough, and the absence of a working piece of software is good?
    andronix
    New Member
    New Member
    Posts:1
    andronix

    --
    29 Oct 2013 03:32 PM
    @Gunther Great, I didn't believe that delivering a single document is possible.
    Every Sprint we should find ways to deliver at least a small piece of functionality.
    Same even for the very first week - when we setup environment, prepare the future requirements - at the end we should show an increment. Even if it's tiny.
    Nitin Khanna
    New Member
    New Member
    Posts:47
    Nitin Khanna

    --
    29 Oct 2013 11:06 PM
    Hi Illya,

    Nice to see you on the Scrum.Org forums. Allow me to share some of my thoughts…

    Its been a while since I took the assessment, so I’ll try to remember what I can. There are also some great comments by others, so I am offering some different examples.

    For (1) –
    We know that the SM is not needed at the Daily Scrum. This implies that anyone from the Dev Team can facilitate. Here’s what I thought -- perhaps the SM can schedule a 15minute meeting using people’s calendars.

    For (2) --
    I agree with you. i.e. “potentially releasable increment” – my interpretation for this is that not every Sprint backlog item may be done, by the Review.

    Also, when talking about “Sprint 0” (which we know isn’t recognized in Scrum), I hear instructors mention that its better to have a little bit of the increment, rather than just analysis, etc.

    For (3) –
    I don’t recall the question and am a bit unsure whether I follow you completely.

    I’m unsure whether its about statistics. I think its simply about the flexibility of the framework, where the max is 4 weeks.

    For (5) –
    Yes!
    Here’s how I thought about it – the PO orders the backlog items and the Dev Team pull it into the Sprint backlog. They are not taking on the risk of ROI, amongst other items which is the responsibility of the PO.

    Also, think of it this way – the DoD may not have evolved or mentioned anything about documentation (poor, in my opinion and would evolve). Furthermore, perhaps this was a shorter Sprint near the holidays or where there were some unusual circumstances so the team may have suggested to work on documents, instead of heavy coding and the PO agreed.

    Also, consider that perhaps some Sprints have passed and a future Sprint has a focus on documentation. Not good practice, in my opinion, as it reminds me of “hardening sprints” (not recognized in Scrum, again) – but it is possible and this *adds* to the increment.

    For (6) –
    There may be an opportunity for the stakeholders and the Team to collaborate even prior, as more is learnt or work emerges.
    Nitin Khanna
    New Member
    New Member
    Posts:47
    Nitin Khanna

    --
    29 Oct 2013 11:10 PM
    @Prabhu,

    This was annoying to me as well.

    However, I was pleasantly surprised at the quick turnaround when I reached out to the Support team and got some feedback. (Not exact questions, but which areas to focus on.)

    May not be a perfect scenario, but just sharing in case you haven't considered this option.
    Derek Davidson
    New Member
    New Member
    Posts:6
    Derek Davidson

    --
    30 Oct 2013 04:31 AM
    @Illya @Gunther : This gives me pause for thought. Here's why:

    Scrum is a framework for complex product development. It's not limited to software development (but lends itself to that really well).

    The Agile Manifesto, which DOES limit itself to software applications states "We value working software over comprehensive documentation" and The Agile Manifesto principles, which DO limit themselves to software applications, states "Working software is the principal measure of progress" and "Working software is delivered frequently (weeks rather than months)"

    So, in the question under discussion, (Can the Development Team deliver a single document at the end of a Sprint, if that is what the Product Owner asked for), if we use the Scrum as our guide, the answer is "Yes". If we use the Agile Manifesto, the answer is "No".

    When taking the PSM I assessment, my view is that we're answering questions on Scrum. (ie: We're NOT limiting ourselves to software products)

    Gunther: Your answer to Illya seems to say that this view is wrong?
    Illya Pavlichenko
    New Member
    New Member
    Posts:36
    Illya Pavlichenko

    --
    30 Oct 2013 05:20 AM
    I'm sure (and absolutely agree here with Gungher) that Scrum should respect and implement the principles of the Manifesto for Agile Software Development. Scrum is a reflection of Manifesto and though Scrum can be used outside the IT industry (as you, Derek said), we have to remember what it means to be Agile.

    To be Agile means conform (don't like this word, but...) to Agile Manifesto values and Principles.
    You can work without Scrum, but still be Agile if your process is respects Manifesto principles, but you cannot do Scrum if you don't implement Manifesto.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:562
    Ian Mitchell

    --
    30 Oct 2013 05:30 AM
    Scrum is primarily, but not exclusively, about the delivery of software. As such a release could consist of a document and no software at all.

    Scrum could be used by magazine publishers, for example. Each Sprint (month) they could release a new issue (a document) which consisted of several user stories (perhaps articles or real stories) that satisfied the Product Owner (editor) met a Sprint Goal (the topic of the issue) and a Definition of Done that was agreed with the production team.
    Gunther Verheyen
    New Member
    New Member
    Posts:26
    Gunther Verheyen

    --
    04 Nov 2013 01:15 PM
    Let me complicate things even more :-)
    Scrum, with its implementation of empiricism and as a 'new new product development game', can be applied on any type of complex product development situation.
    However, the Scrum framework as we know and teach it, has been optimized for software development. Software development is the natural habitat of Scrum.org and most of its community members too. I can't judge whether the way we describe the rules, the accountabilities, the meetings, etc. are just applicable in other domains without tweaking them to that context.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:562
    Ian Mitchell

    --
    05 Nov 2013 06:03 AM
    > I can't judge whether the way we describe the rules, the accountabilities, the meetings,
    > etc. are just applicable in other domains without tweaking them to that context.

    I doubt anyone can really do that. Just look at the cases we have in software development where clients tell us that "Yes we are sort of doing Scrum, but Scrum can't work that way here because..." or "We are special here because..."

    Now try applying Scrum outside of the IT sector, where we face domain experts who can cite their own "special" cases, and for which we can have no ready and knowledgeable answer. If a surgeon tells me "Scrum can't work that way here because..." I'd be less confident than if I was facing a belligerent IT department head with 20 years of dysfunction under his belt

    What I do know is that once you open people's eyes to their current process, and get them to question their established culture and practices, then Scrum usually becomes achievable...and without the tweaking (or butchering) of it.

    You are not authorized to post a reply.


    Feedback