Skip to content

Feed aggregator

The Risks of Anonymous Feedback

Esther Derby - Wed, 05/10/2017 - 21:45

In one of the online forums I participate in, someone declared that feedback between peers must be anonymous. His rationale was that people won’t be honest without anonymity.

I have found that it is possible to be honest and not anonymous. 

I’ve also found that anonymous feedback backfires in number of ways:

People veer into judgement rather than information when they hide behind anonymity.  That’s seldom helpful.  An anonymous zinger doesn’t help. Nor does a value statement such as,  “you don’t pull your weight” or “you’re stingy with information.”

Unless feedback is very specific,  the receiver may not recognize (or even  remember) what the feedback giver refers to.  With anonymous feedback, there’s no way to follow up and ask for examples, understand impact, negotiate a better way to work together, or make amends, if that’s what is called for.

It is fairly normal for people to try to guess who gave a particular bit of anonymous feedback, especially if the feedback is critical, judgmental, or conflicts with the receiver’s self-perception. People often guess wrong, and that distorts and damages relationships.

The practice of anonymous feedback erodes trust in the group.  A feedback receiver may wonder, “If he had a problem with me, why didn’t he tell me…”  People become more cautious, engage in more protective behavior, and hide mistakes or issues.

Honest, congruent person-to-person feedback requires thought and skill. But it is worth the effort. and contributes to a more resilient, and humane culture.

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

Feed enhanced by Better Feed from Ozh

Categories: Blogs

Never Use The :latest Image From Docker Hub

Derick Bailey - new ThoughtStream - Wed, 05/10/2017 - 17:43

It’s tempting to use the “:latest” tag of an image when you first get started with Docker and pulling images from DockerHub. After all, who wouldn’t want the latest and greatest version of MongoDB, Node.js, Redis, etc, when they start a project?

But this is a guaranteed way to ruin your life, destroy your productivity and rip your fancy new hair style to shreds, as you sit at your desk, pulling your hair out while stressing over why your project doesn’t run in your Docker container, a few weeks later.


Ok, it may not ruin your life, but it can certainly cause you to waste hours of it trying to figure out problems.

For example, a while back I was talking with a WatchMeCode member. After watching my Docker episode on running MongoDB in a Docker container, he made the jump.

He followed the instructions I provided in that screencast, set up the appropriate host mounted volume, and ran the container with all the right settings.

And none of his existing data showed up in the container.

After what felt like hours of running around in circles, he reached out and asked me if I had ever seen any issues like this. It took us a long time to figure out what the problem was…

His locally installed version of MongoDB was fairly old. It used an older file system driver, and created files that were not immediately supported by the newer version of MongoDB he was using in his Docker container.

It turned out he was using the latest MongoDB from Dockerhub, without thinking about upgrade issues like this.

In the end the solution was simple – specify the same, old version of MongoDB that he had installed directly on his laptop previously. Once he did this, the Docker container picked up the data file and everything worked fine.

This is only one example of upgrade blues, though.

I’ve had other experiences with upgrading Node.js versions and modules and libraries being incompatible with the newer version of Node.

If I were to specify the latest version of the Node image from Dockerhub, then I would be opening myself to the risk of running into this problem again.

At some point, the code I’m writing today will have an issue with a newer version of Node. It may not happen tomorrow, but it will happen.

It’s just too risky to use the :latest tag for a Docker image, unless you are in control of that image.

So save yourself the headache, and specify the right version of the right image for your Docker projects.

The post Never Use The :latest Image From Docker Hub appeared first on

Categories: Blogs

Examining the Product Owner Role

Scrum Expert - Wed, 05/10/2017 - 17:20
As with everything else related to agile, the nature of the Product Owner role, and whether it is needed or all, depends a great deal on context. As teams discover this, it leads to some common...

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

Accelerate Products Development at SonarSource

Sonar - Wed, 05/10/2017 - 16:53

We founded SonarSource 8 years ago with a dream to one day provide every developer the ability to measure the code quality of his projects. And we had a motto for this: “Democratize access to code quality tooling”. To make this dream come true we invested all our time and energy into developing the SonarQube platform, hiring a great team and building an open source business model to sustain the company growth and keep our freedom. We have also invested a lot in the relationship with our community; giving a lot and also getting back a lot.

Thanks to this approach, here are some examples of what we were able to deliver in the last few years:

  • on-the-fly Feedback in the IDE with SonarLint
  • analysis of 18 languages
  • deep analysis to cover the reliability and security domains
  • high availability and multi-tenancy of the platform to soon launch

