Skip to content

Feed aggregator

Neo4j: – java.lang.IllegalArgumentException: Illegal pattern character ‘T’ / java.text.ParseException: Unparseable date: “2012-11-12T08:46:15Z”

Mark Needham - Mon, 03/06/2017 - 22:52

I often find myself wanting to convert date strings into Unix timestamps using Neo4j’s APOC library and unfortunately some sources don’t use the format that expects.


AS ts

Failed to invoke function ``: 
Caused by: java.lang.IllegalArgumentException: java.text.ParseException: Unparseable date: "2012-11-12T08:46:15Z"

We need to define the format explicitly so the SimpleDataFormat documentation comes in handy. I tried the following:

AS ts

Failed to invoke function ``: 
Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'T'

Hmmm, we need to quote the ‘T’ character – we can’t just include it in the pattern. Let’s try again:

AS ts

Failed to invoke function ``: 
Caused by: java.lang.IllegalArgumentException: java.text.ParseException: Unparseable date: "2012-11-12T08:46:15Z"

The problem now is that we haven’t quoted the ‘Z’ but the error doesn’t indicate that – not sure why!

We can either quote the ‘Z’:

AS ts

│"ts"      │

Or we can match the timezone using ‘XXX’:

AS ts

│"ts"      │

The post Neo4j: – java.lang.IllegalArgumentException: Illegal pattern character ‘T’ / java.text.ParseException: Unparseable date: “2012-11-12T08:46:15Z” appeared first on Mark Needham.

Categories: Blogs

Agile Coaching Exit Strategy

Scrum Expert - Mon, 03/06/2017 - 20:03
When do you need to stop coaching an Agile team? In his blog post “An Exit Strategy for the Agile Coach”, Len Lagestee discusses this question and explains how he will gradually work to...

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

Deep dive into Windows Server Containers and Docker – Part 2 – Underlying implementation of Windows Server Containers

Xebia Blog - Mon, 03/06/2017 - 10:41

With the introduction of Windows Server 2016 Technical Preview 3 in August 2015, Microsoft enabled the container technology on the Windows platform. While Linux had its container technology since August 2008 such functionality was not supported on Microsoft operating systems before. Thanks to the success of Docker on Linux, Microsoft decided almost 3 years ago to start working on a container implementation for […]

The post Deep dive into Windows Server Containers and Docker – Part 2 – Underlying implementation of Windows Server Containers appeared first on Xebia Blog.

Categories: Companies

Are you closing the Distance in your Agile Journey?

An interesting phenomenon has arisen in Agile environments that could become litmus tests to determine if you are Agile.   This phenomenon is the concept of “closing the distance”.   There are three areas that closing the distance is both Agile and good for companies.  The three areas include the distances amongst employees, the distance between employees and customers, and the distance when an idea comes in until it hits the marketplace. Let’s explore each in more detail.  Closing the Distance amongst Employees – Agile focuses a lot on individuals and interacts as one of its values.  The intent is that employees should be on teams with a common purpose bringing people closer.  Agile advocates the concept of swarming where employees collaboratively work together to get work done.  If you are a manager, Agile asks you to get closer to your employees by removing their impediments and also aligns with the practice of walking the “gemba” (walking the halls and asking if you can help employees by removing impediments and more).

Closing the Distance between Employees and Customers – In many non-Agile organizations, there are often a number of degrees of separation between employees and customers.  Agile asks that employees come face-to-face with customers in the demos to gain the precious customer feedback.  I recommend the “two degrees of customer separation” rule where no employee (including management) should be more than two degrees of separation from the customer (e.g., you to employee to customer or you directly to customer). 

Closing the distance between recording an idea until it hits the Marketplace – In this case distance is the lead-time (clock time between the moment the idea is recorded to when it gets released).  If you are doing Agile well, you will ensure the new idea (e.g., new requirement), assuming it is of high enough value, gets looked at immediately, and not wait until the next budget cycle.  Additionally, Agile expects that you will proactively attempt to shorten the distance from idea to release by reducing wait states and removing impediments.  

In summary, have you noticed that during your Agile journey that you have seen the distances get shorter? Are you getting closer to your colleagues and employees?  Are you getting closer to customers?  And is the lead-time distance being shortened from the moment the idea is recorded to when it gets to market?  If not, then maybe you’re not as Agile as you thought.  If you have, then you are headed in the right direction.  Could awareness of these three distances provide you a litmus test on whether you are moving in the direction of agility?
Categories: Blogs

Why Agile Should Be More Predictable Than Waterfall

