Karaoke Agile

Have you ever gone out with your friends to a karaoke bar and watched someone, who did not speak English, sing the best Bon Jovi Livin on a Prayer you have ever heard, just short of seeing Bon Jovi live back in 1987?  I've seen both.  Have you ever worked with or for someone who follows a process or framework to the letter but does not have the first clue why they are doing what they are doing?  Again, I've seen it. The major difference is one is singing a song for personal entertainment and the other is potentially wasting time, money, and putting projects or product delivery at risk.

Cargo Cult

The name is derived from the belief among Melanesians in the late 19th and early 20th century that various ritualistic acts such as the building of an airplane runway will manifest in the appearance of material wealth, particularly cargo, via Western airplanes, though the meaning of the behavior is more complex than a simple misunderstanding. That mouthful is brought to you from Wikipedia.

I hear cargo cult referenced a lot in the Agile community.  I've been to half a dozen Project Management conferences and never heard the term once. I've been to an equal number of Agile conferences and heard it used every time.  We reference it all of the time, referring to the rituals of Scrum, SAFe, and other frameworks.  People memorize the frameworks but don't know why they are doing the rituals. They have little hope of improving upon a framework, if they follow rituals blindly.

Agile Translation

I recently wrote that the Agile community should consider using terms anyone understands.  If I said cargo cult, I would have to spend the next few minutes quoting what I wrote above, to explain it to a customer.  It could make you feel smart, needing to educate someone on a new term.  But, why not use a new term like karaoke agile?  First, I know the Agile community LOVES to use Japanese words.  With a Japanese word origin, from kara empty + ōke, short for ōkesutora orchestra, practitioners should be all over this!  For better or worse, I don't know anyone who doesn't know what karaoke is.  This includes anyone outside the Agile community.

Karaoke Agile

Combine words of Japanese origin and the word Agile.  Stop using the term cargo cult when describing people or organizations that follow processes or frameworks without understanding why they do it.  Win-Win.

3 things you need to increase productivity

What I Believe

If you want to increase productivity, I believe you need 3 key things. In a previous post,  I wrote you needed ritual and motivation.  After some reflection, I decided to update that.  First, create a system to ensure you are always getting stuff done, regardless if you're motivated (though it helps). Second, create rituals to follow within the system.  Last, repeat those rituals until they become habits.

System

My system of choice, for my own work, is Kanban.  It's a method I use to manage everything I do.  In short, Kanban is a visualization of value flowing through a system. I use sticky notes on a wall as signals of outcomes I'm working toward. I have columns on the wall; To Do, Work In Process (WIP), and Done.  I also have the WIP column split into two rows. One row is for active work in process. The second row is for outcomes or work that is blocked.  I believe one of the keys to a successful system is having clarity around its design but also to have low overhead (effort to maintain the system).  It doesn't matter if I use a physical wall or a virtual one, the importance is either are in my field of view.  When on the road, I use a virtual Kanban. When at home, I prefer a physical one.

My supporting system is a Pomodoro.  A Pomodoro is simply a kitchen timer.  Like it or not, I respond really well to deadlines. One of my favorite quotes is:

A goal without a deadline is merely a dream.

Give me a goal with a deadline and I may not get it all done, but I'll make progress and get you something.  If I have a goal without a deadline, I can think something to death.  Like with my Kanban, I prefer to go with physical but I'm happy to use a virtual one as well. The important thing is the timebox. It's like personal sprints. (yep, like Scrum).  Make a commitment; get it done.

Ritual

• Every morning, I review my (virtual) LeanKit board

• I then review my physical Kanban board next

I review my Kanban board in a very specific order:  Done, Work in Process, Blocked, To Do.  [1] I do this to remind myself what I recently got done.  [2] It allows me to verify if I finished something the day before but forgot to pull it to done. [3] It gives me a chance to pull something off the to-do column and put it back in my backlog, allowing space for something of higher value.

• I pull a card from To Do to WIP

• When I'm ready, I set the Pomodoro timer for 25 minutes and begin work

• When the timer goes off, I take a 5 minute break

