Archive for February, 2013

Typical Product Owner mistakes in the organisations

Posted: February 27, 2013 in Agile, Product Development, Scrum, Software Development
12

Hi guys, this week I want to bring a topic about a discussion that I had some time ago with my friend. We talked about how his organization made some mistakes with the Product Owner role. Unfortunately, many organizations do not understand this new role (Product Owner), they think that a typical product manager with the title of Product Owner (PO) will do the job without any necessity to change. So let´s see what are some of the common mistakes that organizations do with the Product Owner role.

Based on my experience, the most common mistake is the lack of presence of the PO. With globalization, it is quite common to find scrum teams that are not collocated with this role. If the organization is not careful, it is really easy to have a product owner that is not there for the team when they need him, specially if he/she does not work in the same time zone as the team.

Sometimes, the reason why the PO is not collocated with the team is, because they belong to other organization. I experienced the same thing. In this case, the PO splits his/her responsibilities between the organization and the team that is developing a product. This is what makes him/her the partial product owner. There are various reasons why this happens but one common is, because of the skills of the PO in the area that is being developed. Companies should play attention to this and avoid such mistake.

On the other hand, there are Product Owners who are completely overloaded with work: the overworked Product Owner. A product owner should not have more than two teams, of course, this is a general rule and it might be possible to have more, but if he/she has more than that, it can be difficult to give full support to the teams.

In order to solve the previous problems, companies sometimes create another problem: The proxy Product Owner. This person acts as a placeholder of the actual product owner. This can lead to decisions´ delay or even conflicts. An author of “Agile Product Management with Scrum”, Roman Pichler, refers to a case where the PO was too busy to take the role, therefore a company got a proxy PO. At the end, there were various conflicts because the proxy PO was not empowered to make decisions and all decisions were supposed be made by the official PO who was never available.

On the same line as the proxy Product Owner the underpowered Product Owner is a quite common mistake. Everyone who is responsible for something but does not have the power to decide anything, probably know what I am talking about. Organizations should empower Product Owners in order to take any decisions to develop the product. If this does not happen, it´s a great recipe for the failure.

The last mistake is the product owner community. This happens to companies that create a committee to be responsible for a product. When there is no responsible person for the product, it can lead to decision´s delays. Often, most of the people involved want to reach an agreement between all parties and this will lead to lengthy meetings without any proper outcome. This is a typical case of “too many chefs in the same kitchen”.

This blog was inspired by the book Agile Product Management with Scrum.

What do you think? Any more ideas?

Cheers,
Luis

Tribes - A good exercise for team´s start up

Posted: February 25, 2013 in Agile, Product Development, Retrospectives, Scrum, Software Development, Team Building
0

Hi guys, this time I want to share an exercise for your new project ramp up. I think this activity is extremely important, because as Lyssa Adkins says “Throwing people in a room or holding a “kick off” is different than a good team start up”. Usually, when a team is formed, people do not know each others, so it´s always a good idea to create some activities that allow team members to get to know each other. The “Tribes” exercise is quite easy yet quite powerful, let´s see how it works…

You must have a big open area with enough space where people can walk around without a problem. After that, ask team members to share some ideas on the topics they are interested in loudly, so that everyone in the room can hear them. People that share same interests on the same topic join the person in the center of the room; this will form a small “tribe”. Ask other individuals to do the same and observe how “tribes” are formed and reformed around the new individual/interest. This is a great exercise that can be used as an ice-breaker activity. It´s always very interesting to observe people´s expressions when they realize that there are many people with the same interests. As a result, the group will understand the other´s appreciations better.

If you want to go deeper in the exercise, you can, for example,ask people to do the same with Agile Best Practices, so that all team members familiarize themselves with different agile skills of their team members. Below you can find few examples, you can create hundreds of them.

* All my tribe members that appreciate pair programming, join me
* All my tribe members that are specialists in TDD, join me
* All my tribe members that love Cucumber, join me
* All my tribe members that think retrospectives are a fundamental part of our project, join me.

I believe, using this exercise will create some kind of bonds among team members and will help them to understand where they position themselves, on personal level and/or on the technical level.

What do you think about it? Let me know whether you use it…

Cheers,
Luis

Using VSM as data gathering for restrospectives

Posted: February 20, 2013 in Agile, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building
9

IMG_20130217_190326Hi guys, in this post I wrote how can we use Value Stream Mapping as a tool to help with system thinking. Many people asked me if I could explain better what Value Stream Mapping is. Therefore, in this blog, I will give a short introduction about it and I will explain how you can use it as a gathering data for your retrospective.

Although value stream mapping is often associated with manufacturing, it is also used in logistics and supply chain, service related industries, healthcare, software development, product development, and administrative and office processes. Value stream mapping is a lean manufacturing technique used to analyze and design the flow of materials and information required to bring a product or service to a consumer. At Toyota, where the technique originated, it is known as “material and information flow mapping”. It can be applied to nearly any value chain. But how can you use this in your team?

