Skip to content

Feed aggregator

The Diagnosis and Treatment of Bimodal IT

Leading Answers - Mike Griffiths - Thu, 05/26/2016 - 05:35
Is it just me, or does Bimodal IT sound like a mental health condition? Unfortunate name aside, it has been adopted by companies reluctant to embrace agile but looking for a halfway-house / best-of-both-worlds solution. In my last post I... Mike Griffiths
Categories: Blogs

The X-Matrix Strategy Deployment Model

AvailAgility - Karl Scotland - Wed, 05/25/2016 - 23:46

There is a model for Strategy Deployment that sits behind the X-Matrix that is worth explaining in more detail as a way of understanding why it is designed the way it is, and how to use it. It is built around describing four types of elements – which I call results, strategies, outcomes and tactics – and how they fit together.

Before we start, lets get the George Box aphorism out of the way:

All models are wrong; some models are useful

Results represent the organisational impact you want to have. They are lagging indicators, success or failure only being declared at the end of the journey. They usually reflect the nature of the business and its economics.

The Results are implemented by Strategies

Strategies are constraints which guide how you achieve the results. They are enabling, allowing a range of possible solutions (as opposed to governing, limiting to a specific solution). Thus they guide decisions on where to focus attention (and hence also where not to focus attention).

The Strategies lead to Outcomes

Outcomes provide evidence that the strategies are working. They are leading indicators of whether the results can be achieved ahead of time. They describe the capabilities that the organisation requires in order to be successful.

The right Outcomes will generate the successful Results.

Screen Shot 2016-05-25 at 20.47.46

Of course the Strategies don’t directly lead to Outcomes. Some form of action has to take place. Thus the Strategies are actually implemented by Tactics.

Tactics are the activities that take place to implement change. They are experiments which test hypothesis on how to achieve the outcomes. The represent the investments in the improvement work that is being done.

Therefore, it is the Tactics that generate the Outcomes and ultimately lead to the Results.

Screen Shot 2016-05-25 at 20.48.11

For change to be successful, there should be a correlation between the various elements in this model (and it should be remembered that correlation is not causation). Each element will have some level of contribution to another. This will range from strong or direct, to weak or indirect, or there may sometimes be none. You could also say that the correlations are Probable, Possible, or Plausible. All together there should be coherence (albeit messy) to the way all the elements fit together.

Screen Shot 2016-05-25 at 20.48.32

By starting with Results, moving on to Strategies and Outcomes and leaving Tactics until last, there is a greater chance that the Tactics chosen are ones which do implement the Strategies and generate the Outcomes. The intent is to avoid premature convergence or retrospective coherence when identifying the Tactics. It is very easy to hastily jump to the wrong conclusions about what the Tactics should be, and then justify them based on the Strategies.

Even if you don’t use the X-Matrix explicitly, understanding this model can be useful for asking questions about change and improvement.

  • What end results are you hoping to achieve?
  • What are your strategies to deliver them?
  • What intermediate outcomes will show you are on the right path?
  • What tactics are you using to move forward?
  • How do all these pieces fit together?

If you can answer these questions, then you should be able to populate an X-Matrix. I will work through an example in an future post.

X-Matrix Simple

Categories: Blogs

Seven Ps for Profound Change

Esther Derby - Wed, 05/25/2016 - 22:38

Captured from my keynote at Big Apple Scrum Day, May 17, 2016.Seven Ps of Change

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

Feed enhanced by Better Feed from Ozh

Categories: Blogs

Agile Metrics – Measuring What Actually Matters

Agile Management Blog - VersionOne - Wed, 05/25/2016 - 17:21


Do you really know how your agile teams are doing?

As organizations transform to agile and stand-up multiple teams it becomes almost impossible to see how healthy all those teams are in a consistent way. This is an important question not just for leaders, but for the teams themselves to understand the areas where they need to improve. Here’s a typical view of what happens today to answer this question:

  • Every agile coach or ScrumMaster creates their own survey or evaluation of team health and maturity.
  • We leverage excel sheets to analyze the data which could get complicated and take weeks/months to analyze.
  • There is no consistent way of measuring health across many teams.
  • Agile coaches are stretched too thin with no clear way to prioritize which teams need their help the most and which teams can use self-manage.
  • Leaders and executives don’t have overall understanding of the health of the organization and where they can help. We tell them ‘agile is working! We FEEL we’re making big progress’ and then only share hard metrics to prove it.

When we talk about the health of teams, we shouldn’t just focus on the hard metrics and agile processes alone. This can lead to gaming of the data. The metrics that give us ‘predictive’ indicators actually come from the cultural and people side. This is called ‘mode 2’ of the bimodal movement according to Gartner.  Susan Courtney, CIO of BCBS NE, actually shared that “80% of their enterprise agile transformation was about the cultural side and 20% about the agile and process side”.


So… We started a couple of years ago digging deeper into this topic of team and organizational health measurement. Our objectives were simple:

  • Have a holistic measurement of team health that is consistent across all teams so that we can identify common patterns and address them.
  • Engage a team in a fun strategic deep-dive retrospective that gives them immediate value. We’ve learned this needs to be a facilitated conversation that allows them to analyze the results of their assessment in real-time so they can build an actionable growth plan.
  • We wanted the results to appear in ONE engaging visual. We were tired of analyzing several graphs to make sense of the data. Hence the birth of the TeamHealth Radar.
  • This needed to happen on a cadence. Similar to how teams do Release Planning every quarter or every Program Increment (PI) (if you’re using Scaled Agile Framework® or SAFe®), we wanted them to inspect and adapt quarterly and then work the growth items during each spring retrospective. Why? So growth is continuous and measurable.

What does business agility and organization health look like?

Let’s go 5,000 feet above before we start digging into TeamHealth. As we’ve worked with many companies attempting to transform themselves and looked at the common objectives for their transformation, four key pillars started to emerge:



Clarity: “Do we know who we are and why we exist? Do we have agreement on our core values and how we should behave? Do we know what’s the most important thing right now at the team, program, and portfolio levels?”

Focus: “Are we able to stay focused until we get something done or do we continue to run after shining objects?” “Do we allow our teams to finish what they started before adding new ideas to their backlog?”  Most of the lack of focus actually comes from lack of enterprise adoption of agile planning and prioritization at the portfolio level. That’s for a different future blog!

Predictable Execution: “Do we all know how to execute work in a predictable way, whether is Kanban, Scrum, or Lean. Do we have a process for it where we all know what it means to be a product owner, how often do we plan our iterations, and what does velocity means for us?”

Healthy Culture: In the middle of that triangle are the healthy and happy people who enjoy what they are doing. This comes from their leaders shifting from command and control to servant leadership, and their teams learning strong collaboration, facilitation, and teamwork skills.

What We’ve Learned About Team Health

We’ve spent a few years now learning and improving our understanding of what makes an agile team (or any team) healthy through building AgilityHealth. The heart of this discovery has been the TeamHealth Radar below in addition to the format of the facilitated quarterly retrospective. This radar provides ‘qualitative’ measures that are critical to understanding how the team is doing and where they can improve. I’ll tackle including ‘quantitative’ later in future blog.