After 8 years of effort, we believe we have built great products along with an awesome 60-person company, a solid business and a great brand. We are very proud of these, but we do not think our dream has come true yet. Why? Because Continuous Code Quality still isn’t a commodity the way SCM, Continuous Integration, and artifacts management are: every developer should benefit from the power of a path-sensitive, context-sensitive data flow analysis engine to detect the nastiest bugs and subtlest security vulnerabilities. should be a no-brainer for anyone who uses, VSTS, Travis CI… In other words, everyone writing code should want to benefit from the best analyzers to make sure each line produced is secure, reliable and maintainable.

To take up this challenge, we have made a choice to partner with Insight Venture Partners, one of the very best VCs in our domain. By leveraging their experience, we strongly believe we will be making our dream come true… way sooner than another 8 years!

Simon, Freddy & Olivier
The SonarSource Founders

Categories: Open Source

Cost of Delay. What Does It Mean?

Leading Agile - Mike Cottmeyer - Wed, 05/10/2017 - 14:29

Oftentimes when I ask Product Owners how they choose which projects their teams focus on first, they don’t have a technique for prioritization.  Cost of Delay is a concept that a lot of organizations are using and that has gained traction over the years. Unfortunately, many people are still struggling with the concept of Cost of Delay, so I want to put it down in laymen’s terms here in this blog.  Ultimately, the Cost of Delay is a concept that helps you decide—if you have two or more efforts—which order to perform them.

“Cost of Delay” in layman’s terms is the Cost of Delay“Well “Duh” you say … doesn’t really help to define the term using the term itself!  Thanks a lot!” You’re absolutely right, so let’s look at it from a pragmatic vantage point. The cost of delay can mean the loss or deferment of a benefit/value due to the delay and/or incursion of some sort of penalty.

For example:  we have all experienced the “cost of delay” getting out of the house late to go to work.  In Atlanta, a 15-minute delay getting out of the house could result in a 30-minute commute becoming an over-hour nightmare.  Couple being late with the “penalty” implications of missing an important meeting, and you can clearly visualize the “cost of delay”.

In business, we do projects to accrue some expected benefit from the result of that work.  Delay the realization of that project by a quarter, and you’ve incurred a “Cost” of a quarter’s worth of that benefit this fiscal year.

project value over time

Miss an expected market window of opportunity, and the Cost of Delay will include an even greater penalty.

project missed the market window will equal greater cost of delay

In Principles of Product Development Flow, Don Reinertsen speaks extensively about Cost of Delay.   He leverages a model that visualizes projects as rectangles with their vertical axis as the Cost of Delay and their horizontal as the time it takes to implement them.

Leveraging this model enables us to determine which order to do the projects to minimize Cost of Delay.  We can visualize this by plotting the projects on a waterfall diagram as shown below:

minimize cost of delay by accelerating projects early

The first project incurs zero Cost of Delay, because it was begun immediately.  The second project’s Cost of Delay can be visualized as it waits to begin.  Likewise, the third project’s Cost of Delay can be envisioned as it waits for the others to complete.

Therefore, doing the projects in the order on the left diagram incurs less cumulative Cost of Delay than the order indicated on the right diagram.

You don’t want to prioritize your projects to start slowly and accelerate at the end. You want them to ramp up early and taper off to minimize the Cost of Delay.

see your ROI sooner by implementing cost of delay to your project

Think of this in a different way …  What if we plotted value (above) rather than Cost of Delay.  Wouldn’t you rather have 83% of your money in the bank halfway through the time-period vice only 12.5%?

One thing to keep in mind while prioritizing projects is: overall value is not just money.  Nor is all cost paid in dollars.  Certainly, you’re looking for return on investment; however, you also need to consider what will happen to your market share, customer loyalty, and brand integrity as you make tradeoffs to meet or delay deadlines. For example, if you choose to delay a project and your biggest competitor releases their version of your product, what will that do to your market share?  On the flip side, what if you rush to market and release buggy software? How will that impact customer loyalty and, perhaps, overall sales? Will it detract from your brand integrity? These nuances should be saved for another blog post, but I’d be remiss if I didn’t mention some of the less obvious, but ultimately tangible, costs associated with delay.

Remember, too, that the value placed on projects is an expected or anticipated value.  Companies do projects with the hypothesis that they will result in a certain benefit.  What if that hypothesis is incorrect?  Wouldn’t you rather have more time to adjust (so you can hit the overall goal) than less time?!?  How many times have you or your executives bemoaned “I wish we’d known that sooner!!!”   There is certainly a “cost” associated with late feedback!

I hope that this overview of the Cost of Delay is helpful.  For far greater detail, please read Don Reinertsen’s book The Principles of Product Development Flow in which he goes to extensive lengths to describe the Cost of Delay.

The post Cost of Delay. What Does It Mean? appeared first on LeadingAgile.