NetObjectives - Sun, 03/05/2017 - 17:17
Executive Summary Many executives have been led to believe that Agile is inherently less predictable than a waterfall approach.  However, Agile, when wrapped in Lean-Thinking, can be more predictable because it enables working directly on the true causes of unpredictability in software development.  Waterfall’s large projects and stage gate approach cause delays in feedback, workflow, testing...

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

Yes, and… - Elizabeth Keogh - Sun, 03/05/2017 - 16:38

Imagine two actors standing on stage. “I like your penguin,” the first says. The other turns round, looking at the empty space where one might imagine a penguin could be following.

There are two things that can happen.

Perhaps the second actor frowns at the empty space. “I don’t have a penguin,” they say. “Oh,” says the first, and that’s it. The scene is dead.

Perhaps the second actor goes along with it. “Why, thank you!” they exclaim. “I only got it yesterday. Rockhoppers, I tell you, you got to get one of these…” And the scene continues, and now it’s funny, because it has a penguin in it, and penguins are funny – especially imaginary ones. The humour emerges, with jokes that are unexpected, both to the audience and the participants!

This is the principle of “Yes, and…” that forms the basic rule-of-thumb of Improv.

It’s also one of the most important principles for Agile transformation… or any kind of change involving people. This post is about why, and how to spot the principle at work and support it.

Complexity has  Disposition, not Predictability

In a complex space, where cause and effect are only correlated in retrospect, we’re bound to make unexpected discoveries. Anything we do in that space needs to be safe-to-fail. Things that we try out that might improve things and which are safe-to-fail are called probes.

As leaders, our temptation is to come in and start poking the space, persuading people to pick up new ideas and try them out. Maybe that’s safe-to-fail; maybe it isn’t.

The people best positioned to know aren’t the coaches and consultants brought in for the transformation. They’re not the leaders and the managers. They’re the people on the ground, who’ve been working in that context for a while. They know what’s safe and what’s not. They know what’s supported and what isn’t. If you listen to the stories that people tell then you’ll hear about what works and what doesn’t… and those stories play into the space, too, and the people on the ground have been listening to them for a while.

They might not know what’s guaranteed to succeed. I once asked a group whether a football game counted as complicated (predictable) or complex (emergent). One of the attendees asked, “Is England playing?”

I think I might have made a face at that! However, it gave me a useful place to explain the difference between predictability and disposition. Just because the England team seem unlikely to win the football match doesn’t mean that they can’t. They don’t lose every match, after all! So perhaps the world of football is disposed against England winning the world cup.

However, we’re disposed for good beer and a beautiful summer with at least a bit of sunshine, so not everything is bad.

In our organizations, different probes will be differently disposed to succeed or fail, and to require amplification or dampening accordingly. The thing about human organizations, though, is that they are Complex Adaptive Systems, or CAS, in which the agents of the system (in this case, humans) can change the system itself.

And they already are.

People are generally interested in doing things better. They’re always trying things out, and some of those things will be succeeding.

The most important thing we can do as coaches and consultants is to encourage those successful probes; to spot those things which are succeeding and amplify them, and to make safe spaces in which more probes can be carried out, so that we can see more success and amplify it again.

Amplifying means taking what’s already in place (yes!) and building on it (and…).

A Really Common Pattern: “That won’t work because…”

Humans have a real tendency to see patterns which aren’t there, and to spot failure more than success. We don’t like failure. It makes us feel bad. We tend to avoid it, and when we see failure scenarios we invoke one big pattern in our head: That won’t work because…

There’s one word that’s short-hand for that tendency to see and avoid failure.

“I want to learn TDD, but it will take too long.”

“We could co-locate the team, but we’d need to find desk space.”

“We’ve got some testers in India, but they’re not as good as we need them to be.”

The word “but” negates everything that comes before it. It’s the opposite of building on what’s already there.  What might happen if, instead, we use the word “and”?

“I want to learn TDD, and I’ll need to set aside some time for that.”

“We could co-locate the team, and we could look for desk space to do that.”

“We’ve got some testers in India, and we need to help them improve.”

Now, instead of shutting down ideas, be they our own or other people’s, we’re looking at possibilities for change. Just changing the language that we use in our day-to-day work can help people to spot things they could try out.

We already use “Yes, And…” in TDD

The TDD cycle is really simple:

  • Write a failing test
  • Make it pass
  • Refactor

However, when we’re dealing with legacy code, which has behaviour that we’re interested in and want to keep, the first thing we do is to amplify and anchor what’s already in place! We write a passing test over the existing code, then refactor with that safety in place, then we can add the new failing test and the change in behaviour.

  • Write a passing test (Yes!)
  • Refactor
  • Write a failing test (And…)
  • Make it pass.

