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.