Categories: Blogs

Agile Fluency Model Overview Video

James Shore - Wed, 05/10/2017 - 10:02
10 May 2017 James Shore/In-the-News

The Agile Fluency™ Project has put out a new video overview of the Agile Fluency Model. Diana Larsen provided the words and I did the animation. It's on YouTube, so it's easy to share with others and use in your presentations.

I'm particularly proud of how this one came out. Here's the direct link.

Categories: Blogs

ScrumMaster Toolbox Podcast on Agile Fluency Model

James Shore - Wed, 05/10/2017 - 10:01
10 May 2017 James Shore/In-the-News

Diana Larsen and I were interviewed on the Scrum Master Toolbox Podcast earlier this year. We shared our latest thoughts on the Agile Fluency™ Model, including why it's different from a maturity model (and where the idea of "maturity" might fit into the model), our "bus zone" metaphor, and how to use it in your work.

Listen to it here.

Categories: Blogs

The Global Network of SAFe Fellows Grows by Four

Agile Product Owner - Tue, 05/09/2017 - 18:31

Our mission at Scaled Agile is to help enterprises achieve better business outcomes through adoption of Lean-Agile principles and practices based on SAFe. Since launching the Framework in 2011, a key aspect of our enablement strategy has been to equip change agents through SAFe Program Consultant (SPC) training and certification.

While support from SPCs is critical to implementation success, there are pivotal moments in many significant Lean-Agile transformations when the organization needs guidance from the ‘best of the best.’ In the early days of SAFe, this often meant calling in Dean and the Framework team. However, just as SAFe is focused on enabling excellence in scaling Agile, the pace at which it has become the industry standard has driven the need to ‘scale’ the pool of experts who are equipped to provide guidance for the most complex and challenging of implementations.

To that end, we grew the Scaled Agile Partner program, and in 2014 introduced the SPCT (SAFe Program Consultant Trainer) program to provide a means of recognizing individuals who demonstrate superior knowledge, competency, and in-depth field experience in SAFe. While this enabled one aspect of scaling, it didn’t fully accommodate the growing demand from enterprises needing support for the most challenging rollouts.

The SAFe Fellow Program

That’s where the SAFe Fellow program comes in. Established in 2015, the program recognizes a select number of individuals with both the depth and breadth of experience to work at the highest levels of complexity in enterprise strategy, and who have established themselves as thought leaders in the Lean-Agile space.

The program is different from other certification achievements offered by Scaled Agile. It goes beyond the 1–3 year qualification process required for SPCTs and identifies individuals with the highest possible level of mastery and thought leadership. ‘SAFe Fellow’ is a designation rather than certification, and requires years of practice and contribution. Prospective SAFe Fellows must be nominated by two existing Fellows, reviewed by all existing SAFe Fellows, and then finalized by the Nomination Committee. It is a multi-year journey.

The SAFe Fellow program represents the ultimate achievement for those looking to advance Lean-Agile methods at enterprise scale with SAFe. If we are in challenging situation—whether puzzling over the next generation framework, or struggling to optimize a SAFe implementation—the Fellows are the folks we turn to.”

—Dean Leffingwell, creator of SAFe, Chief Methdologist

After recognizing five of Scaled Agile’s most experienced experts as SAFe Fellows, we commenced a two-year search to identify the ‘best of the best’ in the field. Today, we’re delighted to welcome four new Fellows to the fold. Each has been hand-picked based on a combination of their ongoing contribution to the evolution of the Framework, their demonstrated success in a broad-range of implementations, and their willingness to share their expertise in the public arena through both writing and speaking.

Introducing Four New SAFe Fellows

We congratulate the following outstanding individuals:

Mark Richards, Context Matters

Mark Richards has been involved with SAFe since its inception, with a demonstrated commitment to remaining on the leading edge of the ART. Part of the first group of SPCs to be certified in 2012, he went on to coach Australia’s first SAFe implementation at Telstra and later became one of the first SPCTs. He has enabled successful implementations across the federal government, telecommunications, finance, insurance and education industries. Mark has also worked with a number of Tier 1 Systems Integrators as they respond to the changing needs of their customers implementing SAFe. A prolific blogger (The Art of SAFe), Mark is also the developer of the widely used SAFe City simulation and has contributed to a number of areas of the Framework, most recently in the areas of metrics for SAFe 4.5 and the ART Canvas in the Implementation Roadmap.

Em Campbell-Pretty, Context Matters

Em’s passion for business outcomes inspired her to launch Australia’s first Agile Release Train in early 2012. Since then, she has led transformations for public and private companies like RMIT University, Westpac, the Australian Taxation Office and ANZ. Her work has influenced the development of the Program Kanban System and fueled case studies. She’s an international keynote speaker, an avid blogger——and author of the book, Tribal Unity.