Download the TeamHealth flashcards to understand what ‘great’ and ‘not so great’ look like for each of the competencies we’ll explore below.



A healthy team should have clarity on their vision and purpose (why they exist) and their measure for success. They should have clarity on their plan; short term, mid-term, and long term. They should have clarity on their roles; what is expected of me individually and what is expected of others on my team? Another critical skill is becoming generalizing specialists. As a team member, am I open to learning new skills beyond my specialty so I can help my team when needed?


Performance is measured in two ways: confidence (the gut-check) and measurements.

Confidence, starting with the product owner, we ask: “As a product owner are you confident and satisfied that this team has the tools, the skills, and the desire to meet your current goals?” We ask the same question to the team members. We also engage the stakeholders outside of the team (users, sponsor, managers, other teams) by asking them for their confidence in the team AND their satisfaction using the NPS popular question ‘How likely are you to recommend working with our team to others?’

Measurement, we’ve gathered the top five drivers for companies adopting agile (see VersionOne State of Agile Report).  These are: predictable velocity, time to market, value delivered, quality, and response to change.


A strong and healthy leadership team has a direct impact on the health of the overall health of an agile team. To assess their health, we focus on these roles: team facilitator (ScrumMaster), product owner, technical lead, and the functional manager of the team. We’ve found interesting relationships emerge. For example, there is a correlation between clarity (as an outcome), and leadership (as an input). This means, as an example, if you want the team to have clarity on vision, plans, and roles, they should have a healthy team facilitator and product owner.

We also believe it is important to assess the functional manager of the team due to the positive or negative influence their leadership can have on the team. We focus on servant leadership, people development, and process improvement. This is important in order to nudge managers to shift their focus on growing individuals, and improving their team process rather than task management and fire fighting.


Probably the most critical aspect of the health of a team is that layer below the surface.   Part of the power of having this will be a facilitated TeamHealth retrospective each quarter, is it provides the team an opportunity to to dig deeper into this layer and open up conversations they usually don’t have during regular iteration retrospectives.

We measure cultural health by having each person rate the following ‘happiness’ statement on a 10-point scale “I enjoy working with this team”.  We then dig into how well the team collaborates, do they trust and respect each other, are they allowed to be creative (and do they actually do it). Finally, do they hold each other accountable or are they still waiting for a boss to do that?


Healthy agile teams have a strong foundation. This is made up of basic principles of agility such as sustainable pace (not burning out), self-organization (empowering the teams to make decisions), technical excellence (which now has its own Technical Health radar), having the proper planning and estimating cadences, and facilitating effective meetings.

The team structure can also have a big impact on health and performance. We assess if the team has the right size and skills, and are they allocated and stable (reduce multi-tasking and pulling people out of the team). Finally is their workspace environment, virtual or co-located, and setup for collaboration?

 Summary and Final Thoughts

As I’ve worked with many companies through their agile transformation it has become clear to me and to the leaders of these organizations that measurement is no longer a nice-to-have, but a must-have.

As you scale agile and stand-up tens or hundreds of agile teams, the visibility and transparency of how they’re doing is imperative to your future success.  Seeing patterns across multiple teams and building much more targeted growth at the team, program, and portfolio/LOB levels takes your transformation to the next level of maturity. I hope you’ll share our vision and passion for leveraging the right set of metrics to enable business agility.


Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

The post Agile Metrics – Measuring What Actually Matters appeared first on The Agile Management Blog.

Categories: Companies

How and when to use a Timeline view (and not a Gantt chart)

TargetProcess - Edge of Chaos Blog - Wed, 05/25/2016 - 16:45

“Let our advance worrying become advance thinking and planning.” – Winston Churchill

Time is an extremely important metric for POs, PMOs, and anyone else managing a team, a project or a portfolio of projects. In Targetprocess, the Timeline view can help you visualize time-related metrics, spot potential delays before they happen, and synchronize projects and teams with important deadlines and company milestones.

For example: want to see if your project will be delivered on time? Or perhaps you need to check which teams will be available to work on a critical project at a certain point in time? Switch to a Timeline view.  Timelines can be useful for anyone who wants to get a high-level look at projects or view any time-related metrics.

To be more specific, Timelines allow you to visualize three key timeframes:

  • Planned Time (a user-determined value for an item’s planned duration)
  • Actual Cycle Time / Actual Time In-Progress (an automatically calculated value which shows how long an item has been “in progress”)
  • Forecasted Time (an automatically calculated value for an item’s duration based on current effort over time)

To view your data on a Timeline, you can either set up a new view or apply a Timeline to a current view by clicking on the Timeline symbol at the top right of the screen. Keep in mind that some views will have no use as a Timeline because they are not related to time (such as a list of all users in the system).  

Public Roadmap

Timelines can be shared as Tauboards with people outside the project team or your own organization (e.g. for explaining the roadmap to customers and stakeholders). Tauboards are updated in real-time, so nobody needs to waste time updating different versions of PDFs or PowerPoints; everyone sees the actual real-time status with just a click. This is especially helpful for high-level planning meetings (especially if any participants are working remotely).  

You can see the Tauboard for Targetprocess’s public roadmap here.

Different ways to use Timelines:

Setting expectations for delivery time is one of the most challenging aspects of project management. Timelines can help managers and team members get away from things such as closed deadlines and low quality releases (if they were the result of pressure from time emergencies). The Timeline view encourages transparency, and allows you to analyze what happened in the past, create plans for the future, and stay on track in the present.

There’s a myriad of uses for Timelines in Targetprocess. We’ll list some of them below.

PMOs and POs frequently use Timelines for:

  • Portfolio management
  • Project and program planning
  • Roadmapping

The ability to display a dozen projects on one screen and show how they all coincide with each other can be invaluable. Users can get a visual comparison between planned and actual end dates, and also see automatic forecasts for when the projects are expected to be completed. Project managers can check estimations against real work to identify and correct any deviations from the plan.

Project Roadmap

Milestones (those colored lines with flags at the top) can add significant value to project scheduling. Milestones in different colors can help to synchronize work across different programs.

Release Managers use Timelines to:

  • Create an iteration or release schedule for teams
  • Plan and track progress across many different releases

QA Managers prefer using Timelines for:

  • Mapping test plans for a test run

Other team or project managers (including those listed above) can use Timelines to:

  • View project allocations (seeing when and for how long people will be available)
  • View individual allocations across several projects

People Allocations Management is a very wide topic because it’s used for all kind of activities. Timelines can help you visualize which people and teams are allocated to which projects and whether there are any potential conflicts which might occur. You can specify what people (teams and individuals) are required for a project, how long you need them for, and what percentage of their total working hours they can be allocated to a project.

Project Allocations

When viewing allocations on a Timeline, cards for people or teams might sometimes be displayed as red. This happens when an individual or team is over-allocated. For example: each person gets a certain capacity amount (e.g. 40 hours a week) which can be allocated to different projects as a percent. If the Percent Participating fields (found in the Allocations tab) for all of the individual’s allocations add up to over 100%, then the card will turn red.

