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:
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?
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?
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.
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.
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.
Be it get-rich-quick schemes or rapid-weight-loss solutions, the Internet is littered with a million improvement schemes. 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.
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.
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.
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.
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
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, 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?
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.
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.
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.
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.
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...
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.
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?