Innovation games - Part 1, Prune the Product Tree

Portuguese version

I've recently being in quest to find tools to help me to get better results at the Product Backlog Management. Scrum does not say much about it (no demerit, Scrum is just a framework afterall).

So, how's the Backlog supposed to be managed and prioritized? How do user histories get there? What if the Product Owner (PO) has to address the demands of several stakeholders at once, disputing for a clear finite resource represented by the development team? What should he do?
The purpose of the Innovation games is to be an aid to address these problems. They're playful ways to generate input for a product or service development.

PRUNE THE PRODUCT TREE

Prune the product tree - I promise that I'll create a translated version

Visualizing the product in a linear manner with inorganic representations of roadmaps seems to show the product growth as something linear over time, what does not appear to represent reality.

This game improves the understanding that the product should grow in a planned fashion, allowing stakeholders to model all aspects of the product rather than just giving feedback about a set of features in a roadmap.

When we prune a tree our purpose is to control its growth to be balanced, so the tree is healthy and able to provide fruits of greater quality.

Its fundamental to comprehend that this process is not about "cutting", but about "modeling". This metaphor is used in the game to help creating the product that stakeholders want.

The game 

First, it is necessary either a white board, a flip-chart or anything in which a reasonably sized tree can be drawn or sketched upon.

Represent the system's areas of functionality as branches in the tree, and the roots as what should support the whole tree (your support and customer care infrastructure). Each release may be represented in the tree's canopy with a different shade of green, for instance. The innermost part should represent your actual system, and the outermost parts, what should be developed in the short, medium and long terms (take a look at the image).

Gather a small group of stakeholders (from as few as 4 or as much as 15), because small groups tend to self-organize and generate better results.

Foster debates among stakeholders about pros and cons of each feature, where they should be placed on the tree and also if they should be part of the next release or a future one.

Besides placing new leaves on the tree, ask the participants to remove old ones too. This act meaning that thease features should be removed from the system (The image shows the removal candidate leaves in the dark green part of the tree).

Stay alert for the heath of the tree's growth. Pay attention if it is growing in a balanced manner, if there is a branch in which all features are being placed, or either, if a formerly weak branch is growing more vigorously now. Pay attention if the proposed features are well distributed among short, medium and long term. Pay attention if the roots are strong enough to support the growth of the tree.

After the session, if possible, expose the resulting tree somewhere visible. It is possible that new ideas and/or restrictions are thought of latter.

Variations

Some variations of this game do not show roots, so in these cases, index cards placed on the ground represent features considered of little or no importance.

Another interesting variation is to create a "cloud of doubt", it works as a kind of "parking lot" to not well understood features or the ones that stakeholders don't know how to use.

Why it Work?

