Portfolio Management and Organization Flow

I’ll be speaking at RallyON Europe this September on the topic of Portfolio Management and Organization Flow.

Complexity of product development increases as we move from a single team or product focus to a cross-organisation portfolio focus. Organisation Flow is about achieving the Lean concept of flow at an organisation level, not just at the level of a single product or product line.

This session will look at an approach to portfolio backlog management, and describe how to manage the flow of work through a portfolio of multiple products delivered by 50 teams in 6 locations across the US, Europe, India and China.

We will include examples of some core metrics that help understand throughput and flow in the organisation. These metrics tell a story about what is happening in the organisation. Lessons from these stories include understanding impediments to flow, and understanding who and what in the organisation is influencing flow.

I did an interview last week with Hannah Shain from Rally. The recording from the interview is here:

There’s a great lineup of content for the conference. If you’re in London I hope to see you there!

Update: Here is the slide deck I used at the conference:

Enjoy a Lean Coffee

What is Lean Coffee?

Jim Benson and Jeremy Lightsmith founded the Lean Coffee movement in Seattle in 2009. Since then, Lean Coffee events have sprung up around the world. The basic idea is for a group of people to get together to discuss topics around which they share a common interest, specifically around agile, lean, kanban, lean startup, etc. There is also an OpenCoffee movement, founded by Saul Klein in 2007. The intent behind OpenCoffee is to provide an open forum for investors, entrepreneurs and developers to come together, meet, discuss ideas, and find opportunities to work together.

The Lean Coffee format is essentially an approach to facilitating learning and collaboration through group discussions. The ‘Lean’ part of the name has its roots in Lean Thinking, and related areas of Lean Production, Lean Software, Lean Startup, etc. The ‘Coffee’ part of the name obviously comes from that nice drink that some of us are partial to. Meetups typically take place in the morning, at a local coffee house, at the same time and place each week.

Lean Coffee events are increasingly becoming a fixture at many conferences, in a similar way that Open Space has. We had a great Lean Coffee event at LESS2011 in Stockholm last year.

How it works

The Lean Coffee format has a lot in common with Open Space, particularly in the sense that you are asking people to move away from an agenda-driven gathering to a more open, collaborative, dynamic, emergent type of gathering.

The protocol, borrowed and modified from the Sydney Lean Coffee group and Limited WIP Society, is as follows:

  1. Everyone offers topics they are interested in discussing by writing them on index cards (or sticky notes).
  2. Everyone presents his or her topic as an Elevator Pitch (max 1 minute per topic).
  3. Use dot voting to vote on each of the topics.  Each person gets two votes. You can only vote once per topic.
  4. Prepare three columns on a table or wall. Call them “Planned”, “In Progress” and “Done”. Add all topics to the “Planned” column, with those that received the highest votes at the top.
  5. Discuss each topic in turn. Move the index card for the topic into the “In Progress” column. Initially, ask the proposer to explain the topic, then go round the table to give an opportunity for everyone to provide an initial comment, then open discussion.
  6. When the topic is done, move on to the next one.  The topic proposer decides when the topic is done, and moves the index card to the “Done” column.  If someone disagrees, then s/he can raise a new topic.  Expect to discuss 3-4 topics over the space of an hour or so.
  7. Consider time boxing each topic to 15 minutes max.
  8. At the end of the overall Lean Coffee session, run a quick retrospective.  What did you like? What didn’t you like? What are ideas for improvement?

As a variation, particularly if you have a large group, consider splitting into sub-groups if people are particularly passionate about specific topics. Then get back together after the topic discussion to present highlights to, and get feedback from, the wider group.

Lean Coffee at work

The idea and format for Lean Coffee is very simple and effective. It can be used in work too. For example, consider hosting a Lean Coffee event every week in your office. It can be a great way to share experiences and challenges across teams and gather interested people who don’t normally get to discuss these topics together.

If you find your retrospectives are becoming routine, then this is a good way to break out of the rut. There is no leader or facilitator required. The team can self-organize a Lean Coffee style event without any preparation. The team decides which topics to discuss, and how long to spend on each topic.

The only prerequisites are a set of index cards or sticky notes, a set of Sharpies, and some interested and willing people.

References

Some sites for Lean Coffee Meetups around the world:

Writings about Lean Coffee

Obstacles to decision making in Agile software development teams

