Resistant to change

The Dark Champion, the Dark for short, will find a wedge to come between those whom seek change and those whom wish to change but lack the motivation to rise up.  The Dark uses fear of change to highlight the loss of power to some and prestige to others.  The comfort of the old way will be the wedge for the rest. All fear, regardless of source, must be brought out in the open, only then can empathy and knowledge be applied through acceptance and closure. Unlike agile, which espouses self-empowered teams to manage change,  there is no comfort in change you cannot control.   I remind teams of an old business axiom “Change or Die”, a saying from well before my time, proven effective by nature through evolution.  Instill Courage in teams to shape their change, so prestige is gained by through predictability, power is gained through reliability by delivering on your sprint commits.  Some feel change will remove them from being the ‘go to guy’, a legitimate fear for people whom have become accustom to being the center of attention.  This can be overcome by helping people evolve into the ‘go to team’.

Hides in plain sight, Politics as a cloak of invisibility

The Dark uses politics to hide in plain sight…the Cloak of Invisibility is used to hide mediocrity, redundancy and increased opacity, the opposite of Transparency, one of the five Scrum values. Political tactics are beyond the scope of this blog post, but knowing who your enemy is, helps out.  This Dark Champion, The Baron, reports to the boss, has the power of process, HR or otherwise, and uses the power of redundancy to slow down your agile initiatives.  When and how change is implemented, the Baron will proclaim “we must adhere to regulations”. Mercy for you if the Baron is supported by legal regulations such as HIPPA or Sar-Ox!

The Baron is brought into the open with a reassignment of power. Although the SM is usually in charge of scheduling the scrum rituals, the Baron is minimized by delegating these duties to him.  The perspective here is for the rituals of Scrum not to interfere, but enhance process improvement.  Inclusion, empowerment and participation are tools the agile coach or ScrumMaster (SM) can use against the Baron, perhaps by going so far as to let the Baron facilitate the rituals as well?

The Dark Champion of Mediocrity takes the forms of the middle manager.  The Dark is responsible for inefficient forms and procedures and resists agile and the call for improvement; a prime example is the TPS report (see the movie, Office Space!)  is threatened by agile’s focus on performance and teamwork.  The Dark will use fear of change especially towards those whom are used to less than stellar work efforts.  Fear is presented as resistance and takes root as apathy.  Once apathy has taken hold then, the Dark will team with the Baron to stymie and outlast you with inertia!

The Agile Champion could propose a strategy to improve team performance, with a modification to HR processes which focus on promotion and bonuses.  Insert a ‘team score’ along with individual performance, so that team wins and losses have an effect on each team member’s overall performance metrics.  This defeats mediocrity and compels those who work less, to work harder, now that everyone’s bonus is dependent on their efforts as well.  For example, use two scores for performance, an individual scale from 1 – 10 and a team score which uses the same scale.  These two numbers are multiplied together (individual score is 8 – great programmer, team score is 5 – needs to pitch in more:  8 x 5 = 40 overall score).  The implicit peer pressure to perform removes part of the motivational burden from the coach and correctly focuses it on the team members to motivate one another.

Part two of this blog, ‘Gathering Allies for Change’ will discuss who can help you in the struggle for Scrum and how they can are empowered to overcome the resistance to Change.

• Transition from technical role to PO role (2)
• When to do estimations (2)
• Agile vs. management culture (6/7)
• Intrinsic motivation in an agile environment (5)
• How to tell management to relax (4)
• How to handle weak POs (3)
• Why Scrum does not work (2)

Agile vs. Management Culture

The host of this topic had the example that new, unknown stakeholders join Sprint Reviews and come with new requirements without knowing anything about agile and the team's new development approach.

The question now was how to handle management and stakeholders who has no knowledge about agile. Following ideas were discussed:

• welcome new attendees at the Review meeting and explain the meeting/format
• enable the PO to do proper stakeholder management
• explain to stakeholders before and during the project how Scrum works
• stakeholders need to share the vision
• PO role and person needs legitimisation by management

Intrinsic Motivation in an Agile Environment

We had a more general discussion about motivators, intrinsic and extrinsic motivation. Following points have been mentioned:

