Interview with an Agile Coach: Mario Lucero
Date: July 2015, By Frank Turley
How did you start to become an Agile Coach?
I started working as Kanban facilitator for a Chilean startup that wanted to improve the workflow of requirements. That startup hired an Agile Coach to provide a great Kanban training and as I showed a great interest on Kanban I became as Kanban facilitator. Then I worked as Scrum Master for several years in medium and large companies dealing with remote team members (and Product Owners as well) and with all of this experience became an Agile Coach. Part of my duties is to help Scrum and Kanban teams to improve their performance and knowledge about Agile practices.
What are the most popular issues that companies are having?
One of the most popular issues is finding a good Product Owners because many companies prefer to assign a Business Analyst or Manager as Product Owner but most of the time they don’t have business knowledge. I have also suggested adding more Product Owners to some projects as the existing Product Owners working on to many different projects, so they missed many times Sprint Planning and Daily meeting.
What kind of projects are you involved with?
I used to work with startups where adopting Agile it is much easier than in big companies but now I am working with multinational companies from different areas such as financial and airlines where I have to deal with traditional mindset and professionals that don’t like to be self-organized.
What Agile techniques do you suggest people to start with?
Many companies are adopting Scrum only because Scrum is popular. I strongly recommend using Lean in order to remove the waste of your process and then start using Kanban. Why Kanban? Because Kanban is less disruptive than Scrum and last but not least, Kanban is simpler to understand and you don’t need to hire an Scrum Master and do many ceremonies (Sprint Planning, Sprint Review or Demo, Release Planning and so on).
What advise can you give a project manager who would like to introduce Agile into their company?
The best advice is to obtain the support of their Directors (or committee) because without it, Agile will fail. In addition, training (and the change as well) has to be done at top levels and then moving to the bottom. Next it is possible to convince the organization that Agile is for all of the areas of the company and not just the IT department.
– For example in the IT Department: you can improve the quality of your code by using:
– Pair Programming (I recommend this after a couple of months),
– Peer Review (it is very helpful for developers),
– Continuous Integration,
Automate test cases as soon as possible in order to improve the testing (if your tester can develop any piece of code you should mix developers and testers at the beginning)
What are the most popular questions that who are new to Agile ask?
Well, there are many but I chose the following:
1) What is a User Story?
The term “User Story” was first used Kent Beck in 1996, and became popular through its inclusion in the first Extreme Programming Project. There are two points that I would like to mention:
2) What is the best approach to deal with unfinished user stories?
Well, there are two approaches: One is to carry over the unfinished user stories to next Sprint and the other is to move all of the unfinished user stories to the Product Backlog so the Product Owner has to decide to include in the Sprint Backlog or not.
If you choose the second approach you have to live with this past and as soon as you want to finish those user stories nobody remembers what was done so you have to invest more time and effort to finish them.
On the other hand, if you choose the first approach you have to keep your eyes on these unfinished user stories in order to finish during the Sprint. If for any reason the owner (developers in charge of working on the user story) are not moving forward on the user story the Scrum Master should talk with the Product Owner in order to decide what other team members are available to finish it.
Furthermore, if you have many unfinished user stories at the end of each Sprint, the Scrum team has to analyze in the Retrospective what was wrong that every Sprint got many unfinished user stories. There are many reasons for this behavior such as the user story was bigger than planned, lack of expertise to develop the user story, incomplete user story or even worse unclear user story.
3) Do you re-estimate your story points during the sprint?
I agree hands down that we do not change story points but I would like to cite a scenario from a company that billed on story points. This company maintained team estimated story points (SPs) and what they could mutually agree to billing. Hence if a story was estimated at 5 SPs but turned out to be 13 SPs, the billing would be for 13 SPs while the team would still see 5 on the dashboard. This also worked visa-versa.
After they had a lot of conflicts they started billing on percentage of the product. It means they calculate what percent of the product was involved in each Sprint and then charge this amount of money (twenty percent of the development cost some dollars and so on).
4) What is the best length for a Sprint?
According many surveys and my own experience dealing with many Scrum teams with different kind of projects, the best length for a Sprint (or iteration as you can find in more Agile Software) is two weeks.
Why? Well, if you choose one week there is no enough time to deliver value to the Product Owner. On the other hand, if you choose four weeks, the Product Owner has to wait too long to receive anything and team members have to wait for a month to get important feedback, so the best time is two weeks.
Do you have a blog and how can people contact you?
Yes, my blog is www.mariolucero.cl with more than two hundreds articles (including book reviews) related to Agile, Lean, Kanban and Scrum. Furthermore, you can read any of my books on www.leanpub.com
The follow list shows the different books:
https://leanpub.com/theroleofproductowner this book is related to the important role of the Product Owner who acts in behalf of each stakeholders of the Product.
https://leanpub.com/theagileanti-manager on this book I renamed the role of Scrum Master as Agile Anti-Manager because he has to help team members in order they improve their performance.
https://leanpub.com/dealingwithtechnicaldebt this book attacks a controversial topic: The Technical Debt that IT Managers do not like to mention until they start getting complains from their clients daily.
https://leanpub.com/agilevirtualcoaching this book focus on a new tendency: working in a remote way as Agile Coach. Over and over companies want to cut their budget with cheaper options in order to hire the best professionals but with the lowest budget.
https://leanpub.com/firstkanban this book explains why every company that moves from Waterfall to Agile needs to start using Kanban instead of Scrum.
https://leanpub.com/theproductownertoolkit this book comprises many useful techniques for Product Owners who need to communicate the Product Vision to every stakeholders who most of the time are not co-located with him.
https://leanpub.com/fakeagileroles this book touch a controversial topic that is on the headlines today. What are the original and unique Agile roles? Well, this short book shows the original and the fake roles that you will run into in many organizations.