Estimation and Meeting Sprint Commitments

In this episode of SoundNotes, Dave Prior and Derek Huether respond to a couple questions from students who have taken a LeadingAgile CSM and/or CSPO class over the past couple months. Here are the questions they will address in this short video podcast:

Question 1:

My team seems to have a problem with estimating and understanding the estimating concepts. The team members are accustomed to traditional waterfall projects and estimating everything in units of time. How can I help them understand estimating, but continue to complete the sprints with no PBIs (Product Backlog Items) rolling over to the next sprint?

Question 2:

I have a team lead who is skeptical of scrum, especially metrics related to the process. He doesn’t think carryover matters from sprint to sprint as long as we’re “creating value” and getting the program priorities completed. Any advice on how to convince him that metrics can be a tool for good, and that the sanctity of the sprint commitment matters?

Failure Pattern in Scrum

I recently spoke at a corporate community of practice event.  My session presented a useful model to identify indicators within a system to predict its failure. First, we started by applying the model to everyday systems everyone could relate to.  Next, I asked the attendees to map a system of their own. As I walked them through my model step by step, I used Scrum as my example system. Upon completion of the worksheet (see my completed sheet below), attendees were able to see if there were any “gaps” in their systems. The gaps provided an indication that a respective system was at risk of failure. To clarify, on a delivery team level, I see the Scrum Framework as a solid method for managing product development. But what about Scrum in the context of the entire delivery organization?  Using both The Three Things You Need To Know To Transform Any Sized Organization and my model, I look at Scrum in a broader context. I can see a potential failure pattern.

Scrum failure pattern

What is the failure pattern I see in Scrum?

My model will segment any system into 5 areas: Clarity, Commitment, Ritual, Progress, and Habit. The gaps that I will note below are those things not mentioned in the Scrum Guide.

Gap 1: Clarity

What does the structure of the organization look like (Portfolio, Program, Product) above the Scrum Team? We need a shared understanding.  What does the governance of the organization look like (Budget, Dependencies, Risks, Quality,…) above the Scrum Team? What are necessary metrics and tools of the organization above the Scrum Team?  Some organizations are very large and heavily distributed.  How will you measure the health of the entire delivery system?

Gap 2: Commitment

In Mike's 3-things talk, he calls this accountability. Given the broad applicability of my model, I prefer to call it commitment.  Commitment can be any resource. So, what money and time may be required for Scrum training of all leadership and Scrum teams within an enterprise?  What money and time may be required for procurement, installation, and training of tooling used to manage and report on the health of the delivery system? Lastly, we need agreement from the Leadership team to follow the Scrum Framework (or more particularly respect that the Scrum team is following it).

Gap 3: Progress

As I noted in my post on Productivity Patterns, if you lack progress, you lose momentum. If you lose momentum (or should I be so bold to say velocity or throughput), you will lose commitment to the system. Those who are funding the efforts (those outside the Scrum team) need to know progress is being made in a way that is important to them.  What is the Time to Value?  Is the Scrum team predictable on a release level (Release Burndown/Burnup chart)?  Are we even building the right things? (Product Fit) Are we building things right? (Quality)

Gap 4: Rituals

Rituals can be event or meetings, as part of your system of delivery. First, let's start with product vision.  Scrum teams have a horizon of a few weeks (the sprint).  Vision is viewed or realized in months, quarters, or years. Read the Scrum Guide and you won't see Vision mentioned once.  Also absent from the the Scrum Guide is the notion of portfolio or release planning.  Unless you have a delivery capability that allows you to release at the end of every sprint, I can't champion release planning enough.  In addition to that, good portfolio planning ensures we have a balanced system of delivery and ensures we have capacity to make commitments against a roadmap.

Gap 5: Habit

Given the rituals I outlined above, you should make it a habit to have periodic Vision Reviews, regularly scheduled Portfolio Planning/Reviews, and ensure you're consistently doing your Release Planning.

Conclusion

I'm not suggesting you abandon Scrum. But after you look at the highlighted gaps I listed above, in a system of delivery larger than a single Scrum team, you should consider more than what is in the Scrum Guide.

I Discovered a Productivity Pattern

My Past Experience