Eric Willeke, CA Technologies

Eric has worked with a broad range of Fortune 500 companies, thousands of practitioners, and key leaders in the technology, media, insurance, financial services, and healthcare industries. His personal vision—to “help everybody on a project sleep better at night”—has shaped his passion for continuous improvement and unlocking human potential. Eric speaks at conferences around the world, has contributed to the Framework and SAFe case studies, has served on the program committee for the Agile 201x conference series, and was the lead editor for the Proceedings of the LSSC conference series.

Harry Koehnemann, 321 Gang

Harry is Director of Technology for 321 Gang where he helps organizations in aerospace, defense, automotive, and medical adopt Lean-Agile methods and SAFe. He played a key role in the development of SAFe 4.0 for application to Lean systems engineering. More recently, Harry has worked with Scaled Agile on toolkits and white papers to provide practitioners with guidance on hardware and compliance concerns when adopting SAFe.

Learn more about the SAFe Fellows program here, including a full list of SAFe Fellows.

Welcome Em, Harry, Eric, and Mark to the global network of SAFe Fellows!

Stay SAFe!
—Drew Jemilo
Co-founder, Scaled Agile, Inc.
SAFe Fellow Program Director



Categories: Blogs

Visual Project Management: Past and Future

TargetProcess - Edge of Chaos Blog - Tue, 05/09/2017 - 17:33

No matter what kind of project you’re managing, there’s a direct, causal relationship between process and outcome. In other words, it’s not just what you’re working on that matters but how you work on it.

Traditionally, the project management discipline has prized control and long-term forecasting over the particulars of work in progress. But considering 46 percent of all projects still fail to meet their original goals and intent, there’s a growing demand for real-time visibility into the movement of tasks and resources.

Visual project management is a new approach (and new technology) designed to address some of these challenges. By embracing it, teams and organizations can complete projects of any type with greater speed and efficiency.  

What is Visual Project Management?

For the most part, visual PM is exactly what it sounds like: a project management strategy designed to increase success through visualization of project components, such as data and tasks.  Mark Woeppel, the author of Visual Project Management, describes it like this:

“Visual Project Management is a process that uses visualization of the delivery process to drive team behaviors.”

Visual features can be a valuable asset for any project style, but they’re most commonly associated with agile methods such as Scrum and Kanban. In some ways, visual PM takes its cue from the good old-fashioned whiteboard. The whiteboard has served as a roadmap, progress tracker, and collaboration tool for all kinds of development teams.

But the history of visual PM is much older than the whiteboard.

The oldest roots date back to 1896, when Polish economist Karol Adamiecki created the “harmonogram” — a floating bar chart used to show tasks or resources changing across time. Not long after, in 1912, the famous Gantt Chart was born — used first to build ships during WWI and later to construct the Hoover Dam.

Adamiecki’s “harmonogram.”

Adamiecki’s “harmonogram.”

Michael Dubakov, Founder and CEO of Targetprocess, says that visual PM started to crystalize around 2010 with the popularity of the Kanban approach. “One of the Kanban principles is to visualize workflow in order to better understand what is going on and what can be improved.”

Modern visual project management software is much more advanced, but its purpose is the same: to provide greater flexibility and improved outcomes through visibility into bottlenecks, tasks interdependencies, progress, and priorities. “In the recent 5 years we have seen a spread of visual tools like Kanban boards, timelines, and integrated BI systems with powerful reporting,” says Dubakov. In all kinds of industries (especially the IT world)  visual project management is now helping teams stay in sync and respond to changing requirements.

In terms of actual methodology, many of the visual tools that have proven useful combine the best aspects of Kanban and lean production with the Scrum foundation that dev teams are used to. Some users have taken to calling this style “Scrum-ban.”

Common visual features include:

  • Real-time dashboards
  • Timelines
  • Graphic reports (Gantt, burndown, etc.)
  • Boards (Kanban)
  • Product Roadmaps
The Changing Landscape

When fully embraced, visual project management can bring some dramatic improvements to the way teams collaborate and work. As modern software continues to evolve, more teams will adopt visual tools to improve their development lifecycles, over time raising the benchmark for an efficient project delivery process.  

Let’s take a look at some of the specific ways visual tools can impact the future of project management. As your organization plans products and strategies for this  year, try to pull some of these ideas into the conversation.

The Ability to Isolate Problem Areas Faster

As your teams work through various projects, there will inevitably be obstacles — things that slow the movement of tasks, stories, or feature requests during a sprint. Without the necessary visibility, it’s difficult for a project manager to troubleshoot delays or recurring problems.

