When working with a new agile team or when a role like the Product Owner or the Scrum Master changes, I’ve found that it is prudent to visualize the specific team responsibilities. If the majority of the team has a basic understanding of the role of Product Owner and Scrum Master this method could be especially useful. Much more so than the alternative of teaching the group about generic guidelines and hoping they figure it out. (However, as a facilitator you should coach the group on which responsibilities could be ideal for thier role-based “standard” agile practices.) Another factor for Scrum centric organizations is that the Scrum Guide doesn’t have details about managers, so this is a good opportunity to codify that for your team(s).
I’ve used this method to help out dozens of teams, and it typically aids in sorting out if everyone is doing the right things, and allows for grey areas to be accounted for.
Team Roles Visualization Exercise Timebox: (30min for established teams, 60min for new teams) Purpose: Bring clarity and alignment for the roles on an agile team.
On a whiteboard draw out columns for the core roles for the team (PO, SM, Devs, Mgr, etc)
Have each individual in that role write in the various responsibilities, processes, and even meetings they feel they’re responsible for.
You now have an inventory of likely most of the things that comprise the teams rhythm of operation. As a facilitator/coach, write down any gaps you are seeing.
Now go through each column and make sure the group is aligned, or if certain things should be moved to a different person. Also, help ensure the gaps you may have written down are addressed.
Document the results with a picture or transcribe to a document that can be posted on your team portal.
It’s suggested to distribute the results to the entire team.
For brand new teams or for teams that do not have an agile background, this similar exercise may be another option to help nudge along this activity. Scrum Roles and Responsibilities Game
“Start with Scrum.” Have you ever heard someone say this? I’ve heard this statement multiple times over the years when folks are talking about agile transformation, and it rubbed me the wrong way. The problem is, I couldn’t quite put my finger on why. In many ways, it makes sense right? Scrum can help someone wrap their mind around work decomposition, shorter feedback loops, retrospection, and being connected to the customer more through user personas. But why are so many teams struggling to find agility with scrum? I think I finally can explain why I think this approach isn’t the right thing to do if your end goal is agility.
Last year when I was presenting at the Global Scrum Gathering, we borrowed from Michael Sahota who said something to the tune of “If you adopt agile practices you could see a 20% benefit. If you adopt an agile mindset you could see 300% benefit!” So many people I meet that are interested in agile for their organization just want the benefits but without the mindset shifts needed to get there. I don’t fault them for that because when you look at the Agile Manifesto it reads out very well and sounds like positive things for most rational people. What is sorely missing is the “counting the cost”. If becoming agile as an organization was as simple as doing some training and doing the Scrum Events, there wouldn’t be agile coaches.
2 – Scrum is so 1990’s. (just like these awesome “hackers” in 1995)
Look…I love scrum. I really do! It’s something that opened up a doorway for me to be exposed to agile manifesto which has changed my life and career aspirations. But, while I was working on a blog post entitled “The History of Agile” it dawned on me that Scrum was a response to waterfall. And it was a tremendous leap in the right direction away from fixed cost/scope/timeline type projects. Then came along the agile manifesto which was a response to scrum and the various flavors of agility frameworks sprouting up. But we need to look ahead and allow the agile mindset to lead us into the great unknown. Ron Jeffries, one of the great original thought leaders in agile even said “I may have invented points. If I did, I’m sorry now.” The point is, we need to inspect and adapt as technology changes, culture changes, and people change.
Here’s another awesome 90s picture just because I found so many great ones to use for this article.
3 – Training wheels can create improper habits.
I was listening to a presentation by Joshua Kerievsky last week and he told a story about teaching his daughter how to ride a bike. He said that many people talk to him about how Scrum is like training wheels for their organization to adopt agile. He pointed out though that training wheels don’t actually teach you balance, they just teach you how to steer and peddle. He took his daughter to the park one day and had her learn how to ride a bike by keeping her feet of the peddles and just pushing herself and lifting her feet to learn the balance. She quickly got comfortable with keeping balanced which is typically the hardest part of learning how to ride a bike. And in no time she was ripping around on the bike! What’s the lesson here? You don’t always need training wheels to begin your journey towards agility.
In conclusion, starting with Scrum may not be the right strategy for your team(s). My personal guidance as an agile coach is to only start with Scrum if you envision something close to Scrum being your destination. And even in that is your situation, always start with trying to adopt an agile mindset before trying to implement a framework. By doing this, you are allowing your organization to tap into their creative potential, untethered to just one framework.
Backlog grooming is an activity many agile teams perform each sprint. This is the process of adding detail, estimates, and order of priority to items in the Backlog. This is an ongoing process in which the Product Owner and the Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Product owner is responsible for having stories ready for grooming, and the Scrum Master is responsible for making sure the stories are groomed before sprint planning (via backlog grooming).
What is Backlog Grooming?
Removing user stories that are no longer relevant or needed
Re-assessing the relative priority of stories based on emerging information
Applying estimates to stories which have yet to be estimated
Correcting estimates based on newly discovered information
Creating new user stories in response to newly discovered needs by the team, product owner, or customers
Splitting user stories which are high priority but too large to fit in an upcoming sprint
Grooming will allow for:
A better understanding of user stories
Identification of dependencies and potential gaps for stories
User Story estimation for upcoming and future sprints
Product Owner’s Role
The Product Owner’s role in backlog grooming should start before the actual meeting. The PO will need to make sure that the stories are already prioritized. This is vital to making sure the team’s time is used to groom the most important items first. The PO should also add acceptance criteria or user acceptance test cases to stories as appropriate, depending on how soon each story will be pulled into a sprint. Backlog grooming should not be done without the PO.
Scrum Master’s Role
For this project The Scrum Master will schedule the meeting and take care of any other logistics. The Scrum Master should also be in contact with the PO before the grooming session to make sure the stories are ready to be groomed. Backlog grooming can be done without the SM.
The Team’s Role
Having the team involved with grooming is imperative. While the PO has a great deal of the content identified up front, the team can help round out the technical aspects, dependencies, and other considerations. With the team’s help, the acceptance criteria can be modified and expounded upon. If the team has the ability to even briefly review the top upcoming items, its ideal.
What’s the potential impact of not having backlog grooming?
Your stories will not be prepared for sprint planning.
The connection of work items to big-picture vision will grow stale.
A dev may be looking or hearing about a story for the first time as they are having it assigned during sprint planning. This typically can increase ramp up time.
Grooming: Same audience as above and including all Dev members and the QA teams.
Just Getting Started?
For the initial 1-2 sprints it’s suggested that both Pre-Grooming and Grooming sessions take place. Cadence and details below:
Pre-Backlog Grooming
(Optional but highly recommended during early stages): A more focused group review to prepare stories for the full team grooming sessions. Goals:
Review story scope
Identify blockers and agree on an plan of action to unblock items
Ensure the stories contain the minimum needed information to the team to be able to discuss and estimate.
Pre-Requisite: Product Owner has reviewed stories for Pre-Grooming and they are ready for review.
Timebox: Try to have 30-60 min planned each sprint for pre-grooming .
Backlog Grooming
A collaborative discussion and elaboration of user story details and estimates. All stories on the agenda won’t always be estimated as some will require additional discussion / decisions. Goals:
Stories should be understood by all members of the team
Blockers should be closed or workable
Stories should be ready for sprint placement
Pre-Requisite: Product owner has reviewed stories for Grooming and they are ready for review.
Timebox: Try to have 1-2 hours planned each sprint for grooming. For teams that are new to this you may want to plan for 2 hours and finish early if you get through everything.
Back To Basics
After your backlog begins to take on a level of refinement, you may find that it’s no longer necessary to have two separate backlog grooming meetings. A great indicator for determining this would be to ask the following question: “Are all of the stories for the next two sprints containing enough detail that the entire team attend grooming without wasting time?”
Questions?
If you made it this far, you’ve consumed a lot of information. Feel free to comment with questions or some suggestions you might have.
Dr. Winston Royce first described a model for working with large software systems in 1970, which we’ve grown to know as “Waterfall”. Interestingly enough what many never read in his writings on SW development, is the following quote: “I believe in this concept, but the implementation described above is risky and invites failure.” (Source: Dr. Winston Royce. Proceedings, IEEE WESCON, August 1970) Why could he have said this? Could it be that many times requirements are emergent? Perhaps it’s that estimating large and complex bodies of work based on a requirements document can be incredibly inaccurate?
While I have a large bias towards Agile methodologies, as a consultant it’s my responsibility to evaluate what truly is the best solution for a client. I was recently on a project in a marketing organization, and while there certainly were some opportunities for Agile principles to be utilized, a framework like Scrum or Kanban just would not have been possible. I’ve heard some waterfall purists sum agile up to a bunch of people who want to get out of documentation and commitments to timelines. Ouch. But I also hear a lot of criticism from agile truthers about anyone who leverages waterfall as being clueless and archaic. Can’t we all just get along? Yeah, we can actually. But we have to start to recognize that Agile and Waterfall have value in different ways.
I’d love to have some discussion about what is seemingly a great divide between Agile and Waterfall methodologies. To help those in each “camp” understand why a specific method has value towards solving their business problems. What are some examples where you think a Waterfall process was truly the best solution for a project? What were some of the identifiers you had to come to that conclusion? Have you had success with using a “ScrumerFall” model where the Requirements, and design is all done up front, but Execution is done in sprints?
Fear not agile warrior, you are not alone and help is on the way. They are many situations where someone just knows that agile could help or even change the face of the entire company if utilized…yet someone or many people within an organization are opposed to the idea. So what should you do? First off what are some reasons someone would be against agile?
The’ve been on a team where agile was used, and failed.
They don’t know enough about agile or have misconceptions.
They don’t believe agile is right for their organization/product.
They’ve worked with an Agile Coach/Scrum Master/Consultant that was not very good at their role. Yes, not everyone does their job well…even in the wonderful agile community.
They are from the past (I kid…I kid! That was an IT Crowd reference)
Now for the part you really came to this blog post for: What are ways I can help my organization adopt and/or support agile?
Start emphasizing agile principles in whatever work you are doing. As a consultant that works on a wide array of projects with a variety of methodologies, I’m often tested with how to apply principles on a personal level. Getting out of the theoretical and nitty gritty practical application is a great exercise towards see if/how agile could work at your organization. If this is something you feel is “out of your league” or you just don’t have the time to do, it’s OK. There’s other ways to makes strides towards becoming more agile.
Propose solutions to problems from an agile perspective but without using agile lingo. Some people are just turned off to agile terms and immediately roll their eyes when you say “backlog grooming” or “daily scrum”. But if you are able to problem solve using agile principles you could begin to win over even the harshest of critics.
Create a mini scrum board for tracking your own work. I heard a story of a person who was trying to advocate for their company to adopt agile, and started doing a scrum wall in a shared space. Pretty soon scrum boards were up all over the company. Some were labeled “Inspiration wall” or “Wall of vision”. Everyone from IT to Sales was using them. Baby steps can be better than no steps, right?
Contact consulting companies. See if they would be willing to share about agile within your organization. Some consulting companies will do this for free because it’s a great way for them to help your cause, as well as demonstrate their expertise in this area should you need their services down the road. Or see if they are willing to just share free resources with you.
Join user groups and contribute to the agile community. There have been times where my primary daily function was far from an agile focus, but I was able to stay energized by attending local groups or writing blog posts in my personal time. Also, sometimes effective reflection comes when you are looking in from the outside.
Find a new opportunity. (Please take this with a grain of salt as it’s just my opinion.) This for many reasons isn’t the first option anyone would like, but it may be the right solution. As the industry seems to be moving more and more towards adopting agile, it’s less likely that a company is just flat out rejecting agile. It could be that they proclaim to use agile but it’s very broken or dysfunctional. These kinds of situations can cause stress if you are a firm believer in the agile principles. But is the disappointment or stress consistently outweighing the rewards or satisfaction experienced? If yes, it may be time to look for new opportunities. Robbie Bach wrote a relevant article you may find useful called “Knowing When To Walk Away“
What about you? What advice would you have for someone in this scenario? I’d love to hear what other people have done or are doing.
This is mostly meant to give you a chuckle, but there is some validity to it as well. In my last blog post I talked about how we need to challenge the limits of what we understand agile to be. Can you be agile and waterfall at the same time? Probably not if you look through the lenses of what we typically view as a waterfall process. But it’s possible.
One thing I’ve noticed as an agile coach is that people like to gravitate towards what they know and are more comfortable with. One way this can play out is when helping a team adopt agile, you can get a strong pull to keeping things in the box of a waterfall process. This happens both at the individual contributor level and management level. Management can sometimes want waterfall type metrics but without the changes needed to realize the true benefits of agile. It’s ok though. Be patient, and see if you can find a way to meet somewhere in the middle. Waterfall isn’t bad. In fact it has tremendous value in the right context. So, as an agile enthusiast make sure you aren’t always negative about waterfall especially when it could be used to your advantage. However, what you don’t want to do is fall into the trap of using the buzz words from agile/scrum but keeping things pretty much the same.
I’ve found it is helpful to ask people questions about why they want to do something a certain way. “What do you think will be the benefits of trying it this way?” “What are you hoping to accomplish by doing it this way vs. that way?” If you say things like “You are just stuck in old thinking.” or “That’s not agile.” you can build walls instead of creating bridges. If they are pushing for trying something, maybe just go with it for 1-2 sprints. Then evaluate the impact it is having. After all, I’ve always found that I am continually learning from the teams I work with, and surprise-surprise I DON’T KNOW EVERYTHING! 😉
If you work in an organization that utilizes one of the many agile methodologies, you have probably heard the statement “that’s not agile”. It could be about a proposed process change, or a critique of an existing way of doing things. It baffles me to no end when people get lost in the weeds about if something they want to try as a team is agile. This is unfortunately very prevalent in Agile Coaches and Scrum Masters who have a lot of experience. Since agile is an emerging idea that is really starting to catch some momentum, some who have been advocates for a longer period of time can be standoff-ish about how to do things. This should be a huge red flag, because there are so many variations of agile and not every organization is the same. You can know all the right things, but completely fail at helping a team adopt agile. That is why it is very important to be flexible, and not have a “better than” mindset. The principles of agile/scrum are meant to be a guide, not a law that must be perfectly adhered to. I’m not suggesting you should throw all caution to the wind and try any and everything, because “everything’s agile!” No. What I am primarily addressing is the way in which this topic is approached.
So, who’s right? Maybe saying “that’s not agile” can be valid. Or maybe we’ve lost sight about what agile is all about. Let’s just take a quick peek at the Agile Manifesto for a refresher on what it’s all about:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
To be brash: If someone tells you “that’s not agile” and it’s something that could enable one of the 4 agile main points of the manifesto, I would seriously question how well they truly understand agile. And agile by nature is something that I believe will continue to evolve as people uncover better ways of doing things. (sound familiar?)
If your organization is looking for an Agile Coach or Scrum Master or you are just trying to improve your skills in that realm, here are some suggestions for what not to do, and what to do.
Don’t try to impress anyone with your agile credentials. Do try to identify things that have been successful on similar teams/organizations.
Don’t be preachy when trying to present new ideas. Do suggest ideas with a humble and flexible attitude.
Don’t rely solely on past experiences of what worked for other teams. Do spend a lot of time listening to people’s needs an challenges.
Don’t react when people are critical of agile. Do find a way to tie what people want back to agile principles and show them how they could enable those things.
Don’t press your own agenda. Do thoroughly understand how you can support management’s vision.
Don’t treat the agile principles as a law. Do use them as a guide for making continual improvement.
Don’t be too critical of a team’s existing processes. You never know how much hard work they have put into building what’s there. Do make a point to try to build on existing foundations, and position it as an improvement rather than tearing down.
Don’t be too quick to judge what will work best for a team. Do ask a lot of sincere questions and follow the breadcrumbs of how things became the way they are.
Hopefully the next time you want to say “That’s not agile” you can remember the big picture and help your teams find the very best solution. What things are important to you as an agile proponent in these regards? Do you have any good stories to share?
The AgileSphere 