• people on the project need to share the vision
• team decides how to split rewards (if there are any, as rewards are extrinsic motivators)
• people involved in decision making are more motivated to act upon it (so Scrum is a good way to realise such involvement in every meeting)
• everybody has different motivators = handle people individually
• enable appreciation between team members
• know exactly what drives yourself
• There were some book recommendations as well:
  • Julius Kuhl - Die Kunst der Selbstmotivation
  • Daniel Pink - Drive
  • Chip Conley - Peak

How to Tell Management to Relax

The example observations of the topic host were:

• story points / velocity are taken too seriously
• retrospectives contain 80% negative topics
• management does not see things that go right

Discussed suggestions:

• make every Review meeting awesome and useful for management
• explain how Scrum/Agile works to management
• keep management busy with other things
• build up trust with stakeholders

Schnitzel and ongoing talks

Finally we ordered some food and had ongoing discussions on the topics. It was a great evening and we're looking forward to see you at the next Scrumtisch here in Berlin.

Coaches from agile42 were present as always and you can also find their presentations here. Dave Sharrock presented Giving Teams the Roots to Grow and Wings to Fly, an interactive session introducing useful and proven practices that increase the sticking power of new agile teams, allowing them to stay agile long into the future. In fact, to create sustainable change, agile teams have to overcome organizational gravity that pulls them back into the old, comfortable ways of working.

Brad Swanson presented From Doing Scrum to Being Agile: Lessons Learned Transforming a Culture, a case study of the agile transformation at Ericsson Mobile Core from 2009-2012 and using John Kotter's 8-step change model for leading the change.

Thanks to Alexander Lutsaevsky for the translation.

This poster is also available in English, French, and German. You’re welcome to print copies for personal use.

For more information, see the original story splitting patterns post.

The Traffic Flow Problem

A reasonable metaphor for this is the speed-density-flow relationship seen in traffic studies. Figure 1 shows the classic relationship, where flow = speed x density. In the case of traffic, the speed of the traffic increases (from a standstill) as the number of cars on the road falls. The flow of traffic on the road, on the other hand, increases to a point, but then falls off as the number of cars on the road falls below a certain number, however fast they are going. In other words, there is excess capacity in the system as the number of cars on the road falls. 

Figure 1: The graph shows the relationship between speed, density and flow for traffic on a highway. The higher the volume of traffic, the slower the speed of the cars, and the lower the flow of cars along the highway. However, as the number of cars on the highway falls, the flow will also drop off even as the cars go as fast as they can (hopefully at the speed limit).

In the case of work requests entering development, the flow of work through the system changes in the same way, increasing to a point, but then decreasing rapidly as the volume of work requests increases. Unfortunately most systems operate at or above capacity, at which point there is a negatively reinforcing feedback loop driving the performance down (Figure 2). Once a system has passed its optimal flow regime, additional work requests quickly decrease the performance of the system, causing longer wait times as more work requests pile up, which can lead to more requests being worked on, decreasing the performance (throughput) of the system even more.

Figure 2: Above the maximum capacity of the system (when the flow through the system is at its highest), we see a negatively reinforcing loop. That is, as the density of cars increases, the flow through the system falls, increasing the number of cars in the system, leading to a further drop in the flow through the system, and so on. Something we’ve all encountered around 5 o’clock in most cities.

This can be seen in any system by measuring the cycle time, the total time it takes to start and complete a single feature or piece of work, and lead time, the total time it takes to complete a piece of work (cycle time) plus the time the work spends in the queue, and plotting these as a function of the number of work items open at any given time.

Limiting WIP in a Scrum Team

So how can we apply this principle to an existing backlog of work consisting of the many valuable and less valuable tasks a product gathers over time? In Scrum, the team limits the number of items they are working on by pulling in only the number of work items (or stories) they can complete in a sprint. This automatically limits the team to a fixed number of stories, hopefully between 6-10 stories. More mature agile teams will also limit the number of stories they are actively working on during the sprint, only working on 2-3 stories at any one time; The purpose of this is to speed up throughput by limiting work-in-progress (WIP).