A visual project management solution can make spotting and solving these “blockers” much easier.  You get a real-time picture of where each component of a project rests, so you can quickly identify bottlenecks and trace issues to their source. For example, let’s say you notice that user stories are repeatedly getting “stuck” in the testing phase or re-entering a later sprint due to unsatisfactory completion. By visualizing the workflow, you can isolate the root cause and then communicate with the relevant team members to initiate change.

Better Resource Planning and Allocation

Resource and requirements planning is one of the most crucial components of any project: get it wrong, and you’ll have a project that gets delivered both late and over budget. There’s a little more leeway with agile projects (since work is done in short iterations), but decision-makers still need to stay responsive to changing requirements and be able to shift priorities or reassign team members when necessary.

Feature Planning By Teams

The speed of change  demands fast resource management. The right visual tools can help you tighten your development lifecycle by maximizing your use of resources—both in the planning phase and in continued optimization during the project. A visual resource planning feature, for example, shows where your team members are assigned and what tasks they’re working on. You can also drill down to assess individual skill sets and schedule availability.

More Projects Completed On-Time

One of the first principles of the Agile Manifesto is “. . . early and continuous delivery.” If your goals are built around this principle, it’s important to remove every possible impediment and give developers maximum visibility. Without the right tools, project information gets siloed into email threads, chat conversations, and spreadsheets, and team members have a hard time remembering who’s working on what. Ultimately, this leads to redundant efforts and a longer cycle time.  

Visual PM can speed progress by conveying real-time project information in a way that is easier to access, understand, and share. It also makes it easier for team leaders to track work in progress and remove impediments before they delay the product. A Kanban board — which uses “cards” to move tasks through different stages of the project — is a perfect example of visual workflow optimization.

Personal Kanban Board

The Spread of Project Management Solutions

Finally, the growing popularity of visual features means that project management software itself will become easier to implement and easier to use for all team members. Even smaller companies with limited experience can set up a cloud-based visual PM solution in less than a day. That means small, agile teams can become even more agile without the overhead of a consulting service or an expensive, time-consuming implementation.

With agility at a maximum, project teams can improve the customer experience by running faster iterations with fewer bugs. Thus, visual PM tools create a more sustainable, scalable development model.

There is, of course, room to grow. Dubakov points to a general lack of research in the visual PM field. “To my knowledge, there are no people who understand both domains well enough in order to lead the visual management movement,” he says. In the coming years, we can hope to see additional research and innovation in some of the following areas:

  • Using visual PM tools to aid decision-making
  • Different visual approaches for different sub-domains
  • Visualizations for planning, capacity management, tracking, and forecasting
  • Process management and problem resolution
  • Closer integration between visual PM and business intelligence tools


Visual project management isn’t some radical new approach that turns the discipline upside down. It’s just a set of tools and techniques that reinforce what we already know: people work and manage projects more efficiently when they’re “in the loop,” and when they have a clear picture of how project components move and interconnect.  The best way to represent and share this information in real time is not with a list, or a spreadsheet, or a series of emails, but with a visual.  

Aleks Peterson is the content manager at TechnologyAdvice, a B2B research firm that connects buyers and sellers of business technology.

Categories: Companies

At the Intersection of Agile and Change Management

BigVisible Solutions :: An Agile Company - Tue, 05/09/2017 - 17:00

Email Monday, training Tuesday, change Wednesday–that’s how quickly some people think change happens. But organizational change is ultimately a human process, regardless of whether the enterprise is experiencing the change or the individuals that comprise it. The change management industry has been focused on making change more “sticky” and that’s why SolutionsIQ is excited to be participating at Change Management 2017 this year — to further our sharing of knowledge in both directions.

In our Agile Amped podcast, “CIO Tim Creasey at the Intersection of Agile and Change Management,” Tim points out that change management aims to “prepare, equip and support people to be successful in the changes” requested of them, and that process needs to time to take effect. Tim shares his thoughts of how companies who undergo an enterprise-wide change like an Agile transformation fail to invest adequately in the change management aspects. And then, if the company is successful in transforming to Agile, they don’t know how to deal with the pace of change. A clear example of this is the stark difference between the rate of change in customer-facing technologies and internal technologies implemented by a company’s IT department. Tim also shows how a change model like ADKAR can work in a Scrum environment.

Dan Fuller: Hello everyone and thanks again for joining us for another Agile Amped podcast. This is your all-access pass to the latest and greatest Agile content from industry thought leaders at events across the country. We’re here this week at the Gaylord Texan resort in Dallas talking to people at the Change Management conference. So, I’m here today with Tim Creasey. He’s the chief innovation officer from an organization named Prosci. So, thanks for joining us again, Tim.

Tim Creasey: Thanks for having me.

