arimidex online https://pharmarxcanadian.com/buy-arimidex-online/

Tag Archives: kanban

  • -

What is Systems Thinking Leadership?

Tags : 

A Rube Goldberg Machine

A Rube Goldberg Machine. Photo by freshwater2006

The conventional wisdom is that leadership is associated with a role. It is something to be left to Bosses, Managers, and those who have authority. This model worked fine when markets moved slowly and competitors had the same leadership model.

Today, business is very different. Markets change very quickly, competitors continually try to take your customers, and the lifespan of companies has shrunk . “The average lifespan of a company listed in the S&P 500 index of leading US companies has decreased by more than 50 years in the last century, from 67 years in the 1920s to just 15 years today, according to Professor Richard Foster from Yale University. Today’s rate of change “is at a faster pace than ever.”

If companies are to survive, they will need a model for leadership that is different than in the past, because, as the accelerated corporate death rate shows, relying on the old methods of leadership has Darwinian implications.

Leadership must move out of the hierarchy and to the front lines. It must move from one or a few brains, to all the brains in the organization. Leadership is no longer a role, it is a task. This task is best accomplished by the person with the most/best information at that time. In most organizations, the person with the best information is rarely the Boss or the Manager, because almost all of their information is second hand.

Leadership needs to be delegated from these Bosses and Managers to the people doing the work with the best information. This has implications for everyone. It means that positional power is not as important to company survival, but too much positional power can threaten company survival.

So, how do we enable Leadership at the front lines? Training? Coaching? Empowering? While all those things can help, the answer is NO. If you want a company that survives and thrives now and beyond, then focus on Organizational Design. The structure of your organization defines how decisions are made, how people are rewarded, what positions have power, what policies are enforced and by whom.

Changing the organizational structure with the specific goal of enabling Leadership at the front lines is a crucial step building a company that will last. This is Systems Thinking Leadership.


  • -

How Spotify Works. Agility with 1 product and 1200 people

Tags : 

Scaling Agile at Spotify. What True Organizational Agility Can Look Like.


Henrik Kniberg and Spotify released an illustrated video on how Spotify is Scaling Scrum and Agile from a 1 team startup to a 1200 person powerhouse of the online music industry. Spotify is a disruptive force in the music industry, forcing record companies, radio stations, and artists to rethink their business models. Spotify is also an Agile company from the ground up. Spotify got its start using Scrum with one team, so there has been no “Agile Transformation” for the company. Instead the company faced the problem of how to maintain the Agility they had with one team while growing quickly.

The video describes their team structure, the organizational structures that span multiple teams, and the key principles that guide their decision making. I think it is fantastic that Spotify was willing to open the Kimono and show the world how they work, and that Henrik, as their Organizational Coach was able to present it is such a compelling visual way.

This is the cutting edge of organizational agility. For most companies, this kind of organizational model is a fantasy, it is so far removed from their current organization’s structure. If I were a music company executive, I would be scared as hell. Instead, I look forward to continuing to help companies achieve their own improvements for Agility in their own business context.

Part 1 of How Spotify’s Engineering Culture Works


  • 1

Dude! Where’s My Backlog? The People and Process of Product Ownership.

Tags : 

In September 2010 I gave a keynote talk at Agile Eastern Europe called “Dude, where’s my backlog?” The talk covers the common pitfalls seen with Product Owners and the Product Backlog. The talk covers the people that bring a product backlog into existence and the processes they can use to maintain it. This includes using ideas from Kanban for personal process and modifications to Scrum for more frequent involvement of the team in maintaining the backlog.

Robin Dymond Keynote: “Dude, where’s my backlog?” from Agile Eastern Europe 2010


  • -

Kangaroo boxing: Scrum vs. Kanban.

Tags : 

