|
Original Broadcast Date : Thursday, June 9, 2011
Time: 10:15 AM PT / 12:15 PM CT / 1:15 PM ET
Speakers:
Bob Galen, iContact
While the product owner (PO) role is arguably the most crucial role within agile teams, we often hear horror stories about POs who aren’t available to their teams, change their minds incessantly on business priorities, or ignore quality requirements and technical debt. Even the best POs struggle to meet the demands of their “regular business-focused job” while providing sufficient team guidance. Bob Galen shares real-world situations where he’s observed product owners who deliver truly balanced value for their business stakeholders. Find out how story mapping and release planning set the stage for effective team workflow by establishing a big picture product view for everyone to see. Explore ways to develop shared goals—at both the iteration and release levels—to cement the partnership between the product owner and the rest of the team. Learn from Bob how to set up a tempo of regular, focused backlog grooming sessions to enable the team and the PO to prioritize well-nuanced and high-value backlogs. Leave with ideas for establishing an ecosystem where the PO and the entire team strive to continuously improve their performance.
About the Presenter:
Bob Galen, iContact
Bob Galen is the director of R&D at iContact and president of RGCG, LLC., a North Carolina-based firm specializing in strategy development, coaching, and training teams making the shift to Scrum and other agile practices. Bob regularly speaks at international conferences and professional groups on topics related to software development, project management, software testing, and team leadership. He is a Certified ScrumMaster Practicing (CSP), Certified Scrum Product Owner (CSPO), and an active member of the Agile Alliance and Scrum Alliance. In 2009, Bob published Scrum Product Ownership—Balancing Value from the Inside Out. You can reach Bob at bob@rgalen.com or rgalen.com.
Presentation Transcript:
Good morning. Welcome back. I'm ah pleased now, on the Agile side of the conference to welcome Bob Galen, of Cary, North Carolina. Bob tells me he has you all pretty much down pat. Maybe you can give lessons to Linda. By day he's director of R and D and Agile coach at iContact by night he's a passionate agilest active in helping the community. He likes cheesecake, reading quiet walks on the beach and product ownership.
I've known Bob for a long, long time. He's a great contributor to our conferences please welcome Bob Galen. Thank you sir. Fantastic. How are you all doing this morning. You all doing okay?
Yeah.
Alright. Good, good. I want to tell little story, I'm lucky I'm here and so I want to really thank Lee for having me. So I, he, he called me, he reached out to me to offer me a keynote and associated with a keynote presentation. I'm not the best writer in the world.
So, you have to write one of those little snippets. Everyone familiar with those snippets that describe the, the talks. And, I get really full of myself, and I, I send back one and I'm like, here's a title, so they, they come in separates. It's the title for the talk and then there's body and it has a word limit.
It's, it's somewhere between, I think Lee, 150 and 175. So, I boldly and courageously threw a title and threw what I thought was a great outline and I threw it over to Lee. And he kicked it back and it's like 67 words Bob, can't you use word, word count? I was like, I was appalled like oh no. I was so honored to be, invited to a key note, and I'm like, crap, I blew it.
So, we bounced it back. Any one to have a, how many times do you think we bounced this back and forth? Take a guess.
About five. Good, very good guess. It's about eight, eight or nine or ten, I think. I think he lost patience with me around the fifth or sixth try which is very uncommon for Lee and I'm like I double crap, I was like crap, crap, I'm not going to, he's going to kick me out. I couldn't, I couldn't, it's not even like I can't do a keynote.
I couldn't even do what, I couldn't even get like the 150 words in,to, as, as the price of admission. But, he was incredibly patient with me and I made it, I made through the door. So, I want to thank you all for coming today and hopefully the content, hopefully I'll have a better time with the content for the talk than I did with the overview for the talk.
So, I want to dive in, I want to talk about the, the role of the product owner and let me go back to the, the title, it's partnering with the team as I think the key thing, a key, a key aspect that I want to, I want to share on. A few years ago, I wrote a book called Scrum Product Ownership: Balancing Value From the Inside Out.
And I felt very strongly about the inside out in the subtitle and that was being team focused. I saw a lot of product owners. What inspired me to, to write the book were a lot of product owners were facing externally towards the customer. And the customers really important. But they were looking outside first.
To the business, to the CEO, to the C level folks. And they weren't looking inside enough and tidying their team. And then the results weren't meeting what the sea level folks were desired. So, they they were imbalanced, and I feel very strongly that this PO role this product owner this this craft of product ownership, that it's a really hard balancing act.
And you have to get it right. I think it really starts with the team first. And that may be counter intuitive at times. Because the business is putting so much pressure on these folks. And they are. It's a hard job, and they, they do a tremendous job. So it's the business putting this pressure. But you have to sustain against that pressure and balance into your team.
And that's really this part partnership. The evolution from that book is that I want to amplify that partnership and how important I think it is for effectivity to be an essential product owner. And that's not just to be soft with the team and squishy with the team. That's to drive business results. That's to drive value. That's how you drive value.
So when I say product owner, I'm not... I use scrum terms a lot in my talks. And I'm not really, that's just my experience base. I try not to be too stuck on scrum. We use a variety of methods at Eye Contact, but I tend to use scrum terminology a lot because it works for me.
So when I say product owner, don't get stuck. It doesn't....you don't have to be in scrum or using scrum... I mean customer, I overloaded. It could be business analyst. It could be stake holder. It could be production manager, could be a requirements provider. It actually could be all of those things sort of wrapped up, it could be multiple individuals.
So anyone sort of tasked with interpreting the business climate and feeding their team well, feeding their team well with the backlog, feeding their team well with prioritized work to do, that's sort of the essence of the role. The other thing for the audience....One of the things Lee and I were talking about when I was getting my words ready, he's like, you know, "I wonder if it's gonna be...this is going to be a general purpose workshop or not.
It is going to be just....How many product owners are there in the world? He's like, "You might have only have three product owners in the room. It may not have wide enough appeal." And I said, "I hope...I hope we're not so narrow. I said, "I think the craft of product ownership sort of touches other members of Agile teams.
I think it touches scrum masters, it touches testers, it touches BA's, it touches the team themselves. I think everyone...I think there's this shared view of product ownership, rather than product owner. I think we should start morphing our view towards...from owner to ownership, as a team behavior." So I'm trying to apply a whole team view, where the entire team sort of collaborates on the work, elaborate stories together, delivers on quality, delivers on value.
Now I'm not implying that there isn't a strong voice. There isn't in a strong decisive you know, singular voice that's driving the product and it is that product owner roll. So it's not, it's not group think around driving it. But it is it is a group and a collaborative exercise around contributing to the vision, around contributing to the backlog.
I hope that come through. So it's not, it shouldn't be, it should be Agile methodology, agnostic I hope and ah, product owners and not product owner centric.
The thing that we're gonna do I want to share this morning is I want to talk about simple patterns. The format of this talk is gonna be simple patterns, what I think of as the good. And they indeed are good. So I am not couching it that they are terrible. I think they are good patterns. But I want to talk about taking good patterns and moving them to essential patterns or what I think are as great patterns ah , and I want to sort of share some stories from the trenches that illustrate that.
So, we're gonna take a pattern focus of good and then great and I'm, maybe 'little g' great. Don't, don't, just really really solid sort of extra effort practices that I want you to focus on. The first one I want to talk about is the notion of, is there one product owner? Is, is there one person who, who has it strapped to their back and is burdened down with all of the aspects of the role?
Ah, I think the methodology sometimes have that view of, there's a product owner. They own prioritization, they own the view of the business.
And they're tasked with all of the work around the backlog, all of the work around business interpretation, all the work around customer, you know customer surrogates in the figuring out what, where the business is going and representing the team. And I like, I don't like that view. Ah, now I'm not saying everyone has an equal voice and everyone and, and when you're breaking ties you need a strong, you need a singular product owner who's breaking ties, who's providing vision and who's, who's setting that direction with the team.
But I think strongly that it takes a village to own the backlog. And part of the, who are the constituents, who can own the back log. I think the product organization, so I'd like to start with above the individual product owner. I think there is in a large at scale Agile instance. I think there is an organizational dynamic like "Who does the product owner report to ?" Do they report to a organization of product management?
So I think that organization needs to help them as well.
They need external help, they need external help and support let's say you have a very large scrum instance. I want to have like meta back logs, I want to have road maps. I want to see things that are guiding multiple teams. I want to see that support filtering down for that individual product owner. So the organization itself I think is really important. Stake holders become important. Their important participants, they need to get in the game.
And, and I think the better model for getting in the game is sort of partnership as opposed to, oh, I'm just simply a customer,stake holder. I tell the product owner what I want, and then it's their job to figure it out from there I just shoot them an email.
Then they will figure everything out. A business analyst pail and testers play a wonderful role, I think, in augmenting product ownership. And helping craft great stories, user stories, ah crafting great views. Ah crafting sign off, what's sign off? What acceptance looks like. And then the programmers, the team, the Scrum Master, absolutely I think, help create that shared view.
So, what do, what do they do? This active, this, this, this team, this, this village, I think they're active in sprint reviews. The product owner itself sits with the team. They get out of their desk. They, they sit with the team.
At Eye Contact, we're pretty pleased that our, our product owners normally, typically sit with the team. They used to, we've just re-organized a little bit and they used to sit directly with their teams. And we got great benefit out of that, we got great collaboration out of that. And that doesn't mean they sat there 8 hours a day permanently , and they were chained to their team. They had external work to do, but they were engaged.
They could hear someone cry in, in pain and they knew that a story was in jeopardy. They could hear someone squeal in the team in delight, and they knew they might be ahead of the game a little bit, for another story. But, they could viscerally feel what was going on in the team, and they could make those adjustments with the team.
They could create a tester and a developer could pull them over and show them a story and execution and they could get a feeling they, we could provide adjustments on the fly. So, I think, that's part of that injection and influence point.
They have the courage, I think product owners in this village model, in the village itself needs to have the courage to tell truth to each other. So, you know, not to blow smoke at the team if the story isn't what you want. To say that's not what I want, you blew it. We need to have, provide corrective action here.
Or for the team to push on the product owner if the product owner is pushing too hard on them, is setting expectations too high and they're short shifting quality at the team level. The team will talk truth, or speak truth to the product owner and say, stop that, right, push back a little bit and the product owner will listen to the team.
So, there's this notion of courage and leadership and I think, speaking truth to each other, so to load balance the team. Clearly the product owner is emphasizing this Agile tenants of working code. It's not just working code but it's reviewed. They, they, they need to emphasize the quality attributes of it.
So, ask questions around, was it, was that unit tested? Did we do a code review of that code? And care about, not just care about the delivery, but care about the quality of what the team is doing. They, they, they can, a solid product owner or part of product ownership, I think is fostering this view of quality.
We care, we don't just care about delivery, we don't just care about value. We care about that. But we also care about how we get there. We care, we care about the execution dynamics.
Is it high quality stuff? Did the team short shrift it or not? And we don't want to, we don't want to foster that. And I think that's an important part of the questions. And you can do that dynamically by the questions you ask to the team.
Another important part is creating that shared vision. Envisioning in the team. So, I'm trying to create a view. I think, it's really important to have this view of a village. It's an empowered village. It's a dynamic village. It's not a village that says, it's, you know, that's my, this is my job and that's your job, and we don't collaborate and if something's, if I don't have a clear story, I point the finger at the product owner, and I am waiting for the product owner to, to redefine that story and unblocked.
We don't have that view, we have a collaborative view.
Another thing that I think is really important, and I get a lot of debate, I have gotten debated this conference um and I like that, I think it's really healthy debate, but I'm a strong proponent of goaling, of goals, of setting goals, of setting sprint goals. I think of terms of user story acceptance criteria, as being goals at the story level.
I think I've done this criteria at being goals at a, a work product level. I think if you're doing release planning for your, your work, if you are setting up multiple sprints in your, your, your, you're identifying a goal for release. I, I think release goals are really crucial and folks back at, at Eye Contact probably are tired of hearing me talking, repetitiously about goals and, you know, driving ourselves with goals and multilevel goals.
I, I know folks here are getting tired of it. But I think there is a simple pattern of defining a sprint goal and I am not really caring about it. It's by rote. Just throw it out there. But I think leading with goals is the most essential pattern. Making goal setting and envisioning important part of product ownership at a team level.
And so you are leading with them. It's one of the first things you do. You set release goals, if you are doing release planning. You set sprint goals, you set feature acceptance. You invest in acceptance criteria, acceptance test of the story level.
I think it requires extra work. I coach a lot and I get around and I look at stories. People send me backlogs because I wrote a book on product ownerships. Backlogs show up in my email, quite often he's like "take a look at this one". Is it good, or is it not good? I'm almost frozen to try to not say anything I don't want to judge, I don't want to judge the backlogs but one of the things I look at is acceptance tests at a story basis and how well defined are they and how pervasive.
So what is the investment that the, the team is making in acceptance test. What is the investment that the teams are making, that team is making in crafting, you know, well defined stories? What is the size of them? Are they, you know, are they sized properly, you all, you all understand that. But, but I think it's really important to, to invest time there.
One of the, one of my observation is, it's really easy to short shrift acceptances test. You can craft good stories, but it's sort of extra work to do, to do well defined acceptance tests, and I think, having this view the product owner, can foster an ownership, can foster this environment, where this stuff is important.
Where you want to invest in really nice, clear, well defined testable acceptance test. And, you did that with features and stories and tests and value driven. Another important part, I don't talk about it in this talk so much. But it's chartering. How many people understand, if I said project Charter.
What? If I said that term how many people would understand what I meant ? Lot of hands go up, but someone shout, shout up, shout out some of the attributes of a product charter. What are some of the characteristics of a charter? Anyone, anyone. Visions, I would buy that, so vision is part of that anything else? Clear goals, clear goals. Anyone else? So clear goals, vision. Compelling.
So energized, so we're embellishing a little bit. I would, it gets my blood flowing, it gets the energy. To me a charter should energize the team. Anything else out there? Come on.
Time line.
Time line, I think typically you see things like time line. You thing, you see things I'll help. I am not a lot of contribution. Risks, you, you see time line, you see dependencies, you see approaches, you see budget, you see things that lay the ground work for, for an effort we're about to embark on and I, and that's a traditional project very often it's tied to approval we provide a project charter and maybe there is a business case is associated with it then we have the notion of approve or sign off and I think that very, the nature of that, the envisioning nature of that, forget the budgeting.
Forget maybe the waterfall escean, parts of that, but the, the envisioning parts of that, the energy parts of that, the, how do we measure success at the end? How do we know what we've hit? How do we know that we're done? That stuff, I think, is really crucial and it can come out, it can come out of chartering, and it's very very important.
So I want to talk about some goal setting stories. So, one story, and I use names here, but I won't use companies. So I won't use Mike, Michael's, but these are real people and these are real stories. But I won't use companies, and I won't use names. And hopefully no one can, no one can read between the lines.
Hopefully they're ambiguous. But there's a survival goal. I worked with a start up a few years ago, well more than a few years ago. An entrepreneurial start up. They were working on a, a new tool to do some software metrics. To collect things from developer's desktop. So, it was, it was quite novel at the time and they were, they wanted to drive, they, they wanted to go to a demo, an event to get venture capital.
So, they were. fortunate enough to be invited, to to this demonstration event, we got seven minutes on stage, I think it was seven minutes. You got seven minutes on stage, to show your wares, to provide a compelling demo to venture capitalists to gain funding. Everyone with me and, and they, they, they were so excited about that because they were running out of, they were running, they, they had mortgaged the house and they were running out of funds.
So, they incredibly excited by it. And they were like but we've never hit a date in our lives, Bob. So, they pulled me in this house and because you are like we think, can this Scrum thing help us hit a date, and, and we want it to be our first sprint. I'm like, maybe not, maybe you want to stay away from Agile and just pray.
Do whatever you have been doing and, and pray and maybe that's the best way to hit this demo date. But they convinced me that they wanted to do Scrums, so we started Scrum . So, we went in and we did sprint planning and we came out with a sprint goal, and the sprint goal was someone guess, what do you think the sprint goal was?
And they had one sprint to get to demo. They had 23 days. So, this was a 23 day long sprint. Anyone guess what the goal was? Provide a compelling demo and compelling was the, the latch word. He was like, what the heck does that mean? But provide compelling content that we could demonstrate in seven minutes, that would generate funding.
That's what they wanted to hang their hat on that. And then we did sprint planning around that. And we had stories established and we had tasks. And they started the gun went off and they started the sprint and when was the first changed the sprint plan? Anyone. When did the sprint plan change? Someone help me.
Day one. It was like they looked at the story, they looked in the code and they were like crap, there's too many bugs in there, that will not demonstrate very well, we need to make an adjustment. So where did they look to make the adjustment? What did they measure the adjustment? What did the product ownership look to?
Kind of went back up to the goal and was like okay, we need to shift to compelling. We need something else. And the team looked there as well. And what I am saying is this was a survival goal. And that goal everyday they encounter changes in their sprint. And everyday they were moving the target, they were moving the tasks and they were moving the stories, but the thing that rallied around them, that kept them on point, that kept them on direction was what?
The goal, that goal kept them on track. To finish the story, and I don't know if it's at Scrum. It's not. They could have failed, as well, but thank goodness they got the funding. And they went to demo, and it was a compelling demo. And part of this sprint plan was practicing it etc. So the goal drove quality aspects.
It wasn't just feature aspects, it was quality aspects.
So, second story. Why are goals compelling? Another, this different company, different person, this is John. John was an engineer on an Agile team, on a Scrum team, at a company that did, that was doing e-commerce work and they were having some complex errors associated with some customer charge-backs. So this company would take customer inventory and then re-sell in on multiple channels. And what they were finding is there were some algorithmic errors that would cause them to make charge-back errors, and they would have to. As part of their SLA to their customers. these bugs were costing them money. Everyone with me? So every time a that customer would lose money they would have to pay, so they had a direct pay back effect to the customer. And John, showed some initiative in the team he was starting to lead he says, "I wonder if we can by using ATDD for so acceptance tests in this case we were using Fitness.
I wondered if we could use fitness to instrument and test some business logic to sort of finalize these. No one knew how the algorithms work. Can I use this testing, get into the business layer and can I correct that. And it was a stretch as part of the sprint. So it was added to the sprint goal.
It was like maybe we can try this, maybe we can eradicate these, we didn't even know what they were, we knew when the bugs would surface, and we knew the customers would charge us lots of money for that. So we knew it was an outlay, and in one sprint,John, just by instrumenting test he found three core issues that were costing us money.
And five potential issues that would have cost us money under other conditions just by going through and defining the fitness test and this was initiated and was part of a stretch goal for that sprint. We demonstrated, I'll never forget, we demonstrated that. So he, he established a Stretch goal with his product.
So, this was shared product ownership. Taking refactoring to the extreme. And I remember when we did the sprint demo, the sprint review, the sprint demo of that code, we showed, we didn't just show features, but we showed the, we showed the automation running and I remember a CEO at the time, and very young, very cocksure of himself, very over confident, not, not very willing to share credit, not very willing to applaud or even show emotion.
But, I think I saw a tear come to his eye. I literally, when we were demonstrating this, and he understood, and he clearly understood, the business implications. But, when he saw what the team had done from a stretch goaling prospective he was, he was just flabbergasted. And that was one of the wonderful aspects of.
I think of Scrum and of transparency and of sprint reviews. The third thing, third example of goaling, why I think goaling is importint is there's a product owner. that I know, fairly well, very near and dear to my heart, we'll call him Rob, and Rob was putting together a series, he had,he had a four cast of series of deliverables.
This company wanted to recreate their message creation engine.
And that wouldn't just fit into a single sprint and it wouldn't just fit into a single release. It required vision and multi release connectors, multi release thinking and multi release strategy, and Rob to his credit, whether he knows it or not. I'm not sure he did this intentionally but he had these innate values, he put together a series of sprint goals, but also he set the tone for the team, of where they were going from release to release. And so for release one he established a minimal marketable feature set, for entry into get it in the door, and this was a software as a service, so at the end of release one we were pushing to production, they were pushing to production, they were getting it in front of customers, it was being used.
release two. He set the stage. Now that we're in the door, we need to watch, we need to stabilize. We have a few, Houston, we have a few issues. a few, not quality issues but feature robustness issues. We need to stabilize the features and he did a wonderful job, of framing his back log to the goals in communicating to the team, this is a stable, man we're focusing on stabilization And then finally in release 3 he talked about complexity, he talked about complex editing, he talked about polish.
These weren't even nice to have. These were differentiators. That's getting some more differentiators in there to really blow away the market. So he did a wonderful job via goals and be via plans via back log of setting this tone. Everyone with me? Goals. Really crucial. Guiding, in this case, in all of these cases, guiding the organization not just the team.
Do you like the picture? So grooming, I have this term, I don't know anyone, ever hear, how many people have heard the from backlog, grooming a backlog. It's not that many, so grooming. I haven't coined it. I don't know how widely used it is, but to me there 's this notion, and I overload it, of grooming back logs, so the care and feeding, one's care and feeding of back logs, and I think they're organic, they're evolving things according my code and according to others you see terms like tips of, you see icebergs or you see pyramids that represent backlogs and grooming is this ongoing activity, where you're grooming very finely grain stories, that are about to executed, or you're grooming epics.
You could be grooming a sprint or like Rob in my past exam well you are grooming a release and you are changing you're view and you changing your lens and your view so that you're grooming at different levels. And you might be estimating stories, and breaking, part of grooming is breaking things down, and providing connectors to, how are we going to, what is the strategy? How are we going to put this together?
So I think there is a simple pattern of just simple backlog grooming where a lot of teams just groom. They get into a room occasionally, they hope and pray that things just sort themselves out and spend a little time on their backlogs.
And then I think essential product ownership is this collaborative. As a village, you get together and there's active and congruent backlog grooming. It's very proactive. It's team based. I give you an example.Testers are looking at backlog, contributing stories to the backlog, relating to technical test data, related to automation infrastructure.
They're magically showing up. They're magically being justified to the business. Why do we need these stories that are related to technical debt. And We're contrasting that thread against feature threads, against minimal marketable feature.
How are we balancing that from a priority prospective? That would be more of the active part, an example of that. And we want create that, I'm a dog lover, so I had to have, almost every, every, every, every presentation I do, I have to fit in, fit in animals. And these were...this was a picture I found that I just fell in love with.
I have a dog...Our dogs are somewhere in between those two those two radical dimensions of the spectrum. I want to talk about grooming dynamics a little bit in Essential. And I'm going to give you some...I think what I characterize as anti patterns to lead into patterns. So in this case, I am going to illustrate some anti patterns.
So, another e commerce company. It was actually the same e commerce company that John was working at. Hope I didn't give that...anything away there. The PO was incredibly well liked. His name is Max. Max was just wonderful, he was a wonderful conversationalist . He was an extrovert. He was wonderful to put in front of customers. Great in front of clients.
Great in front of sales. A consummate sales guy. He could make you his friend in five - bless you - in five or ten minutes. And he was a great product owner from a personality perspective. Great sense of humor. Team loved him. Just absolutely loved Max. so the team was there to please him, to a fault, and I was attending sprint planning with him, on a occasion grooming.
So this was mostly grooming and sprint planning, so in the grooming session, I noticed we were estimating stories. Everyone familiar so we were grooming and we doing planning poker. And we're throwing points. And we're estimating stories. And the team would be looking. so they would be throw, so everyone would throw thirteen.
But Max would like sadly his little head, sort of bend down in his chair, and the team would notice it. And then we have another round. And the estimate would come down to fives. So just by the saddening, and everyone was watching all over his body language and he might be coughed, on occasion he would cough and it was dropped down to a three, and at this point he didn't have even had to say anything, and Max, to his credit, he wasn't trying to do this.
The team was just so in tuned. They really cared for him as a product owner that they were watching. They were driving some of their estimates. So deceiving. Like Linda was talking about, they were self deceiving, they were trying to please Max and their hearts were in this place. God help the team when he actually vocalized something. Where he said, I'm really uncomfortable with that estimate. I mean you could take a 20 point effort or 40 point epic and it would actually not have time.
It would have negative points associated with it.
It would be done. It would be done tonight just to please Max. Healthy behavior. Non healthy behavior. What do you think? What do you want? Not so Max. Max, and he was a consummate product owner, but he wasn't seeing this, he wasn't seeing this pleasing behavior, and the teams were disappointing him from a execution prospective, they were setting themselves up for failure.
And I was talking to him as a coach, and I'm like you really need to almost over accentuate yourself, and demand from the team quality. So instead of watch your body language. And be very careful about body language, about tone. And instead of even pushing on the business case I said, the team wants to please you, by default the wants to give you 1.5 times what you asked for in a sprint. So what you want to do is accentuate.
I think accentuate quality, accentuate doing it right, accentuate are the estimates correct. Ask different questions. Please be cognizant of the power that you have of the team and get this grooming get these estimates from what I think I was not very, not very healthy, not very congruent to a congruent estimation, and I think essential product owners understand, understand that their teams, it 's not just this Max relationship.
And it's not just pleasing Max. We want to please the business. Everyone with me? We hire professionals. We come in the door, I think by default .Linda said it. We come in the door optimistic, we come in the door can do, we can we come in the door over commited and I think good essential product owners sort of don't push too hard, and are very sensitive to that.
Another story. A leadership influence, Todd in this case was a start up. He was a C.T.O. of a small startup. He was the founder. He was an architect. He was a programmer. He was a wonderful technician. He had gone to Carnegie Mellon, a wonderful university for software engineers. Todd was a character, a very flamboyant character.
And he wanted to go to Scrum and he wanted his team to go to Scrum. And I remember I was helping coach them, and we were teaching them in our first planning session. Our first few planning poker sessions, and Todd was a contributor, so Todd had multiple hats. Todd was part scrum master. He was part proud donor.
He was part individual team member. He was part architect. And We were in, we were with the team doing grooming.
And again the team was looking at Tom, eh Todd. But they weren't they weren't sort of by default moving their estimates down. They were looking for permission, everyone with me, so no one would point anything, unless Todd gave like the hi sign and he had multiple ways of doing that. He would tap his foot, he would look up at the ceiling, he would, everyone was not so they would there would be a round robin getting permission getting , is that the right ?
I think it's a three and then is Todd oh his eyebrow . No, it's a 10. Is that the right direction? No, I'm going in the wrong direction. Damn it! It's a half. It's a zero. That's the right direction. And Todd, in this case, was very much overloaded in his role. In this case, he was very hard influencing the team.
He wasn't blatantly doing it, he understood planning poker. In his defense, he really embraced the notion of the team, he and he wanted the team to be empowered. But at same time he was a micro manager and he was an architect and he couldn't get himself out, if that makes sense for everyone.
He didn't get himself out of the technology. One of the things we did then is we literally kicked him out of estimation. If that makes sense. In a polite way, because he was paying the bills and he was the founder. But we really influenced him to get out of that so we could get better plans and better estimates on the part of the team.
And we designated some surrogates for him. So, you want to be careful. Grooming dynamics. Keep them congruent. Keeping them village based. Keeping them very active. So, some active backlog grooming ideas. Bring goals and stories to the table, but be open to change them.
In Max's case listen more, and in Todd's case, listen more, listen very actively. So be an active listener, not an active talker. Watch your body language. Watch all of your stuff. Presuppose that the team is being over zealous team presuppose that the team is being overly optimistic. That is a common pattern. So we don't want that.
Don't negotiate, collaborate. So don't twist folks arms. Organic explorations of scope in options as you get closer to execution. So, in grooming you want I think is very healthy to look for trade offs. To look for those organic explorations as part of the grooming process, probably not at the epic level, probably when you are getting closer to execution, you want the team to engage.
I think it is very healthy team who is thinking about how we are going to put the piece parts together, as the story is moving down the line getting ready for execution, how are we going to put that together from a design prospective and from an architectural perspective? Explore execution dynamics. The team should be thinking about how again, I are we going to put it together? Who's going to work on what?
I think that's fair game to start thinking about who might be the right person to work on that. Do we have a skill set gap in raising those issues? Look at deployment. Look at risk. I think you want to apply pressure on value flow.
So instead of applying pressure on content and applying pressure on dates or time boxes or how much can we do, put pressure on value flow, are we doing valuable things first, have we delivered, are we planning on delivering the highest priority features first, are we working on a minimum remarkable features set or a theme that hangs together from a demonstration perspective. Are we working on quality and sustain - are we working a sustainable pace or are we over committing as a team? And I think the project owner has a responsibility to their team to talk about quality attributes, pace attributes and things like that.
I'd like you to remember that the back log is a share contract so it represent, in my mind it represents work flow. It's not just a series of features that need to be slap ashed together but there's I'll talk about it later I think there's multiple threads through it. And you want to be thinking about work flow.
But teams need to be able to see that big picture and flow from where you're at to where do you want to go, where you're going. You need to see those connectors. You want to visit it often. You want to intensely visit as a group and individually. We get a lot of traction out of, I don't know if people are familiar with the term like a research spike. A user story spike. To me its a story that represents research rather than demonstrable work.
It represents knowledge. We're getting - we're figuring something out, we have a hard story, it may be an epic and we don't even know how to attack it. I think teams don't throw enough - I use the term throwing enough spikes into their backlogs so that they're doing enough look and they're doing enough research.
I have a feeling an internal dynamic or a metric that like 20% of the stories in a given backlog are probably spike able, meaning the complexity. You probably have 20% of your stories that are very complex that need a little pre-work and I'm not giving you a license for waterfall behavior. I'm not talking about big design upfront.
But I'm saying I would rather us do a little bit of grooming in advance on a story to compose it properly than dive in and realize in the middle of a sprint when we've committed to that story, that we don't know what we are doing. We had no pre-work around, how do we attack that. Another pattern I want to talk about is related to release planning.
So I think the simple pattern that a lot of teams do, is a lot of teams do release planning. And I will use the term there, if you have heard Berlitz planning, the XP folks Extreme Programming folks talk about release planning. There's end to end planning, there's a variety of story mapping. Jet Pan has a it's not really a planning technique per say, but a behavior, or a UI behavior visualization technique called story mapping, but all these techniques has these notion of planning releases.
Not just diving in and sprinting yourself to death without a view beyond the current sprint, but, but putting a series of connected things together to nail away release to hit a business a customer facing release point. So I think that simple pattern is folks, some folks adopt that, I don't see it enough.
I'd like to amplify that pattern, and I want you to think in terms of multi-threaded look ahead.
That is a very dynamic look ahead in your back log. This is the tapestry that I was talking about before, I really like this metaphor for the back log. I want you to be thinking of your back logs as a tapestry, with threads to go through it. It's not so, very often I see a tapestry, a backlogged tapestries that just have features going through them.
Everyone with me?
There's a feature set that sort of traverses a backlog. Not that that's bad. In many cases, the worst thread is their disconnected features. So, at any point, the sprint demo would be a set of disconnected features. Yes, they're done but the customer scratches their head and it's like what did I just get?
If you delivered that To me tomorrow, for real and I was using it. How will I use that? I love everything that you've discreetly done. But, but where is, where is the beef? How would you connect the dots for that? So, so themes, collections of stories will be part of that. So, features is a thread.
Value should be a thread. Were you considering value? How are we providing? Are we doing valuation stories? And, and how are we connecting value? Not just high priority, but value priority of things to, to our, to our constituents, to our customers. You're thinking of architecture, have we looked ahead enough from an architectural perspective?
Are we getting too much rework? If you notice that you're getting lots and lots of rework, where at the end of the spring you're like or in the middle of spring you're like, crap, we should have designed that, oh gosh, that doesn't, now we have to extend that, we're refactoring an awful lot based on feature implementation.
I would argue you may not have looked ahead, enough. No, I don't want zero rework. I mean then you would be doing deduff. You'd be doing that big design, big architecture up-front. I am not asking for that, but there is a counter, there is a counter element to beat up, which is this high degrees of rework that really impact the efficiency of your sprint.
So you want to be thinking about architecture and design and looking ahead at process and quality and testing and when you get close to a release point, we're going to do a release, we're going to do three sprints then we're going to push to production. I would argue that the backlog elements close to that push to production might include a regulated traceable regression test, it might include a security test, if that's relevant in your domain, everyone with me?
And that activity should show up in a thread in the backlog if you are really doing that. So, deployment, dependency, something that we have huge challenges with I think at contact historically in something that we can we're getting much and much better at is managing our dependencies and it's linked to our release planning, it's linked to our dependency mapping.
And not only did we plan with dependencies in mind, we even have a notion of story readiness so a story with dependencies doesn't enter a sprint unless those dependencies have actually been mapped effectively and committed to. But we're mapping them through the system and we're mapping them to deployment.
So dependency thread, feedback, customer tempo. The threads are guiding it. The tapestry is this metaphor, for its not just a simple list. It is all of your activity related to getting high value, high quality things out to your clients. What are some unhealthy backlogs, any patterns I've seen, to sort of contrast against the tapestry?
POs drop off the list and walk away. They brainstorm it themselves. Will they get it? They story brainstorming workshop and then they blindly list whatever the team did. It could be in priority order or not. They overload priority, everything is a priority one, if you've ever seen that. Or there's multiples, I see backlogs like this all the time, where they, they try to fool me, there's a spreadsheet, then there's one, and then they have 1-A, 1-B, 1-C, 1-D, and then 2-A through Z, and they're looking at me and that they're like Bob that is not...there is only one priority one.
But I am like, what about this column? No, no, don't look at that column. There is literally just one "one," and they are overloading it and they're fooling themselves. So it goes back to Lynn's point of congruency. Don't fool yourself. Don't lie to yourself. Dependency is trivialized or pretending that they are not there.
You ignore them. Ah, well we will prioritize, we will do planning poker, we will all do these things at work. We will drive them into our teams. And we are not managing priorities. We're not managing dependencies effectively. We are not even talking about them until they flame. Until they. Clearly, you can even corner dependencies until they flame on in sprints and then you're having failures.
Simplistic testing assumed. The view, in many domains if you do all your testing in this frame that's great but too simplistic a model. And you have other things. For example, a full regression test. You have regulatory testing, your system testing, or third party integration testing. You can't do it in the spring or you don't have high degrees of automation then your backlog reflects that with testing activities that cover that test.
You don't trivialize deployment. I see backlogs. When I mean pushing it to servers, there is work associated. There might be check lists, there may be trials. When we get ready to push to production where software is a service company, it's not free, it doesn't magically happen, there's checklists, there's configuration files that we have to deploy, there is configuration checks we have to make.
Someone needs to do that. Healthy postures in creating your back log. Here's some healthy postures, I'm going to get optimistic again. You allow the solution to emerge, just in time, you have that mind set of just in time. Keep it simple. Keep things simple. One of the things, sort of a corollary to what Linda was talking about were overly optimistic.
How many people if they were entertaining windows. Could you not this one, I think as a general rule as technologists we are very, very optimistic. I also think lately, I've been talking about kiss and I've been seeing lots of complex solutions in a variety of places where I've gone. So I also think we have a tendency to, to what?
I think we love Complexity for it's own sake. I think we love to attract problems with really, really because it's interesting. It's sexy. It keeps us engaged. The team moral goes way through the roof because this is a hard problem here, you know. And you want to attract that. I think it's harder to get these just in time really simple solutions.
You want to look ahead, but it's a balancing act. But not too far and you want to iterate, but you do want to look ahead you want to look down your back log, you want to spend some time. One of the things about back log grooming I think people miss is Schweber talked about that in that black book or one of those early books.
He talked about investing in backlog grooming. I don't know if he called it backlog grooming, maybe management or something, but managing, taking activity around the product backlog. He talked about investing 10 percent of sprint time. How many people, you recall that? He talked about a 10 percent of this investment of time of the team's time to backlog grooming and I don't think teams invest that.
And I don't think ten percent is the magic number but it significant number is the point. So what he was alluding to is the backlog is your planning element. The backlog is your execution element. The backlog is your risk element and I think it's really important. I think folks, folks don't get that.
A quality debt recovery should result in stories. I want to see stories. You want to see and you want the team to present. We actively encourage our team members that I contact to put stories in their backlog. It's not going to be a free ride. You are not just going to get it there. You are going to have to present a business case to your product owner.
You have to talk about what's in it for the business.
What did you just solve, and why? I said that's good work. If it's worth fixing, it's worth making the case. It's worth understanding and being able to present that business case. What is that trade off to your product owner. For goodness sakes they're a member of your team. They're representing the overall capacity of the team, so make those cases. Thought from work flow matters. So trust your team's input.
And get, not just trust, get your team's input. And then think in terms of delivering to your customer and done. So some healthy posters in that grooming process. Another pattern, a simple pattern. In fact, I see some threads. I'm becoming a tapestry guy, I don't know. Maybe I'm going to retire and start doing needlepoint or something.
But I see threads for some of these patterns. So simple pattern in this case is work with the team. I think the essential pattern and most product owners get that. They get that it's a team function. They get it as a team behavior. The essential pattern to me is cementing a creative partnership between the PO and the team. Where we are one, we are partners. We have each others' backs. We understand our roles. The product owner start understanding testers and how they think.
Why? Not to replace them, not to become a tester but to understand, they are a team member. Sports analogies, I hate them at conferences, but I will bring it up. I think lineman understand what quarterbacks do, what running backs do to some degree. They have a role but they also holistically understand the interplay of the roles. And they respect the interplay of those roles. And I think the quarterbacks are the leaders and the product owner in this case I think would be synonymous with sort of that quarterback fundamentally understands strengths and weaknesses of their team, and the roles themselves in the interplay, and how do we drive that to be successful.
And that's the creative partnership I'm talking about here. I want to talk about Link. Link was a product owner in another e-commerce company. I spent a lot time in e-commerce related. I am generalizing the companies. Link was a wonderful product owner in this company. And what he would do. And this was before I wrote the book.
So I am washing product owners. I behaved as a product owner. But I was also watching them. I was looking for good ones. And I was looking for not so good ones. And I found lots not so good ones but I found some good ones. And Link was one of those good ones that I was watching, I was watching how he conducted himself, and I was watching his behaviors, and I was trying to to learn from him about the model of product ownership and what the balance of the role was.
And about every 2 months, Link would bring his team into a room for about a half day, he would bring pizza into the room. And he talked about the competitive landscape for his area of the product. He would bring up competition he would bring up competitive studies. He will put up slides and slides talking about the competitive links, the number one competitor, he would talk about the number two.
He would talk about the feature and functional sets in trade off. How we competed. What were our strengths related to their strengths? What were our weaknesses related to their strengths? From a competitive landscape. He would talk about strategy, what his perception is where those companies are going, our number one competitor, where was that company, where did he think they were to be in a year?
What did he perceive they were going to be working on? What is he basing that on? History? He saw some research in an obscure magazine or something or an article and he was providing this leadership. He would effect, they get a dialogue with the team. He would basically try to share I think a big part of his role, his strategic role. He would take them from tactical execution to strategy. He was trying to sort of get this mind share with him, you know, that wisdom of crowd things that Lee talked about this morning.
And in this case, it's a...I guess a wise...or a valuable wisdom of crowds. And he was trying to get the whole team to understand where...not so much where the back log was going, but where they, we, needed to be going.
A lot of folks looked at him like he was silly. And he was like, "Why are you wasting...Those people should be typing code! They should be typing tests. They should be writing user stories, gosh, darn it! You're wasting time." That was a pervasive view. How many people think Link was wasting his time?
Do about every two...What was he trying to get? Anyone. What was he trying to do? Yes.
But have it emerge instead of...You're right. One aspect of it is to emerge a common goal. And he didn't know. Now, could he have created on. Link was great, Link was a great product manager. So, there was no, there was no gap in Link's ability, to be able to say, here this is, this is my vision for the future.
But, he was trying to evoke the team, he was trying pull the team into his world. So, your right to create, one aspect was to create a shared vision. Anyone else? Any, what else he might, sure.
So what, what he's saying is, each team member is viscerally to drive it home. To get that team based, I'm paraphrasing a little bit, but to get that team based, you get it in your belly of this is where we're going, and I'm aligning with that. You're absolutely right. That, that team was wonderfully driven and yes they did sprint goals but they almost didn't have to.
These, these session, the team was almost self goaled as a result of this. I cut you off, someone else.
Shared passion. He was sharing, he shared his passion. Another interesting thing, he did is he shared his challenges, with the team. He's like, you know what, we're in a dogfight. We're in a dogfight. This could play the landscape and, and he was on the spot from a business perspective to provide that direction.
And the team was there, so the team rallied around Link. They're like, yeah, not only was it a competitive landscape, but like, we've got your back man, we, we we've got it. And there was some creativity over sprints as part of that creative solutions. Link would throw a story in and it was very often the case where to, no, no, no that's you don't want to do that.
That is not what we want to do. What we want to do is this plus this and leverage something we did last year and glue those things together, and we'll nail the competition with that aspect. And you know what, what we thought was forty points, is five points and very often it would be 40 points but the point was they were looking at the landscaping.
Coming up with very creative, very creative and dynamic solutions and I think a big part of that is a credit to his team. It is a credit to the leadership, but it is a credit to this dynamic. So, shared ownership, wisdom the crowds, increasing this team's values so that they understood. It wasn't just a stream of, here implement this, implement this, implement this, implement, code this up, code this up, code this up, shut up, code it, test it, get it out the door.
They, they were understanding the big picture and he pulled them into that, and they, and they produced Kiss Solutions wherever possible because they had the competitive landscape in place. He would actually even invite that we had ops plans this is an extensions of that but we, he would present to the executive leadership of the company quarterly and, this was separate from the team where he was, where he would talk about game plans and forecasts and, what we have accomplished.
Vs, what we are planning on accomplishing from a long term perspective. And he had a neat habit. He would invite a few team members to that, to that session and they would quietly sit as chickens in the back and they would observe the commitments that were being made. They were observing this dynamic of the business was being very aggressive and what Link was being held to task for and that, that helped with the partnership as well.
Round trip, trip exposure, so he provided this ability to, and I think in general, it's a very good activity that you want to allow the team to explore as a product, part of product ownership. Allow the team to experiment, to stretch, to fail. I'll say it again, to fail.
Proudly sharing failure stretch points . We, I don't know if it's not failure that's the point. But we pass or fail our sprints at eye contact. Sometimes, many folks look at me like I have two heads. It's like your silly, but if we don't meet a sprint goal, we have, you know, we will look at a sprint and the commitment the team made and we would say, the team failed.
And we don't fire anyone, we don't take money from anyone, we don't take their children, we, you know, we don't send spies out to their houses, to their homes. We simply look at "we" the team, and it's not an individual. So testers don't fail, and developers don't fail, and the product owner doesn't fail, and the scrum master doesn't fail the team failed.
And then the team, in the retrospective said, well what do we do about it? I actually want failures. I want the teams to be stretching, I want us to be trying new things. I had a conversation with our Scrum Masters if they may even be watching.
Not that long ago I said we're not failing enough, we're not stretching enough. We're not stretching the boundaries, we're not trying new things the way we should be and I really want that. So always draw learning from your retrospectives . Know when to push. And know when to pull. I think the product, the product ownership can set the tone for this, can enable it, can enable that expiration, that emergent discovery that's so powerful in Agile.
And then share, this is what Link did beautifully, he shared his pressures in a positive way, the business pressures and his personal pressures with the team, to motivate the team. Do developers share their pressures with the product owner? They're a member of the team. I think the answer is yes, Do the tester?
Yes. And very often we look at the scrum master and the product owner as being maybe not human roles. They are human roles. They are parts of the team. Allow them to express, hey what's tough, what's not tough in my world, let's help each other out as a team. Last simple pattern. I think it's last, I think I saved built to last for last.
I hope there was a method to that. Simple pattern is, of course, quality. Read an Agile book, of course we build in quality, of course, of course, of course. The essential pattern is, I think a lot of folks skip quality. I think we still short shrift quality too much in Agile teams. I think we give it lip service.
I think building quality in and building it right the first time is really, really hard. And I think product ownership plays an incredibly important part in how do we build it right the first time. So build it right, keep it clean, no matter the cost. I know I am being extreme here, okay? So I know there's balance, I know there's business balance.
But build it right, keep it clean and try to have a view of, no matter the cost.
The picture. I am very fond of the picture on the right. There is a pile of steamy stuff there, so we want to avoid the seamy stuff, the steamy stuff, if that makes sense to everyone. Who decides on quality? Of course quality isn't a simple pattern it's sort of a facade.
I wanted to share this quote from Jim Koplene. I borrowed it, I'm paraphrasing it it from a scrum alliance leadership. There's a conversation list, a mail list, I think it's a Yahoo group for the scrum alliance. And about two months ago at the time I was wrapping this slide. Opportunity, sometimes I got blessed, just things that really inspire me and about that time there was a conversation about value and backlogs and he had this quote and I'll just quickly read it.
Value doesn't matter when examining technical debt.
So there was a debate around prioritization and value and then valuation, how do you valuate technical data. And there was a lot of, well you don't. Features trump technical debt. Does that make sense everyone? That was the gist of the discussion. Jim came back and said, rather, so no, don't think of it that way.
Value doesn't matter. On examining technical debt, rather that cleaning up after yourself, transcended the normal determination of business value and was simply an inherent part of delivering software. Right, and that's not a license to do whatever the heck we want. But, it is a license to do what, to do it well.
That we are not getting into evaluation today. Sometimes we get into product, product owners have to enable doing the right thing. Everyone with me? It's, it's beyond features. This inalienable right to build good infrastructure. That decision making wasn't for the business side, the PO, but instead resides within the team.
Now, the PO is a member of that team, but you are fostering that decision in the team. I think a lot of product owners don't understand the investment, don't listen to their teams so well, well enough, deeply enough to grok technical debt and to grok, what the team is sharing with them from a technical debt, from a refactoring perspective, both from a development point of view and from a testing point of review testing infrastructure, test automation.
So, listen to your team, and ask the right questions. And to the degree that you can, to the degree that you can, take these business value discussions out of play when it comes to technical debt, trust your team. Technical debt, it's intentional versus the unintentional. So, we don't have the time.
Intentional technical debt is, is we hack, we skip it, we know better. Right. There's, we don't have the time, you're simply gold plating, I don't trust you or your overreacting, all of you are over reacting, skip that, we have features to build, suck it up, let's just get this product out the door.
Then, there's the unintentional mistakes, mergers and acquisitions, poor design choices, skills gaps. There is the two of them. Unintentional is unintentional, we can't, we can't do much about that. We can, we can train skills, we can do inspections, we can do some things about that. But it's the intentional debt that I am poking at from a product ownership, from a, from a the village perspective that you hope to inspire you to go back and re-evaluate technical debt, and re-evaluate your investment.
Warning signs in terms. So hacking. I, whenever I hear the term in a grooming session and I'll hear this term often. Probably every grooming session, someone will say: Well it's five points. I can do that story in five points if I hack it. Anyone ever hear a similar "ish"? Replace it with another term.
That's not shame on that individual, at all. But it's the cultural, it's how we're setting the tone, it's already being truthful with ourselves. Are we challenging ourselves? But whenever I hear that I'm like, okay, that's answer for hacking. I want the answer for what? For doing it well. I'll talk in terms of being proud.
When you go home tonight, when you look in the mirror, will you feel, will you look at yourself or will you be pleased with what you see based on the technical decisions you made today and if you are embarrassed then go back, and re-quote that work. Don't build in that debt. And differentiate debt for new things, versus big breaking down historical backlog debt.
But attack the debt. So there were these warning signs, krufty...I hear the term at work all the...That's "krufty" code. Okay, well...And I've heard that. I've seen comments in code. Someone should really re factor that. Two years ago someone wrote a comment in...that was...we should really re factor that.
Two years later, that comment is still there and that "krufty" code is still there. We need to do better than that. And product ownership in this village and trusting the team. Not just, "Oh, they're just overreacting. Oh, they'll be..." No, no. Listen to the team and start beating down that technical debt.
I'll talk about Mark. It's an anti pattern. Mark worked at a company, and he was a director of R and D. Every year...the company had a code base, about a twelve year old code base. Every year he would annually put together a presentation for senior management. It was a wonderful presentation. He got into the habit of re-using the slides year over year.
But he would talk about technical debt, where are we, and he would present this wonderful business case for what we need to change. He would prioritize the areas of focus. He and some architects would dutifully craft, and it was very good work, it was excellent work, they weren't talking about re-architecting everything they were talking about attacking their technical debt. Because year over year their maintenance curves were getting longer. Their ability to implement features were getting harder.
The team was struggling with maintenance, and he would take this presentation to the senior leadership and make the case, and what do you think the reactions were? Anyone, guess. Shot down like a little biplane and it would putter up to leadership and the little plane and it was the little plane that could.
And it was wonderfully thoughtful and he would take it and it would be shot down, and they would do no technical debt for the year. But then Mark, to his credit or detriment, the next year, in January, it was budgeting, we were planning, the little plane would pop up on the surface again with a revised deck.
So they would think, they were thoughtful and it would putter up to leadership and it would be shot down again for ten years. That company now going forward is struggling with their financial viability from the point of view that they have now created a mass of debt that they can't, it's affected their competitive advantage of competing in their marketplace.
And debt is a part of that. It's pay me now or pay me later. So I bring up the manifesto for software craftsmanship as something to think about because I think craftsmanship both at the, I like to think of product ownership or craftsmanship at the product owner level, and at a scrum master level. Craftsmanship matters, so I want you to think about that.
So wrapping up, I have about ten minutes left. I think. Wrapping up I just want to quickly review. The patterns that we talked about is it takes a village to own the backlog. I want you to think about leading with goals. I want you to think about active and congruent and investment oriented back log grooming, multi-threaded look ahead.
Think tapestry. Think how am I balancing the quality thread against the re-factor thread against the feature evolution thread, against whatever others threads are important in your context. I want you to cement as a p.o. or foster your p.o.'s. If you're not a p.o. in here if you're a scrum master, if you're in another role, go back and shove this presentation under the noses of your product owners and raise the bar.
And cement that creative partnership between PO and team. You'll get tremendous bang for the buck out of that. And then build it right and keep it clean no matter the cost. So with that, I'm sort of...I think I can stick a fork in me and I am done. And I will take a few questions, if there are any.
There's a mic there.
Have you seen any patterns or anti patterns around the definition of done that you would like to share?
I think I...I'll simplify it so that...I'll simplify it to I think the biggest anti pattern is trivializing the need for done and then measuring to done. And one of the things I talk about at these conferences a lot, which is complement to this talk, is "doneness." I...folks heard me on Tuesday, I was rambling about four levels of "doneness," and how important that is.
And you heard me talk about that in the goaling section a little bit. I think that's a fundamentally important part is that alignment of those goals to me toward doneness, and then measuring to doneness and committing to that doneness. So the anti-pattern is I think short shrifting it, trivializing it or not doing it, or doing it initially and then falling away from it.
Another anti pattern is, doing it well in the beginning but then thinking, oh getting full of ourselves, as an Agile team and thinking that we don't need to measure. It's inherent. We're just getting done by default and not measuring back to them. So I've seen those anti patterns and the pattern to me is just, doneness is crucial.
I think folks you hear that at the conferences a lot. It's absolutely a crucial part of the dynamic of the fabric of Agile. Another question, any other questions ?
Thanks for the great talk. You had um, talked about technical and quality really and asking the right questions. You sprinkled in a few examples such as, you know, has the um code been reviewed, architect review, can you provide some more examples of the right questions to ask to your team when evaluating the quality of the code?
I think it's and it's not not just from a product owner. I had a session back at IContact not that long ago, and I shared with our C level staff questions they should be asking to inspire the team. And it's not just are we there yet? Are we done yet? Are we done yet? Are we done yet? Or, you know, is it date centric or scope centric.
So, I think, things like burn down directions, asking inquisitive questions about burned down, burn up, asking questions about doneness, is doneness still relevant? You know, let's say you go from back end code to front end code. Doneness might actually might need to adjust based on the types from team to team, or what we're trying to do.
Are the business case from a requirement perspective you may have high security, so let's say, you 're doing a backlog that has security implications and you might want to adjust your doneness. And so questions around, have we done security testing, have we done sufficient performance testing, have I provided you sufficient acceptance test for that story or that feature.
So shifting your question landscape around sort of challenging the team, are they doing the right activities. Asking did you do a code review for that? If it's, if it's something that had a spike associated with it, meaning a complex user story, is fair game to talk to the team about can I see the design.
Did you do a design? Could, could we see the design? Is the design on the wiki? Did you share that with someone else? So I think those questions have, have it's not just the, the artifact. But it's the implication that you're making in the team that something else is important, other than what. Getting stuff out the door of a time box.
And it has, it has huge ripple effect, I think in the team of what we ask and what we amplify. And we don't have to ask about time and scope. I, I really think it's self evident. Teams are driven, you hire good people and they, they understand this is a, it's a, it's a competitive landscape. Any other questions?
I have one, Bob I have one. I have one from the virtual audience.
OK .
Would you clarify refactoring? When is it applicable, applicable and when is it not?
I actually think so, so re-factoring to me, clarify is re-factoring is cleaning up after oneself in a, in a code base. So, something that was done poorly. So cleaning up, refactoring code, re-designing code, re-designing test cases, re-designing test frameworks so it's not just, cleaning up unit tests, I often get the question from our teams.
We re-factor some code but we broke half of our unit test. Is that part of the refactoring? And the answer in the audience is: Yes, that's so cleaning up the unit test is probably part of the refactoring. So I think that is refactoring. When is it applicable? I think it's always applicable, it's a question as to how much and I think what I recommend is make it visible, make it transparent, get it on the backlog and drive those discussions around refactoring relative to features, relative to competition.
We're getting some wonderful traction back at I-contact now. At a C level how do I frame this? Our CEO attended an all hands meeting for our R and D staff yesterday, and he was demanding that we do more refactoring, and he was giving us and asking us he's, like, I want you guys to do more refactoring because I'm seeing benefit in cleaning up things with our speed to delivery.
I, I wasn't there to be for that event, but that's the sort of thing, so it's not just a refactoring, it's being an evangelist to make that to make the benefit of that transparent to the organization. So I think it's always applicable, it's just a question of how much and trust the team to make those balance decisions.
Anything else? I really want to thank all of you for the time.
Oh, one more? The question was are the slides available. I think the slides are on the CD. And if not, if someone wants a PDF or something, if you don't like the format, you can drop an e-mail to me, I'm on LinkedIn, etc. I meant what I said with Lee early on. I'm very active in the community.
So I think the Agile community is a wonderful place to be, and people try to help each other. And that's a part of what I enjoy about the community. Any other questions? You guys rock, I want to thank you for the time.
Rob thanks so much. Lunch time now, and we'll reconvene at 12:45, have a good afternoon.
Excellent, excellent.
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Show/hide comment form
(I was hopping back and forth between this session and the Definition of Done webinar and got flashbacks from my past experience in gating pre-release activities in QA and UAT)