Many teams have other kinds of work they have to handle. Perhaps emergency items (such as production support tickets) that cannot wait until the next sprint planning to be addressed, or small enhancements, maintenance items or report extracts, that are part of the everyday maintenance and support of a product or service. These types of work requests can be handled through a contingency stream, captured on the team’s task board, and tracked visibly for all to see. There are a few guidelines for handling these tickets:

1. Set a capacity limit for the team to spend on these additional items, and help the team manage to this capacity.
2. Have clear policies around what to do with larger items (e.g. work requests larger than 1 day go into the backlog, work requests smaller than a day are handled in priority order).
3. Hide the bulk of the tickets from the team (but not the business stakeholders) to avoid distracting the team.
4. Allow the business to prioritize the tickets the team works on – hopefully through the Product Owner – and if this is not possible set clear rules (e.g. date order) and keep to that.
5. Make the work backlogs visible to all so that everyone can see where their ticket is and what is in front of their ticket.

Prioritizing Work across Multiple Projects

In situations where there is a portfolio of projects for a single team to work on, it can be hard for the team to complete one project before the pressure to turn their attention to the next project in the pipeline becomes unbearable. This leads to large amount of unfinished work (inventory with a very real cost to maintain and support or build around) as well as the frustration of abnormally long lead times or time-to-market, incomplete work waiting on small changes, and never-ending projects.

