I have seen a recurring pattern in large organizations – there are large-scale projects that span many separate functional groups, departments and geographic locations. These projects often perform poorly and are difficult to manage effectively. In most cases, Agile is not the most valuable approach to get these projects on track.

At Agile Coach Camp I convened a session to explore this problem and identify some compensations to improve the situation. Many thanks to all the contributors – this is a group work product.

The Problem

Some of the common problems notes by participants were:

• Groups working in silos with missing, slow or broken feedback loops – lot’s of little disconnected pieces
• Incompatible vocabulary between technology and business
• The environments register high for “complexity of self”
• Staff in overload and multi-tasking
• Low visibility, awareness, priority

Please refer to the poster notes for full details.

Compensations

I use the word compensation, to indicate an action that can be taken to mitigate the problem. As there are systemic and widespread challenges in these environments, we did not discuss solutions.

Here are some of the key compensations:

• Draw a project map – who is where, what skills, what % on the project, what component
• Recognize and articulate feedback loops and flow of value
• Create a war-room with kanban boards for all groups
• Measure working software AKA running tested features and “definition of done”
• Conduct a project chartering session including clarification of business value
• Find someone to play the role of project lead (e.g. Toyota Chief Engineer)
• Make sure everyone has tooling for distributed communication

Contributors

• Paul Boos
• Dante Vilardi
• Pascal Pinck

Ooops. I can remember who was there. Please remind me by sending me an email so I can add your name here.

Product Camp Toronto was above all a great networking opportunity since there were lot’s of breaks between sessions for conversation. The day started with people sitting at tables chatting – and boy was there a buzz!

In this post I am going to give a quick pass at the four sessions I was at:

• Keynote on what is a product manager
• How to treat Customers like a Market and Markets like a Customer
• Open forum on Crowd Sourcing
• Market Research with Innovation Games

 What is a Product Manager?

The short answer is: someone who makes choices on product every day. John Stetic used the graphs below to show the breadth of skill required for product management and walked through some of the archetypal product managers and where they shine.

How to treat Customers like a Market and Markets like a Customer

Nick Van Weerdenburg had an engaging and insightful session. For me, the most engaging concept is to conceptualize a market as a person. Really ask yourself – what are they like? Personality? What do they think of you? Do they know your product? Good stuff. Read more below.

Open Forum on Crowd-Sourcing

I offered to facilitate this session (since I am getting pretty good at facilitation) and there was no one else around. As it turned out, we had a great mix of curiousity, skepticism and practical knowledge.

At the end there seemed to be consensus that:

Crowd Sourcing is a valuable activity that makes the Product Manager’s life easier, results in a better product and all this with minimal additional workload.

Below is a summary of the Crowd-Sourcing Flow:

Market Research with Innovation Games

Like crowd-sourcing, Innovation Games®are a powerful way of connecting with customers. The main difference is that Innovation Games® are focussed on real-time collaborative games as a means of engaging customers and stakeholders to reveal what really matters to them and to get breakthrough ideas.

I ran the session to give people an idea about using in-person and online games support envisioning, identifying hidden needs, and prioritization. We also briefly played Buy A Feature game online – and there were more than a few people hooked on it.

Slides are below:

Also, for reference, here is the handout summarizing the games:

Summary

I had a great day a Product Camp and would definitely recommend it.

The purpose of this post is to share a cultural analysis of the Declaration of Interdependence (DOI).

For those of you not familiar with it, the DOI could be characterized by re-write of the Agile Manifesto to be more positive and less waterfall-bashing.

I have had an uneasy relationship with the Declaration of Interdependence. On the one hand, people that I respect were part of creating it or supporting it. On the other hand, it never really resonated with me.

At last week’s XPToronto meeting, three groups picked the DOI to do a culture assessment based on Schneider’s model. Here’s what they came up with:

Some of the comments made by attendees were:

• “The ideas span all the cultures.” (Including opposing ones)
• “It looks like a shotgun of ideas.”
• “Even specific statements have conflicting cultural focus; it was hard to place them.”

Discussion

From the perspective of the Schneider culture model, the DOI is unfocussed. Schneider suggests that groups that are successful typically have one dominant culture. Perhaps this is one of the reasons why the DOI has never really caught.