The easiest way to do this is to grab some flip-chart papers and tape them on the wall, then divide the space in equal intervals, each interval represents a day of the iteration. Draw a line on the Y axis, this line should be on the position Y=0. If they are doing any activity that will bring value to the customer, tell to each member to draw a line on top of the Y axis line. On the other hand,draw a line under the Y axis line, if they are waiting or blocked by something. They need to do this activity everyday in order to to track all different activities inside the team. Do not forget to write notes when people are blocked or in IDLE; these notes are important to be discussed in the retrospective. The possible result can be something as the picture above seen above.

I guarantee you that you will have plenty of data for your retrospective at the end of the iteration. I tried this couple of times and I was surprised how many issues we find out, how many dependencies and blockers we had and so on. Having this information available will help the team to decide how and where they can improve.

P.S. On the picture, you can see different member roles. I know the setup is not perfect but it was what we could do at that time So, if you want to comment on the blog, try to ignore “non- optimal team setup”, instead focus on the activity.

Thank you guys,
Luis

Levels of Agile Coaching

Posted: February 18, 2013 in Agile, Scrum, Software Development, Team Building
4

Hi guys, this post will be short and simple and it will be focused on the different levels of Agile Coaching. Lately many people have asked me what are the differences within Agile Coaching. For this explanation I want to use a bit of what Lyssa Adkins explained in her workshop “Coaching Agile Teams”.

In her view there are three levels of Agile Coachs. Team facilitator, he is responsible to facilitate practices and collaboration on one team. Agile Coach, this level is responsible to develop teams, mentor others and advise managers. And for last Enterprise Coach, this role is responsible to develop leaders, focuses on culture and catalyses change. Below you can see a graphic how these levels are related to each other.

Team Facilitator
This person focuses on one (or two) teams that are already “up and running”. They are developing basic skills in facilitation, mentoring or training, as well as conscious communication. A team facilitator is not yet ready for Agile adoption or transformation initiatives.

Agile Coach
This person focuses on developing teams, other Agile Coaches & Team facilitators to use Agile well, including the ecosystem around the team. He is an expert in Lean-Agile practices and has chosen a knowledge domain focus (Technical expertise, business or organisational change). He possesses significant facilitation skills, some professional coaching skills, and is adept at mentoring and/or teach.

Enterprise Coach
This person focuses on developing the organisation´s capacity to use agile as a strategic business asset, including culture change, leadership development, and work at all organisation levels.

Like I said this blog was based in Lyssa´s workshop that I do recommend to everyone.

Thank you,
Luis

Value Stream Mapping a tool to help Systems Thinking

Posted: February 13, 2013 in Agile, Process Improvement, Product Development, Retrospectives, Scrum, Software Development, Team Building
13

Hi guys, in this post I want to share with you a nice story that happened several months ago with one of my teams. At that time I had a team that was making the first steps towards Agile. They were a fantastic team, really eager to learn but still with the “old waterfall” mentality. They had a typical approach where the developers did development work and the testers – testing, not really a truly Agile team. I believe this is a common problem for teams that are switching to Agile: seeing only a small picture, they are not able to see the entire system. I believe they lacked “System Thinking”. But what is “System Thinking”?

Shortly explained, “System Thinking” is the ability to see the “big picture” and not to be focused on just a small part of your job. For a better explanation, I will use as an example my former team to demonstrate my ideas. In that particular team the work was arranged so that the developers had a set of User stories to work on. A finished User story was passed over to the testers for testing. The problem was that although for the developers these stories were quite simple to implement, they were quite challenging for testing because of several compatibility issues that required full allocation of testing resources. When developers ran out of User stories they were asking the Product Owner for more stories to work on. However, the PO acted rationally and did not give them any new stories until the team delivered everything to the iteration backlog. It was obvious that the team needed some help to visualize everything that was happening. How to help the team?

Clearly, the developers had their best intentions in mind: they ran out of work, therefore, they asked for more tasks. However, because of their lack of “System Thinking” they did not understand that more work for them would mean more pressure on the testing resources that were already fully allocated and, ultimately, an outcome of a poorer quality of the team effort. Apparently, the developers needed to understand that it was not anymore a matter of “us and them” because their job is accomplished when a customer gets the product, and the product would be ready when the team would act as a single unit. I have discussed this issue with some of my colleagues and they gave me a good idea: in next iteration to use Value Stream Mapping (VSM) for observing how the system behaved. This tool is a great instrument to identify different aspects of a system. If you want to use it you need to take some time to explain this tool to your team. From my experience not many people apply this in software development. VSM can be a fantastic tool to be used at retrospectives, but this could be explained in another post ;) . Let´s see what happened at the iteration retrospective (an iteration where VSM was used).

