Anyone else feel like the more they research Scrum, the less they know?

[Kc Para]

So I'm trying to research some information on technical stories, and that branched into an article on Scrum Masters running multiple teams, which of course branched into something else....all pertinent to my position as Scrum Master.

The more I dig into this forum, the less confident I feel that ANYTHING I or my company is doing is even remotely close to Scrum, or at least the core principles.

Anyone else ever get to feeling this way?  And if so, any tips on how to dig out of this hopeless feeling that Scrum is just TOO hard to master?

[Mark Levison]

Kc, good news it eventually gets better. To start pick one or two key books and focus on making small changes.

Perhaps Mitch Lacey Your First Year in Scrum, or Kenny Rubin's book.

Don't worry about solving all problems just ask am I and my team better than last Sprint.

14 years on I'm still finding ways to improve my practice and understanding of people.

Welcome to the greatest game.

Please excuse brevity and errors this was written on my phone.

Cheers
Mark

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Ron Jeffries]

Kc,

On Feb 18, 2015, at 4:19 PM, Kc Para <kc_...@hotmail.com> wrote:

The more I dig into this forum, the less confident I feel that ANYTHING I or my company is doing is even remotely close to Scrum, or at least the core principles.

Possibly you’re not ...

Anyone else ever get to feeling this way?  And if so, any tips on how to dig out of this hopeless feeling that Scrum is just TOO hard to master?

There are just three roles: empowered Product Owner, cross-functional Development Team capable of building what is needed, and a ScrumMaster who helps the team keep the team on its process. Do you have those, and only those roles?

There are just five meetings / activities: Daily Scrum, Sprint Planning, Backlog Refinement, Sprint Review, Sprint Retrospective. Do you know how to do these meetings?

There is just one required artifact and a related requirement: you must build a potentially shippable product increment every Sprint, and what’s going on must be made visible to stakeholders. Are you doing this?

If your answers to any of the above were “no”, how can we help you do those better. If they were all “yes” and you’re still having trouble, tell us more about what trouble you’re having.

Scrum is, of course, hard to master. But if you know some better way to build your product, you should use it … and tell us what it is so we can do it as well.

How can we help?

Ron Jeffries

ronjeffries.com

If another does not intend offense, it is wrong for me to seek it;

if another does indeed intend offense, it is foolish for me to permit it.

  -- Kelly Easterley

[Kc Para]

Okay....a few specifics based on your questions:

Do we have:

Empowered Product Owner - no, not really.  Instead we use BAs to work alongside the Architect and Tech Leads to craft stories based on needs.  Once the requirements are clear to this team, the BA goes back and writes all of the user stories...not very Agile, more Waterfall, I know...and then we groom.  During grooming we will refine each of the stories down to the smallest unit possible, and provide an estimate of work based on fibonacci sequence and t-shirt sizing.  This will then go to the offshore teams (Dev in India, QA in Pakistan)  where they will even further break down user stories and add subtasks for all Dev work needed, and QA will write two as well (one for test case development and one for test case execution).  During the sprint the BA will also function in the role of a Product Owner, and will work with other stakeholders to make decisions on specific stories during backlog grooming.

Development Team - yes, we definitely have this.  However, it is definitely made more difficult by a.) having all Dev and QA offsite and offshore, and b.) having the Dev team in one country and QA in another.  It makes it complicated to keep everyone on the same page at all times!

Scrum Master - that's me...although my time is divided between two teams currently. 

Five Meetings - We do all of these except for a formal backlog refinement meeting.  The backlog grooming is made to be a daily requirement of our PO/BA.

One required artifact - I'm not sure that I have an answer for this.  Off the cuff, I'd say that yes, we are able to provide a PSP at the end of each sprint, but the major impediment to this is that the company wants specific delivery dates, so we wind up getting boxed in somewhat to a delivery date...so if something normally is estimated to take 6 iterations to complete, we do have situations where we need to try to complete the work in 4 because someone has already told the customer that it's going to be delivered on a certain date.  (This is already being addressed as a major problem, and something that requires a major adjustment in the way we do business as a company, not just a scrum team.)

That said, I appreciate everyone's help!!!  Thanks!!

[Wouter Lagerweij]

The fact that you're asking (and working so hard to learn more) is a sure sign you're working to improve. That's pretty much the basis that you need.

If you've been reading here and elsewhere, you'll have seen many opinions, ideas, tactics, disagreements, practices and personalities. Most of them are suited to fall under the scrum umbrella, or at least the agile one. There's many ways to do this. There's even many ways to do it well. There's no way to get agreement on what is right, though:-)

Get everyone used to change. Many small changes works well. Focus on quality, and cooperation. And on getting actual software out, of course. And you'll be fine.

Wouter

--

You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--

Wouter Lagerweij          | wou...@lagerweij.com

http://www.lagerweij.com  | @wouterla

linkedin.com/in/lagerweij | +31(0)6 28553506

[Kurt Häusler]

To be honest no. Scrum itself is much too simple. There just isn't that much to research. 

It is also pretty easy to get at least "remotely close" to doing scrum. The criteria for whether one is "doing Scrum" or not (not that that is especially important) are also fairly minimal. 

My advice is not to worry too much about mastering Scrum, unless you are sure that the real problems you are having will be solved by mastering scrum.

Rather concentrate on delivering good product, and let Scrum sit in the background supporting the team, doing what it does. Don't let "doing Scrum" take too much focus away from what the team is actually being paid to do. 

But that is probably what you mean right: "Anyone else feel like the more they research supporting a team in new ways of working together (e.g. using Scrum and similar ideas) the less they know?" Now that I can understand, but this is something no one will ever completely master. Mostly because it is complex and context dependent.  Feel free to concentrate on specific small ideas that solve specific problems and ignore the rest, trying to learn every crazy idea out there is not a winning strategy.