In this case, we clearly want to allow the team to work on each project a little at a time. But doing this story by story (work request by work request) doesn`t solve the problem of partially complete work unless the work on each project delivers something shippable, something that adds value even if the project in its entirety is not delivered. Grouping a minimal set of stories together to deliver a slice of functionality – a Minimum Viable Product (MVP) the customer can interact with and use – allows the team to work on one project after the other, delivering something of value for the owner of each project (this could be feedback, rather than working functionality, but that’s a discussion for another post) as quickly as possible (Figure 3), while moving each project forward.

Figure 3: Managing multiple projects is hard. Many times, the priority of a project is determined by urgency or whether or not a project is ‘front-of-mind’. In this case, projects can be continually open, never quite ready for release, but not moving forwards either. In order to facilitate effective delivery of projects, we want to break them down into small, releasable slices of functionality. Minimum Viable Products (MVPs) that we can release, perhaps to a limited audience for feedback, before committing to build the next slice of functionality. This allows multiple projects to be developed in parallel, while ensuring each project moves forwards in viable steps.

This does not remove the need for prioritization of the projects. However, this can be done at the portfolio level, even better at the MVP level (rather than the project level). Its easy to say that a performance project has priority over a site re-design project. However, some performance improvements are more valuable than others, and some site re-design changes can be more valuable than other performance enhancements. Prioritizing between MVPs allows the line of business to optimize on what is most important to the business at any one time, while allowing all projects and priorities to move forward.

Working on Fewer of the Right Things

In conclusion, limiting the number of projects a team is working on (making the team do less) does not have to reduce productivity (can actually deliver more). While the development team takes responsibility for delivering an increased flow of work through the team - making sure the capacity is predictable and continually improving, the business team and product owners ensure a transparent backlog of MVPs from which to work from - making sure that how the capacity is used maximizes value delivery. The increase in throughput as a result of focusing on fewer work requests, coupled with an ordered backlog of small features or Minimum Viable Products (MVPs), allows a development group to deliver the most important and valuable work more frequently.

One of the most valuable documents teams can create is a Team Agreement. Team Agreements for software development can range from very detailed specifications of coding standards and practices to a general statement of moral and ethical conduct, or anywhere in between. Team agreements help set the context for team member expectations and provide a framework for the team to operate within. Here are some guidelines for creating effective team agreements.

1. Have a process
It is helpful to have a process for creating a team agreement. Decide who will be part of drafting the agreement and what the feedback process will be for approval. Identify the tasks needing to be done and engage as many team members as possible.

2. Decide what is most important
Depending on the maturity and challenges your team is facing, you may want to focus different things. Some team agreements are more concerned with technical practices while other state principles the team will adhere to. Every team has things they do well and things they do not-so-well. Start with what is most important for your team to keep top of mind.

3. Draft a charter
Draw up a document that states affirmatively the things that are most important to your team. Typically, this will include ten to thirty items. The document can start, “We agree…” followed by the list of agreed upon items. Rather than making this a list of rules to follow, try to make each item empower team members to do their best in situations. At the bottom of the document should be a space for each team member’s signature. Use poster board or butcher paper so the whole document can be on one sheet.

4. Involve everyone
The more everyone feels they have a say in the creation of the team agreement the more likely they will abide by it. Go over each item and get everyone to discuss and vote on whether to include it or not. This is a team building process which is just as important as the document itself.

5. Ask for feedback
Any impediments to agreement are opportunities for alignment. Ask the team for feedback; how will following this agreement improve their jobs. Meet resistance with curiosity to discover what the real challenges are. Get people to recognize the value to them of each item or have them help change it to address their real issues.

6. Get everyone’s agreement
Meet with the entire team and decide together if the proposed charter is something each and every team member can sign off on and abide by. There is a lot of power to signing one’s name to a document. This can even become a ceremony of sorts where team members are acknowledged thanked for their contributions.

7. Keep it visible to everyone
Finally, once the Team Agreement is created and signed, hang it on the wall in a prominent place to remind everyone of what they stand for. Seeing this document day in and day out can really help to solidify the ideas and make them part of everyone’s daily work life. And most of all live it—make it part of your daily lives.

Team Agreements can be a powerful way for the team to quickly reach alignment and work together more smoothly. It can help form the context of a working environment where everyone is empowered to do their best.

Motivation

Explaining why he wanted to start the day with this session, Dirk said, “One of the motivations behind this exercise was to allow everyone to take a different perspective. Software engineering and product management tend to be focused on deterministic things, such as algorithms and data structures, and more often than not, it is a lot about problem solving, bug fixing, criticising this or that. But deep inside, engineers and product managers are creative, emotional people with a lot of passion for their work. I was just curious to see what happens if their perspective would be one that is unconditionally positive - do you love your product ?”

Instructions

Dirk started the exercise by simply writing the sentence "I love my product" on a whiteboard and circling the words love and product.

He then asked, "If you think about this statement… What do you mean by Love and Product? For me, it means that I care for my product, that I worry about my product. What does it mean for you?"

He instructed us to take five minutes, think about this and write down a few ideas on cards. One card for each of our interpretations of love and product. Then, we would pin the cards to a wall and explain.

Output

After five minutes, we had produced an astonishing amount of cards:

The top cards were placed by Dirk and are labeled Liebe (Love) and Produkt (Product). As you can see, we produced a continuum as some ideas were applicable to both sides.

The writing is in German, so I'll translate some of them:

Love

• Single words: life, mindful, proud, care, trust, identification, yearning, complexity, examine, question, provide, develop, honour, responsibility, ambition
• Statements: accept that the product is not perfect, I am aware of the environment of my product, care for well-being, I am generous interacting with my product

Product

• Single words: value, identity, meaningful, inspiring, slender, family, respect, team, inspiring, aesthetic, sustainable
• Statements: my product is valuable for someone, created by many, is useful and helpful, enables someone to do something they couldn't do without it, I want to know (measure) all about my product

Outcome

While we were discussing the results and the emotional engagement that had emerged in such a short amount of time, one of the participants had already created this tag cloud:

The group unanimously agreed that

• this exercise created an emotional bond for the full two-day workshop in a light-weight way that didn't feel weird or embarrassing,
• it let everyone reflect and articulate how much they engage with the company, their product, and why they do it,
• to do this exercise would be motivating for everyone in the company,
• they wanted to repeat the exercise with their teams.

Dirk generously agreed that I post this exercise on our blog, and the group allowed me to publish the picture. Thank you!

One interesting observation I made as a participant in this exercise was that I could join in although I was not part of the PO team. Every participant can think of their own product and still have an interesting outcome to start a conversation. So I assume this would work well at conferences, too...

Your Turn

One inspiration Dirk gave us when we started was to think about projects and products. "Projects end at some point, and you're done. Products live on… What impact does that have on your emotional perspective, on your engagement?" What are your insights on this?

What does it mean to you, "I love my product"? Please tell us in the comments! Where and how would you use such an exercise? Do you think it's particularly useful in any specific phase of product development?

Thank you for engaging in the conversation.

It used to be thought that if only we could write a good specification that accurately described what was to be built, we could take advantage of the cheap labor overseas to cut costs and get software built faster. Unfortunately, reality often shatters such naive hopes. However, outsourcing overseas can help for many tasks and as these workers become more skilled and collaboration improves, these approaches are becoming much more successful. Here are seven strategies for improving collaborating with remote teams.

1. Be in similar timezones
Communicating with teams across timezones can be hard. Some teams use this to their advantage, for example, by having developers send their work at the end of their day to a QA team that is just beginning their day. However, this can also cause problems when these teams have to communicate since they are awake at different hours. Finding at least some common time where everyone can meet and collaborate can be highly valuable.

2. Use video and good collaboration tools
I am not a big proponent of tools but they have their place, especially with distributed and remote teams. Having face time with team members is so important, whether the team is scattered across the world or scattered across town, video conferencing can help increase communication bandwidth.

3. Do trainings together and meet regularly
Successful distributed teams get together regularly to meet in person at least once a year but preferably quarterly or even monthly. Sharing a common experience such as training, key meetings, or just sharing a meal together can help build rapport and deepen working relationships. It is easy to skimp on this but don’t. The expense of getting remote workers together regularly is far outweighed by the increase in communication and productivity it brings.

4. Share a common code aesthetic
Remote teams must be on the same page with the rest of development in terms of coding aesthetic, standards, and practices. Common coding standards should be established, understood, and adhered to by all team members, even remote ones. Remote teams should also share a common development process as the rest of the developers in the organization. Ideally, it should not be possible to tell who developed the code by looking at the source.

5. Decouple dependencies so work can be independent
Give remote teams everything they need to be successful. If the team needs access to the Product Owner who is never available to speak with them then the team is being set up to fail. Find components that can be written and tested independently so development can happen in parallel.

6. Use pair program often
The fastest, most effective way to amplify learning within an organization is to pair. This is true for remote teams as well. Remote pairing is a powerful way to work with remote teams and help them learn many of the subtler things that help them become part of your development culture.

7. Invest in quality
Regardless of where software is built, a focus on quality will alway be cheaper than trying to rush things. Certain things take time to write and if you show you value quality you will more likely get it from your remote teams.

Several years ago companies had the idea they could cut costs by hiring cheap labor overseas. We’ve learned that the most important part of successful software development comes from understand the domain, not pounding on a keyboard, and understanding can be difficult to acquire remotely. However, many countries do have highly talented developers at a fraction of the cost of developers in the US so distributed teams can make sense in some situation, as long as they get the support they need to do a great job.

Many of these discussions focus directly on the advantages of the specific method. Often, they lack focus on fitness for purpose or context. There are so many things that we could do. Many methods that work amazingly well for others. Is that enough to start trying them too?
We need to decide which method or tool is important and potentially useful for us in our environment, for our specific, current challenges. Discussions about new practices, methods and tools without considering our relevant focus of improvement can be wasteful and futile.

Many conversations about practices, methods and tools generalise the needs and advantages. In some situations, practices like continuous delivery are even considered to be preconditions for starting on your agile journey.

Every environment is different. No method brings the same benefits to every environment, is easy to implement or even applicable in every environment. Should a good old IT-department of a bank not strive towards agility, because practices like continuos deployment look impossible in their context?

The important question to discuss is, what is needed in your environment? Having a common understanding on what needs to be in place, next to the functionality to release, could help to clarify our needs. This common understanding about the expected level of quality and other non-functional requirements could be collected in a Release Definition of Done (RDoD) that reflects our needs.

This document enables a continual discussion putting our needs next to our possibilities to achieve them. Fancy practices, methods and tools are not necessarily the best starting point. Maybe in your environment some simple things could really make a huge difference. Awareness of your needs allows for a much better focus for your growing agility than some currently hyped practices.

Don't get me wrong. I'm a big fan of many agile practices, methods and tools. For me the understanding on what are our needs and reflecting back on how to achieve it, is essential to keep in charge of our improvements and achieve ownership of our environment.

The understanding of our needs as a foundation to introducing practices, methods and tools, feels in my experience much more natural and focused on the specific environment.