This is the abstract from a paper I co-wrote with Kieran Conboy and Meghan Drury. It was published in the June 2012 issue of Journal of Systems and Software. The full paper is available from Elsevier.

Drury, M., Conboy, K., and Power, K. (2012). “Obstacles to decision making in Agile software development teams.Journal of Systems and Software, 85(6), 1239-1254.

Abstract

The obstacles facing decision making in Agile development are critical yet poorly understood. This research examines decisions made across four stages of the iteration cycle: Iteration Planning, Iteration Execution, Iteration Review and Iteration Retrospective. A mixed method approach was employed, whereby a focus group was initially conducted with 43 Agile developers and managers to determine decisions made at different points of the iteration cycle. Subsequently, six illustrative mini cases were purposefully conducted as examples of the six obstacles identified in these focus groups. This included interviews with 18 individuals in Agile projects from five different organizations: a global consulting organization, a multinational communications company, two multinational software development companies, and a large museum organization. This research contributes to Agile software development literature by analyzing decisions made during the iteration cycle and identifying six key obstacles to these decisions. Results indicate the six decision obstacles are unwillingness to commit to decisions; conflicting priorities; unstable resource availability; and lack of: implementation; ownership; empowerment. These six decision obstacles are mapped to descriptive decision making principles to demonstrate where the obstacles affect the decision process. The effects of these obstacles include a lack of longer-term, strategic focus for decisions, an ever-growing backlog of delayed work from previous iterations, and a lack of team engagement.

Happy Memories of the ALE2011 Spouse and Kids Program

I was having lunch with Jurgen, Olaf and others at XP2011 in Madrid earlier this year. The details for what would become the first ALE conference would start to be worked out later that week. Jurgen asked me if I had any thoughts about what we could do that would be a little different. I thought it would be good to find a way to include spouses and children in the conference program – not just bring them to wherever city the conference was going to be in, but actually integrate them into the conference.

The Spouses and Kids Program

Monika KoniecznyOlga Woronowicz and Christiane Lewitz took on the job of leading the Spouse and Kids Program and did a great job organizing the program. Mornings were filled with games and other activities in the conference hotel. There was a trip organized for each day after lunch. On Wednesday, there was a visit to Berlin Zoo. On Thursday, it was the Berlin Communications Museum. On Friday they had a dinosaur tour at the Natural History Museum.

Post-It Art

Last week I wrote about Post-It Wars, and how we tried it out at work. I had the chance to hang out with families of other conference attendees (and my own family) at ALE2011, so I got them all to play too. We started off in the room that was reserved for families. The kids had a great time. After some negotiation, they quickly agreed on the music, picking out the Beatles and Bob Marley. Music blaring, they got to work. It was amazing to watch as a group of kids who had never met until a few hours earlier came together to create pictures using Post It Notes.

ALE2011 Kids Making Post It Art
ALE2011 Kids Making Post It Art

While the other conference attendees were in one of the sessions, we broke out into the coffee break area (bringing music with us) and used the windows there too (top left). The parents got in on the action too, and had fun with it. I got some pictures of the work-in-progress from outside the hotel (top right), and their work attracted the attention of some passers by (bottom center).

ALE2011 Post-It Art Collage 1
ALE2011 Kids Make Post-It Art
ALE2011 Kids Making Spongebob
ALE2011 Kids Making Spongebob
ALE2011 Kids Making Spongebob
ALE2011 Kids Making Spongebob
ALE2011 Kids Making Apple Logo
ALE2011 Kids Making Apple Logo

The hotel windows provided a great canvas to work from, and fortunately the hotel staff were very understanding 🙂 Here is what their work looked like from outside the hotel:

ALE2011 Kids Make Post-It Art

Afterwards, we went outside to admire their great art work. Never one to pass up on some fun, Mike came too 🙂

The ALE2011 Post-It Wars Team
The ALE2011 Post-It Wars Team

Some of the kids put their new skills to good use at Thursday night’s dinner.

Marshmallow Challenge

The Marshmallow Challenge is a fun game that I often play with teams. You can play it with friends and family too. At ALE2011 I played it with the ALE families. This time they picked Red Hot Chilli Peppers, U2, Bon Jovi and the Beatles. Rock’n’Roll!