Tips from Targetprocess veterans:

You can customize a Timeline’s cards to display blockers, relations, and many other units.  It’s easy to drill down into these cards for more details. To customize which units are displayed on a Timeline’s cards, just go to the Customize Cards tab in the view’s setup.

Timeline Customize Cards

Click the three gray dots to the right of the name of your view to find the view's dropdown menu. Select "Setup" then click the "Customize Cards" tab.

Visual encoding can be used to highlight items which have been started, or to flag items that could be potentially delayed.  To see potential delays, go to the visual encoding tab and input:

  • ?ForecastEndDate > PlannedEndDate

To see items which have been started, input:

  • ?EntityState is ‘InDev’

You may have to replace ‘InDev’ with whatever workflow stage you have set up for items in progress.

Visual Encoding for Timelines


At the top of the Timeline view, you can find the global time period selector. This is where you select your desired overall date range.

Local Selector
At the bottom of the view, you can find the local time period selector, where you can select which section and how much of your time interval your Timeline view will show. New users sometimes get confused about this function, so I’ve included a short explanatory clip: How a Timeline view should not be used

We won’t try to tell you how to run your projects… but we’d be remiss if we didn’t try to offer some advice. In our opinion, it’s not a good idea to use Timelines to compare the efficiency or productivity of teams. Timelines are about tracking your plans in time and identifying potential delays, rather than measuring productivity metrics.

Why not a Gantt chart?

Why do we have Timeline view and not a Gantt chart? While we do see the value a Gantt chart can offer some kinds of projects, Targetprocess is an agile tool.  Gantt charts assume that work will be completed in a linear fashion, and they don't do a good job of illustrating how the total amount of work left on a project changes with each iteration. 

As Michael Dubakov (our CEO) mentioned in an earlier blog post on Gantt charts, “agile is not about tasks dependency and critical path management — it's about flexibility and temporary dependency." 

Additional reading:

Getting Started with the Timelines

Deciding when to use boards, lists, or timelines

How to share Timelines

How Timelines help project managers track progress


Categories: Companies

SonarLint 2.0 Is Now Available

Sonar - Wed, 05/25/2016 - 15:25

SonarLint is a pretty recent product that we released for the first time a few months ago for Eclipse, IntelliJ and Visual Studio. We have recently released the version 2.0 which brings the ability to connect SonarLint with a SonarQube server and was greatly expected by the community. I think the addition of this new feature is a good chance to recap SonarLint features. But before I do this, let me remind you of the SonarLint’s mission: to help developers spot as many coding issues as possible in their IDE, while they code. It has to be instant, integrated to the IDE, and valuable.

Since SonarLint 1.0, you can install the product from the market place for all 3 IDEs we currently support: Eclipse Marketplace, Jetbrains Plugin Repository or Visual Studio Gallery. Et voilà… You can continue your coding as usual and you will start seeing SonarLint issues reported as you type. If you open a file, it will get decorated immediately with issues.

You also benefit from a nice panel containing a list of issues that have been detected. Each issue comes with a short message and if that is not enough you can open a more detailed description of the problem, with code snippets and references to well known coding standards.

As I am sure you guessed already, all of this does not require any configuration. And this is actually the reason why version 2.0 was so expected: people who have defined their quality profile in SonarQube want to be able to use the same profile in SonarLint. This is the main feature provided by SonarLint 2.0.

In order to have SonarLint use the same quality profile as SonarQube you have to bind your project in your IDE to the remote project in SonarQube. This is done in two steps:

  • Configure a connection to your SonarQube server (URL + credentials)
  • Bind your project with the remote one

Et voilà… again… SonarLint will fetch configuration from the SonarQube server and use it when inspecting code.

That’s it for today!

Categories: Open Source

Agile Change or Adoption: Create a Vision

Notes from a Tool User - Mark Levison - Wed, 05/25/2016 - 11:35

(Continued from Agile Change or Adoption Always Starts with Why: Part 1, Part 2, Part 3)

Most organizational change effort starts with a vision. But problems arise if the vision was created by a few executives who went off-site, as that can result in a vision that doesn’t address the problems felt by the doers at the team level, and it isn’t articulated in a way that makes sense to them.

Instead of inviting just the senior executive team, we need a workshop that involves senior management, middle management, and a fair representation of the doers (e.g. developers, testers, support staff).

Then we need to define our vision collaboratively. Any of the familiar Agile approaches for creating vision (e.g. Innovation Games: Product Box or Prune the Product Tree, or Roman Pichler’s Vision Board) are effective choices. The goal is to create an initial vision with buy-in from all, and that can be easily explained/understood by even those who weren’t present.

But after you create the vision, you have to communicate clearly about it, otherwise the change you hope to generate is at risk.

Traditionally a town hall style event is used to announce a change. The CEO gives a speech, followed by several other executives, and then questions are invited from the floor. But few real questions follow, since attendees haven’t had time to digest or discuss the implications of the change. This isn’t collaborative and doesn’t even qualify as dialogue. It is purely a control and communications mechanism.

Catchball from Hoshin Kanri management (Japanese name for Toyota’s Strategic planning technique) is one collaborative approach to be considered as an alternative. Catchball is a fact-based strategic discussion process that gets Senior Management to sit down with Team Members. Senior Management show their vision, then they metaphorically “throw the ball” – i.e. pass the information back to the Team for their response. Team Members “catch the ball” and break down the vision into smaller digestible parts. They throw the figurative ball back to Senior Management, who review the approach to see if it will meet their needs. The ball is bounced back and forth until both groups are satisfied.[1]

The key point here is that the vision wasn’t just explained – much like creating an effective user story, the vision was treated as an invitation to a conversation. Also like effective User Story conversations, they’re best tested by creating specific concrete examples that reveal whether all parties are describing the same thing.

Case Study
At the WorldsSmallestOnlineBookStore, John, our intrepid former ScrumMaster and now Agile Coach, organizes a Vision Workshop. The goal is to decide as a group what they’re trying to achieve with the significant organizational change they’ve taken on.

John has invited 20 people to the event and asks them to self-organize into three to four teams. Each must have at least one executive, one middle manager, and two doers. Beyond that, he lets people choose which group they want to work with.

His framing question: “In two years and one day we’re part of a better organization, how did we improve? Did we:

  • become more resilient?
  • improve quality?
  • create faster time to market?
  • have better employee retention?

Each team is challenged to create a “Product Box” that illustrates the organizational changes they would like to see.

–           One team creates a box that shows a customer abandoning a purchase, and then a bigger picture of many happier customers. An arrow indicates the change from unhappy to happy.

–           Another team shows quality changing from a rubber stamp, to being built into every brick in a structure.

–           The last team shows a box with images on two sides. On the first side there is a solid brick wall with moss grown all over it. Many of the bricks are old and chipped. At the bottom of the box is a tiny clean section of the wall where the bricks have been repaired. It says “Agile”. On the other side of the box the team shows a wall largely cleaned of moss and with many repaired bricks. They explain that the moss was the past practices that were holding all the teams back. Once cleaned, the teams – both product development and operational – were able to repair many of the bricks.