The Internet is littered with a million improvement patterns. In my many years of attempting to improve productivity for my clients and myself, I’ve tried just about everything. Regardless if the post, podcast, or book is promising to do twice the work in half the time or that you can cram an entire work week into 4 hours, there is something out there for everyone. My first venture into this productivity-focused world was way back in the early 90s, when I watched this horrible movie titled Taking Care of Business, starring Jim Belushi and Charles Grodin. In the movie, an uptight advertising exec has his entire life in a filofax organizer which mistakenly ends up in the hands of a friendly convict who poses as him. The movie is still horrible but the organizer idea seemed to work for me.

Franklin Covey Planner

From this movie, I discovered the Franklin Covey Planner. Yep, my world was filled with A1, B1, C1’s. Alas, I couldn’t make it work. Much like the guy in the movie, everything was in a little leather book with special pages (that were not cheap). Unfortunately, if I didn’t have the book in my field of view to constantly remind myself, things didn’t get done. I think I lasted a year, until I discovered the cost of refilling the book with new pages.

GTD

I then discovered GTD (Getting Things Done) by David Allen. This was 15–20 years ago. Again, it worked for a little while but I then found myself doing too much organizing and too little doing. Things were going away from paper filing and everything in that system was all about paper filing. Maybe I was doing it wrong. It just wasn’t clear to me. I didn’t see any real progress or productivity improvement so I just stopped doing it.

Personal Kanban + Pomodoro Technique

In mid 2009, in a moment of Internet serendipity, I ventured into the world of Personal Kanban. I think I searched “Zen” and up popped a website for a Kanban tool. I started using it and loved it. Alas, that company got purchased by Rally and they are no longer taking registrations. But, this has become the first system I have been able to stick with. Just to try other tools, I soon switched over to LeanKit Kanban. I’ve been using it ever since. I like that it doesn’t make any promises it can’t keep. “Visualize your work, optimize your process and deliver faster”. Around the same time in 2009, I also began using the Pomodoro Technique to optimize my productivity.

LeadingAgile Transformation Framework

In 2012, I joined LeadingAgile. Though we didn’t have a defined system at the time, a Transformation Framework emerged.  Since that time, when the system is followed, it works really well.  When things don’t work so well, the same failure patterns are present.

Productivity Rosetta Stone

So, why do some methods work and some do not? Why did I abandon the Planner and GTD systems so long ago but still use Personal Kanban and the Pomodoro Technique? Well, I started by listing common traits on a whiteboard and saw relationships and discovered some patterns. Not only are there three things I believe every productivity system needs to work, I also see three things that are necessary to prevent you from abandoning that system.

I describe it as a Productivity Rosetta Stone. For those unfamiliar, the Rosetta Stone is a rock slab, found in 1799. It was inscribed with a decree that appears in three scripts: Ancient Egyptian hieroglyphs, Demotic script, and Ancient Greek. The stone presents essentially the same text in all three scripts and provided the key to the modern understanding of Egyptian hieroglyphs. I’ve applied my productivity Rosetta Stone to Scrum, Kanban, Pomodoro Technique, Lean Startup, and even organizational transformation frameworks. All of them check out and it provided me with a key to better understand productivity patterns.

3 Things to Increase Productivity

1. A system is a set of principles or procedures to get something done or accomplished; Anyone can follow a system.

2. A ritual is a series of actions or type of behavior regularly and invariably followed by someone. It’s different from a system. A system might only be followed once, but by many people. A ritual is something someone or some group does again and again, in the hope of arriving at the same or improved outcome.

3. A habit is a regular tendency or practice, especially one that is hard to give up. If you want to be productive, you have to be habitual with your rituals, as part of your system.

How does it all fit together? Name a system. Next, list your process steps, sequence, and any rules around them. Last, do the steps again and again until it becomes a habit.

Lack of These Kills Productivity

Clarity, Progress, or Commitment

1. Clarity is the quality of being certain or definite. You need clarity in order to know what you need to do. Lack of clarity creates confusion and waste. Each step of a system should be actionable and repeatable. In order to ensure certainty around your steps, write them down; maybe draw a picture or diagram. If your outcomes are not repeatable, you have an experiment but not a system.

2. Progress is forward or onward movement toward a destination or goal. Your goal is productivity. If you lack progress, you lose momentum. If you lose momentum (or should I be so bold to say velocity or throughput), you will lose commitment to the system.

3. Lack of commitment to the system results in you no longer using the system. You move on to something new to get the productivity results you seek.