ALE2011 Families Play the Marshmallow Challenge
ALE2011 Families Play the Marshmallow Challenge
ALE2011 Families Play the Marshmallow Challenge
ALE2011 Families Play the Marshmallow Challenge
ALE2011 Families Play the Marshmallow Challenge
ALE2011 Families Play the Marshmallow Challenge
ALE2011 Families Play the Marshmallow Challenge
ALE2011 Families Play the Marshmallow Challenge

Other Games and Activities

Oana Jancu, whose kids were also there, taught everyone ‘Where Are Your Keys?“, an amazing game for learning new skills, particularly new languages. The kids used the game to learn some Portuguese, French, and Irish. Monika played lots of games, arts and crafts activities.  Christiane spent all day Wednesday and Friday with the families. She taught them origami and brought them to the Zoo and Natural History Museum.

ALE2011 Spouse and Kids: Zoo Tour -The Elephants at Berlin Zoo
Learning About Elephants at Berlin Zoo

That’s an elephant’s tooth the tour guide is holding.

ALE2011 Spouse and Kids: Zoo Tour - Watching the Monkeys at Berlin Zoo
Watching the Monkeys at Berlin Zoo
ALE2011 Spouse and Kids: Zoo Tour - Feeding the Monkeys at Berlin Zoo
Feeding the Monkeys at Berlin Zoo

Why Include Spouse and Children in a Conference?

There are at least three big reasons why I think its important to include a Spouse and Kids Program in the conference:

  1. Some of us attend a lot of conferences. That’s a lot of time away from home and family. Being able to bring them with us and hang out during and around the conference is a good thing. Even if you go to only one conference, it’s still nice to be able to bring your spouse and kids. Of course you can bring your family on any trip; the difference with ALE2011 is they were an integrated part of the conference. I like that my wife and children could meet some of the people I have come to know and consider friends. It’s fantastic that my kids can have the opportunity to make friends with other kids from around the world. Vasco tweeted that it made his quality of life better; I concur.
  2. It gives our families a chance to see what we do at conferences. It can be hard sometimes to explain to our families what we do for a living. This gives them some insights.
  3. It is an opportunity to inspire kids to consider a career in our industry. Many countries are struggling to find people with the right skills to fill job vacancies, and there is a growing shortage of children (particularly girls) taking science, maths and engineering courses in school and university. This is a real crisis for our profession. Attending a fun conference can leave them with positive feelings and memories. If they can see that what we do can be a fun and rewarding path, and spread the word to their friends, that can only be a good thing for the future of our industry.
ALE2011 Kids Post-It Art Team with Ice Cream
ALE2011 Kids Post-It Art Team with Ice Cream

Looking Ahead

It was a great pleasure to meet and spend time with the families of Oana, Vasco, Kurt, Andrea and others. I hope this is a tradition we can continue at ALE conferences, and maybe even extend to some other conferences. Based on feedback so far, including the retrospective output, it seems to have been a positive experience overall. Let’s see how we can make it even better for next time.

Using Silent Grouping to Size User Stories

Introduction

User stories are used to describe the functionality delivered in a product or system. Planning Poker is a common technique for sizing user stories, but it can sometimes be challenging. It can be time consuming and teams can get bogged down in unnecessary discussion. There is a technique called Silent Grouping that can be used to compliment Planning Poker, allowing large sets of user stories to be sized in minutes. Silent Grouping has several advantages. It is fast, which in turn leads to significant time and cost savings.

The Silent Grouping Technique

Background

Silent Grouping is a facilitation technique for getting people to group related items without talking. Jean Tabaka has a summary of the technique in her book ‘Collaboration Explained’ as part of a set of techniques used to help teams process large amounts of information. Jean’s variation of the technique is described in the context of conducting a retrospective, but it is equally applicable to grouping user stories.

Overview

There are variations in how this technique is applied. I usually apply the technique in four parts: preparation, individual placement, group placement, and, finally, discussion and reflection. Each part serves a specific purpose, as shown in the table:

Part

Goals

Preparation

Lay the ground rules; set expectations

Round 1: Individual Placement

Quickly get an initial size estimate for all of the user stories

Round 2: Group Placement

Give everyone an opportunity to (silently) provide input to all user stories

Discussion and Reflection

Resolve any disputes; reflect on experience; gain consensus before moving on; discuss insights

Preparation

The facilitator prepares the board. The columns represent the groups referred to in the name of the technique. The team needs to decide on a scale to use for user story point sizes. Many agile teams now use the Fibonacci sequence for user story point sizes. The user stories should be placed somewhere visible and easily accessible so a smooth flow can be established. Pinning or sticking them to an adjacent wall space or laying them out on a table works well. The board should look like this before the team begins:

