Scrum Archive

0

Could a Patent Troll Kill Agile?

patent trollPatent Trolls

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

  1. Should Agile Alliance, Scrum Alliance, PMI, or some other body buy this stupid patent?
  2. Should VersionOne, Rally, and Microsoft join forces to share this patent?
  3. What would you do?

 

Image: Pictofigo

 

Tags: ,
1

Top 10 Negative Personas of a Daily Standup Meeting

standingAll 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

0

Product Owner and the Scrum Team

iiba baltimoreOn March 11, 2014, I presented a talk to IIBA Baltimore on the topic of the Product Owner and the Scrum Team.  I have to say, this was an awesome bunch of people to talk with.  You know you’re at the right place when they offer beer and crab cakes with dinner.  Gotta love Charm City!

The last 10 years of Agile have focused on the team. I believe the next 10 years of Agile will focus on the enterprise. That said, should the Product Owner continue to be a single person or does it need to evolve as well? Let’s cover the basics and then see how LeadingAgile has been successful at leveraging the Product Owner role at scale.

iiba promo code

As a thank you to IIBA, I was able to get a promo code for 50% off an upcoming Agile Requirements Workshop. The code “IIBA” is limited to only 5 seats.  Are you a business analyst in the Atlanta area or want to go visit some friends in Atlanta?  Take advantage of this limited offer.

0

New Agile Training Classes Announced

ICAgile Accredited CourseThough I’ve been doing Enterprise Agile Coaching with LeadingAgile for over a year now, I haven’t been doing a lot of training (or blogging).  I’ve been sticking to agile transformation work and the occasional private class.

Well, it’s time for an update.  Dennis Stevens and myself co-authored the International Consortium for Agile (ICAgile) Agile Project Manager learning objectives back in February.  The result was a solid certification even a PMP could respect.

New Classes and Locations

LeadingAgile has decided to offer more public training.  We’re offering classes in Atlanta, Denver, Orlando, and Washington DC.

Scrum

Certified ScrumMaster certification class

Certified Scrum Product Owner certification class

PMI

PMI Agile Certified Practitioner (PMI-ACP) certification prep class

ICAgile

Fundamentals of Agile (CIP certification awarded)

Agile Project Management (to be announced)


Are in interested in some public training?

Send me an email and I’ll get you a special discount code.


2

New Scrum Team Challenges

Velocity ChartA while ago, I published a post titled: Simple Cheat Sheet to Sprint Planning Meeting.  Though I understand every team is different, I thought it would be helpful to those who are new to agile processes.  People are always looking for cheat sheets, templates, and stuff like that.  What is the harm of giving them what they want?

In retrospect, I think the harm is the lack of context.  When people come to a training class, they are provided an ideal situation.  Even the Scrum Guide was written as though you’ve been doing Scrum for a while. It doesn’t talk about things that happen leading up to your team’s first Sprint.  It doesn’t talk about the complexity of scaling to the enterprise.  It’s just vanilla.

I just got back from coaching a new team and I’ll be heading back next week to see how they are doing.  To get them moving forward, I facilitated release planning and sprint planning.  That’s where things started to get interesting.  What if your team has never done release planning or sprint planning?

Release and Sprint Planning

The purpose of Release Planning is so the organization can have a roadmap that helps them reach their goals.  Because a lot of what we know emerges over time, most of what we actually know is that we don’t know much.

The purpose of the Sprint Planning is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

You’re new to Scrum.  You don’t have a velocity (rate of delivery in previous sprints) and you are not sure of your capacity (how much work your team can handle at a sustainable pace).  What do you do?

The Backlog

The product backlog can address just about anything, to include new functionality, bugs, and risks. For the purpose of sprint planning, product backlog items must be small enough to be completed (developed, tested, documented) during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner. 

Again, you’re new to Scrum.  How do you know what small enough is?

Right Sizing Backlog Items

Product backlog items determined to be too large to be completed in a sprint, based on historical data of the team, should not be considered as sprint backlog candidates during the sprint planning meeting and should be split into smaller pieces. Remember, each story must be able to stand on its own (a vertical slice).  It should not be incomplete or process based (a horizontal slice).

Again, you’re new to Scrum.  You have no historical data.

Determining Velocity

The velocity of a team is derived by summing the estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams focus less on utilization and more on throughput.

If you have a new team, not only do you not have a velocity, you won’t have any completed work to compare your estimates to and you won’t know how many deliverables to commit to.  What do you do?  I think you just go for it!  You keep track of what you are completing and collect historical data.  You get through the sprint and establish some context for future sprints.

The first few sprints are going to be pretty rocky, until the team begins to stabilize. Just ask yourself.  WWDD?  What would Deming Do? Plan a little; Do a little; Check what you did versus what you planned to do; Act on what you discover.