We can do this with our co-workers, our teams and our organizations as well. Of course, we don’t refactor people! Refactoring code, though, usually means separating concerns and focusing on responsibilities. In human terms, that means anchoring the behaviour or probe that’s working, and helping people or organizations focus on their strengths and differentiators. This helps to outline the disposition of the space too, so that whatever we try next has a good chance of working.

Of course, in a complex space, a “passing test” might not always be possible, depending on what we discover. At least, though, by anchoring what we value, we’ve made sure that it won’t be any worse. If we keep the investment in our probes small, it’s safe-to-fail.

  • Anchor valuable behaviour (Yes!)
  • Recognize and celebrate strengths
  • Design the next probe, or just encourage people with more context to do that (And…)
  • Give it a try.

Tim Ferris’s book, “The 4-hour Work Week”, is all about this; focusing on our strengths and letting other people cover our weaknesses, so that we can change our lives to allow ourselves to learn new things.

The Feedback Sandwich is a “Yes, and…” pattern

You’ve probably come across the feedback sandwich before:

  • Say something good
  • Say something bad
  • Say something good

It’s got some other, less polite names, and a poor reputation, so I’d like to show you a different way to think about it. Here’s what we’re really doing:

  • Anchoring valuable behaviour
  • Suggesting improvements
  • Outlining a good place we’d like to get to.

Human beings are complex, and we make complex systems. It’s entirely possible that the good place we might like to get to won’t be easy, or we’ll make discoveries that mean we need to change direction. So that good place we want to get to is actually just an example of coherence; a realistic reason for thinking a probe might have a positive impact. We can think of a good thing that might result from trying out that improvement.

The thing is, people are adaptive. If you can outline a place you’re trying to get to, and it’s good, and other people want to get there, and you’ve already made them feel safe by anchoring the valuable behaviour, then they’ll make their own improvements, and probably try things you didn’t even think of. You don’t need the bit in the middle. People know themselves better than you can, and they know their own disposition. They know what feels safe, and possible. By giving them a suggestion of a good place to get to, we’re freeing them up to find their own way to get there… and they might end up going to a different place that’s better than before, and that’s good too.

In fact, just making sure that people’s most valuable behaviour is appreciated can be a really great way to create change. “Thank you” is a very simple way of doing that, so remember to use those two words a lot! “Thank you” is the “Yes!” of personal feedback.

It’s All About Safety.

improving-agile-teamsThis is the book which prompted this whole post.

In “Improving Agile Teams”, Paul Goddard dedicates a number of chapters to the concepts of safety, failure and fear of failure. I highly recommend this book, especially the simple exercises which are designed to help a team adopt principles that will help to make things safe.

It’s possible to look at an entire Agile transformation through this lens, too.

Typically, an organization starts adopting Agile at the team level, just in software development, often by taking on Scrum or some form of Kanban. It’s pretty easy to do, because we’ve got a lot of tools which enable us to change our software safely. BDD and TDD provide living documentation and help to anchor the behaviour that we care about. Our build pipelines and continuous integration makes sure that whatever we’ve got working stays working. Of course, we can’t quite ship yet! That’s because shipping to production is still a bit of a commitment, and it isn’t safe.

But* now it’s safe for Development in an organization to get it wrong.

Gradually we adopt practices alongside IT Operations which enable us either to fail in a place where it’s safe – making our test systems more like production – or which enable us to roll back in case of failure. Of course, once you’ve got a production-like test system that can be destroyed and rebuilt as required, it’s not a big step to actually make production systems that can be destroyed and rebuilt easily. Jez Humble and Dave Farley’s book, “Continuous Delivery”, is all about this (they call them “Phoenix Servers”, which gives me an excuse to shout-out to “The Phoenix Project” by Gene Kim et al, too; an excellent novel on the same theme).

So now we have DevOps, and it’s safe for the whole of IT to get it wrong.

As we start shipping smaller pieces of functionality more and more smoothly, the Business starts to pay attention. “Well… could I try this out?” someone says, and suddenly we’ve made it OK for them to do probes too, finding out what the market and their customers do and don’t want.

Now we’ve made it safe for the business to get it wrong.

At this stage we can really start churning out probes as a whole organization. There’s a really weird thing that happens in complexity, though. Sometimes people use things in a way that they weren’t intended to be used.

I often tell the story of Ludicorp and their online game, “Neverending”. They built tools for the players to share screenshots. They weren’t just used for screenshots, though, and those tools became the foundation of Flickr. Google started as a search engine. Amazon sold books. These companies don’t do what they started out doing. This is “exaptation”. It’s people, taking what we created (yes!) and using them for something else (and…)