• Reset the timer for another 25 minutes, review what my next highest priority is, and begin

  • If I'm coming back from an extended break like lunch or dinner with the family, I still reset to 25 minutes

  • I continue this process until I finished work for the day

Habit

It's true if you get something done, regardless of the size and complexity, it makes you feel good (thanks to dopamine).  If something makes you feel good, it physically reinforces your behaviour to do it again.  You need a few quick wins (getting things to Done), to start releasing dopamine and establish the ritual for the longer term.  If you don't get outcomes, you're not going to keep doing something.  If you can create the habit of getting several smaller things done per day, you on your way. Habits are like safety nets. They are not for optimum productivity. They are there to ensure minimum productivity.  I recommend breaking work into small enough chunks that you can get something done every hour.

Summary

By doing these three things, you'll achieve increased productivity. If you can get inspired and motivated, your increase will be even higher.  Alas, inspiration and motivation are a different topic.  Until then, capitalize on the system, rituals and habits, until the next time you get inspired.

If you are looking for a system to work beyond personal productivity, the same rules apply.  Visualize your group or organization's continuous flow of value on a wall or board (physical or virtual Kanban).  Define timeboxes, like in Scrum, for teams to focus on work.  Take a short break at the end of each timebox.  Keep reflecting on the things you've accomplished.  Get that dopamine flowing!

Notes:  Picked up by DZone and viewed over 3,000 times in 3 days.

Discipline over Motivation

I recently read a compelling piece titled Screw motivation, what you need is discipline.

It claimed...

If you want to get anything done, there are two basic ways to get yourself to do it.

The first, more popular and devastatingly wrong option is to try to motivate yourself.

The second, somewhat unpopular and entirely correct choice is to cultivate discipline.

It doesn't sound convincingly balanced, does it?

What the author goes on to write

Motivation, broadly speaking, operates on the assumption that a particular mental or emotional state is necessary to start or complete a task.  Discipline, by contrast, separates outwards functioning from moods and feelings and thereby circumvents the problem.

Successful completion of tasks brings about the inner states that chronic procrastinators think they need to initiate tasks in the first place.

If action is conditional on feelings, waiting for the right mood becomes a particularly insidious form of procrastination.

If you wait until you feel like doing stuff, you’re screwed. That’s precisely how the dreaded procrastinatory loops come about.

What I think

I halfway agree with the author's thoughts. But, I believe you need ritual (not discipline) and motivation.  I believe you should create a system to ensure you are always getting stuff done, regardless if you're motivated (though it helps). My system includes rituals that I follow.  Those rituals become habits. Those habits help me get more stuff done.

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.

Correct Context for an Agile Transformation

A few weeks ago, I spoke at the Heart of Agile conference up in Philadelphia. The conference was a two-day conference dedicated to educate attendees on Alistair Cockburn’s new methodology, The Heart of Agile. The Heart of Agile is focused on getting back to the basics of Agile. In the last 15 years, Agile has been weighed down with frameworks and practices of many shapes and sizes. At the Heart of Agile are 4 key concepts: Collaborate, Deliver, Reflect and Improve. From this center we can branch out to all of the principals, practices, skills, and tools.

The two-day event offered:

Opening and closing keynotes by Alistair Cockburn focused on the “Heart of Agile” Speakers - presentations and discussion tracks for Collaborate, Deliver, Reflect, and Improve: Tutorials - Speakers provided presentations and facilitated conversations on hot topics and key trends on Agile principles and practices. This was an opportunity for experienced practitioners to demonstrate and share their knowledge in a specific topic, solution, or technique. Collaborative Conversation - Joint problem-solving with other experienced participants in a topic. A facilitated peer-to-peer event, where everyone had something to contribute to the topic, though may not have been an expert at the topic. The coordinator proposed a topic and a facilitation structure, the attendees worked in small groups (typically 4-8 people), and mutually exchanged and collaborated their outputs. Experience Reports – Experience reports contained first-hand information and reflection: “We saw this…,” “Our team did that…,” or “We learned the following from our experience…” Experience reports served as an exchange opportunity for practitioners to learn from others. Focus of these discussions was to share successes, failures, and lessons learned. Open Space – Ongoing facilitated discussions of topics that were suggested by the attendees.

