Scrum
now browsing by category
Do you have a quick tool to measure team confidence?
Hi guys, this post will be about a quick exercise that I did during last retrospective and I would like to get your input.
Like always I started the retrospective with a small exercise to “set the stage”, something to make the people relaxed but at the same time helping them to get the focus.
I did the brand car exercise, this exercise is quite basic; we just ask to each different team member how they would describe the previous iteration using a brand car.
I had the brand of the car in my mind, I chose a Ferrari. The iteration went very well; the team delivered all promised stories, and they won a private bet against the PO. He did bet with the team that they would not be able to deliver all promised stories :). Naturally I thought about Ferrari and I expected to hear the same from others.
I started to ask one by one which brand they wanted to better describe during iteration. Surprisingly, all the mentioned brands were modest, such as Opel, Skoda, Ford, etc. The only luxurious brand car was chosen by PO. At that moment I didn’t play so much attention, I thought that these guys are humble :).
Later on during the conversation with an Agile Coach, colleague Mark, he mentioned to me “Did you see how their confidence is so low?” The iteration went so well and according to type of the cars they chose, their confidence of achieving something great was quite low.
This conversation with Mark was the main reason why I am writing this blog! I truly believe this can be used as a quick and simple tool to evaluate team´s confidence. What do you think? Do you think this is a useful tool to verify team’s confidence?
Please comment this post and leave me your opinions :).
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Reading list
Time to time people ask me advice on what books should they read about Software Development, Agile and some other cool topics :).
Based on these requests I am creating this post where I will keep a list of books that I think are really interesting/useful :)
Introduction to Agile:
- Agile Software Development with SCRUM
- Lean Software Development: An Agile Toolkit
- Implementing Lean Software Development: From Concept to Cash
- Leading Lean Software Development: Results Are not the Point
- Succeeding with Agile: Software Development Using Scrum
- Essential Scrum: A Practical Guide to the Most Popular Agile Process
Technical books - Agile Software Development
- Agile Testing: A Practical Guide for Testers and Agile Teams
- Growing Object-Oriented Software, Guided by Tests
- The Cucumber Book: Behaviour-Driven Development for Testers and Developers
- Refactoring
- Working Effectively with Legacy Code
- Specification by Example: How Successful Teams Deliver the Right Software
- Domain-Driven Design: Tackling Complexity in the Heart of Software
- Test-Driven Development: A Practical Guide: A Practical Guide
Continuous Delivery
- Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
- Continuous Integration: Improving Software Quality and Reducing Risk
Scaling Agile
- Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum
- Scaling Software Agility: Best Practices for Large Enterprises
Management, Leadership
- Management 3.0: Leading Agile Developers, Developing Agile Leaders
- The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer
- Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results
- The Five Most Important Questions You Will Ever Ask About Your Organization
- Rework
- Peopleware: Productive Projects and Teams
- The Leadership Challenge
- Taiichi Ohno’s Workplace Management
- Freedom from Command and Control: Rethinking Management for Lean Service
- Out of the Crisis
- Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated
- Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers
Teams Interaction
- The Five Dysfunctions of a Team: A Leadership Fable
Agile Coaching
- Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition
- Agile Retrospectives: Making Good Teams Great
- The Art of Agile Development
Agile Project Management
- Agile Project Management with Scrum
- The Software Project Manager’s Bridge to Agility
Workshops and Presentations
- Presentation Zen: Simple Ideas on Presentation Design and Delivery
Product Management:
- Living Service: How to deliver the service of the future today
- Inspired: How To Create Products Customers Love
- Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise
- Agile Product Management with Scrum: Creating Products That Customers Love
- The Principles of Product Development Flow: Second Generation Lean Product Development
Please comment with some good suggestions to be added ;)
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
How long does it take to run your Regression Test Set?
I want to dedicate this blog to a specific problem that we have during this iteration.
This post is for people who have the same problem, therefore can benefit from it and get some ideas from what we are trying to do.
Our feedback time is giant (Too long to know if we broke anything after committing code). After performing a quick value stream map for the development task we found out that we take between 24h to 48h depending on commited time and working hours.
Scenario I = 48 hours
Commit at 9:00 AM
Automatic build ready to be tested at 00:00 AM
Results at 6:00 PM (It takes 18h to run all the test cases, at this time developers are out from office)
Developers are back at 9:00 AM
Scenario II = 24 hours
Commit at 06:00 PM
Automatic build ready to be tested at 00:00 AM
Results at 6:00 PM (It takes 18h to run all the test cases, developers are still at the office)
Currently the team has 2 Test Sets, first one for smoke testing, second Full regression test set; The smoke testing covers just the basic part, all new test cases for new features are added to the Full Regression test set.
New Approach:
The team decided to create a third test set called “Release Test Set”, this test set will contain the test cases for features developed during the ongoing release, this means, all the automated test cases created by the team during the iterations will end on this “Release Test Set”.
When the product is released all these test cases will be moved to the “Regression Test Set”. With this approach the team will save around 17h of waiting time.
We will continue to run the Regression Test Set on daily basis but this time the team has the possibility to get quicker feedback about their actions during the iteration.
I will keep you posted about the results…
Please comment ;);) And give me your ideas ;)
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Succeeding with Agile, Book Review
This weekend I did read a book and I wanted to share my opinion about some issues in this blog. The book is called “Succeeding with agile” from Mike Cohn.
The book does not bring anything spectacular if you are familiar with Agile but it will give you some fresh ideas about several topics.
Below are the chapters that i found interesting.
Chapter IV describes useful tips how to spread good Agile practices inside the company; one way to achieve this is using improvement communities.
Chapter VI is in my opinion the most interesting chapter. The author dedicates a full chapter to the topic of “Overcoming Resistance”. He explains what kind of people most probably will be against the change, what kind of resistance they will show and simple tools to transform them into no resistors.
Chapter IX defines five topics to achieve technical excellence. Test driven development, Refactoring, Collective ownership, Continuous integration and Pair programming.
Chapter X talks about the team structure; this chapter is extremely interesting, it shows how teams should be assembled and present several studies showing how size of the team affects the productivity.
Chapter XIII gives an overview how to organize the product backlog and how to write good “user stories” with the respective acceptance criteria.
Chapter XVIII touches on a quite common topic nowadays: how to use apply Agile with distributed teams.
Chapter XIX presents situations where Agile needs to coexist with other approaches, for example CMMI or ISO9001. This chapter shows that several approaches can coexist.
Chapter XX describes very important topic; Agile methodologies cannot be implemented thinking only about development, the rest of the departments need to embrace the change, otherwise all the transformation will fail.
The book ends with a great chapter (Chapter XI) that presents some tools to evaluate the maturity of Agile in Team/Organization.
Hope this can be useful for you guys.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Is Localization delaying your product release?
I want to dedicate this post to a problem that I encounter several times.
- Did it ever happen to you that localization is the last thing to be done on the project?
- Was the release of your project delayed because of localization issues?
- Did your product go live just in English because there was no time to localize it?
In most of the projects localization is still done in “waterfall” mode, all the development is performed without thinking about it. Localization team is involved at a very late stage of the development cycle.
What impact does it have on the product?
In my opinion there are several problems related to it:
1) First it’s almost sure that the product will not be released on time. The team needs to wait for all localization so that the product can be released. Most of the times when the localization is done at the very end the GUI is not taken into account in order to support other languages than English. When the product includes other languages than English, several issues arise that needs to be solved.
2) Linguistic quality will be affected, localization and its testing will be performed in hurry. To perform localization testing GUI specs are needed. Most of the times at the end of the development GUI specs do change so much that no one has the latest version anymore, this will provoke many of the strings not being tested anymore.
As a final outcome, the localization cost will increase in order to correct all the defects inserted during the process. I am sure there are many more problems related to this but I wanted to highlight what are the most critical ones.
How can we improve this situation?
Based on my experience I believe these issues can be drastically reduced if localization is part of the development interactions.
What to change to make this happen?
The first thing to be changed is the people’s mind set. Localization is something that needs to be thought of since the beginning of the development.
The development team (usually called Scrum Team in Scrum World) should always contain a responsible person from the localization department. Developers should prepare the software in a way where resources files are used instead of “hard coded” strings.
The GUI specialist should work closely with the localization team in order to make sure that all the GUI is designed in a way that localization part will not have any big issues. Other languages than English usually take on average 20-30% more space, preparing the GUI for these situations will avoid many truncations issues.
Having localization part of the sprint, allowing localization test cases to be done and updated at the same time as the GUI changes allows the localization team to update the test cases immediately or even source files avoiding futures errors in the process. The projects I have participated it was normal to have test cases or source files out of date because there was not a clear conversation between GUI/development team and localization team.
For last a good way to make localization part of the development is to include it as part of the Definition of Done. A story is just completed when is fully localized. My experience shows that is difficult to include testing inside of the sprint. A possible way is to perform the testing within the next sprint when all the stories are done and fully integrated.
Resuming:
- Strings are created by the responsible person
- GUI personal needs to design the GUI taking into consideration other languages than English that will take 20-30% more space on average
- Developers work directly with resources files
- Localization department can localize the strings during the sprint
- Localization department can create localization testing cases based on the GUI specs for the stories being implemented during that sprint
- When the localization is ready, the resources files are included in the build
- Localization testing is performed in the next sprint
As a result, at the end of the sprint we will have:
- Software localized
- Localization test cases created
- Localization testing can start in the next sprint
This will help to reduce all the problems mentioned in the beginning of this post.
Do you think this is helpful?
Do you have any ideas?
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
D5 Creation