Blank Sizing Wall for Silent Grouping

It is a good idea to prepare a Parking Lot for any user stories whose grouping cannot be agreed. I usually put this just beside the Grouping board.

Choose and agree a mid-size user story for starting off. This is the bench mark against which the first few user stories will be compared. After that, triangulation will take over and people will size the current user story against all currently sized user stories.

If the team is new to Silent Grouping, the facilitator explains the technique as part of the preparation, and answers any questions.

Round 1: Individual Placement

Team members take turns, one at a time, to place one user story on the board. The goal in this round is to get all the user stories on the board, and hence get an initial size estimate for all user stories.

I find that simply forming a line is the easiest way to run this part of the exercise. As each person takes their turn, they rejoin the back of the line.

Round 2: Group Placement

The team stands around the board. At this point all user stories are on the board. Team members take turns stepping forward and moving one user story at a time. The goal in this round is to get to team consensus on the size of all the user stories.

There can be contention in this round. A user story can get moved repeatedly, e.g., one team member can move a user story, e.g., from a 5 to an 8, and another team member can move it back to a 5. The team has been instructed to consider why the user story might have been moved. Very often, this act of observation and conscious consideration is enough to resolve the disagreement, and the parties will agree on a size without any verbal discussion.

It can happen that two or more people will move a user story back and forth between two (or more) columns, and nobody is prepared to compromise. This is generally a signal that more discussion is required for this specific user story. As the facilitator, when you observe this interaction just remove the user story form the board and place it in the Parking Lot that you prepared earlier. In practice I have found that this tends to occur relatively rarely.

Risks to watch out for in this round include people not participating. This can take a number of forms. They can stand back and just observe, and not size anything after Round 1. They can become disengaged and not observe the proceedings at all. Both of these can be signs of underlying issues. This is where the skill and experience of the facilitator is important, first in recognizing the symptoms, and then dealing with it.

Discussion and Reflection

The facilitator facilitates a short discussion between the team to gauge the level of confidence in the sizes. The Fist of Five is a good technique to use here. It quickly gives a sense for how confident the team is in the sizing that they just performed.

Full Sizing Wall for Silent Grouping of User Stories

Variations

I used to use a ‘?’ column to group user stories that people felt could not be sized because there were too many unknowns. Planning Poker has a ‘?’ card too. However, I found that this provided too easy a way out. I want to provide a situation where teams are forced to either make a decision or openly disagree with each other and question the size of the user story. Decide what’s appropriate for you, but these days I prefer to not use the ‘?’ column.

Summary of Benefits

I have observed the following benefits from using the Silent Grouping technique:

  • It is very fast. You can size large sets of user stories in minutes.
  • It is scalable. I have used this technique with up to 8 Scrum Teams (55 people) in parallel, to size 677 user stories in 28 minutes.
  • It very quickly surfaces any unknowns or areas of disagreement within the team.
  • It is inclusive. Everyone gets the opportunity to comment on all user stories.
  • It works well as a compliment to Planning Poker. You can size initial benchmark user stories using Planning Poker. For any user stories that don’t gain consensus during Silent Grouping, you can size those with Planning Poker.
  • Because the Silent Grouping technique explicitly disallows talking, it is easier for more introverted team members to exert their influence. Conversely, it is harder for more dominant team members to exert their influence just by force of argument or discussion – something that can happen in Planning Poker.
  • If there are language barriers in your team, e.g., if you work with global teams who do not share a common first language ( a very common scenario these days), then Silent Grouping is a good leveler.
  • You can sometimes observe a noticeable delay among Planning Poker players as they wait for others to show their hand first. With Silent Grouping, particularly in Round 1, people must make a decision themselves without influence from others.
  • Silent Grouping applies the wisdom of the entire team to quickly size large sets of user stories. Just like in James Surowiecki’s book, the team will be familiar with the problem domain already. E.g., in one of the early examples in Surowiecki’s book, the people guessing the weight of the cow were all experienced farmers. If it is a truly new problem domain for the team then they need to spend some time before sizing just getting familiar with the problem domain.

Playing Silent Grouping at the XP2011 Conference

I had prepared some slides for my session at the XP2011 Conference, but as it turned out, I did not use the slides. Instead, I decided to run an actual Silent Grouping session. I asked for seven volunteers to pretend to be a Scrum team, and one other volunteer to be a time keeper.

