Here are the slides and reference links for the session Gino Marckx and I are giving at Agile 2010 in August

Triangle Model

Selecting and delivering the most important work is a critical success factor in Agile projects. But how do you know what is important? Unless you are psychic, some help would come in handy. Consider the diagram below to help make sense of the wide variety of strategies and tools.

We explain three different perspectives: Company, Customer, Team.

Team Perspective

The product backlog needs to be structured so that it informs the team of the vision and the work. Whenever the company or the customer priorities are not clear, the team will need to rely on general information and it’s common sense.

Theme Scoring & Screening - Relative or numerical weighting based on criteria (Mike Cohn)

• Video of Mike Cohn at Agile 2008 and Slides
• Agile Estimation and Planning (book)

Story Map – structure the work in a grid that reflects actual product usage (Jeff Patton)

• Jeff Patton’s blog
• Presentation

Software By Numbers – prioritize work by Net Present Value of Minimum Marketable Feature

• Software By Numbers (book)

Customer Perspective

The product backlog prioritization is done from the customer’s perspective, from the perspective of whoever is paying for the product in the first place, whether this customer is internal or external to the company doesn’t really matter. What is most valuable to the customer will be on top. Techniques focussing of this view require strong product domain knowledge, and a good understanding of the impact of specific features on the business.

Kano Analysys - Structured Questionaire to determine feature relevance: Mandatory, Linear, Exciter

• See materials of Mike Cohn from Team Perspective: Theme Scoring & Screening

Innovation Games® - 12 Games to better understand your product and what’s important (Luke Hohmann)

• For Speedboat® and Buy A Feature® + more - innovationgames.com and Book

Company Perspective

Companies need to find a balance in distributing the effort over multiple customers and/or products. But they also need to take the company and product strategies into account, deprioritizing features that might be very valuable for customers but aren’t in line with the company’s vision. As well, this takes into account stakeholders other than customers and sales – support, professional services, etc.

Company and Stakeholder Strategy

• Aligning and Balancing Your Backlog
• Blog: Why Prioritizing Your Product Backlog for ROI Doesn’t Work

Business Value Game – Simulation to illustrate how organizations can define their own business value model.

• Game instructions

Allocation Model - helpful to balance priorities with divergent or competing interests

• See example by Alisson Vale: Slides 40-49

Where to go from here?

The most common questions we have gotten after presenting these techniques are “How do I decide where to start?” and “How do these work together?”

These are complementary techniques and are used to solve related problems. Our recommendation is to start with the area that is the biggest challenge for your project. Maybe this means talking to stakeholders you normally don’t talk to. Maybe it means putting a Story Map up on the wall. It depends.

Slides

As a trainer, I have become increasingly convinced that games and simulations provide an excellent platform for learning concepts and new behaviours. I am playing and training with more and more games than ever before. It was getting hard for me to remember all the games and decide which one to use in a particular situation. (Can someone please create a public website where we can list games, rate them and tag them by the problems they solve?)

Where Games Play

Here are some of the games that I am currently use or want to use in training.

What’s with the grid?

• People – games about people learning individual skills or learning about individuals
• System - games about the team or organization
• Concepts - games primarily about teaching concepts or ideas
• “Experiencing our reality” - games the help us understand ourselves and our context

Links – People/Concepts

• Multi-tasking (10 min)
• Collaborative Origami – collaboration & communication (15 min)
• Yellow Brick Road: Fresh Insights through peer coaching (90 min)
• Pair Draw (30 min)
• 99 Test Balloons – acceptance testing (30 min)
• Go! – Your brain on Scrum (10 min)

Links – System/Concept

• The Biggest Bang for the Buck – backlog organization and prioritization – (60 min). Game I created with Gino Marckx will be released around Agile2010.
• The Backlog is in the Eye of the Beholder – organizing backlog from stakeholder view (40 min). Game I co-created at Deep Agile.
• Business Value Game – helps understand differing sources of value. (90 min)
• Marshmallow Challenge – understand benefits of incremental design (45 min)
• XPGame – Scrum variant – basics of iterative development and acceptance testing (180 min)
• Penny Game – Flow of value, process improvement (40 min?)
• Bottleneck Game – understanding process and applying theory of constraints (90 min)
• Name Game – Limit concurrent projects (10 min)
• Movers and shapers – team dynamics (10 min)

Links – System/Reality

• Ball Point Game – process improvement, teamwork – simpler than penny game (40 min)
• Value Stream Mapping – hmmm. not a game really
• Leadership Game – self-organization and leadership styles (180 min)

Links – People/Reality

• Constellations – Share team perspectives (30 min)
• Improv Games and Hypontizing hypnotist – Get better at collaboration and innovation (10 min to ?)
• MarketPlace – share skills with team members (30+ min)

Other thoughts

Please draw your own maps and share them!

Other games

I did not include games that have are designed to achieve and outcome such as  retrospectives, planning poker or Innovation Games® since the primary purpose is not training/teaching. These are important too.

