Skip to content

Feed aggregator

Cost of Delay. Can It Be Quantified?

Leading Agile - Wed, 06/28/2017 - 21:30

Most organizations are struggling to determine how much revenue any given project is going to create; therefore, they need some other criterion to prioritize their backlogs. That’s the reason I see companies turning to Cost of Delay (CoD) more and more. Often, I overhear people talking about CoD like it’s some mathematical formula where they can crunch tangible revenue numbers, get an output, and that everyone is just going to get it. In my experience that hasn’t been the case.

The reality is that in most cases the CoD is more than just dollars. The cost is usually something more ambiguous, as Jim Hayden alluded to in his blog post, and this is where people get all twisted up.  They have a hard time assessing the value of features that don’t have an exact dollar amount tied to them.

The Elements of CoD

So, how does an organization determine the cost of delaying a project, or the cost of not doing the project at all, when there is an indeterminate financial outcome? Even if they can make that determination, how would they decide on what to do next?

In Principles of Product Development Flow, Don Reinertsen asserts that the CoD can be blown out into the following three parameters:

  • User Business Value
  • Time Criticality
  • Risk Reduction and/or Opportunity Enablement Value

He states that User Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement Value equals the CoD

Weighted Shortest Job First

In his book, Reinertsen also introduces a model that will allow your organization to weigh the importance of each new project and enable you to make an educated decision on which is the next most important thing. He calls this model: Weighted Shortest Job First, or WSJF. Basically, WSJF equals the CoD divided by the Job Size.

Here’s an example table that you can use to determine your WSJF numbers. You will rate each feature relative to the other features on the list, using the three parameters that make up COD.

Determining Value 

Now that we have an established baseline formula, and a means by which to visualize it. How do you determine the appropriate value of each parameter? What’s the unit of measurement? I like to do it the way I do story pointing. I’ll get the product owners and a few lead tech guys around a table and we will begin to assign points.

I like to use a Fibonacci Scale, cap it at 20, and take it one column at a time. You’ll look at the feature and give the Business Value a number, Time Criticality a number, and then the RR/OE Value a number.

Once you’ve determined those numbers you can calculate a point total for CoD, divide it by the Job Size, and get your WSJF number. Once you have the WSJF number, you’ve successfully determined the next most important thing to do.

A lot of times when I introduce this model to one of my clients, they push back and tell me that it feels like they’re just making random decisions. However, keep in mind the importance of each parameter can be subjective. The actual value of CoD may not even be mathematically quantifiable, but that’s okay.

Shared Understanding

CoD and WSJF are only meant to be used for guidance on how to do prioritization. It doesn’t really matter that we are pulling numbers from our collective consciousness, what matters is the relative comparison of one thing to another. Applying this technique allows the decision making to be influenced by the team. It opens a conversation about why one feature has a twenty and another one has a five.

What truly matters is that everyone on the team agrees with what’s on the list and that they all have a share understanding of the points awarded. It has been my experience that when you have a team of people that are all in the industry and have the best interest of the company in mind, more than likely the decision made is the decision that’s best for the organization.

This model is just one way to do prioritization, but there are others. Sometimes, especially in small, lean startups, I’ll see people using Gartner reports, or looking at their perceived market share to make business decisions. Often, they are acting on instincts and using fuzzy numbers to justify investments. The CoD/WSJF model is a good way to clean up a backlog in the absence of dollar amounts. So, if you’re having trouble measuring value I say….

In the words of Reinertsen, “…if you’re going to quantify one thing, quantify the cost of delay.”

Free Download of the WSJF Calculator

Download this interactive Excel Spreadsheet of the WSJF Table discussed above, so that you can use to determine your WSJF numbers within your own organization.

The post Cost of Delay. Can It Be Quantified? appeared first on LeadingAgile.

Categories: Blogs

Service Desk localization: volunteers needed

TargetProcess - Edge of Chaos Blog - Wed, 06/28/2017 - 18:37

Hello everyone!

I am glad to let you know we are working on language localization for our Service Desk. We know that some of your customers and users might not speak English, so now it will be more convenient for them to start using Service Desk – we're aware this was a blocker for some of you.

We have completed the background work to make localization possible. There will be a global default language for the whole application, but users will be able to pick their own language if they prefer something different.

The next phase is translation itself, and here is where it gets tricky. We don’t speak every language that we would like to add (or, at least not well enough). As you know, we are not charging for Service Desk, so it is not likely that we’ll be able to hire some translation agencies to do the job. This means we need your help if you want to see some particular language.

Luckily, there is not much text to be translated. Currently there are around 150 “lines”, and most of them are very short (e.g. “Log in” or “Add a request”). We are using Transifex, so the translation and approval process is easy and won’t require much effort from you. If all 150 lines are too much, you are welcome to translate as many as you can; even one line can make a difference. If the line was already translated by someone else, you can review it and leave a comment if you have another suggestion.

We already have the Russian version almost complete, but we need volunteers for the following languages:

  • German
  • French
  • Portuguese (Brazilian)
  • Italian
  • Polish
  • Dutch

If you need some other language and are ready to provide a translation, we will be happy to add it to the system.
If you are want to participate or have any questions, please contact me directly via, and I’ll send you a meeting invite. Thanks everyone!

Categories: Companies

Scaled Agile Framework (SAFe) 4.5 Released

Scrum Expert - Wed, 06/28/2017 - 16:35
The version 4.5 of the Scaled Agile Framework (SAFe) has been released. The Framework is now known as SAFe for Lean Enterprises. The release 4.5 of SAFe should delivers advancements in...

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

9 Questions to Create Alignment with your Customers and Stakeholders

Scrum Breakfast - Tue, 06/27/2017 - 10:10
When was the last time you really spoke to a customer or stakeholder about their needs? Sure, everybody talks about getting out of the office, but how do you actually do it? Here's an interview template to make customer conversations much easier.

Personal Agility Stakeholder Interview Canvas as PNGDownload the Canvas as PDF from ultimate goal is to have an impact. I have found the best way to do that is to create alignment between myself and my stakeholders or customers.