DF: Today we’re going to talk about two topics that we believe are kind of the intersection between Agile and change management. The first topic, which you and I have talked about a little bit already, in our experience a lot of organizations are going through what we call an Agile transformation. So, this is a radical way of transforming the way that they partner with the business to create software. What we have found is that a lot of organizations under-invest in traditional change management practices that have been tried and true in helping organizations deal with large-scale change. What’s been your experience in that so far, Tim?

TC: Yeah, I think there’s an exciting transformation happening in terms of organizations really getting smarter around how they’re bringing about change, and I think Agile along with a number of the other improvement approaches we’re seeing out there are a part of that. Now change management, and we kind of define it — I’ll give you a definition so we have kind of that context. It’s “How do I prepare equip and support people to be successful in the changes that I’m asking them to make?” What I’m finding is that when an organization tries to bring Agile to life, there is the change to Agile — so, “how do we actually move from a waterfall mindset and toolset to a more Agile iterative approach?” And then there’s “how do we manage the people side of change inside of an Agile rollout?” A lot of times we missed that first one. I use the notion of we send an email on Monday for training on Tuesday that we’re going to be an Agile shop on Wednesday. And that’s just not the way to prepare and equip and support people to be effective in this new interactive, iterative sort of approach to bringing change to life. So, I’d absolutely agree that if we don’t make that first move, then all of the rest of the waves become much more challenging because we haven’t primed the organization to be ready to be successful in an Agile environment.

DF: We’ve had similar experiences. We’ve noticed that a lot of organizations think it’s as simple as “Let’s just train everybody in Scrum.” And although that’s an important part of a change management approach for an Agile transformation, we found that we also need to make sure that we’re working with leadership to change leadership behavior, we need to make sure that we’re addressing fundamental reward structures that will encourage behavior, we need to make sure there’s a communication plan that communicates what we’re changing, why we’re changing, and making sure that the organization has a clear vision that the organization is aligned to. And what we’ve also found is that we need to use some tried-and-true change management frameworks and techniques. You know, ADKAR’s one that we often use with our clients. But under-investing in those types of aspects of organization change for an Agile transformation, what we found is it runs the risk of it not being sticky. You know, we get some short-term success but then people revert back to the way they used to do things.

TC: There’s been so many cases of “this too shall pass.” You know, Agile potentially being viewed as the next fad. “If I just wait it out, this will go back to the way we used to do things.” And that happens when we don’t get leaders engaged, when we don’t communicate why, when we don’t connect it to real business outcomes and results. I think you’re right: there’s some good solid change management that will help us set the tone, so that being Agile is more likely to be successful.

DF: Okay, great. So, if we use a little bit better change management practices and actually invest in that, we’re more likely to actually get to the point where we’ve now become an Agile organization. Now we’re at that point that we wanted to get to, where we’re now delivering shorter cycles, creating value quicker and getting that value up to the market or to our end-users faster. Now what?

TC: Yeah, and I think the interesting thing here is, we’d call this Reinforcement at the end of the ADKAR model, it’s phase 3 in our organizational change management process — and it’s because, you know, it is our natural and psychological and physiological tendency to go back to what we used to know how to do. Fascinating research that it takes the brain more glucose to process things in a new way than an old way, which means it literally hurts your brain to do something different. And so, if we are not intentional and thoughtful around those sustainment mechanisms, I think we run the risk of being left with the toolset of Agile without the mindset shift that we need.


DF: Yes.

TC: And that’s, you know, celebrating successes, a job well done, senior leaders saying, “This is the impact we were able to derive because where we ended up.” Metrics and measurement is huge to be able to show feedback into the organization that loop that comes back and says, “This made a difference…”

DF: Yes.

TC: “…when we made this change.” And I don’t think it has to be grandiose. It can very much be a walking down the hall and just saying, “That was awesome when you guys stepped up and went the extra mile so that we could shorten that down to two weeks, because I know it was hard on you.”

DF: Yes.

TC: That goes a long way to help human being stay in that new way of doing things.

DF: Yep. Now, the second area where we’ve observed organizations don’t really think through, in terms of change management when we’re trying to adopt Agile: we’ve now successfully done an Agile transformation and our teams are now delivering a rapid amount of change to the organization or to our end-user customers. What types of change management practices do we need to do differently in order to actually deal with that constant rate of change that we’re now creating?