XP 2011 Participants Playing Silent Grouping

When teaching this technique it’s useful to have a backlog of user stories already prepared. Rather than try to come up with a contrived product example, I like to use animals. Most people are familiar with most types of animals, so it makes for a good problem domain. To simulate reality, add in a couple of unfamiliar animals, or some that might appear to be ambiguous. For the XP Conference I used 42 sticky notes with stickers of animals. Some animals were represented more than once.

The team sized all 42 user stories in about six minutes.

Animal User Stories After Silent Grouping

Several people who came to my session at the XP Conference tried it out when they got back to work, including @ruby_gem.

Slide Deck

The slide deck is here:

Research Paper

My talk at XP2011 was based on a research paper that I submitted to the conference, and was published as part of the conference proceedings. I was delighted to be named in the final four at the conference banquet for the award for Best Research Paper.

The paper draws on experiences of seven Scrum teams as examples. The paper shows how to apply the technique with co-located teams, and includes an example of how it was used with distributed teams. The paper is 15 pages long and contains some data, charts and more detail on the technique and its application. The proceedings are available from Springer.

Let me know how you get on

I keep records every time I run this, and I also keep records of other ScrumMasters and coaches that use it. I would love to hear how Silent Grouping works out for you. Get in touch and let me know the following. I’ll be happy to credit you in any future papers.

  • Team size
  • Number of user stories
  • Time to size the user stories
  • Number of user stories that needed discussion afterwards
  • Number of user stories sized with Planning Poker
  • Any comments, experiences or insights from you or your team

Definition of Ready

Introduction

Many agile teams are familiar with Definition of Done as a set of agreements that let everyone know when a user story (or a sprint or a release) is really done, and all necessary activities are complete. Definition of Ready is a set of agreements that lets everyone know when something is ready to begin, e.g., when a user story is ready to be taken into a sprint, or when all necessary conditions are right for a team to start a sprint.

Life of a User Story

The typical life of a User Story is shown in the following diagram:

Life of a User Story from Concept to Happy User

At some point in time someone will have an idea or concept for a new feature. The concept will be expressed as one or more user stories, and get added to a product backlog. The team, working together, will figure out how to turn this concept, expressed as one or more user stories, into a real product feature that delights end users. That’s the abridged version; all sorts of interesting things happen along the way.

Viewed another way, we can consider the level of focus that a user story gets at different times.

The life of a User Story in a typical Scrum project

The horizontal axis represents time. The vertical axis examines the level of focus on the user story from the perspective of the Product Owner and the Delivery Team. Of course there are other stakeholders in the user story, but these are the two perspectives I want to consider right now.

Let’s assume we’re talking about a typical Scrum team, although the details are similar for any other agile process. At some point before the Sprint starts (represented by Sstart) the Product Owner has a high degree of focus on the user story. They are trying to figure out what the value is for the user, and how to express that as a user story. As we approach the start of the Sprint, the rest of the team increases their focus on the user story. As part of their Backlog Grooming and look-ahead planning activities the team will start to consider the user story’s general feasibility, acceptance criteria, dependencies and related details. The team will size the user story, and maybe even start to think about the tasks.

Between Sstart and Send the team works on delivering the user story. The team gets into more detail than the Product Owner during this period, as they figure out the software design, test cases, user experience details, implementation details, and generally work towards getting the user story Done (according to the team’s own Definition of Done) and Accepted by the Product Owner. The Product Owner is involved every step of the way – the intention of the diagram is to convey that the team is bringing a higher degree of focus during this time.

After the user story has been accepted the team’s focus changes to the next user story.

At some point after the Sprint ends (represented by Send) the team is considering the product as a whole, and preparing to ship it. By this time the user story has been combined with many others to form a complete product.

Synchronization points

The Product Owner and Delivery Team work at different cadences. They focus on different things at different times. Time-boxed iterations (or Sprints) are one way to synchronize their different areas of focus. Having a Definition of Ready that serves as a set of mutual agreements between Product Owner and the rest of the team brings a focus to upcoming Sprint synchronization points.

Why Have a Definition of Ready?

A Definition of Ready lets everyone know when a User Story is really ready to be taken into a Sprint. It does not need to be “100% defined” with all acceptance criteria, etc. but it should be “ready enough” so that the team is confident they can successfully deliver the user story.

