Skip to content

Feed aggregator

Migrate a complete Git Repository from TFS to VSTS

Xebia Blog - Fri, 02/10/2017 - 12:10
I am migrating some Git repositories from a TFS server to VSTS. Moving a Git repo including all the history is very simple fo course. Since Git is a Distributed Source Control repository. But I always forget the syntax of moving the “complete” Git repository at once. With all the branches, tags etc. So here
Categories: Companies

Scandinavian Agile, Finland, Helsinki, March 2 2017

Scrum Expert - Fri, 02/10/2017 - 09:15
The Scandinavian Agile Conference is a two-day event organized by Agile Finland and focused on Agile software development and Scrum project management. It takes place in Helsinki and discusses Agile organizations, state of the art in programming practices and Agile coaching. In the agenda of the Scandinavian Agile conference you could find topics like “Risky Business”, “How kanban saved a Salvation Army hospital in Indonesia”, “Refactoring Orgs – How to drive change where it is least expected”, “Traditional leadership myths – and how to break them”, “Cynefin for test planning – Cynefin to the rescue for those times when test strategy is decoupled from context”, “Flow and Experimentation: How Unity Ads Grows Software”, “The IT Risk Manager – Managing Risk using Real Options”, “Transforming the software development industry”, “Clarity before speed: Plan-Do-Check-Act (PDCA) applied in practice”, “The best companies are led by dreams. In the future at least.”, “Stop scaling… Start growing an agile organization!”, “NAPA Agile Story: From Zero to Hero in Two Years”, Web site: Location for the Scandinavian Agile conference: Wanha Satama, Pikku Satamakatu 3-5, 00161 Helsinki, Finland
Categories: Communities

Socrates Canaries, Gran Canaria, Spain, April 6-9 2017

Scrum Expert - Fri, 02/10/2017 - 09:00
Socrates Canaries is the Spanish stage of the International Software Craftsmanship Gathering, a series of events for open-minded software developers who want to improve their craft and the software industry as a whole. The local Software Craftsmanship community in the Canary Islands organizes it. The agenda of the Socrates Canaries International Software Craftsmanship Gathering follows the rules of the open conference where the participants create themselves the schedule of the event. Proposals are presented during the event itself in the mornings, and voted by the participants right after. This event is not a hackaton and it’s not about a particular technology, a library or a programming language. It is more about methods, practices, values, principles, and professionalism. Web site: Location for the Socrates Canaries International Software Craftsmanship Gathering conference: NH Imperial Playa, Calle Ferreras, 1, 35008 Las Palmas de Gran Canaria, Las Palmas, Spain
Categories: Communities

Scrum vs. Kanban vs. ADKAR vs. Kotter: Change Management

Learn more about transforming people, process and culture with the Real Agility Program

The battle of the organizational change management approaches!

Check out the presentation I did last night at Agile Mississauga Meetup.

20170208 Agile Mississauga Meetup – Change Approach Characterization Model

I describe a model for understanding change management approaches and deciding which ones to use for your situation.  I also look briefly at Positive Deviance and Appreciative Inquiry.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Scrum vs. Kanban vs. ADKAR vs. Kotter: Change Management appeared first on Agile Advice.

Categories: Blogs

Visualize Your Work So You Can Say No

Johanna Rothman - Thu, 02/09/2017 - 22:43

Most people I know—even the people supposedly using agile—have too much work to do. You have project work. You have support work, formal for customer support or sales, and informal for your colleagues. You have reports to write or file, time cards to fill out, or other periodic events.

You need a way to say no to more work.

I wrote an article for Better Software, which is now online. See Saying No to More Work. (You need to register for the site to see the article. No charge for registration.)

One person wanted to see the kanban boards I referred to in the article. I am happy to show them to you here.

These are two potential kanban boards. The one on the left is the basic personal kanban board. Note that there are no WIP (Work in Progress) limits (yet) on this board. I would add WIP limits. Especially if I wanted to convince my manager I was doing too much work.

