As I started my quest which led to creating what I now call 'My Personal Agility,' my goal was to get more done of what really matters. Today, I stumbled on a TED talk by Tim Urban (author of the amazing 'Wait but Why' blog) that explains why that is so hard to achieve. We are all procrastinators. How can we beat the urge to procrastinate?
Urban talks about the 'Instant Gratification Monkey' who seizes control from the 'Rational Decision Maker.' The monkey wants to do fun stuff, not hard stuff that's important but whose value is far off. The only thing that the monkey is afraid of is the 'Panic Monster' - if the deadline is near enough, panic will set in, the monkey is scared off and the rational decision maker can get to work.
And what if there is no deadline? No panic monster to raise its ugly head, so you never get anything started, much less finished. So procrastination is paralyzing.
Urban's solution was to visualize the weeks in your life and tick them off as you age. This should create a sense of urgency by inviting the Panic Monster into the room. But somehow, ticking off the weeks until I am dead is depressing, and at least for me, that would be even more paralyzing!
How does My Personal Agility help you beat the urge to procrastinate?
The Six Questions of Personal AgilityThe six questions of Personal Agility offer a more uplifting approach:
- What really matters?
- What did I accomplish last week?
- What is important (of all the things I could do)?
- What is urgent (really has to get done this week)?
- What do I think I can accomplish (this week)?
- Who can help?
The answers to Question 1, What really matters, give you guidance for saying yes or no to the many things you could do. It also reminds you what you really want to do.
Question 2, What did I accomplish last week, is an opportunity to celebrate what you have accomplished in the past week. This produces the happiness hormones to keep Instant Gratification Monkey happy and content.
Questions 3 and 4, What's urgent and what's important help you order your thoughts and think about what you want to be doing this week. Some of your time will be for important goals, some will be for putting out urgent fires, and some for having fun!
Question 5, What do I think I can accomplish, is about setting reasonable goals for the week and giving yourself a deadline. This might be an invitation to the Panic Monster, though I believe if you produce enough happiness hormones through question 2, you won't need the Panic Monster as often.
Question 6, Who can help? Why is this question here? As humans, we can accomplish more in collaboration than by ourselves. If you are stuck, this is a useful question, because a new person is always a new source of ideas.
In my case, I found myself unable to ask the first five questions on a regular basis, so I asked myself who could ask me these questions. The answer was obvious, and I asked my wife for help. She offered to meet with me once per week, to ask me these questions, so I can answer them. I call her my Personal Agility Coach. By having a weekly appointment with my Personal Agility Coach, I can reflect on these questions, produce some happiness hormones for what I have accomplished, and remind myself what I really want to be doing this week.
Depending on your context, your Personal Agility Coach could be a life coach, a mentor, a Scrum Master, a fellow student or even your spouse! Just use a board, like Trello, to visualize the answers to the first 5 questions. I call this Your Priorities Map. Then meet with your Personal Agility Coach once per week or so to celebrate your accomplishments, answer the questions, and remind yourself what you want to be doing.
How I do Personal AgilityPeter's Personal Agility
Artwork thanks to @fredzen
I don’t mean to say promises are not useful. They certainly are useful and they are a tool that I know well. I think you should know them – but I don’t think you should use them as your default for async code.Why not use promises, by default?
The TL;DR is that promises add another layer of complexity and potential bugs – especially around error handling.
But, I’m not going to elaborate on the complexities much. Nolan Lawson did an excellent job of pointing out the problems with promises, already.
He starts that post with a question, asking you to explain the difference in four uses of a promise.
This, to me, demonstrates the primary reason that I don’t reach for promises by default. There are a lot of potential mistakes to make.I reach for promises when I see the need.
That need typically arrises in one of the following scenarios:
- I need to wait for multiple async responses before continuing
- I want to cache a response and skip doing the work multiple times
- I want to chain methods together
- Working with async generators
The Promise.all method is great for waiting on multiple async returns. It lets you pass in an array of promises and wait for all of them to complete before firing the callback.
Caching a response is also useful, though there are many ways of doing this (including the memoize function of lodash / underscore, and others).
Chaining methods together can often make existing promises easier to understand and modify, though I don’t typically do this unless I’m already working with promises.
And lastly, the current ES2015 (ES6) generators implementation facilitates better async patterns in our code, but only when we add a small library around the generators.I still prefer Node.js-style callbacks.
Having spent several years working in Node.js, I’ve grown to like the callback style where an error object is passed in as the first parameter.
This code, in my experience, allows more flexibility while preventing the potential problems of swallowed and lost exceptions, that promises present.
Until we see the async / await syntax from ES(v.whatever) make it into Node and most browsers, I’ll probably continue to reach for the callback style as my go-to for async code. Even when that happens, it will take a long time for this callback style to move to the side (if it ever does) due to shear momentum of existing code.A promise is a tool you should understand, and use.
Agile practitioners often fail to realize that 99.9% of society has never heard Agile terminology. As I recently hosted Agile Baltimore Lean Coffee, I heard very smart people use terms like sprints, Scrum, Kanban, Agile, and stories. They described waste as muri, muda, and mura. To top it off, they described learning as shu, ha, and ri. This was all just casual conversation. One fellow at the table was new to the group and asked, what specifically do all of those things mean? Though everyone was eager to clarify, I think there may have been a little embarrassment as well. Before you go super vertical with a conversation, know who your audience is. You shouldn’t need to educate them, just to have a conversation. Speak in layman terms.Overt Overuse of Domain Specific Terms
I’ve been in the Agile space about a decade now. I notice an overt overuse of Japanese and other terms to describe just about anything. I know some came from Toyota Production Systems. But there comes a time when I think we try too hard. I guess if you want to sound smart, take something that already exists. Find a foreign language translation and then start presenting it at conferences. Nothing gets people writing notes faster than a word they don’t understand or have to spell phonetically.
Here are the tweets you likely missed last month!
— SonarQube (@SonarQube) September 1, 2016
— SonarLint (@SonarLint) September 23, 2016
— SonarQube (@SonarQube) September 9, 2016
— SonarQube (@SonarQube) September 7, 2016
— SonarQube (@SonarQube) September 26, 2016
This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen
The secret to getting ahead is getting started.
– Mark Twain
Getting started on a new project is tough. If you’re trying to transform an entire organization, it can be even tougher because it requires you to make some changes. Changing yourself is often the toughest part—especially if it involves losing weight or modifying a habit. So what do you do?
The secret is to just start, and to do it now. You’ve already clarified why and how you need to change. You just need to do it.
This is easier said than done, as most of us are experts at coming up with reasons to procrastinate. We give ourselves excuses to avoid dealing with unacceptable behaviors or situations until the “right” time (e.g., the start of a new year) arrives. If our behavior is truly unacceptable, how can it be okay to wait to change it?
Another way we like to procrastinate is to form teams and make sure every detail is in place before we start anything new. This is folly. Your team is ready, with you as their leader. It is impossible to plan for everything that could possibly go wrong before you start a project. What are you really waiting for? How does delaying look to your team? Is it authentic? Is it respectful?
Last year, as soon as I learned how Paul Akers lost over fifty pounds, I was motivated to lose weight myself. If he could, I could—especially since I only needed to lose half that. Instead of waiting until the new year to change my eating habits I began at that very moment. Five minutes after reading his email describing what he had done, I went to Starbucks to get my usual vanilla latte. Instead, taking a cue from Paul, I bought a regular coffee and skipped the latte. That was the beginning of my health improvement journey. Ten weeks later, I was fifteen pounds lighter. (Coincidentally, the end of ten weeks happened to coincide with the new year, when I would have typically started pursuing a new goal.)
Don’t wait. Start. Now.
Last week during a hands on Cypher meetup, using Neo4j’s built in movie dataset, one of the attendees showed me the following query which wasn’t working as expected:
MATCH (p:Person)-[:ACTED_IN]->(movie) RETURN p, COLLECT(movie.title) AS movies ORDER BY COUNT(movies) DESC LIMIT 10
We can get a full stack trace in logs/debug.log if we run the same query from the cypher-shell, which was introduced during one fo the Neo4j 3.1 milestone releases:
2016-10-03 23:25:07.529+0000 ERROR [o.n.b.v.r.ErrorReporter] Client triggered an unexpected error [UnknownError]: requirement failed, reference to. requirement failed java.lang.IllegalArgumentException: requirement failed at scala.Predef$.require(Predef.scala:212) at org.neo4j.cypher.internal.compiler.v3_1.planner.logical.steps.sortSkipAndLimit$.apply(sortSkipAndLimit.scala:38) at org.neo4j.cypher.internal.compiler.v3_1.planner.logical.PlanEventHorizon$.apply(PlanEventHorizon.scala:43) at org.neo4j.cypher.internal.compiler.v3_1.planner.logical.PlanEventHorizon$.apply(PlanEventHorizon.scala:31) at org.neo4j.cypher.internal.compiler.v3_1.planner.logical.PlanWithTail.apply(PlanWithTail.scala:46) at org.neo4j.cypher.internal.compiler.v3_1.planner.logical.PlanWithTail.apply(PlanWithTail.scala:29) at org.neo4j.cypher.internal.compiler.v3_1.planner.logical.PlanSingleQuery.apply(PlanSingleQuery.scala:47) at org.neo4j.cypher.internal.compiler.v3_1.planner.logical.PlanSingleQuery.apply(PlanSingleQuery.scala:30) at org.neo4j.cypher.internal.compiler.v3_1.planner.logical.DefaultQueryPlanner$$anonfun$2.apply(QueryPlanner.scala:51) at org.neo4j.cypher.internal.compiler.v3_1.planner.logical.DefaultQueryPlanner$$anonfun$2.apply(QueryPlanner.scala:51) at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234) at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234) at scala.collection.immutable.List.foreach(List.scala:381) at scala.collection.TraversableLike$class.map(TraversableLike.scala:234) at scala.collection.immutable.List.map(List.scala:285) at org.neo4j.cypher.internal.compiler.v3_1.planner.logical.DefaultQueryPlanner.planQueries(QueryPlanner.scala:51) at org.neo4j.cypher.internal.compiler.v3_1.planner.logical.DefaultQueryPlanner.plan(QueryPlanner.scala:36) at org.neo4j.cypher.internal.compiler.v3_1.planner.CostBasedExecutablePlanBuilder.produceLogicalPlan(CostBasedExecutablePlanBuilder.scala:95) at org.neo4j.cypher.internal.compiler.v3_1.planner.CostBasedExecutablePlanBuilder$$anonfun$1.apply(CostBasedExecutablePlanBuilder.scala:71) at org.neo4j.cypher.internal.compiler.v3_1.planner.CostBasedExecutablePlanBuilder$$anonfun$1.apply(CostBasedExecutablePlanBuilder.scala:71) at org.neo4j.cypher.internal.compiler.v3_1.helpers.package$$anonfun$closing$1.apply(package.scala:29) at org.neo4j.cypher.internal.compiler.v3_1.helpers.package$$anonfun$closing$1.apply(package.scala:29) at org.neo4j.cypher.internal.compiler.v3_1.helpers.package$.using(package.scala:37) at org.neo4j.cypher.internal.compiler.v3_1.helpers.package$.closing(package.scala:29) at org.neo4j.cypher.internal.compiler.v3_1.planner.CostBasedExecutablePlanBuilder.producePlan(CostBasedExecutablePlanBuilder.scala:70) at org.neo4j.cypher.internal.compiler.v3_1.executionplan.procs.DelegatingProcedureExecutablePlanBuilder.producePlan(DelegatingProcedureExecutablePlanBuilder.scala:99) at org.neo4j.cypher.internal.compiler.v3_1.executionplan.FallbackBuilder$class.producePlan(SilentFallbackPlanBuilder.scala:37) at org.neo4j.cypher.internal.compiler.v3_1.executionplan.SilentFallbackPlanBuilder.producePlan(SilentFallbackPlanBuilder.scala:56) at org.neo4j.cypher.internal.compiler.v3_1.executionplan.ExecutionPlanBuilder.build(ExecutionPlanBuilder.scala:106) at org.neo4j.cypher.internal.compiler.v3_1.CypherCompiler$$anonfun$5.apply(CypherCompiler.scala:176) at org.neo4j.cypher.internal.compiler.v3_1.CypherCompiler$$anonfun$5.apply(CypherCompiler.scala:176) at org.neo4j.cypher.internal.compiler.v3_1.QueryCache$$anonfun$getOrElseUpdate$1$$anonfun$apply$1.apply(CacheAccessor.scala:36) at org.neo4j.cypher.internal.compiler.v3_1.MonitoringCacheAccessor$$anonfun$1.apply(CacheAccessor.scala:57) at org.neo4j.cypher.internal.compiler.v3_1.LFUCache$$anon$1.apply(LFUCache.scala:31)
The problem line seems to be this one:
The solution is actually quite simple. We should be using the SIZE function to calculate the size of a list rather then the COUNT function:
MATCH (p:Person)-[:ACTED_IN]->(movie) RETURN p, COLLECT(movie.title) AS movies ORDER BY SIZE(movies) DESC LIMIT 10
Leading an organization to Real Agility is a complex and difficult task.
Leading to Real Agility is about how leaders including executives and senior managers help their organization achieve great business results and a great corporate culture. This video introduces the topics of our next series of videos.
This is the first video in a series on Leading to Real Agility.Leading to Real Agility
The following topics will be covered in the video series. A new video will be posted every two weeks.
- Leadership Responsibilities – what must leaders do to inspire change.
- Communicate the Vision for Change – how leaders can craft a compelling vision for change.
- Lead by Example – the actions of leaders matter.
- Change the Organization – the primary work of leaders.
- Environment for Change – hindering and helping change.
- Real Agility Practices – how do leaders and their staff work?
- Choosing a Change Approach – options for changing your enterprise.
- Leadership and Culture – what do you need to know to change culture?
- Change Adoption Curve – when do people adopt change?
- Leadership Time Allocation – a major benefit of improvement.
- Handling Resistance and Laggards – leading sometimes means pushing.
- Choosing a Pilot Project – some projects are better than others when you’re starting out.
- Real Agility at Scale – if you have a big organization.
- Organizational Agility – having wholeness and integrity throughout.
- Individual Leadership Development – a leader’s personal journey.
- Assessing Your Organization – where are you right now?
Please subscribe to our YouTube channel to receive notifications when each new video is published!
Mishkin Berteig presents the concepts in this video series. Mishkin has worked with leaders for over fifteen years to help them create better businesses. Mishkin is a certified Leadership Circle Profile practitioner and a Certified Scrum Trainer. Mishkin is co-founder of BERTEIG. The Real Agility program includes assessment, and support for delivery teams, managers and leaders.
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Do you know exactly how much value you delivered to your customers last week, month, or quarter? Can you describe, with precision, the cumulative business value contained within each incremental deployment? Here’s how you can start measuring DevOps performance to … Continue reading →
The post How Measuring DevOps Performance Increases Enterprise Agility appeared first on The Agile Management Blog.
My name is Ariel Klontz, and I have been working at LeanKit for the past few months...
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
Our new integrations help you deliver value faster by enabling you to create a single, virtual system...
The post What’s New: Increased Visibility with New Integrations appeared first on Blog | LeanKit.
Neo4j: Procedure call inside a query does not support passing arguments implicitly (pass explicitly after procedure name instead)
A couple of days I was trying to write a Cypher query to filter the labels in my database.
I started with the following procedure call to get the list of all the labels:
╒══════════╕ │label │ ╞══════════╡ │Airport │ ├──────────┤ │Flight │ ├──────────┤ │Airline │ ├──────────┤ │Movie │ ├──────────┤ │AirportDay│ ├──────────┤ │Person │ ├──────────┤ │Engineer │ └──────────┘
I was only interested in labels that contained the letter ‘a’ so I tweaked the query to filter the output of the procedure:
CALL db.labels YIELD label WITH label WHERE tolower(label) contains "a" RETURN label
Unfortunately that didn’t work as I expected:
Procedure call inside a query does not support passing arguments implicitly (pass explicitly after procedure name instead) (line 1, column 9 (offset: 8)) "CALL db.labels" ^
The mistake I made was calling the procedure implicitly without using parentheses. If you want to do any post processing on the output of a procedure you need to call it explicitly otherwise Cypher gets very confused.
If we add back the parentheses it’s much happier:
CALL db.labels() YIELD label WITH label WHERE tolower(label) contains "a" RETURN label
╒══════════╕ │label │ ╞══════════╡ │Airport │ ├──────────┤ │Airline │ ├──────────┤ │AirportDay│ └──────────┘
It stumped me for a while until I figured out what the error message meant! I think I’ll just use explicit parentheses all the time from now on to save me running into this one again.
This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen
The ability to simplify means to eliminate the unnecessary so that the necessary may speak.
– Hans Hofman
Look around your office, your factory, and your home. What do you see? Do you really need all of that stuff on your desk and shelves? Is there a purpose to each item? Does it need to be available now, or can it be put out of sight for a few weeks, months, or even forever? How much time do you consume (and stress do you create) by looking for the appropriate tool, book, or utensil? Does your kitchen really need three beat-up measuring cups of the same size? How much does it cost to maintain and clean all of your extra stuff ? What does the space, additional complexity, and distraction cost?
Over time, things in our lives (and our companies) accumulate, and we end up wasting a lot time and effort managing them. To reduce the cost of unnecessary stuff, we use a core tool of Lean called 5S. The term 5S comes from five Japanese words that roughly translate to sort, straighten, shine, standardize, and sustain:
- Sort: Review each item, ensure it has a purpose, remove what isn’t needed
- Straighten: Find a defined location for what remains, preferably as close to where it will be used as possible.
- Shine: Clean and polish the newly uncluttered area.
- Standardize: Create a checklist or other method to ensure the area doesn’t revert back to how it was.
- Sustain: Create a habit, routine, or daily activity to keep the area clean and neat, and to audit that it has stayed that way.
In short, you remove what isn’t needed, find a defined home for what remains, clean up your space, turn the activity into a habit, and find a way to ensure it continues. Using 5S ensures that your factory floor has only the tools that are needed, in just the right place, and are always returned to that place.
On the best factory floors, and in the best restaurant kitchens, you will often find shadow boards where every required tool is hung on a wall with the outline of the utensil tool behind it. Everyone knows where to go to get the tool there are no extra tools that need to be sorted through to find the right one. It is visually obvious when a tool is missing.
Decluttering also has a Zen component. I encourage you to find one room, or even one shelf, and evaluate the objects you see. Challenge each one. Why is it there, and what is its purpose? What would happen if it wasn’t there? If it has a reason and has real value, then find and define a home for it.
Cleaning can become obsessive, so be sure the effort adds value and aligns with your principles. Does marking the location of your phone on your desk truly add value? Probably not. However, having a clean, neat environment will help give you the focus and strength to tackle more important challenges. Once you have your workspace in order, you will soon realize that simplifying and decluttering doesn’t just apply to physical stuff.
To be most effective, the cleaning needs to be targeted, not indiscriminately applied. The same boss I described earlier, who asked his employees whether they were “incompetent or just incapable,” also had a painful (for us) Friday afternoon cleaning routine. Around three or four o’clock, he would take a look at his desktop, decide that any paperwork on it he hadn’t already looked at must not be important, and sweep everything into the trash can. This was three decades ago, when most reports were still typed on typewriters, so recreating them was difficult. His staff soon developed a routine of going to his office around two in the afternoon to retrieve any unread reports and paperwork from his desk, just to redeposit them there on Monday morning.
Understanding value is critical before tackling a decluttering project.