The features vary a whole lot in importance and we have a tendency to put all our efforts in the most important ones (they're the ones that provide most value to clients, after all). Unfortunately, this approach commonly leads to the lack of effort on necessary features to complete the product.

The purpose of this exercise is to offer a very visual way for everyone to see the product as a whole. It allows everyone to assess whether the tree is balanced or not. The picture of the tree can be kept somewhere visible to serve as an information radiator.

---

If you want further information on this subject, read Luke Hohmann's Innovation Games Book 

Interview with Ken Schwaber - IT Martini

Portuguese version

Ken Schwaber

Ken Schwaber, co-creator of Scrum, granted an open interview for digital magazine IT Martini in LinkedIn, where members could ask him directly. I had the opportunity to ask him three questions (dark blue font).

This information is provided via IT Martini. Every week, technology leaders and their perspective on the industry are featured in IT Martini Weekly. To date, tens of thousands of IT Professionals have connected socially with IT Martini – both on the web and in person.

Terreece M. Clarke: Hi Ken, Throwing out the first question: what is the biggest misconception IT pros and or management have about SCRUM?

Ken Schwaber: Tereece.
That Scrum solves their problems, when it only makes transparent their problems so they can work on them. Scrum raises people in IT from unconscious to conscious.
Ken

Atul Paradkar: Our stories are usually functional. For example, creating a new input variable on the webpage also needs a new column in database to store the value. Stories would address the validations and business rules. So how to address usability/design and technology (saving in db) using stories?

Ken Schwaber: Atul,
Whenever possible, have any non-functional attached to some (no matter how small) piece of functionality. The functionality proves that it works and lets people see the technology in action.

Beth Bleimehl: Hello, I am looking for some case studies on PMO/Project management and the adoption of agile - specifically Scrum. What does the PMO/project management look like after the company has adopted Scrum? Does the PMO/Project Managers continue to operate as they did in the past? What changes?

Ken Schwaber: Beth,
I don't know of specific case studies. The project manager question has been widely commented on, however. The project manager can either become a scrum master, a product owner, or on the Scrum team. The role of project manager is not part of Scrum.
The PMO often transforms to organizing the product backlog for both the product owners and the development teams. While it doesn't write product backlog items (or order or estimate them), product backlog has many views. These include system software, workflows, functionality, decompositions, and business structures. These must be developed and maintained so product owners can make the most intelligent decisions about what to do next.
Ken 

Raazi Konkader (CSM): Hi Ken,
Are function points (Cosmic or otherwise) a valid measure of size in Scrum?

Ken Schwaber: Raazi,
Function points are a measure of software functionality and are as valid in Scrum as they are anywhere else.
Ken

Leonardo Campos: In the organization I work for, each team is responsible for several different products. The PO normally prioritizes stories from each of these products each sprint, making it hard to create a decent Sprint goal, so the PO simply arguments that the stories are the goal (no purpose, hard to motivate). What do you think about this problem and how do you suggest is the best approach to address it?

Ken Schwaber: Leonardo,
I'd work with the product owner to group, or cluster, the PBI's so they address a business goal or are in the same area of the software. Let him know that it makes your work easier, hence productivity is higher. He/she will pay less.
Ken

Leonardo Campos: I don't know how many questions I'm entitled of, so I'm going to ask one more. Kanban is designed to be very little intrusive, and can be placed upon other frameworks, methodologies etc. How compatible do you think Kanban is to be used as an add-on to Scrum? Would you consider to be viable to have a "Sprint Goal" within a "Scrum-ban" implementation?

Ken Schwaber: I don't implement Kanban by itself, so I don't know about Sprint Goals.
I do like to use Kanban to help development teams learn new development practices, with swim lanes like:
1. Develop acceptance tests
2. Develop design
3. Develop automated tests, code, and documentation
4. Test that they all work together
5. Fix flaws
continue

Raazi Konkader (CSM): Hi Ken,
What are some of the tell tale signs of a team following practice without understanding the theory behind Agile methods like Scrum, XP or Kanban?

How do you generally address this?

Ken Schwaber: They have a problem and don't know how to best address it. If you understand transparency, bottom-up intelligence, help the people do their best, and the art of the possible (all attitudes that come from empiricism and lean), you can make pretty good decisions. If you don't know these, your decisions have no basis and are often counter-productive.

Leonardo Campos: Ken, do you have plans to come to Brazil in the next 12 months? 

Ken Schwaber: No, not in the next 12 months. I'm still recovering from all the food I ate last time. However, I can do a Webex with you anytime. 

Please note this is an interview granted for IT Martini

Inspect & Adapt

Portuguese version

In this short post I'll talk about a very simple recipe for inspection & adaptation (or kaizen, if you have a preference for a Lean term) to make your day-to-day - or process - more efficient:
Given a problem, forget reality and concentrate only on the ideal solution.

1. Confront it with reality. Does it still holds? Does it attend all demands?
2. Now, either update your notion of what is ideal (go back to step 1) or fight to update your reality to make it ideal.
3. In the case you are reading this is because you are trying to improve your reality. Continue to verify if the effects of your actions are indeed leading to an improvement your day-to-day and keep inspecting and adapting always.

Please, leave your comments.

Book Reading Meeting: Improving Agile Knowledge

Portuguese version

I work as a Scrum Master for a major communication company in Brazil.
Our department (R&D) has a program for the creation of, among others, a Content Management System (CMS) able to achieve success in responding to all demands from the newsrooms.
We have 7 teams using Scrum. The whole team comprehends up to 45 people.

Given this scenario, a constant concern I have is to improve the knowledge of everyone on the team (including my own) about Agile tools and methodologies.

We, the ScrumMasters, have recently decided to adopt a practice which has being generating good results, including process improvements: a one hour meeting, twice a week, in which we read and discuss a previously selected book on some Agile subject.

We have started with Henrik Kniberg's - Scrum and XP from the Trenches - because, despite being a pretty simple book, it is an excellent book that everyone had already read. It would fit well for it could serve as a good guide to cover the bulk of Scrum practices (This book covers well the practices, but is admittedly superficial about theories, principles and values). 

It's desirable that every participant have had read the book, or at least the previously agreed upon chapters. For this book in particular, it was not necessary to make prior notes because a fast reading right there was enough to generate discutions, what is exactly what has being generating the best results. I'm pretty sure the next book we intend to read will demand more of us (I'll comment which book we selected in another post).

When we reach some point in which someone has a comment to make, we suspend the reading and let the debate happen. Normally we try to reach a consensus if what the book says is the ideal, afterwards we decide if tie is better than our current practices and why and, last but not least, we try to agree it it is worth to update our current practices (with actions and accountables).

The meeting has a few simple rules:

1. It should happen regardless the absence of some participants
   The objective of this rule is to generate rhythm. As soon as we started, we had only two participants, me and another Scrum Master. The lack of one of us invalidated the meeting, but as more participants joined us, it was possible to create the necessary rhythm. If at least two participants are present, the meeting should happen.
2. Timebox
   Keep the meeting within the chosen timebox. We chose to make it one hour, but decide what is best for you and attain to it, at least until everyone decides to change it.
3. Encourage the presence of representants of every Scrum role
   We now have Developers, Scrum Masters and Product Owners, no Manager yet, it would be very positive, nevertheless. Since every person can see the impacts over its own area of expertise in a cleared way, the discussions become richer and the decisions taken there are more easily implemented
4. Encourage Ideas Confrontation. Read the article Managing Confrontation in Multicultural Teams
   I do recommend you to read the article cited above, but if you are without patience at the very moment, the summary is somehow as follows: The confrontation of ideas makes new knowledge emerge. There are cultures where this is difficult because it is considered rude or simply impolite. If that is the case, the article recommends a simple practice: every participant writes downs their ideas and hands them to a representant who will defend those ideas. It is a way to depersonalize the confrontation.
   The tip here it to keep respectful all the time and do not interpret as "I lost this debate", rather interpret it as "I learned something new". I, for instance, have already lost, I mean, learned a lot of new things.
5. Register the discussion, conclusions and actions
   The register keeps the generated knowledge available to everybody,  clarify the whys of the decisions taken and allows the actions follow up.
   We have being using Confluence to register the meeting. The interesting part is that further discussions take place there, through comments.
6. Actions follow up
   This meeting's objective is to improve knowledge and align perceptions, however, it is also intended to generate process improvements, so it is important to keep an eye over the actions decided on the meeting, specially if they are being executed and if the results are what was expected of them.

I hope you can drop some lines with your opinion, suggestions and any related experience you've had. Oh, please, feel free to correct my English if you happen to see something simply wrong or that could be better writen.