On the right,  you can see a disaster of a personal kanban board. There are many items To Do, three in Progress and a total of six stuck in various Waiting states. Yes, I had a board that looked like this many years ago. Then, I made a picture on a piece of paper and explained to my boss I was just one person. What did he want me to do and not do?

Now, given what I know, I would add WIP limits to each column.

If you want to see the project portfolio images for how I start at the organization level: the calendar view and kanban view, see Manage Your Project Portfolio at the Prags. At the end of the blurb, there’s a link to the quick start guide, which has just two of the images in the book. (I included many possible ways to visualize the project portfolio in this edition of the book.)

Here’s the key idea: Don’t take on more work than you can complete in a reasonable amount of time. Don’t multitask. Instead, see what your work is and how you might discuss it with your manager.

Categories: Blogs

How HR Can Save or Destroy Agile

Learn more about transforming people, process and culture with the Real Agility Program

“Business engagement alone is a necessary but not sufficient condition for Agile to succeed”

It’s taken a while but now it’s well understood amongst seasoned Agile practitioners that Business engagement is necessary for successful Agile implementations. Just when we thought engaged Business owners were enough, we’re now realizing Business engagement alone is not sufficient. The impact of corporate shared services, especially Human Resources (HR), on Agile adoptions or transformations are often overlooked. In fact, Agile practitioners often bypass HR in their zeal to quickly change the way they work and the related people processes.

“Companies are running 21st century businesses with 20th century workplace practices & programs”

– Willis Towers Watson

It’s not just IT departments practicing Agile but 21st century businesses overall that are characterized by flatter organizations and an insatiable appetite for small ‘a’ agility. Agility that is pushing and breaking the envelope of current HR processes and tools. Agile individuals and teams are very vocal when it comes to calling out technical obstacles in their way. The same could be said when it comes to HR related obstacles that impact Agile individuals and teams. If we listen, here’s what we would hear:

  • “Can we team interview the candidate for attitude and fit?”
  • “I was an IT Development Manager. What’s my role now?”
  • “My manager doesn’t see half of what I do for my team. How can she possibly evaluate me?”
  • “With no opportunity for promotions in sight, how can I advance my career?”
  • “Why do we recognize individuals when we’re supposed to be focused on team success?”
  • “Charlie’s not working out. Can we as the team fire him?”

As the volume increases, how will HR and HR professionals respond?

“2016 will be the year of Agile HR … most HR teams have no clue what Agile HR means”

– HR Trend Institute

The reality is that most HR teams have no clue what Agile is, never mind how it will ultimately rock their world. Most Agile initiatives emerge from the grass-roots or are driven independently by IT functions with little to no involvement from HR. HR  sits on the sidelines and watches IT “do their thing”. There is a misconception that Agile exclusively falls under the IT domain; overlooking the fact that the core of Agile is about the people and culture – the sweet spots of the HR profession.