It’s what makes it OK for us to have not discovered everything yet. It’s OK for humanity to be wrong.

This is how I always think of the Agile Fluency Model ™; with these levels of making it OK for people to be wrong. An Agile transformation is all about making it OK for an organization to get things wrong. If we think of it this way, it becomes obvious that safety is going to be a truly important part of that.

If you can’t think of a probe to try that might improve things and which would be safe-to-fail, maybe you can think of a probe to try that increases levels of safety. Something which puts in place the “Yes!” so that the “And…” can follow later. Something which helps people reduce their investments and commitments, providing themselves with options, or helping them deliberately discover information while it’s still cheap to change.

Make it Safe for Yourself, Too

*You can usefully use the word “But” to negate negatives. That’s about all it’s good for. It took me a fair few months to adopt the “Yes, and…” habit, and even I still use “but” occasionally, because I’m human. I slip up. I make mistakes.

So will you.

Celebrate your successes and your strengths, and make it safe for yourself to fail too Forgiveness is pretty much the greatest gift you can give yourself… or anyone else.

It lets you focus on the “Yes!” of your life so that you, too, can have “and…” in it.

Categories: Blogs

Article 8 in SAFe Implementation Roadmap series: Train Teams & launch ART

Agile Product Owner - Fri, 03/03/2017 - 22:37


As we like to say, “Train Everyone. Launch Trains.”

That’s the subject of the eighth ‘critical move’ in the SAFe Implementation Roadmap, as you can see in the new article: Train Teams and launch ART.

This is a milestone moment in a SAFe rollout as it covers the steps that need to be taken to actually launch the first ART, and trigger the business benefits that can be had from the new way of working. It is also when the focus shifts to the newly formed Agile teams, and the training and knowledge they need to succeed as members of the ART.

In this article, we discuss:

  • Training the Agile Teams
  • The Benefits of “Big Room Training”
  • Launching the ART
  • The First PI Planning Session
  • Moving Forward

It’s important to recognize that this is just the beginning of a long and potentially rewarding journey for the organization and all the players. The fact that people have been initially trained in Agile doesn’t actually make them Agile. Just as Agile value delivery is incremental in nature, so is ‘becoming Agile.’ A mindset of continuous learning and inspect and adapt is now essential to the health and wellbeing of the ART and the business goals of the enterprise.

Read the full article here.

As always, we welcome your thoughts so if you’d like to provide some feedback on this new series of articles, you’re invited to leave your comments here.

Stay SAFe!
—Dean and the Framework team

Categories: Blogs

Book Review: Product Mastery

Growing Agile - Fri, 03/03/2017 - 13:07
We were excited to get our hands on a copy of Geoff Watts’ latest book: Product Mastery. We loved how his previous book, Scrum Mastery, included stories of real Scrum Masters and some of the challenges they face. Geoff’s new book for Product Owners similarly looks at important characteristics of Great Product Owners: Decisive, Ruthless, Informed, […]
Categories: Companies

Psychometric Assessments - a peek inside the person

Agile Complexification Inverter - Fri, 03/03/2017 - 09:52
What do you think & feel about personality and behavioral assessments?  Are they useful to you?  Can you share them with others to help improve your relationships?  Do you have the courage to put your personality on display for your collaborators to inspect?

Well I thought I'd try to open the kimono to see if it helps me...

I've studied Psychometric assessments and some I find useful, some I feel are just a step to the left from astrology charting.  Yet might not be harmful for self reflection.  I've also found that it takes an expert to explain the tools and reports such that a layperson can understand and make positive use of the assessment and it's report.  And while I've been "certified" is some of these tools/technique I do not practice them enough to be competent - and my pitch is akin to a snake-oil salesman.

Here is my DiSC Classic profile:

DiSC Classic by WileyHere is my Trimetric assessment (DiSC, EQ, Motivation) by Abelson Group

DiSC WheelMotivators Wheel
Emotional Quotient Wheel

Here is my Myers Briggs Type Indicator - Level II assessment:
MBTI Level OneMBTI Level II reports

Here is my EQ 2.0 - Emotional Intelligence:

EQ 2.0 by

TalentSmart, Inc. Here is my Action & Influence report:

Here is my Personalysis assessment:
Personalysis assessment

See Also:Authentic Happiness - resources in Positive Physiology - 20 assessmentsMartin Seligman TED talk on Positive Physiology
Personalisis assessment ReviewedMBTI Level II assessment Reviewed
Psychometric testing resources