If it works for the companies you work with, please share your stories via comments.

Have you been on a software project where each release gets harder and harder? Many projects fall into the tar pit of the Design Dead Core.

Why do nearly all software projects fail to balance short term choices with long term consequences?

Through game-play you will experience how hard it is to make effective choices. Game learnings will be tied into well-known models in and beyond software such as Technical Debt, Stephen Covey’s Production Capability, and Alistair Cockburn’s theory of competing games.

Recipe

• Game Objective: Participants experience the attraction of short-term thinking and feel the long-term consequences. The game helps executives and managers understand the importance of investment in sustainable development practices. The game is intended to help them get through a Red Pill, Blue Pill moment.
• Number of participants: 6 to 50 (Has been playtested with 40 at XP Toronto User Group Meeting).
• Team size: 3 to 5 people per team.
• Duration: 90 to 110 minutes
• Materials: Game cards (can print or write by hand), pennies (15 per team), dice (two per team)
• Setup: (optional) video projector, tables for group work, whiteboard or flipchart.
• Credits: This game was created by Alistair McKinnell and Michael Sahota.

Session Timetable

1. Intro & Motivate Game [3 min]
2. Break into teams of four or five people. [2 min]
3. Setup Game [5 min]
4. Year 1 [30+ min]
5. Year 2 [20+ min]
6. Year 3 [15 min]
7. Debrief [15 min]

There is a backdrop story that motivates the game situation and is used throughout the game to provide entertainment and inject new rules.

What’s Your Choice?

Here is a photo showing the project choices available to management teams:

Game Narrative

Year One

Resources

• Sustaining Agility Game Options – PDF to print 3″ x 5″ index cards (one set per team)
• Sustaining Agility Score Sheet – Excel spreadsheet to print (one sheet per team)

Facilitation Tips

• It is useful to create memorable even stereotyped characters to help participants connect with the storyline. e.g. CEO has a Texan drawl, CFO is from NYC, Consultant is from California.
• Write Rule fragments on flipchart or whiteboard so everyone can see the rules. I suggest skipping text and just put keywords such as “Invest –>+1D6 Production Capacity”.
• If you have not played the game before, I suggest you playtest it on your own.
• It may be helpful to write up rules on flipchart in advance and then share them when it is time.

Feedback from first run (XPToronto)

• “Fantastic, Magical” – Jorgen Baker
• “Real pressures bottled up” – Alex Aitken
• “Good fun, valuable, opportunity to learn” – Tom Huras
• “Thought-provoking, Fun, Interesting” – Nick Faulkener
• “Lively, Interactive, Team-focused” – Hedi Buchner

Feedback from second run (Agile Games 2011)

• “This game relates hugely to my current work situation where we struggle daily to do thing the right way or increase our technical debt. This game can give great insight to our companies leader to make the right decisions as much as possible.” – A.F.
• “Very interesting game. I’m going to try it myself.” – A.J.
• “Good mix of presentation and game. Provided great thoughts about career goals, revenue and investing in production capability and the future.” – J.V.
• “Great, practical game about strategy and the impact of long-term choices and short-term consequences” – T.M.

Cross-training charts (also skill training charts) are a standard part of the Lean toolkit. They are used to identify limited skill sets that can lead to bottlenecks and work stoppage.  See manufacturing example.

In Scrum (and some Agile), we have the notion of cross-functional teams and place value on generalists who can go where the work is. Cross-training charts can help get you there.

Technology and Domain skills

When helping teams assess themselves, I separate technology skills (who knows a library or tool) from domain skills (who know the frazzit module). Once teams do this, the lightbulb goes off – “Oh that’s why it takes so long when we need to do work on the frazzit – only Bill knows it and he is busy with other stuff”.