In the event your system lacks clarity, progress, or commitment, performance will go down or you’ll stop using it all together.

Scrum

Enough with the  nebulous ideas. Let's apply the patterns against the Scrum Framework.

Jeff Sutherland and Ken Schwaber did a pretty darned good job providing clarity around the system in The Scrum Guide.  Being the Guide is only 16 pages long, there it's a whole lot to it. It includes a definition of Scrum, the theory behind it, and then provides details behind teams, events, and artifacts.  That's it!  Rituals (events) include sprint planning, a daily (15-minute) Scrum, a sprint review, and a retrospective.  Each of these rituals helps provide both feedback and progress within the sprint.  To ensure we see the progress, we timebox sprints, commit to deliver product increments regularly, and use information radiators like burndown charts to visualize the completion of work.  Like any system, if you are not habitual about each of the items within the Scrum Guide, Scrum falls apart.  That means commit to the system and be consistent, sprint after sprint.

Summary

Though I have only provided a conceptual model, try applying it to your personal system. Like in any productivity strategy, once your defined system becomes habitual, you can start to focus on improvements. Maybe you want to do more in less time. Maybe you want to do the same with higher quality. You be the judge. It’s your system. Remember, you’ll still need clarity, progress, and commitment or your productivity will be short lived.

Listen to Dave Prior and me in an episode of LeadingAgile Sound Notes, as we talk about the Productivity Triangle.

If you want an editable copy of the triangle, download it here: productivity triangle template

One final note. It would mean a lot to me if you could leave a comment and tell me which design you like more. Do you like the colorful Venn diagram look or the black and white triangle?  Please tell me in the comments.  Thanks!   ~Derek

Agile Police or Ambassadors

What do some vegetarians and some agilists have in common? It sounds like the setup of a bad joke, doesn't it?  Actually, some believe their practice is best and you are wrong for doing things differently.  Well, at least that's my first hand experience. Over the weekend, I overheard a conversation while we were dining out.

So-and-so isn't a real vegetarian. She eats fish.

It was a little deja vu to me.  Just days earlier I overheard a similar conversation.

So-and-so isn't really doing Scrum.  They use a Product Owner team.

So, what's our deal?  Should I stop eavesdropping on people or should we address why we get so protective of what we think of as a textbook example of something?  Who's keeping score?  There seems to be a fear the vegetarian police or the Agile police are going to be knocking on doors any day, demanding people stop saying they are vegetarians or agilists.  Sure, I get it. You're disciplined. You're passionate about being a vegetarian or passionate about Scrum. But why do we have to be police and not ambassadors?

Vegetarians

A vegetarian diet is derived from plants, with or without eggs or dairy. Varieties include: Ovo, Lacto, Ovo-lacto, Veganism, Raw veganism, Fruitarianism,...  Those with diets containing fish or poultry may define meat only as flesh from a mammal and may still identify with vegetarianism.  Vegetarianism can be adopted for different reasons, including objection to eating meat out of respect for critters.  Other reasons include religion, health-related, it looks cool, can't afford it, or plain old personal preference.  At the end of the day, to each his or her own.

Agilists

An agilist believes in a set of values and principles (originally for software development) in which requirements and solutions evolve through collaboration between members of cross-functional teams. These teams pull work from a prioritized backlog and provide a demonstrable product increment on a regular interval. It promotes value focused adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. Agile methods can be adopted for different reasons, including the solution is not yet fully defined, our organization says we're going to follow the practices, we accept the mindset, or it looks cool.  In the end, the framework or methodology really doesn't matter. 

Commonality

Before you go off and point your finger at someone and claim they are not a real vegetarian or agilist, stop and think about why they are doing either.  In the end, why are you doing it?  Often, I see the similarities will outway the differences. I see many wanting to benefit from a practice but then have to operate within a constraint. I think that's what prevents many of us from being extremists and I'm quite happy with that.  I actually like the diversity.

Perhaps there should be a 13th principal added to the manifesto.

13.  Acceptance of similarities of practices over judgement of differences

As noted earlier, we need a lot fewer Agile police and a lot more Agile ambassadors.

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

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

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

Product Owner and the Scrum Team

On 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.

The product owner and the scrum team. Can one person do this at scale?

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.

New Agile Training Classes Announced

Though 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.

---