I use this canvas to guide my conversations with my stakeholders. It has been a game changer for me! So much, that it is now a part of Personal Agility.

The goal is to understand your stakeholder, build a rapport, and get actionable information to guide the next steps. This might be about our collaboration or a product I want to create for them.
Getting ReadyI generally plan 60 minutes for the interview, but it can be done in as little as 30 minutes if you and the other person are focused. Whether speed or depth is more important to you, depends on the context and what you are trying to achieve.
Doing the interviewStart out with an explanation of why we are here:
As you know, we are working to do <whatever it is you want to do>. Beyond that, my goal is create an effective partnership between us, so that we can work together effectively with a minimum of frictions. I want to focus on doing great things for you and your customers. To that end, I would like to understand you, your goals and your perspective.I have found the following questions and order to be most effective at understanding the stakeholder. Sometimes I will vary the exact formulation to suit the audience, but the flow is usually the same.

  1. Stakeholder - Note and if necessary confirm the person's name and contact information. (Note I save the what really matters question for last)
  2. Main Goals or Objectives - What do you want to achieve through this project or collaboration?
  3. Challenges and Impediments - What are the main challenges to achieving your goals or desired outcome?
  4. Risks, Concerns, Fears - What concerns you about achieving your goals?
  5. Frustrations - What causes you to bang your head against the wall?
  6. Definition of Awesome - If I could snap my fingers, and all your wishes came true on this project, what would that look like?
  7. Support - How can I/we support you to make this come true?
  8. What really matters? - When push comes to shove, what is most essential? ( Generally it is better to ask this question late in the interview. Sometimes you may not ask the question directly, but rather summarize yourself).
  9. What's next? - What is the next thing that you need to do for this stakeholder (follow-up)?
Coaching questions can be helpful to elicit better, more complete answers, e.g. "Is there anything else." or "Let me read this back to you; have I understood you correctly?" Sometimes it is helpful to vary how you formulate the question, so that it resonates better with your interview partner.

I ask the questions in the numbered order. Yes, the "What really matters question" comes almost last, though it is right next to the stakeholder info on the canvas. Often people need to go through the steps of the other questions before they can answer that question.

When I am trying to build a relationship, I also answer each question to my stakeholder, so they understands me as well. This is not about deciding anything, just about understanding. So I try to avoid debate, I just make sure that I have understood the other person.

This is one of several free tools that I offer as around Personal Agility. You can download the PDF with the instructions at (For the canvas, no registration is required, just download!)
Categories: Blogs

Targetprocess Mobile Releases: iOS Board Beta and plenty of useful improvements

TargetProcess - Edge of Chaos Blog - Mon, 06/26/2017 - 17:25

We've been working on quite a lot of improvements for both our iOS and Android apps. The most exciting one is a new board concept that we've introduced in our latest iOS release (v.3.6). The beta release of this board focuses on navigation, and includes the ability to swipe between columns. Lanes will always have visibility because they stick to the header. Quick Add and Drag-n-Drop are absent in the current realization, but we will be adding them soon.


If you want to share your expressions or fears about the new board concept, just let us know at

The enhancements below apply to both our Android and iOS applications, unless otherwise specified.

Relations list in entity details view

For those who need the possibility to look at items related to an entity, we've added a Relations list to the entity details view. Relations are divided into Inbound and Outbound lists.

View setup

If you're not sure why certain cards or lanes are not being displayed on a view, we’ve added the possibility to inspect view configuration. View setup is in read-only mode, but you can reset your personal Project and Team filter.


Quick Add from inner lists

Adding a new entity is now easier on our Android app, as you can add cards from the appropriate inner list. You don't have to search for Project or Team – they are preset from the parent entity.

Turn off notifications directly from the Android app

We've had some complaints about the inability to switch off notifications directly from the app. You can now do this by tapping the 'Mute' button that is located in the 'Notifications' tab.

Some other useful improvements include:
  • Added new actions for comments: Reply to, Copy text, and Delete. Long-press on a comment and select what you need.
  • Extended the Add tab in Android with all existing entity types.
  • Added missing fields into the entity details view.

Click here to download the iOS app.
Click here to download the Android app.

Categories: Companies

Using Personas to Support User-centered Design

Scrum Expert - Mon, 06/26/2017 - 17:18
If some consider Scrum as an Agile project management framework, many people consider that is is more a product management approach. Anyway, Scrum is about understanding the need of the customers to...

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

The Digital Platform - resurrection of the Hub Strategy

There's a lot of talk these days in the tech sector about "digital _________" or a "______ Platform" - have you noticed it also?  I find this astonishing, as the world turned digital back in the 1980s along with disco.  And as for platform - well adding the word to shoes was a bad idea back then also.

So what causes this echo from the past?

I don't know - shall we investigate this over the next few months - the dog days of summer 2017?

Summer is a season.  Season are cyclical - they come around again and again.  So this brings us to ponder... When do the days get longer and why?  Most people answer Summer.  And what's the longest day of the year (Northern Hemisphere)?  Right June 20th, the summer solstice.  And so the next few days the daylight is getting less and less - all summer long the days get shorter and shorter.  Almost completely backwards from what we thought we knew.

Do you remember way back in 2001... when Steve Jobs laid out Apples Digital Platform - called the Hub Strategy?
"The Mac," Jobs said, "can become the 'digital hub' of our emerging digital lifestyle, adding tremendous value to our other digital devices.""Jobs laid out a path of PC evolution that defined the early 80s as an initial 'golden age' of computing based on productivity software, which began to wane in the early 90s. A 'second golden age' began in the mid-1990s with the rise of Internet; but it too began to lose its momentum by 2000. Jobs said he believed a third age would focus on a digital lifestyle, driven by an 'explosion of digital devices.'"

-- by Phil Simon The Age of the Platform

Steve Jobs introduces the "Digital Hub... by HiltonRobb

