Inspired by artwork by Pictofigo
Could a Patent Troll Kill Agile
Texas Patent Troll
I don't personally own any patents but perhaps I should reconsider. If you own a patent, you can sue people for infringing on it. You don't have to actually create anything valuable. You just sue people and make money. You'd think it sounds crazy but it's happening! People known as "patent trolls" are buying patents for the sole purpose of suing others. One guy in Texas owns a patent and sent out 9,000 letter demanding $1000. The violation? He claimed to have patents that cover any networked "scan-to-email" function.
Patent That Could Kill Agile is for Sale
On December 8, Penn State is looking to sell a few patents it owns. One of the patents for sale is US Patent No. 8,442,839, entitled "Agent-based collaborative recognition-primed decision-making." The lead inventors are PSU professors John Yen and Michael McNeese. The patent essentially describes different ways that people work together to solve a problem.
Patent Abstract
Collaborative agents for simulating teamwork (CAST) are provided with a recognition-primed decision (RPD) model, thereby enhancing analysis through linking and sharing information using knowledge and experience distributed among team members. The RPD model is integrated within a CAST architecture to the extent that agents can proactively seek and fuse information to enhance the quality and timeliness of the decision-making process. The approach, which is applicable to both human assistants and virtual teammates, can approximately track human's decision-making process and effectively interact with human users...
Thoughts
So, at the low cost of $5,000, you could theoretically buy the patent and then sue anyone using a collaborative agent (could be software or even physical boards) that helps people make better decisions and share information with team members. Essentially, you could require all Agile teams to pay a licensing fee.
Questions
Should Agile Alliance, Scrum Alliance, PMI, or some other body buy this stupid patent?
Should VersionOne, Rally, and Microsoft join forces to share this patent?
What would you do?
Image: Pictofigo
Time to Replace Backlog Grooming
The Problem
Over the last few years, I've worked with numerous teams. One thing they all struggle with is backlog grooming. They all know they need to do it. Unfortunately, they all seem to struggle with when to do it or who should do it. The most interesting struggle with backlog grooming happened two years ago. The "story time" meetings took place at the beginning of a month-long sprint. The manager stated, the work to be completed and delivered during that sprint had to be refined within the same sprint. This helped explain why the team thought they needed month-long sprints. When I asked why they would try to refine work the first two weeks of the sprint and then complete that work the second two weeks, you know what their answer was? "It said to do it like that in the Scrum Guide!" After I clarified their misunderstanding, we established a cadence to continuously mature the backlog. A rotating selection of people would participate in the scheduled meetings. We would reserve capacity from each sprint to get that work ready for future sprints. The team was able to shorten their sprints to 2 weeks. They more than doubled their delivery rate without increasing defect rates. With that as an example, over the last few years, I have evolved my practice of backlog grooming. Let’s look at some key dates in the evolution of backlog grooming.
Evolution of Backlog Grooming
2005: "grooming the product backlog" is mentioned by Mike Cohn on what is now the Scrum Users Yahoo Group;
I always have teams allot some amount of time to “grooming the product backlog” to make sure it’s ready for the next sprint.
2008: A formal description of "backlog grooming" is given by Kane Mar, under the name Story Time, and recommending it as a regular meeting
I call these meetings “Story Time” meetings....Although they are not a formal part of Scrum, I’ve found that Story Time greatly improves project planning and reduces confrontational planning meetings, which are all too common for many teams. A Story Time meeting should be held at the same time and location every single week and involve the entire team, including the Product Owner and ScrumMaster. The sole intention of these weekly meetings is to work through the backlog in preparation for future work.
2011: The practice of "backlog grooming" is called "backlog refinement" and promoted to an "official" element of Scrum with its inclusion in the Scrum Guide
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
2014: Derek Huether from LeadingAgile evolved the practice of backlog grooming with one of his clients, to allow the practice to work better at scale, calling it a "Progression" workshop.
When operating at scale, my client deals with different problems than a standard Scrum team. They're dealing with separate lines of business. They're dealing with multiple delivery teams for each line of business, to include external vendors. They're dealing with a portfolio roadmap that has annual plan items and budgets. Our strategy encapsulated the entire product delivery value stream, while ensuring we had enough architectural runway. We progressed work to be consumed by delivery teams, via a series of workshops.
Progression Workshops
Our progression workshops differ slightly from the story time meeting detailed by Kane Mar and the refinement meeting mentioned in the Scrum Guide. Counter to Story Time, we don't invite the entire team. Instead, we have elevated the workshop to a group some have come to know as a Product Owner (PO) team. The group of people within the PO team will vary, depending on the line of business. Yes, there will be a Product Owner (Product Lead) and facilitator, but from there we'll include the development lead, testing lead, and an architect. We've found two key challenges when operating at scale. First, is there a well defined backlog that is ready enough to be consumed by different delivery teams? Second, is the work being queued up to the delivery teams free and clear of other teams. That is, have we decomposed it in such a way that we've minimized dependencies on other teams? Beyond that, in order to achieve some degree of architectural runway, we continually refactor existing platforms. Architectural changes are not only made incrementally but we require an architect to be present at every progression workshop.
Counter to the Scrum Guide, I'm not going to be proscriptive as to how much capacity the PO Teams do/should commit to progression workshops. The goal is to have enough work ready for delivery teams to consume for a few sprints.
When progressing work, we do expect some artifacts to be generated, to contribute to the teams understanding of what will be developed, tested, and delivered. Below is a partial list of potential artifacts. To be clear, we do not expect all of these to be generated.
Potential Deliverables
- System Context Diagram
- Dependency and Risk Work Items
- System Architecture Guidance Acknowledgement
- Use Case Diagram and document
- Business Process Flow
- Known Business Rules
- High Level Technology Alignment
- Architecture Backlog for Planned Work
- As-Is Data Contracts
- Feature Work Items Assigned to Delivery Team
- Feature Business Value and Acceptance Criteria
- Feature Stack Rank
- Test Strategy
So, that's the high-level view of the Progression Workshop. Most of the time, a feature will require two or more progression workshops before work is ready to be consumed by a delivery team. Once features progress to a defined level of shared understanding, the delivery teams assist in the decomposition of features to user stories. In this way, work is decomposed to the right level of detail for each delivery team.
I'm curious, how have you scaled feature development and backlog grooming in your organizations? What mechanics outside of the standard Scrum process have you found useful to refine work to be completed by delivery teams? Have you evolved Story Time or backlog refinement?
Image Credit: Pictofigo.com
Vote for my AgileDC Personal Kanban Workshop
Submitting my Personal Kanban workshop to AgileDC
This year, AgileDC will be held October 21 at the Kellogg Conference Center at Gallaudet University. Coming off the popularity and success of my Personal Kanban workshop at Agile2014, I decided to submit an encore workshop to the AgileDC conference
I need your help!
Unlike in prior years where the conference organizers picked who would make the cut and who would not, this year it appears they are using Conference Engine and crowd sourcing it.
How does it work?
1. Click on the link that takes you to my session
http://confengine.com/agiledc/proposal/515/at-home-and-work-how-to-get-more-stuff-done-an-introduction-to-personal-kanban You and read about my proposed session. If you weren't at Agile2014, this will be an encore workshop.
2. Click on the heart to "vote up" my workshop
3. Go to the Login page. Login with one of your favorite social networks. (see image)
4. You may get routed back to the main Confengine website. If that's the case, click on my link again.
5. Click on the heart to "vote up" my workshop
Your vote is much appreciated!
Feedback from Agile2014 Personal Kanban workshop
The votes and comments are in!
A little over a week ago, I led a Personal Kanban workshop at Agile2014. It was to be both informative and interactive. Below is what Agile Alliance sent me.
Dear Derek Huether,
Thank you for presenting at the Agile Alliance Agile2014 Conference; your session helped make the conference a real success!
Please find attached the raw feedback data (including comments) for your session entitled "At home and work, how to get more stuff done. An introduction to Personal Kanban", in which 14 attendees left feedback.
The feedback questions are based on a 5 rating scale, with 5 being the highest score.
Your average ratings are shown below:
- Session Meets Expectations: 4.57
- Recommend To Colleague: 4.71
- Presentation Skills: 4.71
- Command Of Topic: 4.86
- Description Matches Content: 4.79
- Overall Rating: 4.79
Lean Coffee Baltimore Topics for August
Lean Coffee Topics in dot-voted order
Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated. We met at Mad City Coffee at 07:30 . We enjoyed an hour and a half of coffee and conversation.
August Topics
Distributed Teams
When everyone in your company is distributed, what are some ways you can stay connected?
Paired Programming
How do you sell paired programming to your organization? Management sees it as one for the price of two.
Test Driven Development
How exactly does it work? We hear that it's a good thing but why?
Method Turf Wars
Coaches and consultants get so passionate about the frameworks they promote. It used to be Waterfall against Agile. Now it's seemingly SAFe , Scrum at scale, enterprise Kanban and Lean... For the customers, do they really care? They just want stuff to work!
Meetups and Conferences
Have you been to any good meetups or conferences lately? Do you know of any upcoming events?
Conversations
We had some really good conversations around the topics. Rather than bullet them out here, I'll respond in the comments to encourage a little conversation.
My Personal Kanban deck at Agile2014
Here is the deck from my Agile2014 workshop on Personal Kanban. Participants were introduced to the principles of Lean and the application of Kanban to visualize their work, limit distraction and waste, and get stuff done. I covered the core concepts outlined in Jim Benson and Tonianne DeMaria Barry’s book, Personal Kanban, to get attendees of my workshop started.
Click here for Agile 2014 Workshop Tasks.pdf, referenced in my workshop
Top 10 Negative Personas of a Daily Standup Meeting
All Agile teams should be holding a daily standup meeting. Don't think of it as a daily planning meeting. Think of it as a daily opportunity to have a shared understanding of what is getting done and what lies ahead. During a daily standup meeting, participants sometimes exhibit negative behavior that will detract from the meeting. As an empowered team, it is your job to self-manage and encourage good behavior. Some of these behaviors are so common, we don't even realize people are doing them. So, I'm giving them some names. Next time you hold a daily standup, see if anyone (including yourself) exhibits any of these 10 behaviors. Rather than using the list as a means to label others, use it to reflect on yourself. How might others be perceiving you? Is the persona you are projecting counter to your goals?
If you think of some behaviors that should be added to the list, I would love to see them.
Daily Standup Meeting Negative Personas
10. Pat Decker the Obsessive Phone Checker
This person does not always pay attention and is constantly look at her (or his) phone. Did a BFF just like something? Did someone on Twitter just favorite that pic of the team board? In addition to checking her phone, she likes to share what she sees with others during the standup. "Pssst, Bob, check out this Vine video or pic on Instagram". She's not so loud that she's overly disruptive but now Bob missed what someone else said during the standup.
9. Stephen Craig who is Always Too Vague
This person can get stuck on the same task for days but doesn't want anyone to know. When speaking to the team, they are crazy vague. Stephen will offer very few details until the team pushes for a deadline. He (or she) will use language like "Yesterday I was working on task 123 and today I will be working on it some more". No other information is volunteered. When asked if they need any help, they clarify they have no blockers or risks.
8. Bobbie Bainer the Team Complainer
When the attention is on Bobbie, get ready for the positive energy to be sucked right out of the room. Bobbie complains, complains, and complains some more. Management, teammates, or the technology is all fare game. Everything and everyone sucks and no one knows just how bad they have it. Don't bring up religion or politics unless you want Bobbie to go right into a 20 minute tirade.
7. Jess Jewler who loves the Water Cooler
Jess comes to the daily standup to talk, but not about what needs to be done today. Instead, he or she will talk about just about everything else. The next 15 minutes is dedicated to the water cooler. Did you see the last episode of House of Cards or The Walking Dead? Are you going to watch the Ravens play this weekend? My son plays Minecraft and constructed this totally awesome building with redstone. Anything is fair game, as long as it's not about work.
6. Billy Platitude with the Bad Attitude
Billy is a leftover from a bygone era. He was the best of the best mainframe developers and all he needs is a DLD and he'll give you what you need... in a few months. You want any changes between now and then? Forget it! He thinks all things agile are stupid and just plays along begrudgingly. You may catch him make cynical "funny" comments at standup to point out how right he is about how stupid agile is.
5. Will Funky the Non-Committal Junkie
Will does not want to be painted into a corner. Typically, he uses language like try, maybe, pretty sure, I'll get back to you, we'll see, would like to think, soon, almost. You'll also see Will be the last person to comment on something and will usually go with the crowd.
4. Tom Mater the Specialty Updater
Tom only gives vague commitments, usually understandable only by those in his discipline. The overall team gains little value from the statements. If you ask him for details, he'll either tell you to look it up in a tool or he'll be very technical in his response. Half of the team doesn't understand what the hell he's talking about.
3. Drue Gru who thinks he's Better Than You (and the team)
Drue has been around for a long time. He's better than you and he knows it. If you need him, you know where to find him. He either arrives to the standup meeting late or he doesn't come at all. He has little to say because you wouldn't understand what he's talking about. He already knows everything so what is he to gain by slumming with you and the team for 15 minutes? Let him know when something important happens. *sarcasm*
2. Pearl Revolver the Problem Solver
Pearl means well but she lacks a sense of time. She wants to have in-depth problem solving discussions on obstacles identified during the standup meeting. She's very curious what issues others are having because she's going to want to talk it out and fix it right then and there. Even if there is a reserved 15 minutes after the standup, Pearl figures there is no better time than the present to tackle a challenge.
1. Ian Krumpter the Interrupter
Do you listen or do you wait to talk? Stop and think about that. There is a difference. Ian waits to talk. People can be binary in that way. If you're talking, you're less likely to be listening. He wants to prove just how awesome he is so you'll see him interrupt even if the topic doesn't really apply to him.
Thank you to the other coaches at LeadingAgile for their contribution to this post. The original post was dated March 17 over at the LeadingAgile blog.
Image Credit: Pictofigo