Skip to content

Feed aggregator

Personal message from Net Objectives' new COO, Marc Danziger

NetObjectives - Fri, 07/24/2015 - 08:26
Two months ago, I was contentedly leading my life as a singleton consultant down in Los Angeles. I’d managed to get to work for some pretty cool companies – Amgen,, the Academy of Motion Pictures Arts and Sciences (the Oscars folks), NBC, International Lease Finance Corp. (AIG), and Toyota. But, as the cliché goes, something was missing. I was finding that I could get a...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Lean Climbing

I’m on my way to Colorado for a weekend of outdoor adventures, climbing and mountain biking. As I was looking over the route for the climb (Kelso’s Ridge up Torrey’s Peak and a possible double with Gray’s Peak) I remembered an article I recently read on applying the principles of lean climbing to business (here).
I’ve done a couple 14ers before, so this will be my third and maybe fourth, all with my son. We plan on being lean on this climb. Enough water and food, but not much more. Our timebox is getting down the mountain before the afternoon thunderstorms. 
My current client seems to get lean. As we were working through the user stories for the project, they made the decision to prioritize and pull out the lower priority stories without any prompting from me. With so many of my clients, there are many discussions before they think about taking any stories out of the backlog for the current release. 

I think if I could take my clients on a climb, with each user story represented by a small rock in their backpack, they would soon realize the benefit of keeping it lean. There’s a cost with each user story, and being able to defer some stories means you get up the mountain sooner. 
Categories: Blogs

Good Software

Doc On Dev - Michael Norton - Thu, 07/23/2015 - 17:01
I saw a tweet this morning that caught me off-guard.
If your software makes money it is good software by definition. Nothing else matters. #Agile ^ @SkankworksAgile— AgileFortune (@AgileFortune) July 23, 2015 It doesn't strike me as consistent with the type of thing AgileFortune usually tweets. My initial reaction was to reply via twitter, but didn't feel I could express my thoughts well in 140 characters or less.

What is "good"?And by extension what is "good" software? Good has many meanings. To be morally excellent or virtuous, to be satisfactory in quality, quantity, or degree, to be proper or fit, well-behaved, beneficent, or honorable. These are all definitions of good.

Morals and Software?One might argue that moral excellence, beneficence, or honorableness are not relevant to measures of "good" in software. I disagree. They are as relevant to software as they are to medical care, banking, manufacturing, and any other human endeavor. Dishonorable businesses that are morally questionable and do harm to others are not "good" businesses. Sex trafficking is not "good" business. Exploitation of others is not "good" business. Profits alone do not make a business "good". Businesses do not exist to make money, or rather they should not. Businesses should exist to provide an offering of value to others. Money is a means of measuring the value provided to others. With that money, we can continue to provide and improve our offering, should we choose.

Money is to a business as food is to a human. We do not live to eat; we eat to live. We do not run a business to make money, we make money to run a business. Greed and gluttony are entirely different matters; neither of which is healthy or "good".

Other aspect of "goodness"Let's set aside the moral and social aspects for a moment. This leaves us with satisfactory in quality, quantity, or degree, proper or fit, and well-behaved. Distilling it down to these elements, one could assert that if software makes money it is "good", for it behaves well enough for people to use it for some given purpose that results in profit to the software creator, be this in subscriptions, transaction fees, exchange for goods or service, or ad revenue.

Reliable? Must be good enough. It makes money. And nothing else matters.
Maintainable? What difference does that make? It makes money. And nothing else matters.
Secure? Bah! It makes money. And nothing else matters.
Scalable? Who cares? It makes money. And nothing else matters.

Let's look at this measure of success in another endeavor. An electrician whose installations fail on occasion (reliable), makes junctions inaccessible and does not follow industry standards (maintainable), and fails to adhere to safety standards (secure), but gets paid for the job has provided a "good" service. Because nothing other than money matters.

Good and Money are not the sameAs a software developer; a professional software developer, your measure of "good" needs to include factors far beyond revenue generation. Open Source software is often quite good and makes no money. Commercial software is often poor and makes a lot of money. "Good" and "Money" are not the same. Software that makes money is not automatically good.

Categories: Blogs

Let’s Learn to Do Our Jobs Better, Not a Framework/Method, Better

NetObjectives - Thu, 07/23/2015 - 16:11
The software industry seems so caught up in certifications and learning the latest framework, method or approach. The focus is on the wrong thing. It should be on learning how to learn, learning how to do our job better, learning how to collaborate better.  This has sometimes been talked about with the shu-ha-ri metaphor: Shu – initially obey traditional wisdom – that is, just do the techniques...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Why Timeboxing Sucks For Your New Agile Teams

Leading Agile - Mike Cottmeyer - Thu, 07/23/2015 - 15:42

Ever heard these from teams before regarding timeboxing?

  • “What we do won’t fit into a 2 week window”
  • “The nature of our work is too creative for a timebox”
  • <<<Fill in your variation here>>>

If you work with agile teams, some variation of these statements will be familiar. I consistently hear new teams say this over and over when I form new sets of teams.

Here’s the deal, the problem is not the time box. In fact, the time box is exposing problems you need to solve!

Let’s check out some examples of the team’s timeboxing complaints above.

“What we do won’t fit into a 2 week window”

An example team that could have this problem is a one that is siloed by discipline. I am currently working with a set of agile data teams that fit this mold. The team members are very much specialists.

They have:

  • Data Architecture via Modeling and Data Flows
  • ETL
  • Data Analysis
  • Coding in Scala and Java
  • Data Analytics
  • Data Warehousing
  • Stored Procedures
  • Testing and Automation
  • Reporting
  • Deployment
  • And probably a few more things that I don’t even know about