After an hour of work, each team shares their vision with the others and explains what each element represents. They return to their tables and update their own vision based on what they discovered from their peers.

Finally, they come back together at the end to select a box that best represents their overall vision. (This is done by consensus and occasionally a consensus can’t be reached). In our case, they decide that a combination of the first two boxes best represents their vision.  The team that created the last box hasn’t done bad work, they just didn’t sell their peers on selecting it and the idea it represented. Sometimes you can have a great idea but others can’t see it and buy into it.


Image attribution: Agile Pain Relief Consulting

[1] Use the Catchball Process to Reduce Ambiguity – Tim McMahon
Categories: Blogs

My OSS CI/CD Pipeline

Jimmy Bogard - Tue, 05/24/2016 - 23:39

As far back as I’ve been doing open source, I’ve borrowed other project’s build scripts. Because build scripts are almost always committed with source control, you get to see not only other projects’ code, but how they build, test and package their code as well.

And with any long-lived project, I’ve changed the build process for my projects more times than I care to count. AutoMapper, that I can remember, started off on NAnt (yes, it’s that old).

These days, I try to make the pipeline as simple as possible, and AppVeyor has been a big help with that goal.

The CI Pipeline

For my OSS projects, all work, including my own, goes through a branch and pull request. Some source control hosts allow you to enforce this behavior, including GitHub. I tend to leave this off on OSS, since it’s usually only me that has commit rights to the main project.

All of my OSS projects are now on the soon-to-be-defunct project.json, and all are either strictly project.json or a mix of main project being project.json and others being regular .csproj. Taking MediatR as the example, it’s entirely project.json, while AutoMapper has a mix for testing purposes.

Regardless, I still rely on a build script to execute a build that happens both on the local dev machine and the server. For MediatR, I opted for just a plain PowerShell script that I borrowed from projects online.  The build script really represents my build pipeline in its entirety, and it’s important for me that this build script actually live as part of my source code and not tied up in a build server. Its steps are:

  • Clean
  • Initialize
  • Build
  • Test
  • Package

Not very exciting, and similar to many other pipelines I’ve seen (in fact, I borrow a lot of ideas from Maven, which has a predefined pipeline).

The script for me then looks pretty straightfoward:

# Clean
if(Test-Path .\artifacts) { Remove-Item .\artifacts -Force -Recurse }

# Initialize

exec { & dotnet restore }

# Build

# Test
exec { & dotnet test .\test\MediatR.Tests -c Release }

# Package
$revision = @{ $true = $env:APPVEYOR_BUILD_NUMBER; $false = 1 }[$env:APPVEYOR_BUILD_NUMBER -ne $NULL];
$revision = "{0:D4}" -f [convert]::ToInt32($revision, 10)

exec { & dotnet pack .\src\MediatR -c Release -o .\artifacts --version-suffix=$revision }

Cleaning is just removing an artifacts folder, where I put completed packages. Initialization is installing required PowerShell modules and running a “dotnet restore” on the root solution.

Building is just msbuild on the solution, executed through a PS module, which MSbuild defers to the dotnet CLI as needed. Testing is the “dotnet test” command against xUnit. Finally, packaging is “dotnet pack”, passing in a special version number I get from AppVeyor.

As part of my builds, I include the incremental build number in my packages. Because of how SemVer works, I need to make sure the build number is alphabetical, so I prefix a build number with leading zeroes, and “57” becomes “0057”.