TC: Yeah, I think this is — and I’ve been doing some work here. Because that first shift was that move to Agile, while the other has moved inside of Agile to the change management approach. So, what we’re working with clients to do right now is to say, let’s take ADKAR as an example: Awareness, Desire, Knowledge, Ability, Reinforcement. That’s our individual change model. There’s project-level and Scrum-level exercises. And so we would say building Awareness and Desire for the need for change, awareness of the need, desire to participate and support — tends to happen at the project level. And that’s really around priming the system. Knowledge and Ability become very focused on each Scrum, and then with a little bit of Reinforcement and then we get Reinforcement back at the end release. So, we’ve taken ADKAR and started to split it out across, you know, up to the project itself and down to the Scrum. We’ve done the same thing with the five change management plans that Prosci uses. So, the communication plan: we’ll have a project level and we’ll have Scrum level. Training plan tends to primarily be a Scrum-level activity. Resistance management tends to go both ways. Sponsorship tends to be a project-level with a little bit of Reinforcement at each Scrum. And then coaching tends to happen across the board. And so, I just think it’s being a little bit more thoughtful about the toolset we have, and saying, “How does it look a little bit different?” And I’ll tend to draw this on a flip chart and say, “What goes to the project level, what goes to the Scrum level? And let’s start to split out the work we’re going to do around change management.”

DF: Ok, well, that’s interesting. I think you and I both have an agreement there that there’s a lot of synergy between what the Agile community needs in terms of change management, and what the change management community can provide in terms of thoughtful solutions for how we can get there.

TC: Well, yeah, absolutely. I think that’s, I mean, this is where success lies — is when we can help Andy and Becky and Charlie and Debbie be successful in their job and in the changes we’re asking them to make. A lot of times it’s around establishing that expectation with the end-user base or the customer base that things are going to be coming in at a much more rapid pace. Now, I do think things like this (referring to smart phone) have changed the expectation, right? Because if an app breaks, now I expect to get a feed in two days of the updated app that’s not going to crash on me. That’s created an interesting expectation with inside business, because now inside business, I expect things to be served up like they are to my phone when they’re not working.

DF: Yeah.

TC: That can be hard for an IT shop. Because if they’ve not started to embrace Agile, this could be three to six months for us to finally get our acts together to make that one fix that everyone’s now expecting to happen like that. Because customer technology is updating in a much more rapid pace than a lot of times IT.

DF: Yeah, I couldn’t agree more.

TC: And I think it comes down to that smart phone in my pocket.

DF: Yeah. All right well thanks again for your time Tim. We’ve really enjoyed talking to you at the change management conference. So, thanks for joining us for another Agile Amped podcast. Subscribe now to receive real-time updates of future episodes. We’ll be at other events across the country, so look for us there. You can find our podcast available on YouTube, ITunes, or the website.


The post At the Intersection of Agile and Change Management appeared first on SolutionsIQ.

Categories: Companies

Why microservices fail

Xebia Blog - Tue, 05/09/2017 - 09:14

Gianna has joined Avidoo Inc., a productivity platform, as a senior software engineer. In a kick-off meeting with the rest of her team, she brings up the subject of microservices and whether the team has adopted them in any way. She immediately gets a strong reaction. “We have tried adopting microservices, but they don’t work”, […]

The post Why microservices fail appeared first on Xebia Blog.

Categories: Companies

The Agnostic Agile Oath

Scrum Expert - Mon, 05/08/2017 - 17:25
The Agnostic Agile Oath is a movement that aims at recognizing the importance of being agnostic with agility at any level. As it is stated on the web site: “one size does not fit all, one...

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

Agile on the Beach Sold Out for 4th Year Running!

Scrum Expert - Mon, 05/08/2017 - 16:18
Hundreds of global tech gurus will be landing in Cornwall this July as the annual Agile on the Beach conference held in Falmouth sells out for its fourth consecutive year. Organisers of the seventh...

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

Test-First for Quality

NetObjectives - Sun, 05/07/2017 - 22:18
Quality is a pretty open ended term.  Test-first is often thought of as implementation and verification – is the code being written of high quality?.  But there is also quality to the customer – is the right thing being built?   There is also the quality of the culture of the organization developing the software – is collaboration present?  And finally, the quality of the process being used – is...

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

Getting Business Into The Agile Mindset

NetObjectives - Sun, 05/07/2017 - 09:37
I was recently asked “Any recommendations on a book for how a middle manager can drag a business into an Agile mind set against their will?”  The answer is – “you can’t drag business into an Agile mind set against their will.”  In fact, you really can’t drag anyone into an Agile mindset against their will.  I also find it ironic that I hear Agile coaches ask me a similar question, “Any...

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

The Lasso of Truth

Agile Complexification Inverter - Sat, 05/06/2017 - 00:04
Truth is a wonderful concept - but can we really know it?

I'm very excited about the 2017 release of a Wonder Woman movie.  Can't wait - it looks great, I always love the first in a series.  I like the character development, the WHY of the foundational aspects of the character.  From the preview it looks like we will see Princess Diana of Themyscira grow up and the reasons she finds her self in America.  Fascinating...