In total these capabilities make up  a cross-functional team. Inside that team they typically do these tasks in sequence waiting for each other to finish. It’s no wonder they can’t fit anything into a sprint!

To fix this

This team is finding ways to work in parallel. This feels a lot like design by contract for each of these sequential items.

To make this even faster

The team will generalize a bit more to swarm around work that can’t be broken into the design by contract method.

Swarming will require team members learn how to maintain their specialty while learning how to help out with another capability needed by the team. That doesn’t mean be a specialist in both, keep your sanity. So, “If I know ETL, can I learn to help with Data Analysis or Stored Procedures?”

Let’s take a look at another common one.

“The nature of our work is too creative for the time box”

Regarding creatives… there is a large belief that most every discipline in product development is creative by that discipline.

We all see ourselves that way. There is a natural tendency to want to go somewhere, be creative, and come back with our creation. However, the importance of feedback is never more apparent than in truly creative environments.

Let’s consider a company creating it’s brand identity. The brand is going to have a significant impact on how customers pick and choose the company or a competitor. Even in this environment, we don’t want to have a team go away and comeback with some gold-plated logo that misses the mark after 3 months.

To fix this

Instead we want to see steady progress toward success. By keeping the actual creative property transparent while collaborating around it, we can maintain visibility of the value that is being created and decide when enough is good enough.

Getting small

Multiple creatives will be taken into the timebox because no one likes to commit to one thing and have it miss after two weeks. That’s too much risk, so they break it down into smaller deliverables. This benefits the “creative” and the customer.

To wrap up

Timeboxing is not the problem. Timeboxing exposes problems and encourages innovation to find new solutions. From our sprints to daily commitments and on to release planning you will find timeboxes everywhere in agile systems. If you use something like the pomodoro technique, it’s in most every part of your day. This is a critical part for teams to realize as a benefit, not a problem.

The post Why Timeboxing Sucks For Your New Agile Teams appeared first on LeadingAgile.

Categories: Blogs

7 Tips for Valuing Features in a Backlog

Johanna Rothman - Thu, 07/23/2015 - 15:37

Many product owners have a tough problem. They need so many of the potential features in the roadmap, that they feel as if everything is #1 priority. They realize they can’t actually have everything as #1, and it’s quite difficult for them to rank the features.

This is the same problem as ranking for the project portfolio. You can apply similar thinking.

Once you have a roadmap, use these tips to help you rank the features in the backlog:

  1. Should you do this feature at all? I normally ask this question about small features, not epics. However, you can start with the epic (or theme) and apply this question there. Especially if you ask, “Should we do this epic for this release?”
  2. Use Business Value Points to see the relative importance of a feature. Assign each feature/story a unique value. If you do this with the team, you can explain why you rank this feature in this way. The discussion is what’s most valuable about this.

  3. Use Cost of Delay to understand the delay that not having this feature would incur for the release.

  4. Who has Waste from not having this feature? Who cannot do their work, or has a workaround because this feature is not done yet?

  5. Who is waiting for this feature? Is it a specific customer, or all customers, or someone else?

  6. Pair-wise and other comparison methods work. You can use single or double elimination as a way to say, “Let’s do this one now and that feature later.”

  7. What is the risk of doing this feature or not doing this feature?

Don Reinertsen advocates doing the Weighted Shortest Job first.  That requires knowing the cost of delay for the work and the estimated duration of the work. If you keep your stories small, you might have a good estimate. If not, you might not know what the weighted shortest job is.

And, if you keep your stories small, you can just use the cost of delay.

Jason Yip wrote Problems I have with SAFe-style WSJF, which is a great primer on Weighted Shortest Job First.

I’ll be helping product owners work through how to value their backlogs in Product Owner Training for Your Agency, starting in August. When you are not inside the organization, but supplying services to the organization, these decisions can be even more difficult to make. Want to join us?

Categories: Blogs

Monthly Retrospective Plan

Growing Agile - Thu, 07/23/2015 - 14:33
We hold a retrospective each month, to see how we are d […]
Categories: Companies

DevOps Culture and the Informed Workspace

Agile Management Blog - VersionOne - Thu, 07/23/2015 - 14:30









While the DevOps culture has been heavy focused on what tools to use, little thought has been giving to what type of workspaces is needed. Ever since the early days of agile, the importance of an informative workspace has been known. Many of the practices around working together, pair programming and the Onsite Customer from Extreme Programming were to enable the rapid flow and visualization of how the team is doing. Other aspects, such as the Big Visual Chart, were included to keep the information flowing. We have made great progress in this category, but we still have more to do.

Now, fast forward to the DevOps Culture. Much like the original agile movement, DevOps is a relatively unique change in the world of work that involves both cultural and technical shifts. It’s just not enough to have cool new tools like Puppet and Chef, or any of the other cool tools that make continuous delivery “a thing.” We need to be able to think about how we are planning our stories. We need to be able to be including acceptance criteria that go beyond just “is it done,” but also all the way to “is it staying done?”

We often run into this as agile consultants. I have often gone to work with a client and their number one concern as we are going through the engagement is “ok, and what do we do on day one of the sprint when we don’t have you here coaching us?” Now, they are fine on their own, but part of the plan is to know what to do after the training wheels are off. Let’s look at that same idea in terms of DevOps Culture. Stories have a very limited life. Once the product owner has accepted the story, we tear it up and throw it away, metaphorically speaking. But that isn’t the end of the story. The software now needs to live and breathe in the big wide world. How do we do that? DevOps is of course the answer, but what exactly does that mean?

Workspaces in the DevOps Culture