In my project.json file, I’ve set the version up so that the version from the build gets substituted at package time. But my project.json file determines the major/minor/revision:

  "version": "4.0.0-beta-*",
  "authors": [ "Jeremy D. Miller", "Joshua Flanagan", "Josh Arnold" ],
  "packOptions": {
    "owners": [ "Jeremy D. Miller", "Jimmy Bogard" ],
    "licenseUrl": "",
    "projectUrl": "",
    "iconUrl": "",
    "tags": [ "html", "ASP.NET MVC" ]

This build script is used not just locally, but on the server as well. That way I can ensure I’m running the exact same build process reproducibly in both places.

The CD Pipeline

The next part is interesting, as I’m using AppVeyor to be my CI/CD pipeline, depending on how it detects changes. My goal with my CI/CD pipeline are:

  • Pull requests each build, and I can see their status inside GitHub
  • Pull requests do not push a package (but can create a package)
  • Merges to master push packages to MyGet
  • Tags to master push packages to NuGet

I used to push *all* packages to NuGet, but what wound up happening is I would have to move slower with changes because things would just “show up” on people before I had a chance to fully think through the changes to the public.

I still have pre-release packages, but these are a bit more thought-out than I have had in the past.

Finally, because I’m using AppVeyor, my entire build configuration lives in an “appveyor.yml” file that lives with my source control. Here’s MediatR’s:

version: '{build}'
  do_not_increment_build_number: true
  - master
  disable_publish_on_pr: true
- ps: .\Build.ps1
test: off
- path: .\artifacts\**\*.nupkg
  name: NuGet
- provider: NuGet
    secure: zKeQZmIv9PaozHQRJmrlRHN+jMCI64Uvzmb/vwePdXFR5CUNEHalnZdOCg0vrh8t
  skip_symbols: true
    branch: master
- provider: NuGet
  name: production
    secure: t3blEIQiDIYjjWhOSTTtrcAnzJkmSi+0zYPxC1v4RDzm6oI/gIpD6ZtrOGsYu2jE
    branch: master
    appveyor_repo_tag: true

First, the build version I set to be just the build number. Because my project.json file drives the package/assembly version, I don’t need anything more complicated here. I also don’t want any other branches built, just master and pull requests. This makes sure that I can still create branches/PRs inside the same repository without having to be forced to use a second repository.

The build/test/artifacts should be self-explanatory, I want everything flowing through the build script so I don’t want AppVeyor discovering and trying to figure things out itself. Explicit is better.

Finally, the deployments. I want every package to go to MyGet, but only tagged commits to go to NuGet. The first deploy configuration is the MyGet configuration, that deploys only on master to my MyGet configuration (with user-specific encrypted API key). The second is the NuGet configuration, to only deploy if AppVeyor sees a tag.

For public releases, I:

  • Update the project.json as necessary, potentially removing the asterisk for the version
  • Commit, tag the commit, and push both the commit and the tag.

With this setup, the MyGet feed contains *all* packages, not just the CI ones. The NuGet feed is then just a “curated” feed of packages of more official packages.

The last part of a release, publicizing it, is a little bit more work. I still like GitHub releases but haven’t found yet a great way of automating a “tag the commit and create a release” process. Instead, I use the tool GitHubReleaseNotes to create the markdown of a release based on the tags I apply to my issues for a release. Finally, I’ll make sure that I update any documentation in the wiki for a release.

I like where I’ve ended up so far, and there’s always room for improvement, but it’s a far cry from when I used to have to manually package and push to NuGet.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Communities of Practice Revisited

Agile Product Owner - Tue, 05/24/2016 - 22:35

Hello SAFe community!

I’m Steve Mayner. I recently joined Scaled Agile, Inc. after years as an SPC and SAFe® Gold Partner. Shortly after I came on board I was given the opportunity to help improve a few of the framework articles. We’re excited to share with you our updated insights on Communities of Practice. This new article provides deeper grounding in the CoP body of knowledge, and also offers specific step-by-step guidance for forming, growing, and managing healthy communities. You will also see specific examples that illustrate how CoPs can add value to ARTs as part of a healthy SAFe practice.

Promoting vibrant CoPs can go a long way towards realizing the ideals of Principle #8 – Unlock the intrinsic motivation of knowledge workers. As rewarding as work within the Agile team or the program team might be, practitioners thrive when they are constantly growing their skills and networking with other people who share common interests. CoP members bring that learning and enthusiasm back to their ART work, benefitting the entire program. CoPs are absolutely a win-win proposition for SAFe organizations and their team members!

As always, we look forward to your comments and perspectives on this new content!

Enjoy, and stay SAFe!

Steve Mayner
Senior SAFe® Program Consultant
Scaled Agile, Inc.

Categories: Blogs

Leading Agile Change: Proven Change Models for Agile Transformation

BigVisible Solutions :: An Agile Company - Tue, 05/24/2016 - 19:00

Many organizations approach Agile transformations with naïve expectations. They don’t understand that training and coaching teams alone won’t be enough to ensure that their Agile initiative succeeds. Agile transformation entails changes in policies, processes, mindset and culture that will be felt throughout the organization. The key to successfully leading change that runs this deep is Organizational Change Management (OCM).

OCM helps change leaders usher in extensive operational and structural changes. Even more important, it helps leaders facilitate the human aspects of change that occur during Agile transformations.

But first let’s look in a little more depth at what Agile transformation entails.

Agile is the new normal, it has been around for over 15 years and is becoming the mainstream way of building software. Many organizations have already adopted Agile practices and many are in the process of undertaking an Agile Transformation with the goal of transitioning from a set of values and principles aligned to waterfall and sequential development to Agile values and principles. Some organizations have had trouble making this transformation stick, and we have observed that often this is because very few of these organizations used Organizational Change Management practices as part of their Agile Transformation.

An Agile Transformation typically introduces major changes in five different layers within an organization:

5-Layer Organization 

At the Leadership layer, we are typically introducing new leadership styles, which de-emphasize command and control and introduce new styles like servant leadership. At the Organization layer we introduce new cultures of collaboration and new structures and behaviors that are more team-oriented as opposed to individual-based. At the Product and Business layer we introduce brand new roles such as Product Owners and introduce new ways in which the business partners with software development. At the Delivery layer we introduce new frameworks and ways of working to address Agile scaling issues and sometimes introduce specific frameworks such as the Scaled Agile Framework (SAFe). Lastly, at the Execution layer, we introduce new team-based patterns, such as Kanban, Scrum, and Extreme Programming (XP).

Clearly we are dealing with change at much more than just the software development team level so we typically need interventions throughout the organization above and beyond the coaching and training of development teams. And because we are introducing a brand new set of values and principles to the organization that foster totally different individual and organizational behaviors, we would be well served to pay better attention to the change process and ensure the success of their change initiatives. Change professionals have been drawing from a body of knowledge and proven OCM practices and frameworks for many years to help organizations achieve success in their large-scale change initiatives.

In this blog I’ll give a brief overview of a couple of these practices and frameworks, in particular how they could be applied in an Agile transformation.


The ADKAR model by Prosci is a goal-oriented model in which five major milestones are progressed through sequentially to arrive at the desired change. (I had the pleasure of interviewing Prosci CIO Tim Creasey recently at the Association for Change Management Professionals 2016 conference. After you’re done reading this blog, click here to watch the interview.) The five milestones of ADKAR are:

  • Awareness – Before a change can occur, the individuals affected by the change need to be made aware of the need for the change. In an Agile transformation, we must ensure the entire organization is aware of the goals for why we are changing. We can do this with a well thought out communication strategy and plan.
  • Desire – Even if the organization as a whole is aware of the need for change, they may not want to make the change. In order for change to be successful, the whole organization needs to want the change. In an Agile transformation, the desire for change is articulated through the set of Agile values and practices that drive toward the organization’s goals and aspirations and will help it succeed in an increasingly uncertain marketplace. By generating a shared sense of purpose, the people in the organization can begin desiring the change.
  • Knowledge – In order for us to be successful with the change, there is a base level of new knowledge we must infuse into the organization. We can use training as a way to introduce the new level of knowledge as part of an Agile Transformation.
  • Ability – There is a minimum level of performance and capability we are expecting to see in the future state, so we need a way to measure the new ability. We can use a combination of assessments and coaching as a way to improve ability in an Agile Transformation.
  • Reinforcement – It can sometimes be easy to revert back to our old ways so we need a way to reinforce the new future state behavior to make sure the change sticks.
Kotter 8-Step Process for Leading Change

John Kotter is a professor at the Harvard Business School and he introduced his eight-step process for change in his book “Leading Change” twenty years ago:

  • Create a Sense of Urgency – We need to mobilize the organization to want to change. For Agile transformations we often make reference to the rate of change and the dramatic shortening of the average lifespan of companies from the Deloitte Shift Index to create that sense of urgency. If we don’t become more Agile than our competitors, we might cease to exist.
  • Build a Guiding Coalition – On Agile transformations we often create an Agile steering committee and/or transformation team that is tasked with executing the transformation and communicating its progress to the organization.
  • Form a Strategic Vision & Initiatives – We often work with organizations to first set a vision and strategy for why we are trying to become Agile and then we make sure the organization is aligned to that Agile vision.
  • Enlist Volunteer Army – We can do this on an Agile transformation by first demonstrating the value of Agile in a smaller context (e.g., a proof-of-concept Agile experiment). It is often the case that the individuals who partake of these experiments see the value of agility and become early adopters. These early adopters may then decide to champion the change initiative based on their own personal experiences.
  • Enable Action by Removing Barriers – One of the key roles of the steering committee and transformation team is to remove impediments. These can be environmental, behavioral, structural and cultural. We often define an impediment backlog, which we aggressively work through removing.
  • Generate Short-Term Wins – We often recommend having formal celebrations to highlight our accomplishments. If we break our transformation program down into iterations, we can make sure at the end of each iteration we celebrate the major achievements completed during the iteration.
  • Sustain Acceleration – Even changes that are making good progress can stall. We need to make sure we are progressing through the Agile transformation at a sustainable pace. We can use concepts like a Transformation Backlog and Transformation Sprints to break the change down into a set of manageable incremental changes that can be delivered with the available organizational capacity. We also need to make sure that we are building upon the successes we’ve had with our short-term wins.  As we sustain acceleration in an Agile transformation, we start tackling the bigger issues and deal with the organizational changes necessary for an Agile transformation to achieve the vision.
  • Institute Change – When the change successfully takes hold, clearly connect new improvements and results with the implemented changes. There should be a positive delta in some key areas due to the change. On an Agile Transformation we can use an Agile-minded metrics program and transparency to measure performance and also to make course corrections as needed.
McKinsey 7-S

The McKinsey 7-S model is a collection of seven independent dimensions for modeling an organization. They include:

  • Strategy – This represents the organizations plan for how it is going to deliver against its vision.
  • Structure – This represents the physical organization structures that are in existence to support the strategy.
  • Systems – This represents the processes and tools that are in place to execute the strategy.
  • Shared Values – This represents the core set of values that the whole organization is in support of.
  • Skills – The core set of skills that the employees currently possess.
  • Style – This is the way leaders work with their staff.
  • Staff – This is the current labor force in place at the organization.

If we are going to leverage the McKinsey 7-S model we need to make sure our Agile Transformation Roadmap has items on it that address all seven dimensions. Too often organizations only really address the Skills and Staff dimensions through training and coaching.

Satir Change Model

Virginia Satir was a family therapist. Her Satir Change Model is a five-stage process that was originally intended for family therapy interventions and has also been adapted for organizational change. In this model we try to form a bridge from the current state to future statue by starting at the Late Status Quo, which is essentially the current state. In an Agile Transformation this is often described as waterfall or sequential software development. We do this by first dealing with Resistance, which then devolves for a time into Chaos, but then after entering into a period of Integration we are now able to reach the New Status Quo, which in an Agile transformation would be a state that is consistent with the Agile values and principles. (Here is a much more in-depth treatment of the topic by my colleague, Steven M. Smith.)

So as you can see, there are a number of classic models and frameworks that have been used successfully in the past to deal with large organizational change initiatives. What all of these models have in common is the attention paid to the change process. Change, even for a very good reason, is nonetheless very difficult at the individual level. It is imperative to ensure good structures are in place to ensure that the exponentially more difficult organizational change achieves the goals and benefits for which the change was coordinated in the first place.

Agile transformation seems to be the most common organizational change. Companies of every size and industry do themselves a huge service by carefully and methodically implementing change like Agile transformation using a proven change model like those mentioned here. It is for this reason that change management is built into SolutionsIQ’s Agile Transformation Solution.

In my next post, I’ll write on how these models are a great place to start, but need to be adapted to align better with Agile values like collaboration, transparency and rapid feedback.

  • Brown, John Seely,  Hagel III, John, Kulasooriya Duleesha.  (2011).  The 2011 Shift Index – Measuring the forces of long term change.  Deloitte Center for the Edge.
  • Hiatt, Jeffrey M (2006).  ADKAR A Model for Change in Business and Government and our Community.Prosci Learning Center Publications.
  • Kotter, John P. (1996). Leading Change. Harvard Business School Press.
  • Satir V; Baldwin M (1983). Satir Step by Step: A Guide to Creating Change in Families. Palo Alto, CA: Science and Behavior Books.
  • Waterman, Robert H., Peters, Thomas J., Phillips, Julien R.  (1980).  Structure is Not Organization. Business Horizons.


How Agile and change management intersects and can complement each other is an increasingly relevant topic in today’s constantly changing world of work. To learn more about this, including proven practices SolutionsIQ consultants use in the field, join Dan Fuller for our upcoming webinar “Leading Agile Change: Proven Change Management Approaches for Agile Transformation”.

Register Now

The post Leading Agile Change: Proven Change Models for Agile Transformation appeared first on SolutionsIQ.

Categories: Companies

How Practicing Creative Confidence Can Help You Embrace Risk

Pivotal Tracker Blog - Tue, 05/24/2016 - 18:48

For the past few weeks, I’ve been writing about personal advancement. I started out by posing the question: Are you asking for permission to advance? This was followed by: Are you in a culture that values enforcement or empowerment? Then last week I wrote about why we don’t go after what we want.

The grander theme I’m exploring with all these posts is risk and our willing to embrace it.

Risk can mean a number a number of things. It could mean speaking up, or striking out on your own.

But taking a risk is hard.

What’s easier is following a known path. Creating what we’re told to create. Doing what we’re told to do.

So why not just go for the easy path?

Because it doesn’t always lead to us to feeling fulfilled in our careers and everyday lives.

What does feel fulfilling is pushing our creative limits, and that’s where risk comes in.

The reason risk is hard is because it’s surrounded by fear.

Anytime we want to take a risk by sharing ourselves or pursuing a new experience, our inner critic—that little voice inside our heads—stops us dead in our tracks. It fills us with fear: fear of criticism, rejection, and failure.

It’s hard to put the inner critic in its place because of the way we’ve been educated and conditioned: to not make mistakes.

So what does it take to get over our fears and take a risk?

Creative confidence.

Creative confidence is a mindset, a way of being, that comes from design thinking. Design thinking allows you to be experimental, make mistakes, let go of perception, embrace testing to see what happens, and be detached from outcomes.   

In this new episode of FemgineerTV, we’re going to be talking about how to manage the various fears we come across and gain creative confidence.

To help us out, I’ve invited my good friend Maria Molfino, a women’s leadership coach who helps women gain the creative confidence to lead. With a Master’s in Design from Stanford, she has worked with top managers and professionals at companies such as Facebook, Twitter, and IDEO.

Maria says, “If you care about growing and expanding, then you have to find out how to relate to your fears. If fear isn’t coming up, you’re not playing at your edge.”

Here’s what you’ll learn as you watch the episode:

  • Why the fear of failure is bigger than actually experiencing failure
  • Why we’re sensitive to feedback and how to remove the sting of it
  • How to deal with criticism from ourselves, bosses, peers, and loved ones
  • Why it’s important to create space between yourself and your creative work
  • How to reframe self-promotion

This is a must-watch episode if you find want to grow, but feel stuck, and especially if you are looking to help others grow!

In the episode, Maria shares her Creative Confidence Playbook to help you overcome obstacles such as perfectionism, comparison, and more. You can download her playbook here.

Maria also recently launched a podcast called Heroine where she interviews creative women leaders in art, business, design, science, and tech. Check out the podcast here.

Listen to the episode on iTunes!

You can listen to this episode of FemgineerTV on iTunes. Please take a moment to leave us a review. Your positive review will help us get featured in News & Noteworthy and bring more exposure to the work we’re doing, as well as the talented guests we feature!

FemgineerTV is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

The post How Practicing Creative Confidence Can Help You Embrace Risk appeared first on Pivotal Tracker.

Categories: Companies

Yet Another Boring Discussion

TV Agile - Tue, 05/24/2016 - 18:22
How comes that when 10 people gather to discuss a problem usually only 3 or 4 of them really participate? And why the rest looks so bored? Let us discuss how to turn our oh-no-yet-again-a-boring-discussion into something much more exciting, and with better chances of finding good solutions to the problem at hand. Video producer: […]
Categories: Blogs

Looking for an Agile Developer

Scrum Breakfast - Tue, 05/24/2016 - 17:53
As Product Owner for the Scrum Breakfast Club, I want an Agile software developer,  At the Scrum Breakfast Club, our goal is to enable people and companies to become Agile. We need some software to help us make that happen. How do you find an Agile Developer?

When I have looked for a development partner in the past, I have always started what skills, passion and personality am I looking for.

First, let's talk about what this project is not:
  • This is not about creating a pretty website. This is about building the pipes between the various components.
If the following points describe you, we would like to talk to you (must):
  • We need to be able communicate in English. (I have tried working through an interpreter, but I have not found it to work well).
  • Our basic flow is Scrum and we do short sprints. We are not dogmatic, but we want to produce working software at least once per week. We would like you to know what Agile is about before we start.
  • Our Product Owner cares about quality and robustness. So we would like someone who is into TDD, BDD or one of their cousins. 
  • Interest in the work (which is mostly about the plumbing right now!). We are looking at making WordPress plugins for own use and other glue. So the basic skills are PHP and TDD or BDD.
If the following points describe you, you are in a great position to get the assignment.
    • Happy to work in a virtual team. Our team is based in locations from Europe to South East Asia. We use Skype, Hangout, Trello, and various cloud services. 
    • Happy with workloads of varying intensity. We have a clear project now, so you'll be pretty busy. I expect we are looking at a one to two month engagement. After that, we'll see. Maybe there will be phases where we are just in maintenance mode. We do expect a long life for our project and would like to come back to you when we need your skills again!
    • We would prefer someone is independent or in a small partnership. Someone who has control over their own time. You'll be dealing with Principals, and we'd like to deal with a Principal too. 
    • Last but not least, we are looking for good chemistry. We want work to be fun! Actually, this is a must, too!
    Does this resonate with you? Would you like to be collaborate with an Agile team?
    How to contact usTweet a screen shot of your latest daily build or other evidence that you know how to build reliable code! Just include @peterstev and @bindzus and #SBCDEV in the tweet, and we'll reach out to you!

    Update 30.5.2016: Updated to better communicate our goals and priorities.

    Categories: Blogs

    When is Agile Wrong for You?

    Johanna Rothman - Tue, 05/24/2016 - 16:04

    People often ask me, “When is agile  right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile.

    That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You might not have a great environment to start. But a bad environment? That’s a horror show.

    I had a coaching conversation recently. My client has a typical problem. He sees multiple ways to accomplish the work. He’s taking ideas from agile and lean, and smashing them together to create a project approach that works for them, at their company. It’s not quite agile. And, that’s the sticking point.

    His management wants to “go agile.” They have no idea what that means.They think agile is a way to get more good stuff faster with less cost. It’s possible that with agile approaches, they can achieve that as a by-product. To be honest, any approach that stops people from waiting for phases to finish will help. That’s not necessarily agile.

    The management team does know about one of the well-known approaches. They want everyone to go through that training. My client doesn’t think this will work. He has a number of concerns:

    • Management wants to control how people work at the project level. Management wants to define the iteration duration, what the standup questions will be, who will be on which team, and what the teams will do. (That’s enough right there, but there’s more. They are geographically dispersed across the globe. Going with an out-of-the-box solution does not make sense.)
    • Management wants to use team measurements for personal compensation. Specifically, they want to use personal velocity as a way to compensate people. (This is stupid, dangerous and wrong.)
    • Every manager my client has spoken with thinks that he or she does not need to change. Only the tech people need to change. (They could not be more mistaken.)

    If you work in an agile organization, you know the problems with these assumptions.

    Teams manage their own work: their intake is via the Product Owner. They decide how to work, flowing work through the team. Hopefully, the team focuses on their throughput, not who does what.

    Remember, Velocity is Not Acceleration. When managers abuse velocity and use it to measure the team members (not even the entire team!), they create schedule games and a toxic team environment. At best, a manager’s abuse of velocity leads to people taking shortcuts and incurring technical debt. At worse, it destroys teamwork.

    Managers can create the environment in which people can succeed. Especially in agile and lean, managers do not have to “incent” people, or push people to do well. People will do a good job because they get feedback often and they want to. When managers attempt to manipulate an environment to deliver more with less work (what they think agile is), I’m not sure if anyone can succeed.

    I asked my client if the managers understood what agile might mean for them, as managers. He was sure the managers had no idea.

    I suggested that trying agile in this environment would give agile a bad name in the organization. I suggested these alternatives:

    • Ask about the three questions that might help the managers articulate their goals. See Define Your Agile Success.
    • Do a simulation with management to have them feel what agile is like.
    • Explain the system of agile and how the ideas that management have is not helpful.
    • Request a reasonable environment for a short-ish timebox (I was thinking about a month, maybe two months) to show management that their ideas are not the only ideas that could work. I suggested a number of measures my client could suggest to his management.

    Don’t start agile in a toxic environment. It’s not worth it. Agile is wrong for you. Remember that Agile is Not a Silver Bullet and Agile is Not for Everyone.

    Remember, agile is a cultural change, not merely a project management framework.

    Instead of agile, consider using all the ideas of agile ( for example, teamwork to deliver small chunks of value) to show steady progress and decide how to influence your managers. Don’t ask teams to be collaborative when management wants to stay command-and-control.

    Categories: Blogs

    Consistency is the Key When Scaling Agile

    Agile Management Blog - VersionOne - Tue, 05/24/2016 - 14:30


    detourWake up, get dressed, go to work, go to lunch, go home, etc., etc., etc.  Each of these decisions is made over and over again in what might be called a routine.  As part of this sequence, work is done whether simple or complex and the outcome is typically valuable.

    What happens when this “routine” is changed for some un-anticipated reason causing a detour?  Was there a problem or not?  Was the end result less value created?  Festinger coined the term “Cognitive dissonance to describe inconsistencies in our understanding which can cause stress”.  If this identified inconsistency can cause anxiety leading to failure, could it be that consistency will have the opposite effect and lead to success?

    According to  VersionOne’s 10th annual State of Agile Report, 43% of the respondents rated consistency the most important success factor when scaling agile, followed by implementation of a common tool across teams (40%), and agile consultants or trainers (40%) were cited as the top three tips for successfully scaling agile.

    Top 5 Tips for Success with Scaling Agile

    What is it?

    Consistency Defined – agreement or harmony of parts or features to one another or a whole.  We know there are many parts to our lives, some of which are complicated and others can be classified as simple.  An executive in a company might have as part of their daily routine dropping their kids at school and then spending the rest of the day re-structuring companies in which they serve.  This combination of decisions can get convoluted quickly if there is not a certain “agreement or harmony” of the parts that make up the day.

    music-250x156In this small case, a traffic problem can cause the corporate world to be delayed in a strategic decision. These are the decisions that need more time, research, and analysis as seen through a bigger lens.  Consistency in the simple decisions allow for more time to be spent on the complex ideas and solutions.

    Agile software development values keeping things as simple as possible.  One of the Agile Manifesto’s principles is “Simplicity–the art of maximizing the amount of work not done–is essential”.  Things like people, process, terminology, events, and locations can all contribute to a complex work environment.  As more decision points are added to any project, complexity increases.  Scaling agile contributes directly into this increasing cognitive map and can lead to a less harmonic result.

    Why is it important?

    When people are added to teams, there is a need for existing members to take time out of the regular schedule for assimilation into the workflow.  This typically involves sharing of information, team culture, and idiosyncrasies associated with this group seen or unseen.  The routine is changed.

    With scaling, teams are being added to teams creating many more points of reference, collaboration, and potential confusion.  Consistency is important because confusion creeps in which produces change and can lead to chaos.  The chaos factor will hold back teams from delivering on a regular basis.

    peopleRobinson and Rose stated, “Often, in the tension of a chaotic stage, team members simply start doing things to burn off the emotional energy.  The difficulty with this is that the activity is often not well-thought-out and can actually have nothing to do with the actions that they need to take to be successful.”

    Similarly, changes in process, can have the same effect.  Like a detour on the way to the office, a small change can signal a disruption in success.  Following well-known and mature processes can facilitate the ability to keep moving forward.  A common cadence will help settle the dust of simple questions like when and where, so the complex issues are allocated more time and effort.

    Bell and Raiffa posited, “Many of the central issues of our time are questions of how we use limited information and limited computational capacity to deal with enormous problems whose shape we barely grasp.”

    With this limitation already acknowledged, how can we increase consistency?

    How do we do it?

    Brief analysis of the ceremonies a group does can shed light into what is “consistent” and what might need to change. Start with the people because this affects everything else.  I know of one company that has set a Service Level Agreement (SLA) on contracted teams to support consistency so their Bounce Rate stays small.  People naturally form routines and look for simple answers.  Self-organization can help to surface inconsistencies and supports faster acceptance of change.  Also, look at the process, culture, terminology, and location as indicators for or against consistency.

    consistency is keyGetting to agreement or harmony can take agile teams some time; however evidence shows that consistency will enhance success.

    Find out more by downloading the 10th annual State of Agile Report and reviewing archives of past reports.

    Decision Making: Its Logic and Practice
    By Byron M. Roth, John D. Mullen

    Teams for a New Generation: A Facilitator’s Field Guide
    By Greg Robinson, Mark Rose

    Decision Making: Descriptive, Normative, and Prescriptive Interactions
    By David E. Bell, Howard Raiffa

    State of Agile is a trademark of VersionOne Inc.

    The post Consistency is the Key When Scaling Agile appeared first on The Agile Management Blog.

    Categories: Companies

    Agile in a Bag, London, UK, June 10 2016

    Scrum Expert - Tue, 05/24/2016 - 11:00
    Agile in a Bag is a one-day conference that takes place in London. It proposes workshops to help you understand how Agile works and interesting presentations explaining Scrum ideas. It is also a great place to network with fellow Agile practitioners in London. In the agenda of Agile in a Bag, you can find topics like “Wicked Problems in Organisational Design”, “Kanban is more than a board, let’s discuss deep Kanban”, “Coaching the Agile organisation”, “Avoiding ‘Mini-Waterfalls’ in Agile Environments”, “From Rust to Robust-From Iron To Agile Triangle”, “Cynefin A&E Simulation Game”, “Coaching Tools for Agile Leaders”, ” Quantifying Cost of Delay – Why is it the ‘one thing’ to quantify, How do I do it?”, “Influence techniques of Scrum Master: how to build a team without a power”, “The Journey of a Lean Enterprise”. Web site: Location for the Agile in a Bag conference: Mary Ward House, 5-7 Tavistock Place, London, WC1H 9SN, UK
    Categories: Communities

    Agile Coach Camp Canada West, Vancouver, Canada, June 17-19 2016

    Scrum Expert - Tue, 05/24/2016 - 10:30
    Agile Coach Camp Canada West is a three-day conference that creates opportunities for the Agile coaches community to share successes, learning, questions and unresolved dilemmas. All this happens in an energizing and supportive environment. The Agile Coach Camp Canada West follows the open space format for conferences. Each participants makes a contribution to the art and science of helping people and teams be their best as they create valuable software. Share your stories, observations, and puzzles. Discuss coaching challenges you have overcome or those you are wrestling with today. Describe challenges you see emerging as we seek to improve the organization of knowledge work. Bring your questions. Test your ideas. Listen and learn from others. Web site: Location for the Agile Coach Camp Canada West conference: BCIT Downtown Campus, 555 Seymour Street, Vancouver, British Columbia, V6B 3H6, Canada
    Categories: Communities

    Agile Coach Camp Canada East, Cornwall, Canada, 3-5 June, 2016

    Scrum Expert - Tue, 05/24/2016 - 10:15
    Agile Coach Camp Canada East is a three-day conference that creates opportunities for the Agile coaches community to share successes, learning, questions and unresolved dilemmas. All this happens in an energizing and supportive environment. The Agile Coach Camp Canada East follows the open space format for conferences. Each participants makes a contribution to the art and science of helping people and teams be their best as they create valuable software. Come to share your stories, observations, and puzzles. You will be able to discuss coaching challenges you have overcome or those you are wrestling with today. You will describe challenges you see emerging as we seek to improve the organization of knowledge work. Bring your questions. Test your ideas. Listen and learn from others. Web site: Location for the Agile Coach Camp Canada East conference: NAV Centre, 1950 Montreal Road, Cornwall, Ontario K6H 6L2, Canada
    Categories: Communities

    SoCraTes UK, Dorking, UK, June 2-5 2016

    Scrum Expert - Tue, 05/24/2016 - 10:10
    SoCraTes UK is an International Software Craftsmanship retreat for open-minded craftspeople who want to improve their craft and the software industry as a whole. It’s a great opportunity to speak to and code with many like-minded and talented developers. The conference itself is free. SoCraTes UK, the International Software Craftsmanship retreat follows the open space format for conferences. Open space is a simple methodology for self-organizing conference tracks. It relies on participation by people who have a passion for the topics to be discussed. There is no preplanned list of topics, only time slots and a space in the main meeting room where interested participants propose topics and pick time slots. Web site: Location for the SoCraTes UK conference: Wotton House, Guildford Road, Dorking, Surrey, England, UK
    Categories: Communities

    Agile Coach Camp Italy, Lavarone, Italy, June 9-11 2016

    Scrum Expert - Tue, 05/24/2016 - 10:00
    Agile Coach Camp Italy is a three-days of highly collaborative, self-organized open space conference. It’s for everyone involved in Agile coaching, training, mentoring and helping Agile organizations. Agile Coach Camp Italy follows the open space format for conferences. Open space is a simple methodology for self-organizing conference tracks. It relies on participation by people who have a passion for the topics to be discussed. There is no preplanned list of topics, only time slots and a space in the main meeting room where interested participants propose topics and pick time slots. Web site: Location for the Agile Coach Camp Italy: Grand Hotel Astoria, Piazza Italia, 38046 Lavarone, Italy
    Categories: Communities

    Knowledge Sharing

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