British Psychological Society’s Psychological Testing Centre (PTC) provides information and services relating to standards in tests and testing for test takers, test users, test developers and members of the public.

National Cultural Studies - assessments at the meta level - the personality and behaviors of nations.

Categories: Blogs

A Light Bulb Moment

Agile Complexification Inverter - Fri, 03/03/2017 - 09:16
A few months ago Michele of Sliger Consulting, Inc. asked about my first Agile Light Bulb moment, I've had a few of them but one that easily came to mind was this one with the Washington State Appellate Clerk court case management systems people back in 2005.

In just two months our newly delivering Scrum team had put into production the "undoable" feature - BAM! - value delivered, trust confirmed, transformation successful.
"My light bulb moment was during the product demo in the Sprint Review Meeting, when the state of Washington Appellate Clerk of Court told me he and the courts had been waiting 20 years for the feature that our team had just delivered. In just two months our newly delivering Scrum team had put into production the "undoable" feature - BAM! - value delivered, trust confirmed, transformation successful. He later sent me the requirement spec for the 20-year-old feature and it read just like our epic story and its children we discovered. Yes, this was a completely different system than the previous retired system - yet it had the same customer needs. We had transitioned from a deadlocked in analysis paralysis development group to a Scrum team in under 3 months, delivering into production every month new features, bug fixes, and tested working software."  -- David Koontz
See other Light Bulb Moments at Sliger Consulting Light Bulb Moments

Have you seen in other collections of Light Bulb Moments?  Please comment below.

Categories: Blogs

Q: What is an Agile Transition Guide?

Agile Complexification Inverter - Fri, 03/03/2017 - 09:12
David Koontz guiding a canoeI was at the Dallas Tech Fest last week and was asked several times what an Agile Transition Guide was (it was a title on my name tag)... it's surprising to me how many people assume they know what an Agile Coach is, yet there is no good definition or professional organization (with a possible exception coming: Agile Coaching Institute).

So naturally the conversation went something like this:

Inquisitive person:  "Hi David, what's an Agile Transition Guide?  Is that like a coach?"

David:  "Hi, glad you asked.  What does a coach do in your experience?"

Inquisitive person: "They help people and teams improve their software practices."

David:  "Yes, I do that also."

Inquisitive person: "Oh, well then why don't you call yourself a coach?"

David:  "Great question:  Let's see...  well one of the foundational principles of coaching (ICF) is that the coached asks for and desires an interaction with the coach, there is no authority assigning the relationship, or the tasks of coaching.  So do you see why I don't call myself a coach?"

Inquisitive person: "Well no, not really.  That's just semantics.  So you're not a coach... OK, but what's is a guide?"

David:  "Have you ever been fishing with a guide, or been whitewater rafting with a guide, or been on a tour with a guide?  What do they do differently than a coach?  Did you get to choose your guide, or were they assigned to your group?"

Inquisitive person: "Oh, yeah.  I've been trout fishing with a guide, they were very helpful, we caught a lot of fish, and had more fun than going on our own.  They also had some great gear and lots of local knowledge of where to find the trout."

David:  "Well, there you have it... that's a guide - an expert, a person that has years of experience, has techniques to share and increase your JOY with a new experience."

Inquisitive person: "Yes, I'm starting to see that difference, but can't a coach do this also?"

David:  "No, not unless the coach is willing to switch to a different modality - to one of mentoring, teaching, consulting, or protecting.  Some times a guide must take over for the participant and keep the person/group within the bounds of safety - think about a whitewater river guide.  A coach - by strict interpretation of the ethics, is not allowed to protect the person from their own decisions (even if there are foreseen consequence of this action."

Richard FeynmanAnd now the conversation start to get very interesting, the Whys start to flow and we can go down the various paths to understanding.  See Richard Feynman's dialogue about "Why questions"

So, I'm not a Coach

I've been hired as a coach (largely because the organization didn't truly understand the label, role, and the ethics of coaching).  This relationship was typically dysfunctional from the standpoint of being a coach.  So I decide to study the role of coaching. I've done a few classes, seminars, personal one of one coach, read a lot and drawn some conclusions from my study - I'm not good a coaching within the environment and situation that Agile Coaches are hired. I've learned that regardless of the title that an organization uses (Agile Coach, Scrum Master, etc.) it doesn't mean coaching.  It intends the relationship to be vastly different.  Since I'm very techie, I appreciate using the correct words, and phrase for a concept.  (Paraphrasing Phil Karlton: In software there are two major challenges: cache invalidation and naming things.  Two Hard Things)