Simon writes "Apple forced this third golden age by developing its platform -- and making it so compelling to use." To see the ecosystem of the computer as a hub of your digital life. They have executed on that vision with the iPod, then the iTunes store, the iPhone and the App store, now the iPad and the iBookStore. Are we following a pattern, is there a cookbook? The leader has a vision, shares the vision with the followers, the followers buy into the vision and together make it a reality. 

The new product adoptions phases are progressing quite nicely. Apple is a master at this process, described by David Pogue in:

Wildly Successful New Product Launch Phases:
  • Phase 1 feverish speculation and hype (preannouncment)
  • Phase 2 disappointment and bashing (prerelease)
  • Phase 3 attainment anticipation and adoration (post release)

How the iPhone was Born:  Inside Stories of Missteps and Triumphs

See Also:

Why Tim Cook is Steve Ballmer and Why He Still Has His Job at Apple by Steve Blank
"What happens to a company when a visionary CEO is gone? Most often innovation dies and the company coasts for years on momentum and its brand. Rarely does it regain its former glory."

Categories: Blogs

That's a goatee of a different color

I've made a transition from gray tones to living color - much like Dorothy in The Wizard of Oz (the first color motion picture).

Dog Groomer's have a natural capability to accept a being for what they are and how they present, as well as what their humans may desire.  This is a wonderful ability - we should learn from them.  I had a great conversation with my local groomers at the Blissful Bark Dog Wash, about peoples expectations and inherent biases based upon look, job title, etc.  This capability of acceptance and a deeper level of judgement came to me as they asked about my hair color choices.  They told of the judgements that a dog groomer receives - one even equated the title's status to that of a stripper (good company if you can have friends in low places).

From this and other conversation I've had as a result of a choice to live with more color, I've made some interesting observation about you people.
  • You humans are preoccupied by noticing inconsequential details in your field of view and then fixating upon the possible meaning of such trivial, while being totally oblivious to the important patterns happening all around you.   Dogs do not have this bias.
  • Women are about 8.347 times more accepting of the appearance of someone than men are.
  • Men are generally judgmental - there first question for me has been - Why?
  • White Male Privilege is difficult to comprehend from this state of being.  Having experienced just one fuchsia hair's width of the other side for a fleeting 3 weeks - I can say I understand intellectually - but have no knowledge or understand of it - no experience - no wisdom.
  • Human bias to blend in to the group norm, to look like others, but desire to stand out is ineffable.
Tracy bought a boat - a hole in the water for $$$In our desire to stand out on Lake Grapevine, my good looking wife bought a 1959 Crusier runabout, all wood boat with a '59 Johnson Sea Horse 50HP.  Yes this is your father's ski boat.

Texas want's to legislate which restrooms a person uses...  I've heard you can pee next to George.
“If you show your support with one of these shirts, well, urine my good graces.” –George Takei

Just Wash your Hands!

Categories: Blogs

What is the Product Backlog in Scrum?

Scrum Breakfast - Sat, 06/24/2017 - 19:59

According to the Scrum Guide, the Product Backlog is “an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.”

Each entry in the list is called a Product Backlog Item (“PBI”). Since User Stories are such a common practice, Backlog Items are often just called “Stories” even though User Stories are not part of Scrum and backlog items are not necessarily in User Story format. (I use story and backlog item interchangeably).

A list is just a list, so there is nothing binding about the Product Backlog. It is a list of ideas – things that you think belong in the product, but this list is subject to change at any time.
Each backlog item has the following attributes:

  • Description – a statement of the goal or purpose of the story.
  • Sequence number – its place in the queue – determined by the Product Owner
  • Value -  a statement of the business value of the story – determined by the Product Owner
  • Estimate – the development team's guess about how much work is necessary to get the story to “Done”.

Often, the acronym INVEST helps to remind us what makes a good backlog:

  • Independent – the product owner can prioritize in any order
  • Negotiable – the story does not define how the story should be implemented
  • Valuable – the story has business value (e.g. to a user, customer or stakeholder) – no artifacts purely for the benefit of the development team are allowed.
  • Estimable, Small and  Testable – each of these serve to ensure that the backlog item is small enough and concrete enough to be implemented reasonably effectively.

We can think of a Backlog Item as a reminder to hold a conversation. That conversation is between those who understand the goal (often the product Owner, a stakeholder, a subject manager expert or even an actual user) and the development team, i.e. those who will implement the story.

This conversation should be held shortly before the backlog item will be implemented so that it is easy to verify that the story was implemented correctly. Everyone still remembers the decisions that were taken and no one has had time to change their minds!

The result is the “confirmation” – a statement of how to confirm or verify that the implementation of the story met the goals set for it.

The process is often referred to as the “three C's”: Card, Conversation and Confirmation. The idea is that you write the story of the front of the card and the confirmation on the back of the card after the conversation. In a software environment, that confirmation will become more formal acceptance tests and ideally, automated acceptance tests, if the team is good!

The conversation serves to get the story ready for implementation. The Team and the Product Owner may agree to rename to the story to make the description more understandable. They may take large, complex stories and “refine them” into smaller stories with simpler acceptance criteria. The sum of the parts equals the whole, but is easier to implement, validate and accept. Important: A small story is not a task, it still meets the criteria for a Product Backlog Item: When implemented, it has business value.

Ideally, your stories should be small enough that the team will forecast at least 6 and preferably 10 stories or more, regardless of sprint length.

This process of making the stories smaller and getting them ready for implementation is called backlog refinement. This video explains the process:

For an explanation of estimating with story points, check out Explaining Story Points to Management

Categories: Blogs

Possibilities for Managing Individual and Team Compensation

Johanna Rothman - Fri, 06/23/2017 - 16:15

There’s a twitter conversation about how to manage team compensation. How can we pay people what they are worth and compensate a team for their value?

I know there are teams where I was quite valuable—not because I was “the” leader, but because I helped the team achieve our goals. And, there are teams where I was not as valuable. I did great work, but my contribution wasn’t as valuable as other people on the team.

That is the crux of the matter when we think about team compensation.