--

[Kurt Häusler]

On Thu Feb 19 2015 at 00:06:12 Kc Para <kc_...@hotmail.com> wrote:

Do we have:

Empowered Product Owner - no, not really.  Instead we use BAs to work alongside the Architect and Tech Leads to craft stories based on needs.  Once the requirements are clear to this team, the BA goes back and writes all of the user stories...not very Agile, more Waterfall, I know...and then we groom.  During grooming we will refine each of the stories down to the smallest unit possible, and provide an estimate of work based on fibonacci sequence and t-shirt sizing.  This will then go to the offshore teams (Dev in India, QA in Pakistan)  where they will even further break down user stories and add subtasks for all Dev work needed, and QA will write two as well (one for test case development and one for test case execution).  During the sprint the BA will also function in the role of a Product Owner, and will work with other stakeholders to make decisions on specific stories during backlog grooming.

This doesn't sound too bad. The BA is essentially your PO. One minor concern is that the user stories should probably come from a business perspective rather than a technical one, so I am not sure the BA should be getting so much help from technical roles like Architect and Tech Lead. He should rather get his help from users and business people, and the technical roles should probably be involved later. This will help empower the team to feel like technical issues are up to them rather than decided by experts before they are even involved. 

 

Development Team - yes, we definitely have this.  However, it is definitely made more difficult by a.) having all Dev and QA offsite and offshore, and b.) having the Dev team in one country and QA in another.  It makes it complicated to keep everyone on the same page at all times!

This can work fine nowadays with modern communications tools. It is a extra cost I guess, and the Scrum Master may have to be a little more proactive then usual to make sure communication works well enough.

 

Scrum Master - that's me...although my time is divided between two teams currently. 

Also might not be a problem, moderating meetings, coordinating removal of impediments and coaching for one team is sometimes hard to make into a full time role, simply because the team cannot be doing Scrummy things with the SM the whole time, they need to program etc too. This is however controversial, and many people say it should always be a full time role for one team, but usually in this case the SM also has a mandate to further agilise the company outside the team, which is often not the case.

 

Five Meetings - We do all of these except for a formal backlog refinement meeting.  The backlog grooming is made to be a daily requirement of our PO/BA.

Also fine.

 

One required artifact - I'm not sure that I have an answer for this.  Off the cuff, I'd say that yes, we are able to provide a PSP at the end of each sprint, but the major impediment to this is that the company wants specific delivery dates, so we wind up getting boxed in somewhat to a delivery date...so if something normally is estimated to take 6 iterations to complete, we do have situations where we need to try to complete the work in 4 because someone has already told the customer that it's going to be delivered on a certain date.  (This is already being addressed as a major problem, and something that requires a major adjustment in the way we do business as a company, not just a scrum team.)

Specific delivery dates are fine and usual in Scrum, and being boxed into them is a feature of Scrum. Are you planning to yesterday's weather? When release planning it might be helpful to be a little pessimistic and add some uncertainty buffer. Also in Scrum if you find that only 75% of the scope desired for a certain release will  be available then you discover this early, and can take some sort of action e.g. descoping or coming up with a simpler way to implement a story.

But this is classic project management, made a little bit easier by Scrum.

 

That said, I appreciate everyone's help!!!  Thanks!!

[Yves]

scrambled by yPhone

Op 19-feb.-2015 om 07:02 heeft Kurt Häusler <kurt.h...@gmail.com> het volgende geschreven:

To be honest no. Scrum itself is much too simple. There just isn't that much to research. 

It is also pretty easy to get at least "remotely close" to doing scrum. The criteria for whether one is "doing Scrum" or not (not that that is especially important) are also fairly minimal. 

My advice is not to worry too much about mastering Scrum, unless you are sure that the real problems you are having will be solved by mastering scrum.

Rather concentrate on delivering good product, and let Scrum sit in the background supporting the team, doing what it does. Don't let "doing Scrum" take too much focus away from what the team is actually being paid to do. 

But that is probably what you mean right: "Anyone else feel like the more they research supporting a team in new ways of working together (e.g. using Scrum and similar ideas) the less they know?" Now that I can understand, but this is something no one will ever completely master.

That and sometimes the best thing is to do nothing and let the team figure it out themselves.

I have seen a lot of coaches/scrummasters (unintentionally) killing self-organisation because they feel an uncontrollable desire to DO SOMETHING

(Hint when you feel that, try stepping back)

[Wouter Lagerweij]

On Thu, Feb 19, 2015 at 7:20 AM, Yves <yv...@hanoulle.be> wrote:

That and sometimes the best thing is to do nothing and let the team figure it out themselves.

I have seen a lot of coaches/scrummasters (unintentionally) killing self-organisation because they feel an uncontrollable desire to DO SOMETHING

(Hint when you feel that, try stepping back)

Stepping back is certainly necessary, and knowing when to is an art.

Just to provide the balance, I do have to say that I also see many cases of that same group not stepping *in*, and leaving a team floundering without direction. That is just as bad. Providing some guidance first, especially for inexperienced teams, is crucial. Then step back a little, let them try things, and step in again with advice and nudges to encourage them to try new things... etc.

Wouter

 

[Yves]

Agree on the balance,

I prefer to err on the side of to little, and step in when needed.

As that is visible , when people err on the side of too much , it's harder to see when it's too much (as teams will always think they need more)

In parenting you have two architype of roles:

Mother role which is caring

And the father role which is "pushing a kid out the door to stand on it's feet"

Another reason why I like PairCoaching 

scrambled by yPhone

--