On the left is a legend I have used with a couple of wiki-enabled clients to track the matrix. (Excel works too and has a nice colouring feature under conditional rules but is less visible.

Consider the example cross-training matrix below for the developers. (QA, BA important too, but they have different technologies/skills). Across the top we have the names of the developers. As you can see, on the front end, they have an OK idea how to use SpringMVC and JSTL; there are no experts, though, so it may not be clear what their frame of reference is. Sometimes people don’t know what they don’t know. Very limited experience with UXD (User eXperience Design) which may be an area for attention depending on usability goals for the product.

What about the domain matrix? Well, it looks the same but with areas of the application outlined at an appropriate level of detail. You can put the whole team (not just dev) on this one.

Lottery/Truck Factor – Are you managing your risks?

Truck factor is about how many people on your team can be hit by a truck before you can no longer effectively support a piece of software.

The cross-training chart can be used to assess how well management is managing risk. Usually what I see is “not at all” and the result shows in terms of deteriorating code quality due to departures and growth.

How to spread knowledge?

There are lots of ways. My favourite is pairing. I also like to impose a limit on publicly declared learning goals – just pick one thing to learn at a time to provide focus.

My suggestion: give your team time to share knowledge and let them decide h0w they want to do it.

Footnotes

• I keep talking to people about this so I thought I had better post on it. Most recent discussion was at a session at Agile Coach Camp in Waterloo.
• See complementary practice of Timeline and Marketplace for understanding other team members.

I was really excited to see the presentations from the Munich Scrum Gathering posted on the ScrumAlliance site since I was not able to attend due to a date conflict with Agile Tour Toronto. It took some time to go through all of them so I thought I would post some of the ones I found interesting here to encourage you to check them out and maybe some others. A big thank-you to the Scrum Alliance and authors for posting them.

Ideas from Other Fields

Making Change Happen – Peter Stevens

Peter Stevens has a visually pleasing presentation – Making Change Happen – that summarizes organizational adoption challenges and includes key ideas from one of my favourite books – Fearless Change. The diagram at the left illustrates that there are often factions in an organization pulling in different directions with different agendas – not just your favourite (Scrum or Agile). Check this out if you are involved in organizational change.

Social Objects in Software Development – Dave Harvey

Scrum talks about self-organizing teams. How do you get there? One idea is that we need to think about social networks. These form around social objects, so this is a good place to start. Social objects reinforce our identity and sustain our tribal identity. Consider the photo showing other dimensions of people’s lives. Not only can networks form around this, but it also primes our behaviour to think about others as … people. The presentation is done in zen style and I would totally love to hear Dave in person.

Self-Organizing & Subtle Control: Friends or Enemies? – Mike Cohn

Mike talked about self-organization not happening in a vacuum. It is management’s responsibility to guide the evolution of behaviours (rather than specify what how everyone needs work). He then went on to talk about Containers, Differences and Exchanges as a way of making indirect changes to a team. There is also a discussion of Philip Anderson’s 7 levers for influencing team evolution. Worth checking out if you are interested in coaching teams.

Stories from Scrum in Practice

Agile at Telefonica R&D Gemma_Hornos & Monica Izquierd

Although the presentation is about large scale enterprise adoption of Scrum, there are lots of interesting bits of information that apply in general. One example is image is about styles of growth of Scrum within an organization – I really like the viral/mosquito! Lot’s of other great visuals as well.

Practical Roadmap to Great Scrum – Jeff Sutherland

Jeff shares some of his key understandings of doing Scrum well. Want to double productivity? –> Focus on DONE. Want to double again? –> Focus on READY. Self-organization is identified as the 3rd way to double performance. The presentation also talks about large scale adoption and CMMI. Lot’s of good bits of info packed in here.

10 Contract Forms For Your Next Agile Project – Peter Stevens

Peter has a great analysis of the advantages and disadvantages of different types of contracts from both the vendor and the supplier perspectives. Phased development (see photo at left) is one that balances the interests of bother parties and encourages cooperative behaviours. If you need to set up a contract, check out this presentation.

Kicking Scrumbut – Rowan Bunning

Rowan takes a fun and informative look at some common failure modes that organization exhibit when adopting partial Scrum (AKA Scrumbut). Of course all the failure modes are matched with advice on what to do to resolve the problem. Even if you are an experienced coach or Scrum practitioner, you will be sure enjoy and learn from a different perspective.

The biggest news from Agile 2009 this year is that the PMI has launched the PMI Agile Community of Practice.  As there are many historical and cultural differences between the two groups, the shared hope is that by communicating and sharing understanding there are opportunities for everyone to succeed.  Not everyone agrees.  Check out this InfoQ article for some other points of view.