So to stop the confusing and the absurd use of the terms, I quit referring to my role and skills as coaching.  Then I needed a new term.  And having lots of friends that have been Outward Bound instructors and understanding their roles, the concept of a river guide appeals to me in this Agile transformational role.  Therefore I coin the term Agile Transformation Guide.  But many organization do not wish to transform their organization, but they do wish for some type of transition, perhaps from tradition development to a more agile or lean mindset.  So a transition guide is more generic, capable of the situational awareness of the desire of the organization.

What does a guide really do?  
This question may best be answered by David Kelley in his TED talk, "How to build your creative confidence."  In this talk David points out his desire to teach parents that there are not two types of children - the creative and the non-creative.  There are, however, children that lost their desire to express their unique talents early in their lives.  He helps people regain this capability.

It is much like how Dr Bandura has developed his treatment for phobias.  David will tell you about this basic guided mastery technique that restores self efficacy.

How to build your creative confidence. TED Talk by David Kelley
This is what an Agile Transition Guide does... they guide you on a journey toward self efficacy via many techniques in mastery of your domain skills and capabilities.

See Also:
Six Kinds of Agile Coaches by Ravi Verma Describes the HUGeB coach, the one to be.
So what is a Coach and What is a Trainer - Agile 102
Where Agile goes to Die - Dave Nicolette - about those companies that are late adopters or laggards in the innovation curve and the challenges that "coaches" have when engaging with them.
The Difference Between Coaching & Mentoring

Scrum Master vs Scrum Coach by Charles Bradley

Agile Coach -or- Transition Guide to Agility by David Koontz; the whitewater guide analogy to agile coaching.

Academic paper:  Coaching in an Agile Context by David Koontz

What is the ROI of Agile Coaching - Payton Consulting

Interesting Twitter conversation about the nature of "coaching" with Agile42 group.

Categories: Blogs

Targetprocess Mobile for iOS Release 3.3: Notifications tab, view setup, follow entities

TargetProcess - Edge of Chaos Blog - Thu, 03/02/2017 - 20:10
List of notifications inside the application

Previously, you could get push notifications sent to your device, but you couldn't view a list of them inside the application. We've now put all notifications into one place, so they are much easier to find.

You can find notifications for:

  • State changes for entities assigned to you
  • New comments where you are mentioned
  • When you are assigned or unassigned to an item


View setup

For those who aren't sure what's going on with their board, such as why certain cards or lanes are not displayed, we’ve added the possibility to see the view configuration. This includes:

  • Cards selected on the board and filters applied to them
  • Horizontal and vertical lanes and filters applied to them
  • Projects and Teams and selection that is applied to the displayed cards and lanes

You can see it all in read-only mode plus and also choose to reset your personal filter applied to cards:


Some other useful improvements include
  • Copy the link to an entity
  • Follow an entity
  • Save Attachments


If you have anything you want to share with us, use the Feedback form in the app's 'Me' tab, or shoot us a message at

Click here to download the iOS app.

Categories: Companies

What Makes an Effective Agile Manager?

BigVisible Solutions :: An Agile Company - Thu, 03/02/2017 - 18:00

Imagine you are a software development manager in a company with a waterfall SDLC. You advanced to the position of manager by exhibiting ambition and technical excellence. You have grown your sphere of influence by adding more positions that report to you. You have been successful directing a large group of developers, assigning work to them and instructing them on how to improve their skills.

Now your organization is undergoing an Agile transformation. Your people are now members of self-organized, empowered teams. They are learning new skills from each other. Someone called a “Product Owner” prioritizes what the team will work on, organizing and managing the Product Backlog and representing the customer in the development process. A ScrumMaster removes impediments, escalating issues to ensure that team productivity and quality remain high.  Suddenly there does not seem to be a need for all the things you, the manager, did for your reports on a daily basis! Is a manager even needed in this new agile world?

Where Does the Manager Fit in the Process?

In the past five years or so, the need for Agile management has come into clear focus: people don’t need managing, but processes and the overarching system do. The Agile Manager is a caretaker of the human system and helps the organization in the following ways:

  • They address impediments that ScrumMasters have escalated to leadership.
  • They determine whether team members (new and existing) need training and in some cases in what areas. They are invested in the growth of teams and team members, so that everyone can be successful in their role.
  • They escalate to executive leadership organizational changes that need to be addressed upstream and downstream to ensure that the bottleneck to delivering customer value is removed completely not simply moved to another department (e.g., QA, Ops, etc.).
  • They research and provide new resources that address team needs and help them achieve high performance.