Experience Report

I was asked to present a report on one of my recent experiences.

Instead of presenting the below embedded deck about the correct context for an Agile transformation, I drew everything on a flipchart. If you know your content, you don't need a PowerPoint deck! I wanted to make the original presentation available for others who were not in the room (and those who were).

Correct Context for an Agile Transformation

If there is one question I would ask, to know if you should view/download this presentation, it would be: Are you exactly like Spotify?  If you are not Spotify or your company business goals do not align with Spotify, then this would be a good presentation to view or to talk with me about.

Get a free copy of the presentation from Derek Huether

Work in Process - WIP

What is 'Work In Process - WIP'

Work in process, also known as WIP, refers to activities that have entered the completion process but are not yet outcomes. Work in progress (WIP) refers to all materials and partly finished products that are at various stages of the production process. WIP excludes inventory of time or materials at the start of the completion cycle and finished products inventory at the end of the production cycle.  That means you don't count the things you have not started or have not finished.

Work in Process vs Progress

I see the difference between process and progress as being very small but I want to make a distinction.  I see progress being anchored to physical goods at different stages of completeness on an assembly line and process being completion of any activity as part of a goal or outcome.  Your process could be as simple as To-do and Done.  If you are multi-tasking and have 5 things started all at the same time, you have a WIP of 5.

Personal Agility Tip

One of the secrets of managing your work in process is to only start work on things you actually have capacity to work on. When you have capacity, you can pull work into your "queue". Rather than accepting and starting every task that comes your way, limit the amount of stuff that you’re working on at any given time.  Focus less on starting things in your queue and more on finishing them, and I can pretty much guarantee you’ll get more done.

Personally, I know that I can only deal with three activities at a time before things start to get dropped. Know your personal limits and set them accordingly. If you’re working on something and you get blocked, don’t just pull in more work. Add a visual indicator that shows the item is blocked and continue pulling working to done. Once you unblock work, you can pull it the rest of the way through your system to done.

Have questions?  Ask me how I do it!

Personal Agility

Recently, I've been doing a lot of reflecting on how to increase personal agility. No, I'm not talking about doing somersaults or some crazy yoga poses. I'm speaking of the ability to focus on value and be adaptable in what I do every day; the agility mentioned in the values and principles of the Manifesto for Agile Software Development.  When the Manifesto was written back in 2001, there were representatives from Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others present.  So, when I say agile, I don't necessarily mean Scrum.

Scrum for One?

For the sake of this post, I want to direct focus to people and not organizations.  Being an Agile coach and consultant, I have learned a lot of strategies that have helped me manage customers and accounts.  While working with large complex organizations, I have seen productivity improvements on organizational levels by leveraging Lean and Kanban and on a team level by leveraging Scrum and Kanban. But what about all of the individuals who work for those organizations or on those Scrum teams? What about people who have no idea what Scrum is and don't care? How can they better their productivity?

In the Lifehack article "Scrum for One," Dustin Wax describes how many of the elements of Scrum could be adapted for individual productivity. When reading the article, I wasn't sold on the idea. Scrum is an awesome framework for teams but it's like jamming a round peg in square hole, if you want to use Scrum for your day-to-day productivity.

In Scrum, you demonstrate value to your customer or customer representative every 2-4 weeks, as part of a sprint.  Does that make sense for managing your personal work? No.

In Scrum, you have a 3 roles: ScrumMaster, Product Owner, and Team.  Unless you have a split personality, it's just you!

Most of the things I think about when getting things done include: Aligning activities to outcomes, breaking work into managing chunks, iterating on what was creating so it can be improved over time... The list goes on.  To that, these are not elements exclusive to Scrum.  So, why limit yourself to Scrum?

Personal Agility Manifesto

I believe personal productivity needs to be rethought.  Is personal productivity about being really busy or is it about getting things done?  To be productive, it means you must produce.  If not, you are active. There is a difference!  To help shape my thoughts, I wrote a personal agility manifesto.  You'll notice it's a lot like the Agile Manifesto.  But, there are key differences.

