�ݺ�ߣ

Editor's Notes

• #2: Hello! Thank you all for taking the time to join me today! My name is Jeremy Jarrell, and I want to talk to you about Improving the Odds of Your Agile Transformation. Before we get started, just a bit about me: I’m an agile coach, software engineer, and author who’s articles and videos have appeared on publishers such as Pluralsight, Front Row Agile, and InfoQ. And I’ve been luck enough to be involved in many agile transformations both as a team member and advisor to other teams So I’ve had the opportunity to see first hand a lot of teams succeed with their agile transformation, and unfortunately some teams fail
• #3: One thing I’ve noticed along the way is that there’s no perfect recipe for creating a high performing agile team since every organization and culture is different. But Commonalities between the teams that succeeded and those that didn’t Your situation is unique, but following those practices improves your odds
• #4: So what are the practices? There are lots, but there are 3 specific ones that I’d like to share with you today. Based on My own experiences with teams Occurrences in the scrum literature as indicators for success
• #5: The first practice we like to look at for teams to improve is “are their stories ready to cook?” Should be ready to be worked on as soon as the team picks them up Borrowed from Nivia Henry Paints the perfect picture of what we’re looking for in a story before we pick it up.
• #6: So what makes a story “Ready to Cook?” Title is not ambiguous Point of the story is obvious Avoid unclear language like “look into” or “think about” Title should be immediately actionable like “Add ability to…” or “Fix error that occurs when…” As many questions answered as possible What the customer wants, how we’ll approach it Tracking down answers isn’t a good use of dev’s time Often don’t have the connections in org to do it We can still change our mind But nothing should be stopping us from getting to the point where we find out we need to Clear end goal What are we trying to accomplish How do we know when we got there We’ll talk more about this in a bit
• #7: So how do we know if our story is ready to be worked on? Luckily there’s tool called “INVEST” which can help us get there. Acronym captures 6 ideal qualities of stories Independent Can be worked on without needing to depend on other stories. Stories can have prerequisites But once the prereq is complete this story should be able to move on its own No jumping back and forth between stories to finish a feature Let’s us move a story around in the backlog without worrying about what needs to come with it Negotiable Room for devs to decide how to best approach Avoid overly specific language or details We can also see this come into play before the story is selected for the sprint Fringe details can be split off and prioritized for later Valuable Not busy work Makes a meaningful impact Provides value to the customer This may not be directly, for example, the story may be a technique pre-requisite for another customer facing story But it should be obvious to us how this story helps us get there Is the most important thing the team should be working on right now Estimateable Understood well enough that the team can give a reasonable estimate Sized Appropriately Big enough that it makes an impact But not so big that it can’t be understood As stories get bigger they become harder to understand and estimate Prefer small stories A story should be big enough that it makes a different…and no bigger Testable We understand how to check if we finished the story The story is in a testable state May need dummy data or scaffolding, that’s ok if that’s not the focus of the story Remember, we’re testing the end result of the story….not the implementation
• #8: This criteria seems a bit abstract when we just talk about it out of context, so lets look an example Imagine a sales management application The first story is to let salespeople access the product Lets see how it does against INVEST Independent? No. How do they get accounts? Invited? Self-register? Let’s assume they already have accounts. We’ll add stories later to let them be invited or register themselves. (click to change story). Now the story is more independent. Its smaller, and only focuses on a single, specific action of the login workflow Negotiable? Yes, we can negotiate types of login before we start Password, social login, etc And details of implementation after How complex does the screen need to be? Just a login form, or additional info like recent news of the system Valuable? Yes, without it users can’t access the system Most important thing we should do right now? Yes Estimateable? Yes, its familiar…most devs have built a login screen Smaller than it was previously. Giving users access to the system wasn’t estimateable, asking us to create a password login screen is. Sized appropriately? Yes, once again because its smaller than it was previously. This should be small enough a dev can “hold it in their head” at once Testable? Yes, there’s a clear end state. Either the user was able to log in or they didn’t Remember that we didn’t handle how the user gets an account in the first place This is an example where we’ll need to use dummy data, manually adding a user to our database first That’s ok because its lets us test this story, and its not the point of this story This story is now about how a user gets an account, only how they login after they have one We’ll handle creating a user account in another story, and because we went through this process its highlighted that that’s something we didn’t consider INVEST gives us a nice set of criteria to evaluate stories, but its not perfect Some overlap – small stories tend to also be more estimateable and easier to test That’s good, this creates a circle in which improving one aspect tends to improve others A common theme is that many of these criteria can be improved by simply making the stories smaller Not all attributes will apply to all stories though Some stories so small they’re not negotiable INVEST is a guide post…not a hard set of rules
• #9: Now, applying this criteria to every story in your backlog may seem overwhelming at first The good news it that you don’t have to. Don’t apply INVEST to everything in the backlog Just stories ready to go into the sprint Don’t know enough about stories further down the backlog anyway INVEST helps us tell stories that are ready to be worked on from those that aren’t
• #10: The list of stories our team is still slated to work on is called our “backlog”. Most important stories are at the top They will be worked on next Stories become less urgent as you move down the backlog Word “urgent” is intentional. Sometimes you want to avoid the word “important” with customers Ordering the backlog like this lets us see which need to meet INVEST criteria and which don’t Capture the qualities of a backlog as DEEP We like our backlog to be Detailed appropriately Stories near the top should be well defined, or meet INVEST Stories further down don’t need to be Won’t be worked on soon Actually want to leave lower stories undefined for now May not ever be worked on, don’t waste time defining them Don’t know enough about them yet…we’ll probably know more as they work their way up Estimated Each story needs to have a rough estimate…even those that aren’t well defined Helps with prioritization as we can weigh the cost of each story against its benefits We accept the estimates get less accurate as we walk down the backlog Don’t worry, the team will get the chance to provide a better estimate if the story is selected Emergent The backlog will change over the course of a project Some stories will change, be added, or be removed Expect more churn near the bottom of the backlog Another reason why we don’t define these stories well Prioritized Most important work at the top, less important at the bottom Walk down the backlog and pretty the project was stopped. Would you be happy with what you shipped? If not, then you need to reprioritize
• #11: We’ve talked a bit already about understanding what the goal of a story is, as well as knowing whether or not we actually hit it. So, how do we know when a story is complete? Work with customer before starting Define what the story looks like when done Luckily our next practice takes care of this.
• #12: Some of the questions we need to ask are What is the goal What are we trying to accomplish? What should the user be able to do when done? Corner cases or exceptions? Always corner cases Can we think of them now Handle them now, or later as a separate story What will the story NOT do This is important Boundaries help the customer and dev team understand what we’re trying to do And will it be enough If not clear, both customer and dev team will make assumptions When assumptions don’t agree we get into trouble Agreeing on this ahead of time not only gives the team a clear goal to shoot for, but it also dramatically increases the chance that the customer will accept the story once it’s shown to them.   We call this “Acceptance Criteria”. (click on “Acceptance Criteria”)
• #13: Now, does this mean that we can never change our mind on a story?  Not at all, agile is all about being adaptive to changing situations.   Stories more often rejected for misunderstanding than changed mind Reduce the misunderstandings We can focus on changing minds
• #14: Acceptance criteria tends to emerge from conversations with the customer Most won’t emerge until the story is the most defined, just before it gets worked on Expect some to emerge over the course of development This will make more sense if we see it in action so lets take an example Salesperson logging in Questions come up as we get ready to work on the story so we capture them as acceptance criteria What happens after login Helps establish our goal What if the user misses their password? How many tries do they get? This helps flesh out corner cases or exceptions This means the user needs to be able to reset their password? Are we doing that as part of this story This helps us define our boundaries. A lot of these questions will come up during our planning meeting, when the team is trying to estimate the story Often its not the goal that tells us how big a story is, it’s the details. That’s why we want to establish as many of those details as possible with acceptance criteria Good acceptance criteria is Specific and easily measured For each of these cases we it will be obvious whether or not we hit it
• #15: Defining how we know when a story is done doesn’t stop with the customer though.   How many times have you heard a developer say “this story is done…” (click) “But it still needs to be tested” Or, maybe “testing the story” “we just need to review it as a team” “just need to add it the build script” Whatever the reason, if a story is “all done except for…”, then its not really done.
• #16: Instead, we need to talk as a team and decide together what it means for a story to be done Maybe that means that a story Has unit tests Has been peer reviewed Has been deployed to a staging environment. Whatever the criteria is that you pick, decide and agree on it as a team. We call this “Done Criteria” Keeps you honest as a team Avoids stories that claim to be “done” but really aren’t Choose criteria that represents past problems Lots of duplicated code, use peer reviews New changes often break old code, add unit tests
• #17: The final practice is to keep teams together once they’re formed Teams for instantly But take times to gel Each time the team goes through same progress Forming Storming Norming Performing
• #18: Let’s look at each stage Forming Teams start feeling each other out People are polite, try not to upset Storming Gotten to know and trust each other Gloves come off Start to challenge each others opinion (good) Conflict starts to arise (good or not) Norming Team starts to gel Major disagreements resolved People fall into normal routines Performing Team is on fire Know how to work together and manage themselves Has conflict, but productive conflict that solves problems Few teams get here But those that do are very productive All teams go through this process, or at least as far as they get, but it can take a long time.  The problem is that each time we change a team, we reset this process back to the beginning. Teams vary how fast they go through this process, so be patient and give the team time to gel before deciding it isn’t working and breaking them up again. Each time you break the team up you’ll have to start over. It varies, but most teams can take any where between 2-4 sprints to really start to gel. Give a team at least that much time before calling it quits. (Tuckman’s stages of group development)
• #19: As an example, Joe, Steve, and Susan are all working well together. Progressed through all four stages and are high performing Then Michael joins Only increased by one but now is a new team Have to go through Forming, Storming, Norming, Performing process all over again May be quicker, but will still take time No guarantee the team will get back to Performing Every time we change a team we interrupt it’s flow which is disruptive to the team’s productivity. Instead, once we get our team the right size...leave it alone.
• #20: So, this always begs the question “what is the right size for the team”.   Rule of thumb is 7+/-2…or between 5 and 9 Less than 5 – hard to get meaningful work done without outside help More than 9 – Too big to self-manage Team starts to step on each other’s toes 7+/-2 doesn’t just mean software engineers Includes testers, designers…anyone who contributes If on high side, hopefully team isn’t just engineers Will be hard to keep 7 engineers busy without getting in each other’s way If you have a choice, err on the side of smaller teams Easier to self-manage Can’t tackle as much work at once so Planning becomes easier Less likely to step on each other’s toes
• #21: As a matter of fact, speaking of smaller teams Most recent research says that 5 is actually ideal
• #22: So, now that we know the practices we need…where do we go from here? First, look at next stories be picked up Does each meet INVEST How do we get them there Don’t have to do this for every story in backlog, just the ones next to be worked on This is the single most important thing a scrum team can do to improve their productivity Start with all stories ready to go, and be amazed at difference Then, define each story’s acceptance criteria with the customer What would it take to consider it done May miss some things or things fall through cracks…that’s ok Goal is to getting into the habit of starting each story thinking about its end game And, sit down with team and talk about what it would take for you to consider it done Unit tests, peer review? Whatever it is, write it down, hang it up, and stick to it for all stories in sprint Avoid formal document, hand write the criteria on a piece of paper This reinforces to the team that we can change criteria if we find we missed something or if something isn’t working After sprint is over What was missing? What wasn’t important Use what you learned to keep refining your done criteria Finally, keep teams together Sometimes out of a dev team’s hands….but not always Talk to your managers and discourage from rapidly reforming with the Forming/Storming/Norming example I mentioned today If team does change At least be aware of the phases you’ll go through each time Use this new awareness to accelerate and get back to performing as soon as possible
• #23: If you have questions about anything I’ve talked about today, anything in these course, or about agile in general, don’t hesitate to reach out to me through twitter at @jeremyjarrell. In addition, you can always reach me at my website www.jeremyjarrell.com, This site also a lot of information about the problems that teams face when first implementing agile, and how to overcome them. I’m happy to help you in any way that I can.