All of these are systemic issues that Agile managers can help address. As organizational complexity increases, the need for caretakers of the system become more accentuated. Traditional managers must stop haranguing people and start wrestling with the processes (or lack thereof) that assist in production. As I said in this video, “It starts with [Agile management] supporting self-organized teams and providing the teams everything they need to succeed”.

“Today’s Companies Need Leaders, Not Managers”

In “The Third Wave of Agile”, SolutionsIQ Chairman Charlie Rudd discussed how Agile shines a spotlight on traditional management and its shortcomings: “…The role of the manager needs to change to support the emerging needs of empowered Agile teams.” He also calls for the role of management to be redrafted to account for the explosive growth of Agile teams.

Too often, though, management is an obstacle to long-lived, sustainable Agile transformation and the real business benefits it yields. This is because the traditional value system of a manager does not align with Agile. At the root of the problem may be the fact that Scrum doesn’t define a role for management. This problem has been resolved in the intervening years and where once teams shouted, “No managers!” they are now shouting, “Agile managers!” As Jeff Sutherland puts it in “Endangered Species? Management’s New Prime Directive”:

“What teams really need from managers [is] help, facilitation, leadership… As the manager in my company, I’m really a coach to the company. I’m a team member. I work on a team. If there’s a ScrumMaster needed, I become a ScrumMaster for a while. If there’s a product, I help out with the product.”

In short: “Today’s companies need leaders, not managers.”

What Does It Take to be a Leader in an Agile Enterprise?

In simplest terms, an Agile manager is a leader. In an organization with multiple layers, you may have many managers, and many leaders above them. In a flat organization, you may have no managers — but you always have leaders. The only true distinction between a manager and a leader is the scope of their influence. What individuals do with their influence and control epitomizes the difference between an Agile organization and a traditional organization. Further, much of an individual’s motivations is revealed in how he or she communicates with those that they influence and control.

Agile is built on the fundamental notion that people are at the center of every enterprise and, hence, the key to the enterprise’s success. For Agile leaders people are not the cause of the problem but are part of the solution. An Agile leader has completely different, human-centric tools at their disposal. Effective communication becomes crucial to aligning values across people and teams and throughout the organization. A taxonomy for helping others succeed emerges when the manager becomes a servant leader dedicated to making others better at delivering real business value and also to be fulfilled and happy in their work.

Some of the tools and techniques for being an effective Agile manager (and all around better human being) are discussed in our webinar “Agile Managers: Redefine Your Role”, including:

  • STOP micromanaging people
  • STOP perpetuating communication anti-patterns (e.g., hearsay, ad hominem)
  • START facilitating discussions and conflict resolution
  • START shepherding human systems
  • START employing advanced communication patterns (e.g., assuming good intent, Perfection Game, high advocacy/high inquiry)
  • START thinking in terms of spheres of Control, Influence and Concern

Something else managers and leaders should start and stop, according to Solutions Consultant Tirrell Payton? START giving teams problems to solve and STOP giving them solutions to implement.


It may seem like Agile is attacking management, but Agile actually is offering management and managers an opportunity to contribute to the new solution space that has arisen out of the increasing complexity of today’s world. Agile empowers managers to make teams and organizations better at delivering customer value by leading well and using new communication tools. Agile aims to eradicate traditional ways of thinking, being and acting that give managers the false sense that they are “more important” than their reports. Agile managers and leaders are so crucial to Business Agility that we have incorporated it into our Agile Transformation Solution. Without buy-in and modeling from Agile leaders, no enterprise can successfully achieve sustainable systemic change.

Agile Managers Webinar

Being a manager in an Agile organization is completely different from the traditional role that most are familiar with. In our webinar “Agile Managers: Redefine Your Role”, SolutionsIQ’s William Rowden invites management and leadership to upgrade their human operating system and provides some tools and techniques that leaders at every level of the organization can use to empower people and bring more value to the organization.

The post What Makes an Effective Agile Manager? appeared first on SolutionsIQ.

Categories: Companies

Automate incident investigation to save money and become proactive

Xebia Blog - Thu, 03/02/2017 - 14:41

How many hours did your best engineers spent investigating incidents and problems last month? Do those engineers get a big applause when they solved the issue? Most likely the answers are “a lot” and “yes”… The reason that problem and incident investigation is hard, is because usually you have to search through multiple tools, correlate […]

The post Automate incident investigation to save money and become proactive appeared first on Xebia Blog.

Categories: Companies

Agile and Beyond, Ypsilanti, USA, May 4-5 2017

Scrum Expert - Thu, 03/02/2017 - 10:00
Agile and Beyond is a two-day conference focused on Agile software development and Scrum project management that takes place near Detroit in Ypsilanti, Michigan. It aimed at taking together software...

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