First, (any) outcomes are the primary measure of progress.  This isn't all about software development.

Second, I'm focused on minutes, hours, and days to get things done.  Teams will continue to focus on days, weeks, and months to get work done and shipped.

Conclusion

I'm looking to dig into something anyone can use.  When you hear "Agile" it's actually a pretty niche group. But, when you talk personal productivity, the audience size explodes.  Like with agile, I don't think there is a single right way.  So, I'm looking to experiment and continue to try and get better. Hell, I've been writing about Personal Kanban since 2010.  You'd think I'd have this figured out by now.  Well, I don't.  If you have any tips or tricks, I would love to hear them.

How You Can Get Valuable Time Back: Part 2

This is Part 2 in a series I'm writing about how you can get time back in your day, week, month, or project.   When a team reaches a natural velocity or throughput, how can you get more out of them? They physically can't deliver any faster, given current conditions.  If we assume we have stable teams, let's focus on governance and process.  Specifically, I'm going to talk about meetings again.  Why?  We all hate meetings but we all still have them. In part 1, I wrote about a strategy to enable your email auto-responder to help manage the inbound meeting invites. In Part 2, I'm going to give you a simple strategy to start Spring Cleaning your calendar.

Spring Cleaning

If you've ever had a professional organizer come to your house for Spring cleaning, they may have employed a common strategy to weed through your crap.  It doesn't matter if you are the CEO of a Fortune 500 company or some person appearing on an episode of A&E's Hoarders. We all have too much stuff.  In this case, we're not deciding if you should keep that mountain of National Geographic magazines sitting in the corner or all of those plastic shopping bags you've been keeping when you return from the grocery story. No, we're going to inventory your meetings. Over time, we tend to accumulate meetings.  Time to take inventory and do some Spring Cleaning.

Inventory

As mentioned in the last post, some meetings have value than others. We're going to need see which meeting we need to keep, which meetings we're going to give away, and which we're going to throw away.

Remember, meetings are supposed to be about the exchange of information.  Unfortunately, they are wildly inefficient and offer limited value.  For the most part, they are a waste of our time.  Nobody wants to listen to you go on and on about how many meetings you have, now that you're becoming a bottleneck in getting things done.

To start, I'm going to review every existing and new meeting request and bucket those meetings into 3 categories.

1. Non value added but it is necessary.
2. Non value added but it is NOT necessary.
3. Value added.

1. Non Value Added But Necessary

Instead of automatically accepting the next meeting request, pause and consider the meeting’s return on investment to you.

• Does the purpose of the meeting align with the company’s strategic goals and priorities?
• Are the objectives of the meeting clearly defined?
• Can the organizer explain specifically why you were invited and the value you will provide?
• Will this meeting assist you in achieving my objectives?

If the first four questions were all answered with a yes, you should still ask.

• Will anyone notice if you didn't show up?
• Is attending this meeting the highest and best use of your time right now?

If any of the first four questions were answered with a no, you should seriously consider declining the invitation. If I was Spring cleaning, this pile would be earmarked to donate.  Because we can't "donate" meetings, I would propose having someone else attend on your behalf or find some way of being informed of the meeting outcomes or action items.

2. Non Value Added But It Is NOT Necessary

Did you read that right?  This meeting not only does not provide strategic value but it's also not necessary.

If I was Spring cleaning, this pile would be earmarked for the trash.  This is like a meeting to prepare for a meeting.  Before outright refusing, try to meet the organizer part way.  What problem are they trying to solve with the meeting?  Can it be solved some other way?

To ensure everyone has a shared understand of what meetings are not NOT acceptable, I would recommend making an actual list.

Thou shalt not have meetings about putting cover sheets on TFS reports

3. Value Added

If I was Spring cleaning, this pile would be a keeper.  This is something that you want or need, as part of business process.  Release Planning, Sprint Planning, Demos... I see these as all valuable meetings.  They all require decisions.

Conclusion

Remember, every time you say yes to a meeting, you are saying no to something else.

Check out some of these templates, including Meeting Agenda/Minutes template