By that time, the team was already familiar with the VSM and they were quite impressed with the amount of information we collected using it. Having looked at different VSMs (we created one for each different User story), it was not long before the team could see that bringing more User stories to the iteration would not translate into higher output because the testers were already fully loaded, therefore, producing more code would only mean that the testers would not be able to deliver everything on time. The team started appreciating more “System Thinking” and not just think anymore in terms of their separate “boxes”. After some discussions, the developers decided that in the folllowing iteration they would help the testers with all the testing activities to deliver more User stories as a team. In the following iteration the developers and the testers worked more as a team and the output of the joint effort of the team was indeed of a higher quality and volume.

Do you think this is something to consider when you work with your teams? What are your ideas on the topic?

Thanks,
Luis

What metrics should we use in an Agile project?

Posted: February 11, 2013 in Agile, Product Development, Scrum, Software Development, Testing
7

Hi guys, this week I started to read a book that is part of a reading list for the CSP exam. “Extreme Programming - Installed” and I found an interesting chapter about a topic that me and my colleagues were struggling with couple of weeks ago - “What metrics should we use in order to see how the project is progressing? ” Let´s take a look into it…

Ron Jeffries, Ann Anderson and Chet Hendrickson said there are mainly six kinds of metrics that is useful to play attention to in our projects: Resources, Scope, Quality, Time, Tracking and Reporting Scope, Tracking and Reporting Quality. So let´s take a look at each of these metrics.

Resources
Authors of the book defend that we should always keep a track on key resources - planned versus actual. These are number of developers, testers, customers assigned to a project and number of computers in a development, test and production.

Scope
Number of stories over time: how many stories exist, and how many of these are actually accomplished. We can also see how many stories were initially planned vs stories that we have on the backlog at the moment. This metric can give us an idea whether a product owner adds lot of stories or whether he sticks to the initial release scope.

Quality
Here, a simple graphic can be used to show how many automated test cases were run and how many of these were successful.

Time
The core is to track the results of each released plan and discuss the outcome and impact on the project when any functionality was added or removed.

Tracking and Reporting Scope
There are two main metrics: Iteration and Release burndown. The iteration burndown chart helps a team to track the iteration work (estimated vs done).

To track how the release is progressing we can use a graphic presented below. The red bar shows the stories that need to be implemented, green bar demonstrates the ones that were already achieved and the yellow ones the stories that were added to the product backlog.

This website serves as a source to a picture displayed above blog You can find more information how to “Read a Release Burndown Chart”.

Tracking and Report Quality
This part describes three interesting metrics. According to the authors, the first metric, that demonstrates the percentage of unit test that passed on an iteration rate, should be available. The number of successful tests tell how well a team is doing. Please, do not take me wrong, this does not mean that teams should not care about having all tests green during the iteration. You should always aim to have it as “green” as possible, but tracking it on iteration level is a good way to see how the team is doing on a release basis. Here you can find more background information to support this statement.

The second metric applies the same thought as mentioned above. However, this time it serves for acceptance and integration tests. Perhaps, in this case, it makes sense to separate the test by product area in order to see which of the product areas are more complicated. Below you can find a report for acceptance testing during an iteration.

AcceptanceTesting

Finally, as a last metric, a comparison matrix - test cases vs date can be used. This would show us which test cases failed and when did it happen. This would allow us to identify any trend that could emerge from there.

Do you think there is anything missing? Please feel free to comment.

Thanks,
Luis

Is there any demand for “Agile Localization”?

Posted: February 6, 2013 in Agile, Localization, Process Improvement, Product Development, Scrum, Software Development
3

Hi guys, this week I want to tell you what I have been up to for the past couple of weeks. I have written about it as it is always easier to see new ideas in a better light once they are written down. The purpose of this particular post is to invite you to a discussion about Agile Localization.

I have previously mentioned that I started with Agile some years ago, around 2007. Few years onwards while working for one of my previous employers I became responsible for improving the localization process for several products. At the time the localization for those products was done the traditional way - at the end of the product development process towards the end of the project. My role here was to change the traditional approach in-line with the Agile approach so that the product deliverables of each iteration would be localized. The initiative was a success and we were able to have product deliverables of each iteration localized in 87 different languages. After some years of working with Agile I decided to share all the knowledge I acquired during those years with other Agile developers out there, so I started the “Agile Localization” project.

I started writing a book on the subject thinking that it would be something I do in my spare time, but feedback I received from several friends and colleagues made me believe that my interest in Agile localization could lead to something more than just a book. Such as, a consultant might consider writing a book in order to have a successful career in consultancy. Together with two other colleagues we started a consulting company “Oikosofy”. The website mentions several innovation and Agile services that we offer, but there isn’t a mention of Agile localization there.