As mentioned earlier in this article, the idea of an informed workspace is a valuable tool in our belt for moving deeper and wider into the DevOps culture. Think back to one of the biggest cultural changes called for in the early adoption of agile. Agile called for bringing QA into the room. We aren’t treating QA as a separate team, but part of the team. All of a sudden we are paying close attention to the number of tests that are passing. So now part of our Big Visual Chart is focused on the pass/fail rate of our tests, not just the status of the story itself. This shift took a lot of effort, and I think that if we are honest with ourselves it’s not done yet. But that is an article for another time. We want to take a deeper look at the keys to successfully affecting a further transformation to the DevOps culture. What aspects will really help us do more than just have lots of automated builds that we call done, with no thought to what happens after?

The first step is to think about the cultural changes required. What is it that we will need to change in our thinking in order to make DevOps more than just another buzzword at our shop? The first, and hardest, change is to stop thinking in terms of the “DevOps team”. The whole team is part of Dev and Ops. There just is no wall to throw “finished” product over anymore. It’s all about creating great and long lasting software. There are many steps that we have already taken to get there, but this is one of the biggest. So let’s take a look at the different activities that really make a DevOps culture thrive.

DevOps Activities

Of course, the first thing one thinks about when discussing DevOps is the activities that support continuous delivery. This means an even higher need for all tests to be automated. Unit tests are merely the start, followed closely by automating your acceptance tests. Having these tests running continuously throughout the day is basically the cost of entry into the DevOps culture. Without a strong continuous integration server, running tests all day and every day, we just can’t be sure that what we are releasing is of a high enough quality to stay healthy in the real world. After that, the art of continuous deployment becomes an additional challenge. Orchestration tools are vital to make sure the right bits get bundled with the other right bits, and then get put where they belong. And then, since we are all part of “keeping the lights on,” we need monitoring tools to help us visualize whether our software really is behaving properly. So yes, there is a definite technical aspect to DevOps.

That’s a lot of moving parts! We need to keep track of where we are. This leads to one of the cool parts of a true DevOps implementation. All those cool monitors that the Ops guys get with the fancy graphs and uptime charts? They come into the room with the Ops people. And we need to add to them. We are going to track story progress from idea to implementation, and then into the wild. My acceptance criteria are going to include things like “must have Nagios hooks” and “will use less then x% of CPU”. And now we have to live up to it. This means it is more important than ever to be able to visualize the entire flow. Our Big Visual Charts need to be able to show us not just how the current iteration is going. They must show us the state of the build server, the state of the various builds and where they are in any of the extended process, such as UAT, etc. And, in the unlikely event of a failure anywhere along the line, or in post-production, we can follow a clear chain of events back to find the problem quickly.


So now we see that, while DevOps is primarily a people problem, there are a lot of technical aspects that enable a strong DevOps culture. The key to success is the union of the people and technical aspects, which in a way make DevOps a Cyborg. In order to balance these two aspects, and in order to keep ourselves from burning countless hours and countless brain cells chasing down all of the moving parts, we need to focus on Information. The more Information that we can have at our fingertips, the more effective we will be. Each team will identify which information is the most meaningful to them, and how best to interpret it. You can bet that this will be in live charts rather than stale reports. Being able to orchestrate the entire flow of a story’s life, from inception to realization to retirement will be much easier if we can visualize each step of the way. If this means our team room might start looking like the command center in war games, what’s so bad about that?

About the Author

versionone-coaches-steve-ropaSteve Ropa
CSM, CSPO, Innovation Games Facilitator, SA
Agile Coach and Product Consultant, VersionOne

Steve has more than 25 years of experience in software development and 15 years of experience working with agile methods. Steve is passionate about bridging the gap between the business and technology and nurturing the change in the nature of development. As an agile coach and VersionOne product trainer, Steve has supported clients across multiple industry verticals including: telecommunications, network security, entertainment and education. A frequent presenter at agile events, he is also a member of Agile Alliance and Scrum Alliance.

Categories: Companies

When, Why and How To Estimate

NetObjectives - Thu, 07/23/2015 - 13:09
There are three disparate views on estimation.  One is that estimation is harmful because management misuses the estimates, another is that estimation is a form for waste because it doesn’t provide value directly, and a third is that estimation is critical in order to do planning.  Let’s discuss each of these views and see what we really need to do regarding estimation.   The origins of most of...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Neo4j: Loading JSON documents with Cypher

Mark Needham - Thu, 07/23/2015 - 08:15

One of the most commonly asked questions I get asked is how to load JSON documents into Neo4j and although Cypher doesn’t have a ‘LOAD JSON’ command we can still get JSON data into the graph.

Michael shows how to do this from various languages in this blog post and I recently wanted to load a JSON document that I generated from Chicago crime types.