New Case Study: SAFe increases employee satisfaction, provides hiring edge for censhare

Agile Product Owner - Wed, 03/01/2017 - 21:51

“Having a clear methodology and training in place has been very helpful when hiring people: Good developers expect a modern methodology. Being able to tell candidates that we take Agile principles seriously-by mentioning that we have trained and certified product owners and Scrum masters, and that we follow a clear Agile path-definitely makes a difference.”

Walter Bauer, CTO, censhare

case-study-box-censhareOur latest case study from censhare shows the value of getting management on board from the start. Based in Munich, the international software firm was not new to Agile principles, however, their experience was limited to local interpretations of Scrum. That approach worked to an extent when the company was small, but not as it reached 150 employees.

CTO Walter Bauer explored SAFe initially by attending Leading SAFe® training. Soon after, he decided to bring SAFe to the company to solidify Agile across the organization and prepare it for future growth.

With the support of Scaled Agile partner, Improuv, censhare followed the concept of ‘train everyone, then launch a release train.’  They started with a one-day workshop for executive management, then trained the Scrum Masters, and followed that with SAFe Product Manager/Product Owner certification for product management.

Before the first PI planning event, Improuv organized a training session that actually simulated the PI activities—a key to the eventual success of the first planning sessions.

After a successful rollout, the CTO points to a number of positive outcomes resulting from SAFe:

• Release of a new product version
• Greater alignment and transparency
• A common vision
• More team spirit and empowerment
• Enhanced employee satisfaction and hiring

In fact, Bauer reports that having SAFe even aids in hiring new developers.

Check out the full case study here.

Many thanks to Walter Bauer of censhare AG and Stuart Fish of Improuv for sharing their Agile story.

Stay SAFe,

Categories: Blogs

Change Artist Super Powers: Observation

Esther Derby - Wed, 03/01/2017 - 21:13

When I was a kid, there was a party game called Pin the Tail on the Donkey. The game involved a large wall poster of a sad-looking, tailless donkey. Armed with a replacement tail and a pin, each child attempted to give the donkey a new tail—while blind-folded and a bit dizzy from being spun around by the parent hosting the party. (I know, it sounds awful.) Obviously, the chance of an accurate placement was quite small.

Without the ability to observe what is happening, any attempts to improve a situation in your organization may be similarly misplaced. Or you may succeed—purely by chance. When you hone your ability to observe, you stand a much better chance of choosing an appropriate action. My ability to observe is my second Change Artist Super Power.

A manager called me concerned that people on his team were too timid, and could benefit from assertiveness training. I observed several meetings where the manager did 80% of the talking. When someone did get a word in, the manager interrupted. When I shared my observation, the manager was shocked and chagrined. He changed his behavior, and discovered his team had a lot to say. He also realized that his first idea for a fix was misplaced.

At another client, I observed that data about system outages was presented as monthly outage minutes in pie chart form. People knew which system was the biggest culprit in the past month, but had no idea about trends or impacts. I dug into the data and created charts that showed outage minutes over time, and how many people were affected by when a give application went down. Seeing this information in a different form allowed them to address the biggest issues, rather than pointing the roving finger of blame based on a monthly snap shot.

In both these cases, observation was key choosing appropriate action.

Observing sounds simple. In fact, it is hard work and requires practice and skill. You can practice any time, by choosing just one thing, and consciously noticing that for a short period of time. However, sharing your observations can be tricky, especially if you are an outsider and have not been invited to observe. Any time you are observing, it is imperative that you share only what you have seen and heard in neutral language. Stay away from judgement and interpretation.

What might you observe to increase your ability to solve problems?  What might you gain by having a fresh set of eyes observe your organization?

© Esther for esther derby associates, inc., 2017. | Permalink | No comment | Add to
Post tags:

Feed enhanced by Better Feed from Ozh

Categories: Blogs

Agile Alliance Board 2017 Officers Elected

Scrum Expert - Wed, 03/01/2017 - 19:18
The Agile Alliance has announced that the Agile Alliance Board of Directors has elected officers for the 2017 term. The board — comprised of Agile thought leaders from a variety of backgrounds and...

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

Lisa Hershman Will Serve a Interim CEO of the Scrum Alliance

Scrum Expert - Wed, 03/01/2017 - 18:24
The Scrum Alliance has announced that Lisa Hershman will serve as interim CEO. Hershman joined the Scrum Alliance Board of Directors in 2015 and will step away from her newly elected position as...

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

Knowledge Sharing

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