However, I think Oikosofy could offer Agile localization as a service to localization vendors to be offered to their customers. At least this is what I had in mind when I had a “sales call” from one of the vendors. But it seems the guy did not understand me, rather, as one of my business partners puts it: the problem is not with the listener but with the messenger. I believe, I did not explain myself well enough. So, I take this opportunity to explain my idea in order to see how you like it. Let’s say in this post I present my MVP(Minimal Viable Product) and I would like your opinion on whether there is a demand for this service out there.

The idea behind this service is to help companies sync their localization with their Agile development, so that the deliverables for each iteration would be localized. Of course, to make this possible a team must be already working in Agile and if they are not working in Agile yet, they can always contact us for help with the transition to Agile . But coming back to the topic, this would be a service designed for teams that are working already in Agile yet still treat localization as something to be done outside the Agile process, at the end of the entire product development process. So our role would be to coach the team while working together with them and helping them adopt Agile localization practices so that they could have their product deliverables localised for each iteration.

This service would be offered as a partnership with the localization vendors who would take care of the localization of the product and we would be working together with the customer changing their way of doing localization. This would help the localization vendors because it would improve their collaboration with the customers taking it to a new level. Instead of receiving a huge amount of strings at the end of a development project they would be able to deliver small batches of translated strings for each iteration. This would be also beneficial for the customer because it would allow the customer to have the deliverables of each iteration in all the languages they require. Another advantage here is that the feedback loop would be scaled down, too, which means the customer together with the localization vendor can timely fix any problems with the localization thus improving the quality of the product and reducing its time to market.

So this would be one of the Oikosofy services in a nutshell - Agile Localization . This is my idea of how Agile localisation could be developed into a service and I would greatly appreciate your feedback. Do you think there is a need for such service? Do you think Localization deserves to be a special service for Agile development, what would be pros and cons of it?

Thank you so much for your most valuable input that will help us a lot in developing further the Agile community!

Luis

How to help a team that is not performing so well - Part III

Posted: February 4, 2013 in Agile, Retrospectives, Scrum, Software Development, Team Building
0

In my last post I discussed the pyramid with the five dysfunctions of a team and the appreciation exercise. If you did not see my previous posts, I would highly recommend you to have a look at them first, because this is the last post of a series of posts where I present a possible structure of exercises to help a team recover from a non-productive situation. Here I will explain the remaining exercises necessary to finalize the set of my Team Recover Exercises.

The following exercise is about reinforcing the Scrum values. Lyssa Adkins uses the metaphor of a tree, stating that in order for a team to be highly productive, they need to have strong roots. When the roots are strong and solid the tree can grow and flourish bearing beautiful fruits. Below you can see Lyssa’s example.

Commitment is the state or quality of being dedicated to a cause, activity, etc.. A commitment should never be broken and if it is broken it was not a commitment but an empty promise and a lie. In the Scrum world this means that everyone involved in developing a product is committed to working towards a common objective.

Courage is the ability to confront a fear, pain, a danger, an uncertainty, or intimidation. In software development all these feelings will be always present and it is up to the team members to try to dispel anything that prevents them from being successful.

Openness is the ability to be open to new ideas, new approaches and new ways of working. This is a fundamental state in Agile software development because every day teams encounter different problems that need to be approached differently, being open is mandatory for achieving success.

Focus is the process of selectively concentrating on one aspect of the environment while ignoring other things. In software development this means teams should completely concentrate on one topic at a time, they should not start a new topic before finishing the previous one.

Respect is a feeling of deep admiration for someone or something elicited by their abilities, qualities, or achievements. In Scrum all team members interact closely, respect is mandatory for such relationship to work.

In this blog, you can find another point of view about Scrum values. I believe one hour should be enough to refresh the Scrum values with the team. After this exercise they will be ready for a more practical approach.

At this point, with the values written on a flip-chart, the team is ready for a new exercise. Make sure to reserve half of a day for the next exercise. By now you will need a tool to help the team recap the basics of Scrum and I believe the Lego Scrum is highly effective for that. The goal of the game is to simulate every aspect of the Scrum process: the team members will be asked to build an entire city using Lego blocks. The team will have to put in practice everything learned previously. More details about the Lego Scrum can be found here.

After all these exercises I believe the team will be ready to start all over again and start working better as a team delivering software products of higher quality.

I am not expecting to find a super productive team upon arriving to the office right on the next day after the exercises This is only a starting point, like I mentioned in my SECOND post, there can be five dysfunctions in a team and the exercises that I proposed are just for tackling the most fundamental problems, such as lack of trust. It is up to the Scrum Master or Agile Coach to continue working with the team in order to help them to overcome problems and to become highly productive as a team.

Hope you’ve enjoyed this series of exercises. If you want to try it in your own team, I would like to ask you for a favour: please, come back and share the results .

Thanks,
Luis