I learned a bit about the truth of the back story of the back story of ... well the history of the creator of the Wonder Woman myth in of all places... a training course on DiSC by Dr. Abelson.  [Queue the spooky dream sequence music.]

The inventor of the Wonder Woman myth is William Moulton Marston. Wonder Woman made her debut in All Star Comics #8 (December 1941), scripted by Marston.  If you have one in the garage I'll buy it from you.  Apparently, Marston designed Wonder Woman as an allegory for the true leader; the kind of women who should run society.

"Wonder Woman is psychological propaganda for the new type of woman who should, I believe, rule the world."
Marston [6]
In the World War I years (1917),  [at that time they didn't use the ONE designation for some reason - guess they didn't plan on rev-ing the concept, how silly not to thing that humans would improve the concept of World War] Marston was interested in discovering physiological evidence of a person as they deceive - he's though of as one of the father's of the modern lie detector (Polygraph).  When he created his leader epitome, he gave her the power to discern truth via the Lasso of Truth.

Wonder Woman's physical appearance and her bullet bending bracelets were inspired by Olive Byrne, Marston's lover in an open relationship with he and his wife, Elisabeth.

Going back a bit deeper from the Wonder Woman idealized leader, Marston investigated normal people and their emotions. In the late 1920s he developed a theory of human behavior based upon two aspects, environment and reaction to the environment.  This theory produced the classic quadrant model and is known as the DISC Theory which was refined by in 1956 by Walter Clarke into the DISC assessment model.
"Marston viewed people behaving along two axes, with their attention being either passive or active; depending on the individual's perception of his or her environment as either favorable or antagonistic. By placing the axes at right angles, four quadrants form with each describing a behavioral pattern:
  • Dominance produces activity in an antagonistic environment
  • Inducement produces activity in a favorable environment
  • Submission produces passivity in a favorable environment
  • Compliance produces passivity in an antagonistic environment.

Marston posited that there is a masculine notion of freedom that is inherently anarchic and violent and an opposing feminine notion based on "Love Allure" that leads to an ideal state of submission to loving authority."This DISC theory and model were never trademarked or copyrighted - therefor there are quite a few versions and instances of this tool.  Including wonderfully misleading FaceBook questionnaires that should be view with skepticism.  DISC practiced well by a practitioner can be a very useful tool for self discovery.
David is a "High D" - classic Developer profile
See Also:
Psychometric Assessments - a peek inside the person
Multiple Views of the Truth are Perceptions
The Life of the Mind: Hannah Arendt on Thinking vs. Knowing and the Crucial Difference Between Truth and Meaning Brain Pickings
Categories: Blogs

Live from Agile and Beyond: Agility Infusion 101

Leading Agile - Mike Cottmeyer - Fri, 05/05/2017 - 19:00

Gaining agility is different than “doing agile”, particularly at scale. This session will start with how agility makes a difference for the business and for the teams adopting it. We will look at the business structures that are needed for agility to thrive, how teams are organized and the new measures that will redefine success. With agility, one size does not fit all, but there are proven solutions, and this session will look at success stories as well as the dead-ends every organization wants to avoid.

Agility Infusion 101: Agile & Beyond from LeadingAgile

The post Live from Agile and Beyond: Agility Infusion 101 appeared first on LeadingAgile.

Categories: Blogs

Gain Insights Across the Enterprise with Project Portfolio Management

Learn how LeanKit enables portfolio project management, arming everyone with the information they need to stay focused on delivering customer value.

The post Gain Insights Across the Enterprise with Project Portfolio Management appeared first on Blog | LeanKit.

Categories: Companies

Live from Agile and Beyond: An Executive’s Guide to Leading a Large Scale Agile Transformation.

Leading Agile - Mike Cottmeyer - Fri, 05/05/2017 - 16:00

Edit: Live Stream was swapped out for a recording since the internet connection at the conference was unstable.

Join us as Mike explores the change management and engagement techniques necessary to make sure you are building meaningful organizational support as you engage the enterprise. He’ll discuss how to build and execute a change management strategy to keep everyone safe and informed throughout the transformation, how to sustain and improve the changes over time, ultimately creating an organizational ecosystem where business agility is part of the fundamental DNA of the company. The goal of this talk is to show you how to systematically and planfully introduce agile into your organization.

The Executives Step-by-Step Guide to Leading a Large-Scale Agile Transformation from LeadingAgile

The post Live from Agile and Beyond: An Executive’s Guide to Leading a Large Scale Agile Transformation. appeared first on LeadingAgile.

Categories: Blogs

Knowledge Sharing

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