Software development has its trends and its innovations. The term Agile came about because people practicing different iterative workstyles decided to come together and develop a brand, Agile, that represents their common principles and values. Agile workstyles include Scrum, eXtreme Programming (XP), Crystal Clear, Feature Driven Development (FDD), and Dynamic Systems Development Method DSDM. Then people like Mary and Tom Poppendeick recognized that Agile software development could benefit from the ideas of the Toyota Production System, also called Lean for western implementations. Now some of the proponents of Lean, many of them from the Agile community, have been attacking Agile methods like Scrum, claiming that Lean is “better.” To me this doesn’t make sense. Agile and Lean ideas are complementary. Ideas from Lean come from manufacturing, so applying them to software development requires care and understanding of how software is different, and why. More importantly however, the conflict goes against the spirit of Agile, and does not do the software development community any good. It drives a wedge and a barrier where there should be none. It causes proponents of either camp to ignore or resist good ideas from the other. Primarily this conflict seems driven by personalities in the community who see personal gain and status with attacking another’s work. The idea that in a community of thinkers one can gain reputation by putting down other proven and legitimate ideas is false. Gaining reputation in a community of thinkers such as software development requires that you show leadership in new ideas AND in integrating new ideas with proven ideas already in place. The battle of Scrum vs. Kanban reminds me of kangaroo boxing… Richard Attenborough narrates…


  • -

Combining Scrum with Kanban for support and enhancement teams.

Tags : 

I often hear: “How I can use Agile on support teams who do defects and small enhancements on multiple platforms?” Support, “business and usual,” defects, and enhancements are ideal for an Agile team. Think about it for a minute: the changes are usually small and independent, they are doable in a short time, and can often be deployed without major architectural or data related changes. This article describes how Scrum was modified to improve a support team’s process.

In the fall of 2005, a production support team of developers, testers, and analysts was setup to support 5 different production systems. The team was responsible for completing customer support requests for defect fixes and small enhancements. Major enhancements were handled by the platform teams. There were 5 different customers that made requests for each system. The team was setup to use Scrum, with Amy Ripley, CSM as Agile Coach and a single Product Owner. The Product Owner worked with the customers to define a single product backlog with priorities for all requests across the 5 systems. While each customer had different needs, many of the systems had interactions, so priorities were easier to determine than if all were disparate systems.

The team was co-located in an Agile team room and started out using standard Scrum with a 3 week iteration length. As the team and the Coach worked together, they realized that Scrum did not account for some of the unique properties of an enhancement and defect support team such as:

  • Customers want quick turn around on fixing defects found in production
  • Defect and enhancement implementation is small piece work compared to building new application features
  • Requests for changes are independent of each other

Managing 5 customer’s expectations lead to pressure for more frequent updates to production. The Coach and the team saw this as a valid concern, and decided to make changes to their Scrum process that would better suit the small piece work and customer needs for faster turn around. The changes included:

  • Weekly releases to production. Given the production support nature of the team they changed their release pattern from once per 3 week iteration to weekly releases.
  • Allowing work to cross iteration boundaries. Some requests would be started later in the iteration but could not be completed by the iteration’s end. Given the weekly releases, this was acceptable, since the customer would not have to wait for a whole iteration to see the item in production.
  • The regular story board was not providing enough clarity as to what was in progress and its state. A more structured Kanban style board would allow the team and stakeholders to more accurately track progress of work items. A Story board was implemented to show the status of a User Story that was in progress. The story would move with its task cards through analysis, dev, test, and release columns on the board. Each the 5 systems had rows for their stories.
  • A team agreement was made to take each work item from beginning to completion before starting a new work item. As could be expected in a large organization, issues frequently came up that would stop progress a work item. When progress was stopped by obstacles outside of the team’s control, then a team member could start on a new work item. These obstacles were escalated to the Coach, the Product Owner and management for resolution.

This kanban style User Story board really helped the Scrum team, Product Owner and stakeholders understand the state of work at any time. The kanban style User Story board also helped reduce work in progress, since once a story was started, team members would not start on another story until it was completed.

The team continued to use the Scrum practices of self organization, the 4 meetings and a 3 week iteration length. The team and stakeholders valued the planning, it helped set expectations for everyone as to what could be completed in the near term. The demo meeting allowed the 5 Customers gain visibility into all the work done by the team. This “see the whole” is a key principle in Lean and with this team it provided a key benefit to maintaining stakeholder equilibrium, as all of these systems served the same department and overall business function. The Scrum principle of self organizing teams was also maintained, as they achieve higher performance and have higher morale than directed teams. Self organization also frees leadership to innovate and create more effective work environments.

Congratulations to Agile Coach Amy Ripley and team for inventing this Kanban style board and process for their Scrum.

“Two strong personalities and too much debate. Need is the mother of invention”
– James Grenning on inventing Planning Poker