This is a snippet of the JSON document:

    "categories": [
            "name": "Index Crime", 
            "sub_categories": [
                    "code": "01A", 
                    "description": "Homicide 1st & 2nd Degree"
            "name": "Non-Index Crime", 
            "sub_categories": [
                    "code": "01B", 
                    "description": "Involuntary Manslaughter"
            "name": "Violent Crime", 
            "sub_categories": [
                    "code": "01A", 
                    "description": "Homicide 1st & 2nd Degree"

We want to create the following graph structure from this document:

2015 07 23 06 46 50

We can then connect the crimes to the appropriate sub category and write aggregation queries that drill down from the category.

To do this we’re going to have to pass the JSON document to Neo4j via its HTTP API rather than through the browser. Luckily there are drivers available for {insert your favourite language here} so we should still be good.

Python is my current goto language so I’m going to use py2neo to load the data in.

Let’s start by writing a simple query which passes our JSON document in and gets it straight back. Note that I’ve updated my Neo4j password to be ‘foobar’ – replace that with your equivalent if you’re following along:

import json
from py2neo import Graph, authenticate
# replace 'foobar' with your password
authenticate("localhost:7474", "neo4j", "foobar")
graph = Graph()
with open('categories.json') as data_file:
    json = json.load(data_file)
query = """
RETURN {json}
# Send Cypher query.
print graph.cypher.execute(query, json = json)
$ python
   | document
 1 | {u'categories': [{u'name': u'Index Crime', u'sub_categories': [{u'code': u'01A', u'description': u'Homicide 1st & 2nd Degree'}, {u'code': u'02', u'description': u'Criminal Sexual Assault'}, {u'code': u'03', u'description': u'Robbery'}, {u'code': u'04A', u'description': u'Aggravated Assault'}, {u'code': u'04B', u'description': u'Aggravated Battery'}, {u'code': u'05', u'description': u'Burglary'}, {u'code': u'06', u'description': u'Larceny'}, {u'code': u'07', u'description': u'Motor Vehicle Theft'}, {u'code': u'09', u'description': u'Arson'}]}, {u'name': u'Non-Index Crime', u'sub_categories': [{u'code': u'01B', u'description': u'Involuntary Manslaughter'}, {u'code': u'08A', u'description': u'Simple Assault'}, {u'code': u'08B', u'description': u'Simple Battery'}, {u'code': u'10', u'description': u'Forgery & Counterfeiting'}, {u'code': u'11', u'description': u'Fraud'}, {u'code': u'12', u'description': u'Embezzlement'}, {u'code': u'13', u'description': u'Stolen Property'}, {u'code': u'14', u'description': u'Vandalism'}, {u'code': u'15', u'description': u'Weapons Violation'}, {u'code': u'16', u'description': u'Prostitution'}, {u'code': u'17', u'description': u'Criminal Sexual Abuse'}, {u'code': u'18', u'description': u'Drug Abuse'}, {u'code': u'19', u'description': u'Gambling'}, {u'code': u'20', u'description': u'Offenses Against Family'}, {u'code': u'22', u'description': u'Liquor License'}, {u'code': u'24', u'description': u'Disorderly Conduct'}, {u'code': u'26', u'description': u'Misc Non-Index Offense'}]}, {u'name': u'Violent Crime', u'sub_categories': [{u'code': u'01A', u'description': u'Homicide 1st & 2nd Degree'}, {u'code': u'02', u'description': u'Criminal Sexual Assault'}, {u'code': u'03', u'description': u'Robbery'}, {u'code': u'04A', u'description': u'Aggravated Assault'}, {u'code': u'04B', u'description': u'Aggravated Battery'}]}]}

It’s a bit ugly but we can see that everything’s there! Our next step is to extract each category into its own row. We can do this by accessing the ‘categories’ key in our JSON document and then calling the UNWIND function which allows us to expand a collection into a sequence of rows:

query = """
WITH {json} AS document
UNWIND document.categories AS category
$ python
 1 | Index Crime
 2 | Non-Index Crime
 3 | Violent Crime

Now we can create a node for each of those categories. We’ll use the MERGE command so that we can run this script multiple times without ending up with repeat categories:

query = """
WITH {json} AS document
UNWIND document.categories AS category
MERGE (:CrimeCategory {name:}) 

Let’s quickly check those categories were correctly imported:

match (category:CrimeCategory)
return category

Graph  23

Looking good so far – now for the sub categories. We’re going to use the UNWIND function to help us out here as well:

query = """
WITH {json} AS document
UNWIND document.categories AS category
UNWIND category.sub_categories AS subCategory
RETURN, subCategory.code, subCategory.description
$ python
    |   | subCategory.code | subCategory.description
  1 | Index Crime     | 01A              | Homicide 1st & 2nd Degree
  2 | Index Crime     | 02               | Criminal Sexual Assault
  3 | Index Crime     | 03               | Robbery
  4 | Index Crime     | 04A              | Aggravated Assault
  5 | Index Crime     | 04B              | Aggravated Battery
  6 | Index Crime     | 05               | Burglary
  7 | Index Crime     | 06               | Larceny
  8 | Index Crime     | 07               | Motor Vehicle Theft
  9 | Index Crime     | 09               | Arson
 10 | Non-Index Crime | 01B              | Involuntary Manslaughter
 11 | Non-Index Crime | 08A              | Simple Assault
 12 | Non-Index Crime | 08B              | Simple Battery
 13 | Non-Index Crime | 10               | Forgery & Counterfeiting
 14 | Non-Index Crime | 11               | Fraud
 15 | Non-Index Crime | 12               | Embezzlement
 16 | Non-Index Crime | 13               | Stolen Property
 17 | Non-Index Crime | 14               | Vandalism
 18 | Non-Index Crime | 15               | Weapons Violation
 19 | Non-Index Crime | 16               | Prostitution
 20 | Non-Index Crime | 17               | Criminal Sexual Abuse
 21 | Non-Index Crime | 18               | Drug Abuse
 22 | Non-Index Crime | 19               | Gambling
 23 | Non-Index Crime | 20               | Offenses Against Family
 24 | Non-Index Crime | 22               | Liquor License
 25 | Non-Index Crime | 24               | Disorderly Conduct
 26 | Non-Index Crime | 26               | Misc Non-Index Offense
 27 | Violent Crime   | 01A              | Homicide 1st & 2nd Degree
 28 | Violent Crime   | 02               | Criminal Sexual Assault
 29 | Violent Crime   | 03               | Robbery
 30 | Violent Crime   | 04A              | Aggravated Assault
 31 | Violent Crime   | 04B              | Aggravated Battery

Let’s give sub categories the MERGE treatment too:

query = """
WITH {json} AS document
UNWIND document.categories AS category
UNWIND category.sub_categories AS subCategory
MERGE (c:CrimeCategory {name:})
MERGE (sc:SubCategory {code: subCategory.code})
ON CREATE SET sc.description = subCategory.description
MERGE (c)-[:CHILD]->(sc)

And finally let’s write a query to check what we’ve imported:

match (category:CrimeCategory)-[:CHILD]->(subCategory)
return *
Graph  24

I hadn’t realised before running this query is that some sub categories sit under multiple categories so that’s quite an interesting insight. The final Python script is available on github – any questions let me know.

Categories: Blogs

The Best Productivity Book for Free

J.D. Meier's Blog - Wed, 07/22/2015 - 18:04

image"At our core, Microsoft is the productivity and platform company for the mobile-first and cloud-first world." -- Satya Nadella

We take productivity seriously at Microsoft. Ask any Softie. I never have a lack of things to do, or too much time in my day, and I can't ever make "too much" impact.

To be super productive, I've had to learn hard-core prioritization techniques, extreme energy management, stakeholder management, time management, and a wealth of productivity hacks to produce better, faster results.

We don’t learn these skills in school.  But if we’re lucky, we learn from the right mentors and people all around us, how to bring out our best when we need it the most.

Download the 30 Days of Getting Results Free eBook

You can save years of pain for free:

30 Days of Getting Results Free eBook

There’s always a gap between books you read and what you do in the real world. I wanted to bridge this gap. I wanted 30 Days of Getting Results to be raw and real to help you learn what it really takes to master productivity and time management so you can survive and thrive with the best in the world.

It’s not pretty.  It’s super effective.

30 Days of Getting Results is a 30 Day Personal Productivity Improvement Sprint

I wrote 30 Days of Getting Results using a 30 Day Sprint. Each day for that 30 Day Sprint, I wrote down the best information I learned from the school of hard knocks about productivity, time management, work-life balance, and more.

For each day, I share a lesson, a story, and an exercise.

I wanted to make it easy to practice productivity habits.

Agile Results is a Fire Starter for Personal Productivity

The thing that’s really different about Agile Results as a time management system is that it’s focused on meaningful results.  Time is treated as a first-class citizen so that you hit your meaningful windows of opportunity, and get fresh starts each day, each week, each month, each year.  As a metaphor, you get to be the author of your life and write your story forward.

For years, I’ve received emails from people around the world how 30 Days of Getting Results was a breath of fresh air for them.

It helped them find their focus, get more productive, enjoy what they do, renew their energy, and spend more time in their strengths and their passions, while pursuing their purpose.

It’s helped doctors, teachers, students, lawyers, developers, grandmothers, and more.

Learn a New Language, Change Careers, or Start a Business

You can use Agile Results to learn better, faster, and deeper because it helps you think better, feel better, and take better action.

You can use Agile Results to help you learn a new language, build new skills, learn an instrument, or whatever your heart desires.

I used the system to accidentally write a book in a month.

I didn’t set out to write a book. I set out to share the world’s best insight and action for productivity and time management. I wrote for 20 minutes each day, during that month, to share the best lessons and the best insights I could with one purpose:

Help everyone thrive in work and life.

Over the coming months, I had more and more people ask for a book version. As much as they liked the easy to flip through Web pages, they wanted to consume it as an eBook. So I turned 30 Days of Getting Results into a free eBook and made that available.

Here's the funny part:

I forgot I had done that.

The Accidental Free Productivity Book that Might Just Change Your Life

One day, I was having a conversation with one of my readers, and they said that I should sell 30 Days of Getting Results as a $30 work book. They liked it much more than the book, Getting Results the Agile Way. They found it to be more actionable and easier to get started, and they liked that I used the system as a way to teach the system.

They said I should make the effort to put it together as a PDF and sell it as a workbook. He said people would want to pay for it because it’s high-value, real-world training, and he said it was better than any live training he had ever taken (and he had taken a lot.)

I got excited by the idea, and it made perfect sense. After all, wouldn’t people want to learn something that could impact every single day of their lives, and help them achieve more in work and life and help them adapt and compete more effectively in our ever-changing world?

I went to go put it together, and I had already done it.

Set Your Productivity on Fire

When you’re super productive, it’s easy to forget some of the things you create because they so naturally flow from spending the right time, on the right things, with the right energy. You’ll naturally leave a trail of results from experimenting and learning.

Whether you want to be super productive, or do less, but accomplish more, check out the ultimate free productivity guide:

30 Days of Getting Results Free eBook

Share it with friends, family, colleagues, and whoever else you want to have an unfair advantage in our hyper-competitive world.

Lifting others up, lifts you up in the process.

If you have a personal story of how 30 Days of Getting Results has helped you in some way, feel free to share it with me.  It’s always fun to hear how people are using Agile Results to take on new challenges, re-invent their productivity, and operate at a higher level.

Or simply get started again … like a fresh start, for the first time, full of new zest to be your best.

Categories: Blogs

Planbox and BrainBank Merge

Scrum Expert - Wed, 07/22/2015 - 17:35
Planbox, a cloud-based agile project management solution vendor, has merged with BrainBank Software the pioneering platform for cloud based collaborative innovation management. The combined company will be called Planbox. BrainBank and its Idealink product will be marketed as Planbox Innovate and the existing solution as Planbox Agile. Ludwig Melik currently CEO of BrainBank will be the CEO of the combined company which will continue the development and support for both Planbox and BrainBank products – all existing agreements and support arrangements remain unchanged. “The combined offering will allow us to benefit ...
Categories: Communities

Ivar Jacobson International Releases Agile Essentials Cards

Scrum Expert - Wed, 07/22/2015 - 16:58
Ivar Jacobson International has released a starter pack of agile practice cards that aid team-based software development by ensuring that core agile team practices are transparent and effective. Each practice contains a small number of cards that provide useful, structured advice on how to apply the practice. In many organizations, arguments rage between software development “experts” and teams on which process framework is best – e.g. Extreme Programming (XP) versus Scrum versus Kanban. Even though agile principles are clear that “no one should tell the team how to do their work”, ...
Categories: Communities

Airport Baggage Claims, Selective Consumers, and RabbitMQ Anti-Patterns

Derick Bailey - new ThoughtStream - Wed, 07/22/2015 - 16:57

One of the patterns found in the Enterprise Integration Patterns book covers the idea of a “selective consumer” – that is, a message consumer that uses some criteria to determine which messages it receives and processes, from a given channel (queue).

Years ago, when I was first working with queueing in WebsphereMQ, I used this pattern to ensure my message consumers only got messages they could handle. It worked well. Fast forward to more recent days, though, and when I tried to do the same thing in RabbitMQ, I found it to be painful and fraught with problems. The pattern of selective consumer turns out to be an anti-pattern in RabbitMQ!

Baggage claim

That doesn’t mean we can’t be selective about what messages are consumed. Instead of using selection criteria, though, we have to turn to the features and capabilities of RabbitMQ to accomplish the same thing – something that is easier and more natural than you might think.

The Core Problem: Selection

RabbitMQ doesn’t have any kind of selection criteria that you can apply to a consumer and a queue. Once a consumer is attached to a queue, it will potentially receive any message from that queue. If you have multiple consumers on a given queue, you don’t know which one will get the message but there’s a possibility that any of the consumers could get a specific message. You have no way of ensuring a specific message goes to a specific consumer, once that message is in a queue. 

To simulate the idea of a selective consumer, you can write code that examines a message once it is received from a queue. If the message cannot be handled by the consumer, the consumer can ‘nack’ the message and send it back to the queue.

This works … to a point. But it introduces some potentially serious performance and thrashing problems in your application.

The Problem, Applied To Airport Baggage Claim

Imagine for a moment, that you’re standing around an airport baggage claim carousel – the kind of carousel where bags ride conveyor belts around and around, waiting for people to grab them.

You stand there, hoping to find your bags quickly – but they never show up. After a few minutes of seeing other people’s luggage go by, you look toward the opening from which the luggage is pouring out. What you see is utterly dumbfounding – but it explains why you haven’t seen your luggage in front of you.

Every time a piece of luggage comes out of the conveyor belt, some one looks at it to see if it belongs to them. If it doesn’t, they don’t let the bag continue to ride around the carousel. Instead… THEY THROW IT BACK! Down in to the depths of the luggage loading system it goes – to be put at the end of the line, waiting to be stuck on the conveyor belt again!

This is MADNESS! Why would anyone toss these bags back to the end of the line, instead of letting them ride the conveyor belt?!

WAIT! Is that your bag, there? YES! … NO! SOMEONE GRABBED IT AND TOSSED IT BACK!!! Now you have to wait for it it come back out and hope no one else checks it before it gets to you again. AAARRRGGGHHH!!!! 

Selective Consumer: The Airport Luggage Anti-Pattern

Using code to selectively check a message, determine whether or not the current consumer can handle it and ‘nack’ it back to the end of the queue is exactly like having your luggage thrown back to the end of the line in the baggage claim. 

If you have multiple consumers attached to a queue, you are potentially at the whim of every other attached consumer. If one of the other consumers consistently picks up your message and tosses it back to the end of the queue, you’ll never get your message and never be able to process it. The queue will continuously thrash as the message is received, examined and rejected … over and over and over again. 

Don’t do this. 

Solving The Selection Problem With Routing

RabbitMQ doesn’t allow you to apply selection criteria to a queue, for a consumer. Instead, you have to assume that any message consumer attached to a given queue can handle any message delivered to that queue. To prevent consumers from receiving the wrong message, then, use routing keys to only send messages to a queue with consumers that can handle the message. 

If you have a consumer that knows how to handle “enroll student” messages, then you should have a queue for “student.enroll” (or similar). Each consumer that attaches to this queue must be able to handle “enroll student” messages appropriately. If the consumer cannot handle that message, it should not attach to that queue. 

Patterns And Practices: Apply With Care

The Enterprise Integration Patterns book is still the source of knowledge for working with messaging systems and message based architectures. But that doesn’t mean you can carte blanche apply these patterns as-is with every messaging system and message broker out there. RabbitMQ, for example, does a great job of including many of the patterns and practices found in this book. That doesn’t mean RabbitMQ applies all of these patterns in the way the authors of the book describe, as you’ve already seen. 

To get a better understanding of how the most common and most important of the Enterprise Integration Patterns apply to RabbitMQ, check out my RabbitMQ Patterns email course / ebook. In here, you’ll find a wealth of experience in applying messaging architecture and patterns to RabbitMQ and application design – enough knowledge to help you get up and running, applying these patterns effectively with RabbitMQ. 



Categories: Blogs

How to Improve Productivity with DevOps & SAFe

TV Agile - Wed, 07/22/2015 - 16:08
DevOps and SAFe adoption is not easy. This session will discuss a real world DevOps/SAFe transformation and the lessons learned by exploring how a Fortune 100 company transformed from a traditional software shop to an Agile organization. Video producer:
Categories: Blogs

Pitfall of Scrum: Assigning Tasks

Learn more about our Scrum and Agile training sessions on

Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should be assigning tasks to team members. Don’t do this!!!  It is better to wait for someone to step up than to “take over” and start assigning tasks.

Assigning tasks can be overt or subtle.  Therefore, avoid even suggestions that could be taken as assigning tasks. For example, no one should ever tell a Scrum Team member “hey! You’re not doing any work – go take a task!” (overt) or “This task really needs to get done – why don’t you do it?” (semi-overt) or “Would you consider working on this with me?” (subtle). Instead, any reference to tasks should be to the team at large. For example it would be okay for a team member to say “I’m working on this and I would like some help – would anyone help me?”

In the Scrum Guide, a partial definition of self-organizing is given:

Scrum Teams are self-organizing….. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

A more formal definition of the concept of “self-organizing” can be found here:

Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.

The key here is that there is no single point of authority, even temporarily, in a self-organizing team. Every individual member of the team volunteers for tasks within the framework of “the laws followed by the process” – namely Scrum. Scrum does define some constraints on individual behaviour, particularly for the Product Owner and the ScrumMaster. People in those two roles have specific duties which usually prevent them from being able to volunteer for any task. But all the other team members (the Development Team) have complete freedom to individually and collectively figure out how they will do the work at hand.

What If One Person Isn’t Working?

People who are managers are often worried about this.  What if there is one person on the team who just doesn’t seem to be doing any work? Isn’t assigning tasks to this person a good thing?  Scrum will usually make this bad behaviour really obvious. Let’s say that Alice hasn’t completed any tasks in the last four days (but she does have a task that she volunteered for at the start of the Sprint). Raj notices that Alice hasn’t finished that initial task. An acceptable solution to this problem is for Raj to volunteer to help Alice. Alice can’t refuse the help since Raj is self-organizing too. They might sit together to work on it.

Of course, that might not solve the problem. So another technique to use that respects self-organization is to bring it up in the Sprint Retrospective. The ScrumMaster of the team, Sylvie, chooses a retrospective technique that is designed to help the team address the problem. In a retrospective, it is perfectly acceptable for people on the team to be direct with each other. Retrospectives need to be safe so that this kind of discussion doesn’t lead to animosity between team members.

Remember: everyone goes through ups and downs in productivity. Sometimes a person is overwhelmed by other aspects of life. Sometimes a person is de-motivated temporarily. On the other hand, sometimes people become extremely engaged and deliver exceptional results. Make sure that in your team, you give people a little bit of space for these ups and downs.  Assigning tasks doesn’t make a person more productive.

What If There is One Task No One Wants to Do?

Dig deep and find out why no one wants to do it. This problem is usually because the task itself is worthless, frustrating, repetitive, or imposed from outside without a clear reason. If no one wants to do a task, the first question should always be: what happens if it doesn’t get done? And if the answer is “nothing bad”… then don’t do it!!!

There are, unfortunately, tasks that are important that still are not exciting or pleasant to do. In this situation, it is perfectly acceptable to ask the team “how can we solve this problem creatively?” Often these kinds of tasks can be addressed in new ways that make them more interesting. Maybe your team can automate something. Maybe a team member can learn new skills to address the task. Maybe there is a way to do the task so it never has to be done again. A self-organizing Scrum Team can use innovation, problem-solving and creativity skills to try to over come this type of problem.

And, of course, there’s always the Sprint Retrospective!

Why Self-Organize – Why Is Assigning Tasks Bad?

Autonomy is one of the greatest motivators there is for people doing creative and problem-solving types of work. The ability to choose your own direction instead of being treated like a mushy, weak, unreliable robot. Motivation, in turn, is one of the keys to creating a high-performance state in individuals and teams. The greatest outcome of good self-organization is a high-performance team that delivers great work results and where everyone loves the work environment.

Assigning tasks to people is an implicit claim that you (the assigner) know better than them (the assignees).  Even if this is true, it is still easy for a person to take offence.  However, most of the time it is not true.  People know themselves best.  People are best at assigning tasks to themselves.  And therefore, having one person assigning tasks to other people almost always leads to sub-optimal work distribution among the members of a team.

The ScrumMaster and Assigning Tasks

The ScrumMaster plays an important role in Scrum.  Part of this role is to encourage self-organization on a team.  The ScrumMaster should never be assigning tasks to team members under any circumstances.  And, the ScrumMaster should be protecting the team from anyone else who is assigning tasks.  If someone within the team is assigning tasks to another team member, the ScrumMaster should be intervening.  The ScrumMaster needs to be constantly aware of the activity on his or her team.

I have added a video to YouTube that you might consider sharing with ScrumMasters you know about this topic:

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!

The post Pitfall of Scrum: Assigning Tasks appeared first on Agile Advice.

Categories: Blogs

A Subtle Benefit Of ES6 Arrow Functions With Backbone/Marionette

Derick Bailey - new ThoughtStream - Tue, 07/21/2015 - 19:56

I started a new Backbone/Marionette application this week, and decided to put Babel in place so I can use ES6 features (if you want an introduction to Babel / ES6 features, check out my WatchMeCode series on ES6). I honestly wasn’t sure what benefit I would get, at first. I’ve been playing with ES6 for a while now, but have not yet found the “AHA!” moment that makes me really want to use it everywhere.

What I have found, however, is a subtle benefit of using arrow functions with Backbone/Marionette, that makes me smile every time.

Managing “this” With Arrow Functions

One of the nice features of arrow functions is the ability to manage “this” in the function being executed. Arrow functions use lexical scoping to ensure “this” is maintained based on the context of the function being called (see this WatchMeCode episode on arrow functions for more details). 

In short, that allows me to take this Backbone/Marionette code:

and turn it in to this:

The difference is small… it’s a bit subtle, if you’re not looking for it. But it’s right there on line 5.

Subtle, And Important

The difference of manually specifying “this” as a parameter to the event handler, vs having it managed for me through the arrow function is important in my mind. It prevents me to having to manually manage and manipulate the value of “this” in many circumstances. And while this isn’t the “AHA!” moment that makes me swear ES6 is the greatest thing to happen to JavaScript, it does provide enough value that it warrants the additional layer of BabelJS transpilation in my mind.

Categories: Blogs

Video: Sprint Zero is Not Part of Scrum

Learn more about our Scrum and Agile training sessions on

Find out why Sprint Zero is a bad idea, and what you can do instead!

More Scrum and Agile videos to come!  Please subscribe to our WorldMindware channel.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!

The post Video: Sprint Zero is Not Part of Scrum appeared first on Agile Advice.

Categories: Blogs

Five Tips for Improving Communication

Agile Management Blog - VersionOne - Tue, 07/21/2015 - 14:30

Communication is the key to solving problems and successfully collaborating, but many of us still have difficulty communicating with particular team members. Why?

Because the words we use mean different things to different people in different contexts.
Matt Badgley, an agile product consultant at VersionOne, recently gave a presentation at Agile Day Atlanta about communication techniques you can use to solve problems and improve team meetings.


VersionOne: Why is it important to focus on the words we use?

Matt: We all know that collaboration is the key to success. Ultimately, solving a problem is generally done by people talking to each other and working things out. Solving problems often happens inadvertently, through conversations.

So that’s why communication is key, and communication is made up, of course, of verbal and nonverbal cues. The same goes for the role of ScrumMaster. So, if you are in the role of product owner or ScrumMaster and you’re not good at facilitating communication, you are not going to be successful. So that’s why it’s really important.

When you actually talk about what words mean, you will find that certain words in certain organizations trigger emotions. They are bad words. They are basically four-letter words that are emotional for people. So you have to be aware of that. You will also find that there are some terms that mean one thing in one context and something totally different in another context. For example, epic is a word we use all the time in agile. And even the word project means different things, and it actually evokes different feelings in people.

VersionOne: In your presentation you shared some fun facts about communication – can you share those with us?

Matt: One of the most interesting statistics is that women speak roughly twenty thousand words per day on average, while men speak on average seven thousand words per day, and we all have around twenty-five thousand words in our active vocabulary.

Generally, we say between one hundred to one hundred and seventy-five words per minute, although we can listen to up to eight hundred. That is why we can often eavesdrop on other people’s conversations and gain insight. Our conscious minds can only process about forty bits of information per second, which includes colors and things like that. However, our subconscious mind, which deals with our motor skills, processes around eleven million.

One last little fun fact: the word that has been shown through studies of the brain to be the most dangerous in the world is the word no – probably because we learn that word at a very early age and get our hands slapped. So if you say no in a conversation, that instantly turns the context of the conversation around, or changes the tone. This just goes to show that the actual words we use are often undervalued and can mean so much more.

VersionOne: What are some of the ways you suggest for people to solve that problem?

Matt: In my presentation I make five suggestions.

1) Don’t redefine the obvious.

For example, when talking about requirements, we often use the word feature or capability. Now the scaled agile framework refers to requirements as a business epic or a feature epic. You’ll hear different terms that people throw out, just simply to change the term. So, be very deliberate on whether or not you need to change a word or not.

2) Be deliberate and intentional.

If you make the decision to change a term, be deliberate and intentional about using it. For example, the Spotify model uses the word squad rather than team. Squad makes you think of the military or a small group that is a subset of a sports team. A team is a bigger composition, but a squad is a smaller and more intentional group of people. By redirecting and changing people to use that term, it has some underlying meaning that’s beyond the word team.

3) Be aware of biases around a word.

Bias is a preconceived feeling around certain words. A funny one to use is the word ScrumMaster. The term master has some bias behind it, some predefined bias that people bring into the room with them. It’s not always perceived how it is meant to be, although ScrumMaster does actually mean the master of the scrum process, the sensei. At the end of the day, that bias can be dangerous. So be aware of the bias.

4) Use domain language.

Use the words that the business uses already. This suggestion goes with number one: don’t redefine the obvious, but also don’t go out of your way to use a word that’s not unique to your industry. Accept and embrace some of the acronyms that are associated with the industry. For example, in the agile industry, we use the term product owner and sprints, so embrace those kind of words.

5) Use visual elements when defining a glossary.

It may sound strange to create a visual glossary, but the idea comes from how we learned words as kids. You learned the word apple because you saw a picture of an apple. Defining ways in which people can not only read the word, but also visualize the word helps things stick.

Check out these posts to learn more about how you can improve your communication by focusing on what words mean.

Categories: Companies

Talking with Tech Leads now available in print - Tue, 07/21/2015 - 10:49

Late last year, I announced the release of “Talking with Tech Leads,” which was then available in a variety of e-book formats including PDF, mobi and epub. Although e-books have their place, I know how important it is for some people, to have a real physical book. After all, it’s very difficult to physically gift something to people, when it’s on a tablet, or computer.

Stack of books from Talking with Tech Leads

After some more work on the physical aspects of the book and many draft copies back and forth from the, you can now order your very physical copy of Talking with Tech Leads. You can order copies depending on region including:

What people are saying about the book:

Your book has really helped me find my feet – James

This book is a well-curated collection of interviews with developers who have found themselves in the role of a tech lead, both first-timers and veterans – Dennis

The book is well-organised around a number of themes and I found it very easy to read and to ‘dip into’ for some inspiration / ideas. – Gary

Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.