Here’s how I managed this problem in the past:

  • I created (with HR’s input) technical career levels. I often had 5 levels: associate engineer, engineer, senior engineer, principal engineer, consulting engineer. The principal and consulting had first-level manager and group manager as parallel. In addition, I had a couple more management levels (director and VP).
  • I wrote down expertise criteria that differentiated each level. The criteria focused on breadth of responsibility, collaboration capability, and strategic vs. tactical thinking. HR made me add “typical education” which I amended to say “or years of experience.
  • I asked my groups to provide me feedback on these criteria.
  • When I was sure the criteria were correct, I met one-on-one to make sure we each agreed where each person fit into the criteria. Some people were on the verge of a promotion. Some were not. We worked together to make sure we were both comfortable with their title and compensation.

Now, I had the ability to provide people individual compensation and promotions. And, I could provide team-based compensation. Here’s how it worked.

One guy, John, wanted a promotion to senior engineer. He was a high-initiative person. He coached and mentored people in the team. He got along with everyone quite well, and his solutions were often good. It was the often that was the difficult part. When he got an idea in his head, it would take a disaster to convince him he was wrong. His judgment was not as good as a senior engineer needed to have.

I’d provided feedback in our weekly one-on-ones explaining both my happiness and concerns with his judgment, depending on the circumstance. (This was not agile. We used staged-delivery, a feature-driven approach. I was the manager of several groups.) I asked him if he wanted coaching, and yes, he did, but not from me. That was fine. I arranged a coaching arrangement with someone who was a principal engineer (2 levels up).

The two of them met twice a week for several weeks. I think each meeting was about 20-30 minutes. The coach asked questions, provided guidance and options. The engineer learned a ton in that month and started to explore other options with his team. He started to realize his very first idea was not the be-all and end-all for the work.

It took him several months of practice, and I was able to promote him to be a senior engineer.

People need to know what the criteria are—why the org values them. If the salary ranges are too tight, there is no flexibility in hiring. If the salary ranges are too loose, it’s too easy to have discrimination in payment, especially if someone started their first job too low. (Yes, I have experienced salary discrimination.)

Let me provide a little context for team compensation. John’s team was involved in a new product. We didn’t know much about the customers and product management wasn’t much help. (I said this is before agile.) John asked the tech writer, Susan, for help in understand what customers wanted.

Susan guided the entire project. She helped the team understand the requirements. Because Susan was a principal engineer, she had customer contacts and she used them. She created what we would now recognize as a ranked backlog. John had the idea of a “pre-beta,” which were builds we provided to a select group of customers. You might think of this as a series of MVP (Minimum Viable Products) to these customers. The customers provided feedback to Susan, who used that feedback to guide the team.

We released the product and it was a great success. My VP came to me and told me I would get a $10k bonus (a ton of money back then). I said I had not enough to do with the project, and that the team would get the money. My boss cocked an eyebrow and said, “I don’t want to lose any of them.” I told him I would make it right, somehow.

I went to the team and told them I had been chosen to receive a $10k bonus, which I thought was wrong. They all agreed!

I asked them to explain how they wanted to divide the money. (I was thinking evenly.) Before I even had a chance to pass out stickies, John said, “Susan should get the most. She was the heart and soul of this project.” Everyone nodded their heads.

I said that was great, but let’s do a private vote in case not everyone agreed. I passed out stickies and asked people to write down how they wanted to divide it. Every person said: 40% to Susan, the rest evenly. Well, one person added me in the evenly part. I thanked the person and demurred.

That’s what we did. Susan asked for part of her increased percentage to be a team dinner with spouses/significant others and they invited Mark and me.

The team knows who did what. The team can manage bonuses.

I don’t know that this is the “best” approach. I have always wanted to know what my organization wanted from me. I have found a career ladder in the form of expertise criteria a great way to accomplish this. In addition, I want to know that if there is extra compensation, the team will receive that extra as a team. Every project I’ve ever been on was a team effort. Agile approaches make that even more obvious.

Categories: Blogs

Agile Open California South, Irvine, USA, September 7-8 2017

Scrum Expert - Thu, 06/22/2017 - 09:00
Agile Open California South is two-day conference that provides Agile and Scrum practitioners in Southern California an opportunity for learning and networking. Agile Practitioners and newcomers come...

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

Lean, Agile & Scrum Conference, Zurich, Switzerland, September 14 2017

Scrum Expert - Thu, 06/22/2017 - 08:30
The Zurich Lean, Agile & Scrum Conference (LAS) is a one-day conference taking place in Switzerland that focuses on Lean and Agile approaches for software development. The conference should...

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

The Role of Management in SAFe

NetObjectives - Wed, 06/21/2017 - 20:54
I was asked to chime in on a discussion group about the role of Management in SAFe and as I was writing it up I thought it’d come out better as a blog. I believe the role of manager in Agile has been ignored (the Agile Manifesto), vilified (chickens and pigs) and then to the other extreme transformed (they should be leaders).  In my mind, all three of these is not the role of first line...

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

Effective Teams Patterns

Scrum Expert - Wed, 06/21/2017 - 18:38
Some software development teams are orders of magnitude more effective than others, turning around business solutions in days or even hours. Their secret is a combination of smart technology choices,...

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

#TargetprocessTips: Search, WIP Limits, Batch Actions, Workflows, Card Prioritization

TargetProcess - Edge of Chaos Blog - Wed, 06/21/2017 - 17:14

We've started posting regular product tips to our social media accounts. Just search for #TargetprocessTips on Twitter, Facebook, or LinkedIn to see some bite-sized advice on how to get the most of Targetprocess. Here’s what we’ve posted so far:


Placing a ‘+’ before keywords will yield only exact matches in search results. More on search. 

  • The search bar in the the left menu is used to find a specific view or folder. The search bar to the right of this is the global search; it is used to find entities throughout the system.
  • Global search will not yield results for entities in inactive projects.
  • When using global search, you can replace any letter in your keywords with a ‘?’ to include possible misspellings in the results.


WIP Limits