Happy to be finally attend InnovationGames in Chicago, July 15/16.

For years I have preferred Scrum as a starting place rather than XP since it is easier to adopt. One of the patterns of Fearless Change is to take small steps. Scrum is a much smaller step than XP. That’s old news. Lot’s of folks like to start with XP, that’s OK by me.

Probably a good thing to clarify at the start is that Kanban is part of the Agile family of processes.

Kanban is easier to adopt than Scrum

Way easier. Like almost trivial. Let’s see: no process change, no role change, no change in team structure. Just make the work visible. Wow! There is so much value in just making the work visible. Lot’s of little problems can be fixed and voila – productivity and cycle time gains.

Kanban uses Kaizen = Continuous Improvement

Kaizen is about continuous improvement. Define a standard process and then start improving. Take smalls steps. Get everyone involved. Kanban is a standardized process flow that starts with the existing process.

In the graph of performance vs time on the left, kaizen will result in improvements that will asymptotically approach the limit within that paradigm.

As teams mature, they may go beyond this into the place where Scrum/XP start…

Scrum/XP is Kaikaku = Radical Overhaul

Kaikaku is discontinuous improvement. It is about a revolution in the way things are done. It is also called Breakthrough Kaizen.

Can anyone say Scrum or eXtreme Programming? It changes work groups, job titles, roles, and project basics. For contexts where Scrum is a good fit, it is a high-value, high-cost game-changing move. James Shore has a great post on Kaizen and Kaikaku where he argues that this is a better starting place if you want a high-performance team.

What does this look like in terms of performance? See graph below. It looks like Virginia Satir’s Change Model.

In the Lean world, companies use both kaizen and kaikaku depending on circumstances as they are complementary approaches.

Why a gateway drug?

The gateway drug theory states that softer drugs (Kanban) can lead to harder drugs (Scrum, XP). This is a great metaphor because this theory has been proven as well as dis-proven. To quote David Anderson “we are only beginning to understand the differences between Scrum and Kanban”.

Do I believe in the the theory? I’m not sure that I care – as long as people are working to improve their work environments at a pace that works for them, that is good enough for me. For me, any Agile is good –  it does not need to be one particular style.

Let’s face it – lot’s of organizations are ready for a radical overhaul. For companies like these, Kanban is a great place to start. Getting off the sofa and going for a marathon may not be a good idea. For some it may be better to start by jogging around the block.

Other Perspectives

David Anderson has a contemporaneous post (go read it, it’s good) supporting the notion that Kanban is primarily focussed on continuous evolution until the organization has enough maturity for more radical changes.

Ken Schwaber is continuing the drum beat that Scrum is the one true path.

I am really excited to have two sessions accepted at Agile 2010 in Orlando. As I am a big fan of pairing to get high quality, I am happy to say these are both pair-designed and will be be pair-led with other great coaches.

The biggest bang for the buck! Strategies to organize & prioritize your backlog – with Gino Marckx is an introductory tutorial and simulation that is part of the Product Management Stage. (Dry run at XPToronto meeting in June)

Look before you leap – Agile readiness assessments done right – with Gerry Kirk is an expert-level workshop that is part of the Agile Adoption Stage. (Dry run at Agile Coach Camp Canada) Check out the program links for more details.

I would like to thank everyone who provided input on the draft sessions in the wave, as well as the comments from reviewers. Oh, yeah, and a big thanks to Gino and Gerry for partnering with me on this.

BTW, there is no official Agile 2010 Speaker logo that I am aware of – I made up the one above

I recently attended a ThoughtWorks QTB – Rapid, Reliable Releases (AKA It’s not making money until its in production) by Rolf Russell and Andy Duncan. It was a solid presentation around the importance of managing environments effectively.

I will walk through the diagram below starting with …

a reliable continuous integration system creates a foundation for rapid reliable releases. It provides early integration and gives the teams rapid feedback on how they are doing. Everything else follows from this.

A key ingredient for successful management of production and other environments is collaboration with dev and ops. There is even a new type of role appearing – DevOps – that handles both development and operations. Either way, someone needs to champion this important interface.

The next topic was about using value stream mapping to see what it takes to actually get something into production (I heartily agree with this approach as I have found it very effective). What we often see as a result is that the work is optimized for each department and is not aligned with the best needs of the whole business and there are lot’s of delays and handoffs.

The next step is to envision future state - what items can go in parallel to get feedback as soon as possible. In one environment is was functional testing, performance testing, and UAT.

A practical idea is to use the cloud for scalable parallel Continuous Integration. In this situation we need lot’s of computers for a short burst, so this lines up nicely with the cloud’s pay per use model and lets testing go really fast.

The final bits of advice were around creating deployment recipes that go with the code (including database changes). In order to accomplish this you will need to create consistent environments and encapsulate differences (such as number of servers, specialized hardware, etc). Once you explicitly handle all the risky bits, then it is easy to support reliable and automated deploys.

If you haven’t done this sort of thing before, then it may seem like a lot of work. For me, it’s seems just normal. I personally implemented a lot of this when I worked at a startup in 2000 and have been using it ever since. I can say firsthand that work on this really pays off.

Video is available on InfoQ.

Below is the presentation I gave at STC (Society for Technical Communication) Management Day in Toronto last week. Technical communications as a field is moving out of just documentation into more value-added activities such as facilitating shared understanding and agreement between diverse groups. As well, getting involved early to reduce documentation required by helping ensure software aligns with users needs.

Last fall, I had the opportunity to hear Ross Pettit and Jane Robart present at the ThoughtWork QTB in Toronto.  You can see the full presentation and slides on InfoQ. (Hint: if you are in Toronto, there is a talk on Legacy Systems coming up on Friday, Feb 5th).

The most memorable phrase from the presentation is: All IT projects are a voyage of discovery. This seemed to be a very salient way to express learning and communication are key.  Check out my drawing of a boat

So the talk is all about governance - how do we ensure that our projects are succeeding? There really isn’t very much in there about the PMO’s role and for that matter about Agile.  Still some very interesting points…

One aspect of governance is making sure we have the right people in the right roles since IT is a people business. The reality is that most managers tend to stick with people even if they aren’t working out in that role. One idea is to use net promoter score: would you recommend a colleage for another project?

Another key idea is independent steering committees. In many cases the stakeholders (usually senior management) are on the steering committee for a project that they are sponsoring. Well, you know what happens when there is a conflict of interest. I’ve seen it happen first hand recently and it wasn’t pretty.

Finally, good steering committees have a breadth of talent that can function as a team to dig into the project data and ask tough questions. They need the right set of lenses to view the project from different perspectives – technical, financial, customer, etc.

Overall the talk was quite informative since I have seen lot’s of room for improving governance at most organizations I have worked at.

Scott Ambler gave the keynote at Agile Tour Toronto this past Fall. As a conference organizer I only caught part of it, but still there were some useful perspectives that I wanted to share. Scott’s presentation is here.

Scaling Factors are about the kinds of things that make software projects more difficult (whether using Agile or not). Each of these factors require additional considerations that are outside of basic Agile practice. I find this a nice way of thinking about project complexity since this directly maps to the challenge with adopting Agile.

There are no repeatable projects.

There are no repeatable projects. I thought that was worth repeating since a lot of organizations still don’t understand that each project has a distinct signature and may require a different approach: Standardization is a good recipe for failure. Reading between the lines this seems to be a shot at PMO’s that are mandated to standardize software delivery.

Mike Cohn placed a challenge on his blog for people to describe a Waterfallacy – “A waterfallacy is a mistaken belief about agile that has been caused by prolonged exposure to the waterfall process.”  This is to promote his new book – Succeeding with Agile.  I have found it very useful in my Agile work and would like you to consider ordering it now to succeed with Agile

I have run up against this waterfallacy many times. Here are some of the things I have heard:

• “Agile is all about coding, not about documenting.”
• “The Agile manifesto says documentation is not important.”
• “How can you deliver software without a requirements document?”

The assertion is that there is little or no documentation in Agile and the implication is that Agile cannot possibly work.

How to overcome these statements?  I talk about 4 things:

1. Agile manifesto – what it actually says
2. Why Agile values face to face communication
3. How Agile documentation works and how Agile teams document a lot
4. If you are using Scrum, it’s up to the organization to define what is right.

Agile Values: Working software over comprehensive documentation

In the Agile Manifesto we talk about valuing working software over comprehensive documentation. So, working software comes first since that is what will make our businesses succeed. The manifesto does not say to avoid documentation entirely – that’s a mis-read!

Agile Principle: Use face to face communication

One of the key Agile Principles is:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This signals that people should talk to each other rather than communicating through documents.  Does it say not to document?  No!

Agile Documentation – just the right amount

Agile teams tend to use wikis as a lightweight and searchable knowledge base. They document things that they think are important or useful. It may be text, photos, diagrams. For more info on how to make this work, check out this article on Agile Modeling.

Most of the Agile teams I work with produce a lot more useful documentation than more traditional teams I have worked on.

Scrum lets the organization decide how much to document

If you use Scrum, let me remind you that Scrum is completely silent on documentation. It’s up to the organization to decide how much and what types of documentation need to be completed every Sprint.

Usually people are convinced at this point and say – “Wow!  I didn’t know that.”

I am very happy to announce that Michel Goldenberg (CSM, CST) and I will be running some public training in February in downtown Toronto (Residence Inn Mariott at 255 Wellington St West).

• Certified Scrum Master Training – Feb 16 & 17
• Agile Games Day – Feb 18

This is a great chance to learn from not one but two experienced Agile coaches.  If you know anyone who might be interested, please let them know.