What can we get wrong?


#1

Hello, long time reader, first-time poster. Let me start by thanking the Uprising for providing this wonderful forum.
I have been given an opportunity to introduce Agile and Scrum practices to my organization. We’re Federal contractors that specialize in Data Analysis, however the leaders of our joint venture are developers from the old school by training and trade. It was my initial interest in learning Agile that sparked theirs and they have been very supportive and are allowing me a lot of freedom in adopting Agile practices to how we work.
And that is the challenge: While I have been studying and practicing Scrum for almost 6 months, I am not certified and only have limited experience. Already I have donned the roles of management by naming the Development Teams (including choosing the product owners, projects, and Scrum Master -me) and also Agile Coach because no one else is familiar with the concepts. We have conducted several introductory meetings, sprint plannings, and backlog grooming sessions and all have been received positively and we can already feel the concepts resonating and taking hold.
My biggest concern is falling too easily into Agile-Lite which will put long-term implementation at risk but I also worry that strict adherence to the dogma might not be possible and I will have to exert a more authoritarian role to maintain the core principles which I am very reluctant to do. So my title question is: What can we get wrong and still practice Scrum in a meaningful way so we can build a lasting foundation?


#2

@jayberk First. Welcome. Great to have you with us on this wild and crazy journey.

Q: "What can we get wrong?"
A: Just about everything, as long as we don’t lose sight of our values and principles, our “north star” (or for @bradstokes and our cohorts Down Under… the Southern Cross…)

Scrum Values: https://www.scrum.org/resources/scrum-values-poster
Agile Values: http://agilemanifesto.org/
Agile Principles: http://agilemanifesto.org/principles.html
Modern Agile Principles: http://modernagile.org/

And do your best to avoid half-arsed agile: http://www.halfarsedagilemanifesto.org/


#3

There is a great deal to take from Scrum. It is a brilliant framework to learn from and lean on. I wouldn’t be stressed about being perfect scrum, you can derive at least some value from any part of it. Get the underlying values right as @andycleff mentions and you go so much further.

For me, the retros and the reviews are two of my key pieces of the puzzle. I find it really important to expose the work of the team to the company and the company to the team.

The retros provide a space for real introspection and adaption to get better. It doesn’t have to be in set retros, but I have found that having the space that a set time provides is invaluable.

We are all works in progress, and like you I am still young in my journey. Always glad to meet a fellow traveller on the road. If you get lost, don’t be afraid to ask very specific questions here, I am continually grateful for the guidance and advice members of this community have provided.

The other thing to note is when the core values of scrum are embodied by the team, they may be a position to move beyond it. It might not be scrum, but it may still be a perfectly agile way of operating effectively.


#4

@jayberk thanks so much for taking the plunge to get involved. This is a great question that I don’t think gets asked enough!

Andy and Brad are of course dead on, but I wanted to offer something additional. “Wrong” is not the word I would like the community to use. There are so many situational variables that can make some tweak to process viable in orgs. Who am I to say you are doing something “wrong”?

I prefer to identify the behavoiral outcomes leadersihp would like to drive toward and then come up with some experiements to see if they can be achieved. I say experiements because they may not work first time out. But if you couch them in this light it sets expectations more realistic.

Make sense?


#5

@jayberk-

I once led a transition where “agile” was a word nobody cared about… so I put only one thing in place… Monthly Retrospectives.

3 years later, we were doing a pretty good implementation of Scrumban (Scrum + Kanban). I used every retrospective as an opening to apply a pattern from the agile community to solve the problem at hand and improve.

So… in my opinion, the only thing you can get wrong is the retrospectives. Because if you are doing them, and doing them well, the rest will eventually come along.

(also, if you add your location to your profile, you might get help finding a local “support group” to lean on.)


#6

I would totally agree with @bradstokes that retros are one of the keys to making a transition like this. Some people are stuck in their ways and fear big changes, so making small changes every week or two is cognitively easier for a lot of people. We just did a transition from several years of “scrum-like” development to a more structured scrum approach with a coach that came in. Working with some of the senior developers myself (as an SM), I’ve not been able to help them move along the right path more quickly than that because they resisted any major changes.

The more you can get the team to think that the ideas are theirs (whether they came up with it or were led to it) is important. The more the teams feel that the ideas for the positive changes are their, the more bought in they will be.