It will save a lot of time if each user story meets Definition of Ready before the Sprint Planning meeting, but it is also OK to work on the user story during the Sprint Planning meeting to bring it to Ready.

Sample Definition of Ready

This section shows a sample Definition of Ready for a user story, and a sample Definition of Ready for a Sprint. I generally use these as baselines or starting points, and work with teams at the start of a project or release to customize the Definition of Ready for their product and environment.

Definition of Ready for a User Story

  • User Story defined
  • User Story Acceptance Criteria defined
  • User Story dependencies identified
  • User Story sized by Delivery Team
  • Scrum Team accepts User Experience artefacts
  • Performance criteria identified, where appropriate
  • Person who will accept the User Story is identified
  • Team has a good idea what it will mean to Demo the User Story
Most of these bullet points are targeting specific problems I have encountered on projects over the years. A little preparation can go a long way towards helping the team delivery user stories. When I presented this at XP 2011, one of the participants suggested adding that last bullet point. I like that suggestion.
I advocate that teams do not commit to taking a user story into a Sprint unless there is sufficient clarity and evidence of commitment from Product Owners. Remember the “3 Cs” of a user story (Card, Confirmation, Conversation). There’s a balance here, and judgement and common sense need to be applied. We don’t want to replace the Conversation aspect. I am not suggesting to turn user stories into specifications. I am suggesting that Product Owners and teams give themselves a greater chance at successful delivery of user stories by considering some issues ahead of the Sprint.

Definition of Ready for a Sprint

  • The Sprint Backlog is prioritized
  • The Spring Backlog contains all defects, User Stories and other work that the team is committing to
  • No hidden work
  • All team members have calculated their capacity for the Sprint
    • Fulltime on project = X hours per day
  • All User Stories meet Definition of Ready

Examples of ‘other work’ might include lab setup, build environment maintenance, creating a test application.

Scrum Masters, working with Product Owners and the rest of team, can use this to prepare for upcoming Sprints.

Slides

These are the slides from my talk at XP 2011 in Madrid:

Conclusion

Try using Definition of Ready to bring a focus to Backlog Grooming meetings and Look-Ahead planning activities. Product Owners can use it as a guide when preparing user stories for upcoming Sprints. Teams can use it as a checklist to make sure that they have an increased chance of success in delivering the completed user story, and that there is enough thought gone into the user story before they start to deliver it.

Refactoring the Organization Design – LESS2010

I was invited to speak at the First International Conference on Lean Enterprise Software and Systems, 2010, in Helsinki last week. I presented on the topic of organization change in engineering organisations, as part of the Scaling Agile to Lead track.

The main theme of my talk was in support of applying concepts from Stakeholder Management to support agile and lean adoption. I used the concept of refactoring to talk about some of the changes that can be made to organizations, and showed some examples of how Martin Fowler’s classic Refactorings can be re-purposed to talk about organization design rather than software design.

The main topics of my talk were:

  • Using Dan Pink’s Motivation 3.0 Type-I toolkit for intrinsic motivation as a guide for what we should be refactoring towards
  • Refactoring applied to Organization Design
  • Agile transition journeys
  • Designing a process: core framework versus toolbox
  • Refactoring toolshed
  • Stakeholder Management
  • Stakeholder Mapping applied to Scrum teams
  • Stakeholder Management and the challenges of Product Ownership for large organizations
  • Stakeholder Management and the role of manager
  • Stakeholder engagement
  • The power of metaphors for organizational learning
  • Jazz improvisation as a metaphor for organizational learning and stakeholder engagement
  • Artful Making as a metaphor for software development and stakeholder engagement
  • Organization Patterns

Paper Abstract

The following is from the abstract of my paper that was published in the conference proceedings:

Every organization has a design. As an organization grows, that design evolves. A decision to embrace agile and lean methods can expose weaknesses in the design. The concept of refactoring as applied to software design helps to improve the overall structure of the product or system. Principles of refactoring can also be applied to organization design. As with software design, the design of our organization can benefit from deliberate improvement efforts, but those efforts must have a purpose, and must serve the broad community of stakeholders that affect, or are affected by, the organization. Refactoring to agile and lean organizations demands that we have a shared vision of what the refactoring needs to achieve, and that we optimize the organization around the people doing the work.

The full conference proceedings are available form Springer.

Presentation slides

My presentation slides are here: