For me, 2010 was a year for attending many conferences but I only did one planned training session – Innovation Games® Master Course with Luke Hohmann – and it was awesome.
It all started with name cards
Who knew what a fun activity this could be? It’s not everyday that I get to use glitter glue …
Never enough wall space
With interaction knobs turned to “11”, the walls were covered with Big Visible Charts or Information Radiators. Note for Agile teams – you can never have enough wall space. A projector was only used for a little bit on the second day.
Grow the Product Tree
Grow the Product Tree is a variant of Prune the Product Tree where the participants create all the leaves. So no pruning, only growing. This is how to play the game if you want to generate lots of options.
Luke spent a lot of time telling war stories about using games. For me this was great. Lot’s of learning and gems. In the photo below we were discussing running parties and galas in online games.
Spider Web for Financial Services Product
Big paper = Big Ideas! Map out how your product interacts with related products.
When and where to Use Games
Here we see what games might be played to support a team at various points in the planning horizon. For example, at the strategy level, we might want to answer the question “What is our BHAG (Big Hairy Audacious Goal)?” and we might use the game Product Box to help answer this.
Same but for Product Development Lifecyle. For example, after the release of a product, we might want to answer the question “What do customers like about the product?” and we might use the game Show and Tell to help answer this.
The above diagrams show that all you need is an image and you can create a brand new game.
Where to find out more?
You can find out about the different Innovation Games® here.
For those of you who follow the Agile Games Google group, you may already be aware of my proposal to create a Serious Games Stage at Agile 2011. The initial title concept was Agile Game stage, but then based on feedback from the list, I read about Serious Games and realized that this title fits the bill.
This week I finally get to learn a ton of useful information at Luke Hohmann’s Innovation Games® for Consultants class. So when we got a chance to do Product Box, I picked the Serious Games Stage as my product. Below are photos of the product box I created as well as a lightning talk (video) where I sell it (You may want to up the resolution to 720p when viewing).
I have also posted a proposal for the Serious Games stage.
The Product Box
Here are the slides and reference links for the session Gino Marckx and I are giving at Agile 2010 in August
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.
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)
Story Map – structure the work in a grid that reflects actual product usage (Jeff Patton)
- Jeff Patton’s blog
Software By Numbers – prioritize work by Net Present Value of Minimum Marketable Feature
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 Analysis – Structured Questionnaire 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)
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.
Derek Longmuir presented ThoughtWorks QTB on working with legacy systems. You can see the video and slides on InfoQ.
I like the definition given by Michael Feathers:
Legacy code is simply code without tests.
Legacy Systems have Value. They are usually business critical and feature rich. They may even be stable and reliable (YMMV). Hint: in the MindMap below, start at 3 o’clock and go clockwise.
Why change from a legacy system? There are number of good reasons: obsolete technology, can’t add features, system is fragile.
This is an important problem since most systems we have 10% of the effort to build and 90% effort to maintain. So to manage costs, we need maintainable systems.
What to do? Traditional approaches such as Big Bang (think explosion) and wrapping/hiding legacy systems rarely achieve business objectives.
Do a system health check. Look at the code. Get complexity measures. Look at test code ratio. What state is the system in?
Before getting started, there are some tools that you will need for basic technical hygiene. The equivalent of brushing and flossing your teeth is test and build automation.
How to tackle this?
With the Strangler approach, the goal is to strangle the existing application by building a new system that runs in parallel. The idea is to put a new interface in place and begin migrating the functionality in a piecewise fashion. This approach takes a lot of effort and makes sense when there is no hope for the existing code base.
The Phased approach is about rehabilitating the system piece by piece. How do you eat an elephant? One bite at a time.
Strangely, there was no mention of the bible on this topic: Working Effectively with Legacy Code by Michael Feathers. This book is a must-read on this topic. As is Refactoring, Refactoring to Patterns, and Clean Code.
This is a review of Luke Hohmann’s excellent blog series on Product Backlog Prioritization. As usual, I have captured what I believe to be the salient points in a visual note. The main points are to:
- Align with Company Strategy
- Balance stakeholder demands
- Drive Profit
Starting at the top left and going clockwise…
Company Strategy. Do you know what it is? Do you know the top 3 priorities. Do you know the product strategy? As product owners, we want to eliminate the work that does not align with these. We also want to focus on those that are most strongly aligned with strategy.
Software By Numbers is a great concept but is difficult to use in practice. Firstly, no one has then numbers and secondly business value models need to account for intangibles.
Driving PROFIT is one aspect of a healthy model. Several different approaches (customer pipeline, market research, etc) can be used to identify key business drivers. Hohmann argues that these are at the theme or epic level rather than an MMF (minimum marketable feature).
Finally, it is critical that product releases satisfy internal and external stakeholders. For me, this is perhaps the deepest insight in this blog. Product owners need to listen to and support a wide constituency for a product to reach its potential value to an organization. In my work as a coach, I sadly notice internal stakeholders such as architecture, support and services are frequently ignored. If you haven’t already used them, Innovation Games® are a great way to understand and make choices.
Ken Schwaber has a great presentation where he talks about the Innovator’s Dillemma and how companies build a (design) dead core.
A typical (success) story
- Management – we need to hit the date.
- Developers – OK, we’ll cut quality but won’t tell you.
- Success! We made the date. We’re heroes!
BUT, this is a horrible long term strategy because you get a design-dead core and can no longer ship product.
Do you have a design-dead core? Here’s a quick checklist (see mindmap below):
- The code is fragile: difficult to work with and things break unpredictably
- Little or no automated test harness.
- Few experts who really understand the technology.
The purported dilemma is that you need to choose between fast delivery and maintainability. So, if you want to get to market fast you need to take shortcuts that are going to hinder you in the long run.
This is also called the inventor’s dilemma.
Agile to the Rescue
Teams that follow Agile practices avoid this peril in two ways.
By managing features and scope, teams can find the most valuable software to deliver by a certain date.
Technical practices such as automated testing, continuous integration and refactoring keep a code base healthy and maintainable. They also helps teams go faster.
Release Burndown to illustrate the Innovator’s Dilemma
Consider the chart below. Companies start at burndown line A. If they use Agile, they will stay there. Most companies don’t. So, release by release, they accumulate technical debt and the code base decays. After a few years, they build a design-dead core.
As a coach, I like to show teams the chart below and vote on their code base. Many companies are at line C with some area’s that are D.
Help! I have a dead core!
OK, so you’ve got a dead core. Sad news. There are ways to recover. I’d suggest you start with Michael Feather’s book Working Effectively with Legacy Code.
Yesterday, Gerry Kirk and I kicked off a 4 day Agile Assessment with a presentation aimed at taking some of the uncertainty out of Agile and providing context for the transition/assessment. See slides below.
The values and agile project life cycle slides were not show; instead, Gerry did a live diagram construction (see photo below). This approach worked well and we got lot’s of great questions.
One of the questions was about Agile contracting. There is a good presentation I commented on in a recent post.
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.