The other thing I would suggest is go way overboard (or at least it will feel that way) communicating your transition out, and especially the principles behind them. Don’t do it in a way that points out things people are doing wrong, instead communicate out often what people are doing right and how that fits into what changes you are implementing. Communicate how important the teamwork is, how different parts of the organization “are supposed to” work together, and celebrate quite often (especially in the beginning) those wins when you see them.


#7

I can see where you are coming from, would “not by the book” be better?


#8

This is so true!


#9

Thank you all so much for welcoming me to the journey. I sincerely appreciate the feedback and input. Just knowing that there is no wrong way removed a lot of self-imposed pressure. The counsel to focus on retrospectives is particularly helpful. We attempted one but I took this discussion to the team and they are already looking forward to the next one. I will also make sure to include management and the appropriate stakeholders.
Thank you again. I will be sure to keep the group updated and I look forward to growing and sharing my journey.
Cheers!


#10

If you are looking for retro ideas you can check this thread. There are some great ideas. I like the speed car, catapult and wish to action retros. I’ve found them quite good.


#11

As long as you strive to maintain the values that are important to your teams, you’ll be fine.

These are from Modern Agile:

  • Make people awesome
  • Make safety a prerequisite
  • Experiment and learn rapidly
  • Deliver value continuously

If you want to “roll your own” there are plenty of exercises to guide you.

Here’s one collection: http://www.andycleff.com/2015/08/agile-best-practices-values-principles-virtues/


#12

I think we should create our own cert workshop: “create your own agile values.” As @JayHorsecow keeps repeating on the podcast, “shirts and certs!”


#13

Well, in a nutshelll, agile is a state of mind.
Agile is relative.
Agile is not dogmatic.
Agile is pragmatic.

Agile is designed to reduce the gap in time between doing something, and seeing a result that you can “measure.”

Blend in Lean concepts.
Read The Goal.
Don’t do giant monolithic things.
Learn how to decompose your “features/expected outcomes” into bite-size chunks.
Don’t plan across a far horizon to the same degree.
What folks are tasked with doing today better be clear and have unambiguous meaning of "DONE"
What folks are tasked with doing in 2 months better be rather nebulous and broad.

Don’t be complacent and relax.
Question the value of deliverables that are needed to fulfill some process step for some other team.
Ask any downstream recipient what they truly need – and why.
Try new processes.
Reflect.
Agile takes constant effort and constant partial attention if you are doing it right.
Be holistic.

BTW: Are you writing code in the “Data Analysis” domain? Or are you doing “Data Analysis” projects?


#14

Thank you, Jon! And to answer your question: A little of both but mostly the latter. In simplistic terms, we are a company that collects and analyzes data. However, we have hired a lot of really good and really bright people and we now have abilities in the development side of Data Analysis as well as higher-level querying and use of BI tools. So now we have an opportunity to become more of a “data shop” that creates and delivers products, not just analysis.


#15

Hi, @jayberk - I agree with others here that have emhasized retrospectives as being really valuable. It can be very hard to continue to take the time to do them, especially when it can feel like you’re challenged to deliver features / value, but team retrospectives are the best way I know of to provide time and space for the team to examine how things are going and choose what to keep and what not to keep doing, and come up with ideas to improve - in a safe space, while the project is still going on and these ideas will be most powerful. There are some great links posted for retro ideas and here’s another one I like to refer to, as well:
Retromat: https://plans-for-retrospectives.com/en/

Another thing that helps me a lot is to just keep going back to the basics and ask myself, is the action I’m doing or considering helping to move the agile values and principles forward.

And in everything, I try to ensure that I’m empowering the team.

I’m really excited for you! Like you, I’m on this journey too, and it’s fun and I learn new things every day. :slight_smile:


#16

Lots of great advice here! I’ll add a little more food for thought from a lesson I learned the painful way early on in my Agile journey.

As you’re tailoring whatever framework you’re using (Scrum, Kanban, etc.) to suit your team’s needs, be aware that every process tweak will very likely bring unexpected and probably unintended outcomes. These frameworks were designed with careful consideration over time to provide the most likely path to success and when you start designing your own adventure, you may get a happy surprise and things may be as good as or better than expected, but usually, it’s the opposite - a major impediment bubbles up or the system breaks down and a crisis ensues.

This is just one of those quirks of making changes to a complex adaptive system (+1 by the way for the recommendation to read The Goal). If you communicate the trade-offs you’re making and the results you’re hoping for though and acknowledge that you’re trying something out and will adjust based on the results, folks are usually much more open to experimentation and okay with accepting unexpected outcomes and tweaking as you go.