You can set up WIP Limits for both horizontal and vertical lanes on boards by going to view setup → Limits. Read more here. 

  • When a WIP Limit is exceeded, the state column will be visibly highlighted in red.
  • WIP Limits cannot be applied to the first (initial) state of a workflow.

WIP Limits


On Timeline views, the global time period selector is found at the top of the view, while the local time selector is displayed at the bottom. If you're unfamiliar with Timelines, you can learn more about them here


More on Timelines:

  • Timelines are one of the 4 main types of views, along with Boards, Lists, and One-by-One views.
  • You can right-click on a point in the Timeline to add planned start and end dates. 
  • Planned dates are shown with a dotted line, actual dates are shown with solid background, and forecasted time is shown with a semi-transparent background.  


Card Prioritization

Prioritize cards on Board and List views by holding the 'Shift’ key and dragging selected cards to the desired position. If the system prevents your from applying prioritization, this guide article should explain why.


Working with cards from multiple views:

You can use the Selected Cards Panel to work with cards from multiple views at once.

  • Since sharing this tip, we've released Batch Actions, which allows you to update multiple entities at once. However, please note that you can only apply Batch Actions to cards on a single view at once.   

Selected Cards Panel


Workflow customization:

Admins can rename and customize workflows and states by going to Settings → Process Setup. Read more. 

  • Be careful when editing a process that is currently in use. If you remove states which are populated by entities, the entities will be moved to a different state. 



Categories: Companies

Sprints or a Kanban?

Agile Game Development - Wed, 06/21/2017 - 15:45
There seems to be some confusion that using Sprints or a Kanban is a competition of sorts with "one being better than the other".  Might as well argue whether a hammer is better than a saw.

Sprints are more suitable to complex problems that a cross-discipline team will swarm on to solve.  Complex work has "unknown unknowns" that require experimentation and defy planning and estimation.  The time-box is a limit of time that is established to touch base with the business side and to replan our next move on a complex mechanic.

A Kanban, a way to visualize a lean flow, is used for complicated work.  Complicated work has "known unknowns", like creating levels and characters for a game with established mechanics.  The variations are manageable. It is more predictable and uses hand-offs of work through a flow.

Using Sprints to manage complicated work results in batched work and an artificial division through sprint planning and review. It hides discipline inefficiencies and leads to split stores which create no value individually. Imagine the cost of buying a house if every one was a custom concept home built by a guild of craftspeople.

Using a Kanban to manage complex work results in turbulent flow that either creates inefficiencies and a lack of transparency or artificial deadlines to call things "done" when they really aren't.  Kanban doesn't handle the back-and-forth of exploration very well. This creates debt and can limit the creative potential of a game. It's why we don't use an assembly line to design a new car.

I often see Kanban used for complex work because there is still an "upfront planning" mindset that thinks a new uncertain game mechanic can be broken down into bite-sized discipline centric steps and pushed though the teams. Sprints are abandoned because the developers cannot be trusted to take larger goals and break down the work as they see fit.

Choose the best tool for the work.  Wielding a hammer with great skill to cut long pieces of wood into smaller ones isn't as useful as using a saw.
Categories: Blogs

UnBoxing: Open Space Agility workshop

I'm taking Mezick's introduction course to OpenSpace Agility - thought I'd write a bit about what I'm learning.

Day One:
Beginning concepts - leaders have a duty to set direction and name constraints; yet stay away from telling how to achieve the goals.  Executives commits to holding first OpenSpace and Acting upon the proceedings.  And holding a second OpenSpace after a time box (100 days).

A constraining forces in OSA will be the Agile Manifesto, actions and experiments should be judged by this definition and if seen to support it, be considered good.

Another foundational concept of OSA - Self Management - defined as the behavior of a group to know and practice their decision making process (whatever that may be).  A good test is to ask 5 people how their group makes decisions - then count the number of answers - one general description of their decision making apparatus points strongly toward a self-managing team.

Q:  Many agilist are searching for a scaling framework.  If the foundations of agile mindset shift is a willingness to engage in dialogue about possibilities; how does one scale willingness?  Dan pointed to UX designer Micah Zimring candidly discusses his experience of the OpenSpace Agility process, including his initial skepticism going in. (Note: When you hear the the word ‘churn’ used in this interview, it means ‘lack of decision-making’ or ‘indecision’).