There are three significant change movements gaining momentum:

  1. Reinventing the way we work – whether it’s IT adopting Agile or an organization becoming more nimble.
  2. Reinventing HR – where HR is moving beyond its historical focus on basic people administration, compliance and transactions to a valued place at the executive table; ensuring context and alignment across the business to generate Customer delight.
  3. Reinventing organizations – as the level of human and organizational consciousness evolves from valuing meritocracy, accountability and innovation to valuing self-management, wholeness and evolutionary purpose. (See “Reinventing Organizations” by Frederic Laloux:

All three have the common denominator of people; an integral part along the entire timeline of each movement. As these three movements overlap – at the intersection – will be HR. So, who better to help navigate the emerging paths of each change than “the People’s people”?… otherwise known as “HR”.

An analysis of the Human Resources Professionals Association’s (HRPA) Competency Framework shown below can help guide which HR competencies will have the greatest impact (on a scale of 1 to 10) on Agile.

“How do we get HR started towards their destiny?”

If you’re an Agile team member, invite HR to start a conversation about what Agile is and how they can help you and the team.

If you’re an HR professional, here are some suggestions:

  • Learn about Agile
  • Visit with your Agile teams during sprint reviews or daily scrums
  • Talk to your friends and colleagues about their Agile experiences and challenges
  • Review in-progress HR process & tool changes through an Agile lens
  • Partner with IT and other Agile implementation stakeholders to guide the success of Agile

To help HR take the first step, here are some suggested Agile learning resources:

It’s time for HR to get off the sidelines and get in the game.  HR needs to be a “friend” to Agile, not perceived as a “foe”.

Borrowing from a Chinese proverb,

When the winds of change blow, some will build walls while others build windmills… the harnessing of your greatest natural resource, your people, into power.

Build windmills.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post How HR Can Save or Destroy Agile appeared first on Agile Advice.

Categories: Blogs

Insights into Agile Transformation Success, Part 1

BigVisible Solutions :: An Agile Company - Thu, 02/09/2017 - 18:00
Agility at the Leadership & Organization Layers

Contributors: Mike Dwyer and Richard Lowery

Throughout 2016, SolutionsIQ helped a growing number of companies successfully kick off and execute many large-scale Agile transformations. Having done this now with dozens of enterprises, we decided to retrospect on some of the common elements of a successful Agile transformation. We’ve summarized our findings along the Five Layers of Agile Transformation (read my blog “Leading Agile Change: Proven Change Models for Agile Transformation” for more on this):

Five Layers of Agile Transformation

  1. Leadership – The traditional industrial-age management style (e.g. Taylorism) is not an effective leadership style to maximize performance in a modern, digital organization of knowledge workers. Modern pressures to move and change fast require a different mindset, one that engages employees and challenges them to exploit innovation for competitive advantage. Agile leadership facilitates the emergence of organizational constructs capable of adaptability in the face of ambiguity and constant change. The Agile leader exhibits leadership styles that create a culture of transparency, decentralization, engagement, collaboration and accountability.
  2. Organization – Business Agility refers to an organization’s ability to sense and respond to change in ways that allow it to thrive and innovate. Understood in this way, organization-wide agility is constituted by a set of capabilities. These capabilities are embedded within the organizational structures, policies, and practices, as well as within the cultural beliefs and individual mental models through which an organization functions. This includes on-boarding, employee reviews and incentives; finances and accounting; and everything that enables the enterprise to operate as a healthy living organization.
  3. Product & Business – How clear is the product strategy to the people that are implementing it? What is the connection between the strategy and the daily software development work? Crucial for this connection is the Product Owner role and Product Management skill sets and the way that the enterprise specifies and prioritizes work for the software development team.
  4. Delivery – Agile began as a way to speed up software product delivery and as a result this is the area that is (unfortunately) considered the full extent of what is possible with Agile. As seen in our paradigm, however, the Delivery layer is only one segment that benefits from Agile transformation. Focusing on the practices and processes of teams and groups of teams delivering a project, program or product, Delivery encompasses how well individual teams and sets of teams are using Agile frameworks like Scrum and Kanban, how Lean principles are being applied to value streams, and how successfully we are applying scaling patterns and frameworks like Large-Scale Scrum (LeSS) and the Scaled Agile Framework (SAFe).
  5. Execution – The purpose of Agile is to deliver high-quality value to the customer quickly. At the foundation of this product creation pyramid, therefore, are the technical execution practices and principles that enable development teams to produce high-quality products. This includes the technical practices used in constructing, verifying, validating, and deploying software-based products, which are known in Agile as Extreme Programming (XP) and, more recently, DevOps. Executing within a disciplined Agile framework across the whole value stream can help improve project management discipline, value delivery, and predictability. It helps organizations to identify gaps in their capabilities and to highlight impediments that prevent them from achieving peak performance.

In order for an Agile Transformation to provide lasting transformative results, the employed approach must be holistic and comprehensive. When we help organizations layout their Agile Transformation strategy, we typically anchor that strategy around these five major dimensions of capabilities. Now that we know what the goal is, let’s look at each of these five dimensions in a little more detail to reveal some learning insights into the patterns we have observed in enterprises achieving lasting results with Agile transformation. In this post, we consider the first two layers, Leadership and Organization.


In addition to adopting new leadership behaviors and styles that are congruent with the modern expectations of knowledge workers, leaders of organizations in the middle of a successful Agile transformation have committed to a few key leadership activities, starting with a clearly articulated vision of the future state you are trying to reach. Questions to pose to your board and leadership include:

  • Why is the company undertaking an Agile Transformation in the first place?
  • Is it to achieve parity with peers?
  • Is it to leapfrog the competition in terms of time to market and/or quality?
  • Is it to achieve a level of disruptive innovation and enter new markets?

Being clear on “why” is important, as is making sure the entire enterprise from top-level leadership to middle management and down into delivery teams is aligned and bought into that vision. When you achieve that level of alignment, you can realize some pretty far-reaching and transformative future states.

One additional best practice we have observed is establishing a communication plan. This is more than just a broadcast from leadership; it’s a bidirectional feedback loop that communicates intent, invites and receives feedback transparently, and objectively measures progress.

Lastly, one of the other key success indicators for an Agile Transformation is a greater degree of empowerment throughout the enterprise:

  • Leaders empower middle managers to resolve problems at the sub-executive level and only intervenes when management escalates issues.
  • Management empowers teams to provide guidance in terms of best practices to yield optimal results and only intervene when the team escalates issues.
  • Team members empower each other to be informed about what high quality means at the development level and how to achieve it. Team members are also empowered to request resources to achieve their goals while actively radiating progress.

This is no easy task. It takes a well-conceived strategy communicated by a dedicated leadership continuously and unwaveringly in order to achieve the desired results. That is partly why, in “The Third Wave of Agile”, SolutionsIQ Chairman Charlie Rudd calls for the role of management and leadership to be redrafted to account for the explosive growth of Agile teams and Agile adoption in general.

Naturally, leadership cannot accomplish anything without individuals actually doing the work, so let’s turn to the people in the organization. In particular, we look now at some of the key success indicators in the Organization layer.


For many enterprises, Agile Transformation is the largest organizational change it will ever undertake. The results are deep and broad, including structural and behavioral changes, as well as the introduction of new mindsets that may fundamentally alter the overall culture of the organization — and in a good way.

However, these sweeping changes don’t just happen. In order to become a learning organization with high degrees of transparency and collaboration, the enterprise needs to have a strategy for designing, executing and maintaining change. Many of the organizations enjoying success with Agile Transformation owe it in part to using some classic organizational change management models and frameworks, including:

  • John Kotter’s 8-Step model
  • Prosci’s ADKAR framework
  • Jason Little’s Lean Change Management, a newer emergent model that is starting to get a lot of attention

What makes organizational change management so thorny is that people – many, many people, all with their own capabilities and fears – are the focus. Change, as will surprise no one, is something that few people enjoy. Often leadership, specifically, creates a corporate culture against change, because fluctuations of even the smallest degree can affect the bottom line. Operating under a traditional world view where the market is wieldy and fluctuates little to not at all, stability is the only important metric. However, in today’s continuously changing business world, only those institutions – and those people – who are capable of learning and growing and changing as quickly as possible have a horse left in the race. In other words, organizational change management must be a part of any successful enterprise’s survival kit. Otherwise, any and all success will be short-lived.

This is where departments traditionally seen as “support” (HR, finance, recruiting — even sales and marketing) are brought into the change equation. In organizations who want people resilient to and even adept at change, for example, human resources and recruiting has to be better at finding and keeping them. In addition, to achieve long-lasting changes to mindsets, culture and behavior, enterprises must fundamentally rethink their overall incentive programs — and this is exactly the trend we are witnessing with many of our clients. The corporate value of collaboration becomes suspect when individuals are rewarded and promoted at the expense of their own team mates. Fortunately, we have seen a handful of our clients switch to more team-based rewards so as not to undermine their hard-earned successes achieved through Agile transformation. Positive, managed changes throughout the organization like these require consistency and transparency, which creates an even stronger imperative to leverage tried and true change management models.


So as you can see, there are a number of dimensions to a successful Agile Transformation. We’ve explored the first two, Leadership and Organization:

  • Leadership – Agile leaders exhibit leadership styles that create a culture of transparency, decentralization, engagement, collaboration and accountability. Enterprises who have success with Agile Transformation include a focus on Leadership as part of the overall transformation strategy.
  • Organization – The success of any enterprise lies in the people on staff. Enterprises who have success with Agile Transformation use change management frameworks and tools in order to manage and maintain change in the direction of the desired organizational culture. These enterprises also update their approach in support roles like HR and recruiting.

In the second part of this series, we continue the discussion by exploring the remaining three dimensions of a successful Agile Transformation: Product, Delivery and Execution.

Be the first to get your hands on the white paper “Insights into Agile Transformation Success” — sign up for our AgileUp newsletter!

The post Insights into Agile Transformation Success, Part 1 appeared first on SolutionsIQ.

Categories: Companies

Running Windows Containers on Azure Service Fabric - Part II

Xebia Blog - Thu, 02/09/2017 - 13:39
The previous post showed how you can create an unsecure Service Fabric test cluster in Azure, and how to run a Windows Container on it. In this follow up post, I'll show you what's going on inside the cluster, using the Docker command line. Knowledge about this can be very useful when troubleshooting. Verify your container
Categories: Companies

Running Windows Containers on Azure Service Fabric

Xebia Blog - Thu, 02/09/2017 - 13:37
Background Since the release of Service Fabric runtime version 5.4.145, Microsoft added a (preview) feature to run Windows Containers on Windows Server 2016. The Linux version already supported this for a while. This post explains why Containers are useful and how to get it to work. What is Service Fabric? Most companies have a lot of applications
Categories: Companies

The value of coaching

Growing Agile - Thu, 02/09/2017 - 10:27
If you’ve never been coached you might not know that the role of a coach is not to offer advice, judgement, or solutions. Their role is to listen deeply, ask powerful questions, help you explore answers you already have within yourself, and help you craft a definitive action that you then take. We recently attended […]
Categories: Companies

Certified ScrumMaster Training Workshop in Toronto—April 18-19

Notes from a Tool User - Mark Levison - Thu, 02/09/2017 - 01:01
Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Toronto—April 18-19 taught by certified ScrumMaster Trainer Mark Levison.
Categories: Blogs

Certified ScrumMaster Training Workshop in Montreal—April 10-11

Notes from a Tool User - Mark Levison - Thu, 02/09/2017 - 00:51
Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Montreal—April 10-11 taught by certified ScrumMaster Trainer Mark Levison.
Categories: Blogs

Predicting the Future (link)

Learn more about transforming people, process and culture with the Real Agility Program

I just read a great article Impressionism: Go ahead, try to predict life. You’ll fail


Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Predicting the Future (link) appeared first on Agile Advice.

Categories: Blogs

Top 5 Lean Books to Add to Your Reading List

Practicing Lean depends upon fostering a student mentality — recognizing what you don’t know, and approaching the...

The post Top 5 Lean Books to Add to Your Reading List appeared first on Blog | LeanKit.

Categories: Companies

How a Non-Agile Big Corporation Lost Out

Learn more about transforming people, process and culture with the Real Agility Program

The Scenario

In a search for new vistas and growth, my husband had been scanning employment ads across the country and applied for a job he was well-suited for with a large corporation. He received two interviews by telephone and SKYPE. The new job would require us to move several provinces, leaving family, friends and a community we were attached to.

He received confirmation by telephone that the corporation wanted to hire him. We spent a few days agonizing over a decision, consulting with family and friends, praying about it, and decided my husband would accept the job. After his verbal acceptance, a contract followed a few days later, which he duly signed and sent back. He was told it had been signed at the other end and he could now announce the new job publicly.

He gave notice to his present employers, as did I mine, and we proceeded to take steps to put our house on the market, search for housing in the new city, and pack. We had begun to say good-bye.

Three days later a phone call came from the HR Department of the corporation saying they had to rescind the contract as someone “higher up” had not given approval for it.

We were stunned. There had been no hint in any part of the process that the job offer was in any way tentative or not thoroughly vetted. We had taken many steps forward, and now had to backtrack several steps.

My husband had to go, hat in hand, to his current employers to see if he could retain his job. After a painful good-bye session with my team I had to inform them that I was not leaving.

This whole experience has brought to mind the importance of what my employer, BERTEIG Inc, is attempting to do through agile training, consulting and coaching.

The “Agile Manifesto” proclaims:

“Individuals and interactions over processes and tools.”

And, further on: “Customer collaboration over contract negotiation.”

These are prime values to be lived by small and large businesses.

Admittedly, Agile was initially created for software developers, but more and more corporations and organizations are seeing the value in being agile, and are responding to this necessary change of culture in what is currently a time of deep disruption.

What If?

What if the corporation my husband was contracting with had honored the implications of “individuals and interactions over processes and tools” and “customer collaboration over contract negotiations?”

If some “higher up” had not actually given approval for this hiring, once the contract was signed at both ends (which it was), could this higher-up not have responded with more agility, more compassion, and more ethically?

What if he had acted in such a way that, even if he did not approve the contract, he acknowledged the good intentions of both sides and let it go? After all, his corporation was getting a highly-qualified, experienced employee.

What if he was transparent and acknowledged that the contract was not to his liking, and asked would my husband consider some other version of it? And then consulted directly with my husband and HR over certain changes to the contract? And made sure everyone was agreeable with the changes?

What if the “higher-up” just called my husband directly, apologizing that the contract was made without his say-so, that they were not in a position to hire him, and offered two-months salary for any damages – material and emotional – that had been incurred?

The above scenarios could have changed the situation from one of loss, to one of win-win for both sides. Agile frameworks are clearly proving to be of great benefit to employers and employees alike.

Hundreds of eager attendees take Certified Scrum Master and Certified Product Owner training from us. Many have taken our Certified Agile Leadership offering in cooperation with Agilitrix. Do the corporations they belong to welcome the changes these attendees are prepared to make? Are corporations taking steps to truly alter their culture?

The Losing End

My husband was almost employed in that organization, where hundreds of others are employed. I wonder how often their employees experience this type of trauma, since this neglectful handling of my husband’s contract is a likely sign of ongoing cultural problems within.

This rescinding of a contract was a losing situation on both ends. The corporation in question lost a highly-talented employee who would have been extremely loyal and hard-working (as was determined in the interviews). My husband lost professional credibility having to backtrack with his current employers. We lost the challenge of a new adventure.

We’re recovering, despite this having a huge emotional impact on our lives. We’ve been agile enough to say: we’re still here, we still have jobs, we can make the best of it all.

I just wish that Big Corp would get it. And soon. Before more is lost.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post How a Non-Agile Big Corporation Lost Out appeared first on Agile Advice.

Categories: Blogs

From Tasks to Stories with Value

Johanna Rothman - Wed, 02/08/2017 - 19:06

I’m almost at the end of the January Practical Product Owner workshop. One of the participants has a problem I’ve seen before. They have a backlog of work, and it’s all tasks. Not a story in sight.

I understand how that happens. Here are some ways I’ve seen the tasks-not-stories problem occur:

  • The technical people see the work they want to accomplish. They create a list of tasks to get there: design database, create infrastructure, fix these typos in the UI, and more.
  • Or, someone (such as an architect) is in charge of breaking down work, not team members. That person creates tasks.
  • Marketing or sales (or someone not in the product development team) says something like this: “I want a drop-down menu,” or a radio button or another report. They don’t remember to explain who the value is for, or why they want that value. Pretty soon, the idea of value is gone altogether, and only tasks remain.
  • Teams start to create stories, and the stories are so large, they create tasks to cover the stories. Pretty soon, they stop creating stories at all. They only create tasks.

Here’s a gotcha: When teams measure story points as opposed to features, they often feel pressure from management to do more points. (See Who’s Playing Agile Schedule Games?)

Your customers don’t buy points. They buy completed features.

Something clicked for the participant last week. He saw the feature chart, which explains how scope expands during the project and what the team(s) delivers.

This chart shows the features complete, added, and remaining to do. Because it measures features—what customers buy and use—there’s no confusion about work done or not done. Plenty of work might be done. But, if the work doesn’t add to a feature, the work is inventory (or possibly waste).

Here’s one value of this chart: Until tasks add up to features, you don’t count them.

My participant couldn’t articulate the problems before. The chart helped him see and discuss:

  • Tasks—by themselves—might not add up to a feature. He wants features.
  • When he counts features, he can describe what’s in a feature set—a collection of features that you might call an epic or a theme.
  • He can explain why he wants just this small feature, and not necessarily all of a feature set for now.

The chart helped him see how to separate stories and count them. He is moving from tasks and technical stories to features, real user stories.

I use this chart with cumulative flow diagrams and the product backlog burnup chart to see where our work is and how much progress we make over time for a given feature set.

I recommend you build and count features (stories). The smaller you can make a story, the faster you can get feedback and see the value in it.

If you’re interested in this workshop, I have just announced the May 2017 dates. See Practical Product Owner Workshop: Deliver What Your Customers Value and Need.

Categories: Blogs

The Canvas Strategy

I’m making my way through the Tim Ferris' book Tools of Titans. It’s well over 600 pages but it has a lot of useful, interesting advice, though I'll admit some of it is a bit out there. He breaks the book up into three areas; Healthy, Wealthy, and Wise. The book is really just a summary of podcasts done over the years with some other advice added in.
One piece of advice I appreciated is what he called the canvas strategy. The idea really came from Ryan Holiday. The name refers back to when apprenticeships were common; a budding  painter learns his craft by serving under a master and doing such things as preparing his canvas. 
In today’s terms it’s about serving the people you work for…sounds like servant-leadership! Some examples he gives includes ideas such as giving your boss an idea you came up with and not looking for credit or finding out the job no one else wants to do and taking it on yourself.

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px 'Helvetica Neue'; color: #454545} p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px 'Helvetica Neue'; color: #454545; min-height: 14.0px}
This strategy will accomplish a number of things. It will keep your ego from getting to big.  As you make those around you successful, you will also become more successful; the adage "a rising tide lifts all boats." Finally, if you're feeding ideas to your boss, or coworkers, then you will start steering the direction they are going.
Categories: Blogs

Digging Into the “Works On My Machine” Problem

Derick Bailey - new ThoughtStream - Wed, 02/08/2017 - 18:12

Someone recently asked me why developers should care about the “Works On My Machine Problem”.


While I can say that I implicitly know that this is bad, the question caught me off-guard.

I was able to provide a basic answer – needing to deploy applications to production, have coworkers be able to run our code in development, etc. – I realized I don’t have a strong answer for this question.

So I Did Some Research and I Found … Very Little.

It seems all the “Works On My Machine” blog posts and articles out there (at least, the ones I found after a few quick google searches) are focused entirely on the “how I solved <this WOMM instance> with <my favorite tool set>”.

There are few, if any, blog posts and articles that really hit the heart of why this statement is a problem, or the underlying issues that this statement is obscuring.

What I want, then, is a broad view of the situation.

  • What causes people to say “Works On My Machine”?
  • What are the problems that this statement hides or causes?
  • What kinds of solutions exist, to help fix or prevent this?
  • etc.

To that end, I put together a quick survey and I would love to get your input.

A Short Survey Of WOMM

If you’ve ever said “Works On My Machine!” to anyone, or had it said to you, take a few minutes and

Answer the Works On My Machine Survey

I’m planning to use the results as a blog post to start, but there will be other uses for the information. All of the questions are optional, as well.

The post Digging Into the “Works On My Machine” Problem appeared first on

Categories: Blogs

Scaling Agile with the Theory of Constraints

Scrum Expert - Wed, 02/08/2017 - 17:13
Lear how to use the Theory of Constraints to scale Agile and Scrum development teams. The Theory of Constraints is a methodology for identifying the most important limiting factor (i.e. constraint) that stands in the way of achieving a goal and then systematically improving that constraint until it is no longer the limiting factor. While implementing Scrum and shortening Time To Market in large financial institution we were slowed down because of obstacles in planning and analysis. I came with the idea to use Theory of Constraints which helped us to calculate real TTM and gave us hints how to release faster and cheaper. Now they’re ready to change direction anytime and do releases more often. This presentation is suitable for people in organizations trying to lower workload of releases. Video producer:
Categories: Communities

Definition of Done

Leading Agile - Mike Cottmeyer - Wed, 02/08/2017 - 15:14

definition of done

Is it done, is it done done, or is it done done done?

I bet you’ve asked that question before, if you are in the business of application development.  When asking the questions, it is important to note who you are and your level in the organization. Delivery teams, program teams, and portfolio teams define done differently. For certain, we need is a clear definition of done at each level of the organization.

Definition of Done

The definition of done (DoD) is when all conditions (acceptance criteria) that a software product must satisfy are met, to be accepted by a user, customer, team, or consuming system.  We must meet the definition of done to ensure quality.  It lowers rework, by preventing user stories not meeting the definition from being promoted to higher level environments. It will prevent features not meeting the definition from being delivered to the customer or user.

User Stories

The most common use of Definition of Done is on the delivery team level.  Done on this level means the Product Owner reviewed and accepted the user story. Once accepted, the done user story will contributed to the team velocity.  Meet all of the defined criteria or the user story is not done.

The below examples might be included in the User Story DoD:

  • Unit tests passed
  • Code reviewed
  • Acceptance criteria met
  • Functional Tests passed
  • Non-Functional requirements met
  • Product Owner accepts the User Story

Done on this level may mean it qualifies to add to a release.  Not all user stories need to be completed. Rather, it means the feature may be sufficient to satisfy the need. Once accepted, the done feature will contribute to the release velocity.  Meet all of the defined criteria or the feature is not done.

The below examples might be included in the Feature DoD:

  • Acceptance criteria met
  • Integrated into a clean build
  • Promoted to higher level environment
  • Automated regression tests pass
  • Feature level functional tests passed
  • Non-Functional requirements met
  • Meets compliance requirements
  • Functionality documented in necessary user user documentation

Done on this level may refer to a organizational strategic priority, portfolio plan item, or some other collection of features that satisfied a market need.  Not all user stories or features need to be completed. Rather, the epic may be sufficient to satisfy the need. Once accepted, the done epic will contribute to throughput calculations to see if the supply is in balance with demand.

The below examples might be included in the Epic DoD:

  • Non-Functional requirements met
  • End-to-end integration completed
  • Regression tests pass
  • Promoted to production environment
  • Meets defined market expectations

Just as the definition of ready is super important, so is the definition of done.  Never start work on something until you have agreed on the definition.  Be consistent. Be clear. Have a shared understanding.

The post Definition of Done 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.