Paraphrasing Dan:  'Most Impediments come from:  People making decisions they do not have authority to make e.g. boundary issues with authority & decisions.'

 Harold highly recommended book:  Fierce Conversations by Susan Scott (better than Crucial Conversations - you say potato, I say pootato, let's check it out.)

Day Two:
There was a interesting conversation happening on the pre-meeting video conference... people engaged and communicating on a true personal level (acting with trust).  This is quite unusual for so many tech video conferences, regardless of team size, team maturity level, group dynamics.  I felt as if I'd entered an old familiar bar where everyone knew my name - Norm!

We might return to this concept... later...

So my notes say we might have started with a bit of a lesson on the distinction between some points on the influence spectrum.  After all many Agile "coaches" attempt to influence other people, many times they have great impact for the good (well at least that's how I get to sleep at night).  I may have ruined this one guy's whole sleep over... he joined our little band of developers in Seattle and got along well, we learned to develop working tested software, and to the direction of a great PO.  She had the vision to lead us on a journey - there was some unknown territory along the way - and we discovered the reasons for some weird missions.  Later this guy wrote on a discussion thread about the woes of the good old days - that he'd rather not work on Agile projects any more, because he knows from experience what it can be, what it should be, ... but the project are not that.  It's lipstick on a pig.  He'd rather do waterfall projects.  Because coding to the spec is easy, no work at all really.  However playing the in-between game is hell.

Oh - sorry - that crap just jumped out of my fingers... we were talking about influence - all the way down the slippery slope to manipulation and into coercion.  Now I can not define these term - now after two beers ... and it's just going to get worse as I type and imbibe.  So look it up your self if you don't have a good feeling of the continuum we are discussion.  Do you agree these are on the same dimension?

When does one cross the invisible line from influence to manipulation?  Does it matter... if the ends justify the means?  Dan suggested a way to view manipulation - I'd never heard it explained so well.  I've always considered manipulation as influence in the eyes of the influencer, while being manipulation in the eye of the beholder.  Dan defined manipulation as something you realized happened four hours ago.

What's this got to do with OSA?  Turns out it is a foundational principle of OpenSpace.  The aspect of having freedom and agency to make a decision to participate.  Show of hands - who has been informed by the leaders that they were going to now start practicing this Scrum process, and these coaches were here to help you?  All the hands go up.  Who has been invited to be part of an Agile Transformation?  Two hands only.  Which set of people have been influenced?  Which set have been manipulated?  How does this effect the long term commitment to a "transformation"?

Topic Jump to Meetings - what is the generic structure of a meeting:

  • Goal
  • Rules
  • Progress
  • Participation

Going into detail on these...  but let's just focus upon Progress - how's it measured?  Maybe in most meeting by the clock hands.  Sometimes by agenda items checked off.   Are those items classified into one of a few groups:  discussion, decision, information dissemination, a waste of time.

Participation - is your meeting an Opt-In meeting or an attendance required (with unknown consequences to be determined later by the boss) meeting?  Perhaps making this explicit would be helpful in an organization of more than 5 people.  At the heart of OSA - the invitation (Opt-In) format of the events.

So how does a meeting differ from a Game?  Is there any real difference?  Fun... oh yes!  Why is fun not an emergent outcome of meetings?  Games have this very same structure.

Games and meetings have these aspects as well as structure:

  • Control
  • Progress
  • Belonging

One big difference in games and poorly held meetings is the visual depiction of progress.  In beginner games (Candy Land) the board is the indicator of progress.  It takes very little synthesis to determine who is progressing well in the game.  Chess is quite different.  How are your meetings progressing?  What visual indicator of progress do you include for the people?  Do they become motivated or demotivated by seeing progress made toward a goal?

Why are most games perfectly well run with player participation and no umpire or referee?  Is it the well understood mental model of the rules and proper behavior on the field of play?  What would happen if meetings had these rules?  Do they have rules?  Where's your meeting rule book?

Topic transition to Leadership concerns for OSA.

Sponsor understanding their role and what is about to happen (maybe they feel out of control).
 - development of theme (together, maybe a group)
 - invitation development (come finish the story with us)
Sponsor must communicate:
 - explore the theme & contribute to proceeding (artifact)
 - suspend disbelief for the duration of experiment (100 day trial)
 - invited to the post-experiment Open Space (in 100 days)

Book:  Leader's Guide to Store telling - Steve Denning

Leaders are constantly signaling - ever micro expression gets a mean assigned by followers constantly watching - no rest for the leader - never off stage, the mic is alway HOT.

Story telling is a signaling event with a bull horn.

Book: by Alex Pentland - MIT

Emergent Leadership is like musical chairs.  People change their minds during the game; they may be motivated to move quickly to acquire a seat (at the table), to contribute to the outcome of the story we write to become our future selves.  Open Space encourages people to get a chair.

OpenSpace is a game about authorizing and authority - who has it, who is giving it, who is receding it, etc.  It is played out in a high frequency feedback space of face to face - full body contact - interactive group dynamic.  It is full of potential energy - release it.

Open Space is an Authorizing Function over the time domain of the event.

People authorize others to contribute to the shared understanding, by giving their time and attention to the speaker.  Because they are also free to seek more value if they deem the speakers value lower than opportunity cost.

Day Three:

We started the lesson with the topic of Leadership Prep - the admonishment was to "eat our own dog food" - to open space for the leader to learn about OSA to experiment with safe to fail experiments, to inspect the results and adapt to the needs of the leaders to grow in their understanding of the Open Space.  Search softly for the leader's maximum skin they will put into the game,  cut that in half and practice.  It is this experience (safe to fail) that will lead to understanding - it may be the only way for mere mortals to catch a glimpse of the philosopher's stone inside of the Open Space onion skin of powerful technology.

At some point Harold explained the inside joke of the term Technology in OST... perhaps it's useful in the simplicity of it's inverse, in it's sarcastic usage...  OpenSpace Technology requires the very first and hardest to understand technology that humanoids developed - language skills.

Warning:  Do NOT lead with an unacceptable invitation.  This was Dan's advice, and other's echoed it.  The advice seemed to come from a deep desire to short cut our journey toward successful engagements with clients.  With an action step of starting small, almost imperceivable - don't mention OSA at all - just encourage the leader to make a meeting optional.  A true Opt-In event, with the power of invitation and no repercussion for checking out.  See what the leaders can discover in the behaviors of the people - are they following - are they happily engaged - are they curious - who's participating - who's willing and able to change behaviors?

Another experiment (a few steps up the ladder) - Dan calls it an "A1" meeting.

Look up. B. J. Fogg - Persuasion Lab - I can't remember why - guess I wasn't persuaded.

We spent a bit of time discussing and practicing non-verbale signaling.  A suggested resource: The nonVerbal Dictionary.  Do you read body language?  If not you may be well toward one side of the autism spectrum.  Most everyone does read body language quite well, we've been doing it since very early - I think I heard a story that infants can read facial patterns.

Look into Powerpoint karaoke - a great team game.

Topic of Organizational Learning (time to get your Senge on).

What impedes org learning - fear. When a human is afraid the Neo-cortext is not being engaged, and the monkey mind is getting all the blood flow, this severally limits learning.

What can we do to counter act the stimulus-response mechanism over which we have little immediate control? Create physiological safety... yeah, but how? Well maybe a lesson for another time - but for sure this is a learning enabler. To check this out - watch small kids on the playground. Playing is learning. When play stops - what happened?

Topic of Informal Authorization. How do we recognize this form of authorization? It's communicated constantly, learn to sense it... it's not on a sign post, or in a sound wave - yet it is all around you. Tune into the signal, learn to amplify it, to dampen it and to withdraw informal authorization. It is a powerful force - recognize who is using this, and who is oblivious.

Review: Invitation has: clear goal, rules or constraints, a way to experience progress toward goal, an opt-in participation.

Challenges (Opt-in homework):

Invitation: What are the most simple invitations (with 4 aspects) that we can generate?

Spark some invitation experiences: Issue 3 or more invitations this week.

Read Sprit by Harrison Owen PDF - search for number of occurrences of "open space" vs "Open Space" investigate usage and content - what was he signaling?

Well expect to be surprised: Harrison Owen showed up on the conference call to share some space with our group.

Harrison Owen - discover/giver of Open Space Technology
Here are some badly paraphrased quotes from Harrison:

I have a suspicion or a conviction that:
  • life is self organizing; so, what is a manager for?
  • self organization does the best job; are we stupid to use management techniques?
"Since the universe has been practicing for 13 billion years on self-organizing principles - its not really about improving self organization; but how do we optimize self-organization to enable people?"

Read his book:  Wave Rider

Peter _____ studying behavioral characteristics with performant systems - they have zero regard for external authority.  From scale of micro <--> cosmic.  This group self-organization principle appears to hold true.  Discipline with respect to self organization phenomena :: forcing people to do something that doesn't work for them ... is counter to system goals in long run.  Distinguish between external / internal discipline :: bad / good.

Example traditional education techniques rely upon discipline - it's a destructive force.  Learning is play - Learning is a self organizational system a phenomena with a virtuous cycle.

Day Four:

Question:  what's up with this core protocol: Check in/Check Out process?
A: it's a subtle little hack - about getting a small agreement to communicate and engage.
One might also find info in Influence books topics.

Question: Harrison Owen spoke of "sitting in the Question" - what's that about?
A: not knowing - be OK in that space.
One might also find solace in Donald Rumsfeld's "There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know."
- hummm... or NOT!

Liminality - participants "stand at the threshold" between their previous way of structuring their identity, time, or community, and a new way, which the ritual establishes.
Learning is CHANGE - it is hard to un-learn :: therefore hard to change.  Many people will make up myths to avoid uncertainty and worry - be very very careful who is allowed to create the myths of your organization.  If the leader's are not telling stories - the vacuum of story telling will be filled - by someone.
From Ritual to Theater - Victor Turner - The Human Seriousness of Play
One may think of OpenSpace as a study in authorization - imagine that one could easily and without malice deAuthorize a colleague that was advocating for a position or path that you disagree with.  In OpenSpace this should be relativity easy - see the Law of Two Feet.
Some Wisdom & Warnings:
The Proceedings - one may think the sponsor will do everything suggested in the proceeding and that the sponsor will be responsible for carrying it out - think again.
Watch out for a sponsor that said YES easily.  (But action show them as meaning NO.)
Learning is fundamentally destabilizing - a sponsor or leadership that needs stability might not be ready for a group of subordinates that are ready to learn (make mistakes and attempt new risky behaviors).
If you are actively coaching the Org or leadership; do NOT facilitate the OpenSpace - pass the authority - it will benefit the organization and in the end, you also.

----post workshop:  I attended a one day "open space" styled conference and saw that I had learned quite a bit in Dan's sessions.  Knowledge is like magic.

See Also:
Ted Talk on the use of texture in architecture and the effects upon people in public spaces.

Check out the OpenSpace Agility site.  From the about page:
OpenSpace Agility (OSA) is a repeatable technique for getting a rapid and lasting Agile adoption. It works with what you are currently doing, and can be added at any time. For executive leaders, OSA is a template that operationalizes the core values of Lean, namely: respect for people, and continuous improvement. For executives who are truly committed to these values, OSA represents a simple, effective and very efficient way forward. With OpenSpace Agility, you can expect:
  • A dramatic reduction in the coaching & training costs of implementing your Agile program
  • A genuine, rapid and lasting Agile transformation
  • A dramatic increase in employee engagement scores
  • A dramatic increase in stakeholder satisfaction and potentially, genuine stakeholder delight
  • Predictable, reliable, repeatable, EVIDENCE-BASED improvement in overall results
OpenSpaceAgility incorporates the power of invitation, Open Space, game mechanics, leadership storytelling and more…so your Agile adoption can actually take root. OSA is based on people, THEN practices. You can use any practice or framework with OSA: Scrum, Kanban, DaD, SAFe, LeSS, and more.
Categories: Blogs

Learning Git with GitKraken: How to Squash Commits

About SCRUM - Hamid Shojaee Axosoft - Wed, 06/21/2017 - 01:17

We created a series of Git tutorial videos that were really well received by developers wanting to learn Git. However, we got a lot of feedback that you (the viewer) wanted to see how those Git concepts could be applied in GitKraken. So, voila! We created the Learning Git with GitKraken video series.

Our latest video in this series is about squashing commits. In 90-seconds, you’ll learn what it means to squash commits, and you’ll see how easy it is to squash commits in GitKraken.

Watch this video and subscribe to our YouTube channel for more videos in this series!

Categories: Companies

Who’s Afraid of Emergent Design?

Leading Agile - Tue, 06/20/2017 - 21:39

A hallmark of lightweight software development methods is the notion of emergent design. The idea is that the design of the solution will emerge little by little as we build up the code in small increments, typically using test-driven development with very short red-green-refactor cycles.

When it goes well, we avoid a number of problems. We won’t create a comprehensive design and write a lot of code that only leads us down a rabbit hole that’s hard to climb back out of. We won’t get carried away with our natural creativity and over-engineer the thing way beyond what our customers want to pay for. We won’t end up with a suboptimal architecture because we invested too much too soon in our initial design ideas.

It’s a simple enough idea in principle. It really isn’t difficult in practice, either; I can vouch for the fact it makes the work considerably less stressful and more enjoyable than the Old Ways of building applications.

And yet…

Have you ever tried to push the north poles of two magnets together? The magnets get close, and then slide apart. Each time they slide apart, it’s in a different direction than the time before.

When working with developers who are unaccustomed to emergent design, I sometimes get the same feeling. They seem to understand the concept, and they seem to be getting really close to doing it, and then it slips away from them.

Why so much difficulty? Well, as the saying goes, the devil is in the details.

Where’s the safety net?

If you’ve always worked from a comprehensive, detailed design specification, then starting to code with anything less than that is going to feel pretty uncomfortable. What if you forget something important? How can you be sure the design that emerges will be any good? Lacking detailed design specifications, how will you know whether a proposed code change will affect other parts of the solution?

It feels like you’re crossing a half-frozen river by leaping from ice floe to ice floe. That design documentation was your safety net for changing the code. Now, what are you supposed to do?

Actually, you do have a safety net, and it’s far more trustworthy than any design document. Remember that we use the technique known as test-driven development for emergent design. Those executable test cases accurately and fully describe the low-level behavior of every unit of code in the solution. They are always up to date with respect to the production code, however little or however much of it there is on any given day. Driving every new feature, every modification, and every bug-fix from tests gives you a high degree of protection from errors.

Nothing is foolproof, of course, and like anything else we do in our work, test-driven development is a learned skill that requires practice. But that’s nothing new for you. After all, you weren’t born knowing all the things you know how to do. You had to learn them. All of them. This is just One More Thing. And it’s easier than most of the other things you’ve learned about software development over the years. (See? I told you it was less stressful!)

Just enough design initially

Developers who are just beginning to learn emergent design often hold a certain misconception at first. They think “emergent design” means “no design at all.” You just open up your favorite editor and start typing. That’s not quite right.

There’s an old mantra that (I think) came from the Feature Driven Development community years ago: Just Enough Design Initially (JEDI). To take an emergent approach to solution design, JEDI is our starting point. There’s a lot of territory between comprehensive, detailed up-front design and no design at all. It’s incumbent on us as professionals to be able to make judgments about where, in all that territory, we should begin any given project. It isn’t always the same spot.

Well, if JEDI means different things in different situations, then how are we expected to learn to make judgments about it? The bad news is there are no hard-and-fast rules. The good news is there are no hard-and-fast rules. We get to use our intelligence, creativity, training, and experience, and we get to collaborate with other smart, creative people, rather than just coding to someone else’s spec. (See? I told you it was more enjoyable!)

Architectural design or application design?

I find it useful to draw a distinction between architectural design and application design. Most of the time, when we write a new application we aren’t simultaneously inventing the architecture that supports it. The architecture is like scaffolding on which applications can hang. Yet, many people think it’s mandatory to begin each project by designing the architecture for the solution.

As long as our application is a new instance of an existing type of thing, we don’t need to begin our work with an architectural design. There’s already an architecture, if not several architectures, relevant to our new application. “Just enough” up-front design is probably not very much.

Sometimes, if we’re lucky, we get to build an entirely new type of thing. There’s no existing architecture on which to hang it. In this case, “just enough” up-front design amounts to more than in the first case…but you still might not do a comprehensive design up front, as there’s value in emerging the architectural design, as well, once you get to a good starting point.

We aren’t necessarily starting completely from scratch when we build an application. There may be reference architectures, design patterns, libraries, code generators, and other resources available to save us time and effort. You don’t need to design an architecture to support a new web app. You can choose from Model 2 or MVC, Hierarchical, and Single-Page architectural patterns. You don’t need to design a responsive web app from scratch; you can choose a web app framework that has responsive design built in already. You don’t need to design an architecture for a mainframe batch process that grinds up sequential files all night. You already know it must comprise a subset of extract, sort/merge, edit, update, and report steps. These are well-known types of things, and once you’ve seen an example or two, you never need to re-design one from whole cloth.

The basic advice here is: Don’t reinvent the wheel.

Your past experience counts as up-front design for your next project

I don’t recall where I first read or heard that saying. I didn’t make it up, but I like it. Your new application isn’t identical to any existing application. After all, if it were, then you wouldn’t need to write it at all. But at the same time, the new application probably isn’t so very different from other work you’ve done in the past.

Do you really need to re-draw all the design diagrams you drew on those past projects? I’ll bet you don’t. You’re just checking a box on a checklist of tasks: “Draw design diagrams.” I’ll bet if you drew those diagrams, you’d never look at them again. After all, you didn’t the last 25 times you drew them, now did you? Come on, ‘fess up!

Don’t do anything stupid on purpose

That’s another one of my favorite old sayings. It’s been common among engineers for decades. Signs hang on the walls of labs bearing those inspiring words. All those software design principles folks like us are always jabbering about can be derived from that single ur-principle: Don’t do anything stupid on purpose.

Sometimes, when developers are first trying to apply the idea of emergent design, they very strictly follow the (intentionally)-incomplete and -lightweight specifications to the letter. That is, they don’t do anything that isn’t explicitly specified.

And that violates the ur-principle. You know your application has to handle exceptions gracefully. You know it has to support logging. You know it (probably) has to support internationalization, accessibility, and a host of other things that most or all applications have to do. Do you really need someone to write that stuff down for you every single time? You know the drill.

So, who’s afraid of emergent design? Not you.

The post Who’s Afraid of Emergent Design? appeared first on LeadingAgile.

Categories: Blogs

Commenting Policy and How to Get Answers to Your Questions

Here is a short reminder about the Commenting Policy for this site. You can read the full policy here or via the link in the footer on every page.

A lot of the value of this blog comes from the discussion in the comments, and so it is important that all comments be related to the original post. While I appreciate anyone who takes the time to leave a comment, if a comment is not related to the original post, I won't reply and may delete the comment.

Do not hijack a post to an entirely different question. Please see if your question has been addressed by other posts. If not, you can submit it at

I try to address the questions and topics suggested there through this blog and my weekly tips emails.

I'm sorry, but I cannot reply by email to questions that are highly specific to your team. If your question or topic is one that I think is of general interest to others here, I will do my best to address it in a blog or weekly tip.

Categories: Blogs

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.