Agile
now browsing by category
What kind of rewards should we use in our organisations?
Hi guys, several weeks ago I brought you a polemic post that generated quite interesting feedback. Based on this post, I would like continue the polemic and bring you when should we use rewards towards employees. This blog is inspired by Daniel´s Pink book - “Drive: The Surprising Truth About What Motivates Us”.
In one of my posts, I explained that goals tend to narrow our focus. This is good only for activities that use the left part of the brain; simple tasks that do not require creativity. But for complex and conceptual taks, giving a specific and measurable objective can blinker the wide-ranging thinking that is necessary to come up with an innovative solution. Based on this, I would like to explain for what kind of rewards should we use the Daniel´s flowchart.
Basically, Daniel refers that we should use “If-Then” rewards when a task is boring, not challenging or when we cannot connect it to a wider purpose. This means, “If you do this, then you get that”. We just need to offer a reason for the task, acknowledge the boring task and allow people to come up with their own solutions to solve it.
When the task is not straightforward and it requires using the right part of our brain, we should impose different type of rewards. First, we should use non tangible rewards such as praise and positive feedback, and then provide useful and positive feedback about their work.
As you can see, most of organisations are doing it completely wrong. What can we all do to help companies to change? I guess its our job as Agile Coachs, Agile practitioners and Agile passionates to do something about it. Give me your thoughts…
If you want to know more about Daniel´s book you can take a look in the video below…
[youtube=http://www.youtube.com/watch?v=u6XAPnuFjJc]
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
Change Management tool for Agile Coaches
Hi guys, this time I want to share a simple exercise that I learned last week in the Management 3.0 workshop given by Jurgen Appelo and Mads Troels Hansen. I highly recommend this training! At the end of the training you will go back with a bunch of nice exercises that you can apply right next day at your work.
The exercise is called “Moving Motivators”. To do this exercise, you need a set of cards like these ones. The game is simple, you spread the cards on a horizontal row putting the most important values on the left and the least important ones on the right. After that you think about a change that is happening inside of your organisation and you move the cards up or down depending how the change will impact your values. When you finish, you will have a visual picture how the change will impact you and your values. Below you can find an example.
I believe this exercise can be extremely useful to use with anyone within an organisation that is being affected by changes. I imagine this exercise to be used on a daily basis for Agile Coaches. There are several people, especially middle managers, who are strongly affected when a company goes agile (more about this topic can be found here), performing this game with them can reveal their needs and their fears allowing a coach to work together with them to minimize a negative impact on the work.
Was it useful for you? Leave me your comments and suggestions :)
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
What is an Agile Manager
Hi guys, in this post I want to talk about the role of an agile manager. From my experience, middle managers are the ones that suffer more with an agile transition, let me explain what I mean. When agile is introduced at companies, there are typically three “layers” that are affected at the company: development teams, middle management and top management.
Development team is the first to be affected but their daily job do not change much. The way how they work will change radically but their daily tasks will be the same; they continue developing software to customers. I believe that with top management it´s the same. They must understand agile principles and their the implications, but as for development teams, their daily job will be the same. They will be focused on company´s strategy, not changing their daily tasks that much.
With the middle management, a lot of things change. All their daily work life changes and that´s why I believe that middle management is the part of the organisation that suffers the most. They get insecure because the scope of their work changes drastically. Let me give you a couple of examples; At one of the companies where I worked in the past, middle managers owned most of the technical decisions, they were responsible for team members´ assignments. QA managers were responsible to say if the product was good to be shipped or not and many other things typical from old “silos” companies. But, if everything changes, what is the new role of the middle manager? What are his new responsibilities? Let´s take a look…
Organisational Change Artist - he/she should be one of the persons guiding the organisation towards agile.
Boundary Keeper - reinforcing boundaries both within the team and between the team and the rest of the organisation.
Value Maximiser - one of the persons managing the portfolio of projects. He/she is like a product owner, but in a bigger scale, always asking what is the highest business value project in the organisation.
Lean Manager - will use lean thinking to improve organisational flow so that the value that teams deliver can be delivered without delay.
Organisational Impediment Remover - will navigate trough the organisation and remove all the impediments that are blocking teams to deliver value to customers.
Team Champion - will coach agile teams helping them to achieve fantastic results.
The previous definitions were taken from Lyssa Adkins and Michael Spayd workshop: “Coaching Agile Teams Workshop”. I want to add that most of the new roles do not come naturally, and they require a lot of training and education in Agile. However, I believe these are the new roles for agile managers. What do you think?
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
Different coaching styles for different levels of Shu Ha Ri
Hi guys, in my last post, I spoke about Shu Ha Ri as a tool for agile Coaches and how it can help them to identify at which level of Shu Ha Ri their teams are. In this blog, I will explain what type of coaching should you apply depending on the level of your team. On the picture below you can see different kind of coaching styles for each different level (the original model can be seen in this post).
Teaching - A the name shows, at this stage you must teach the rules. The teams that are at this level they have a really basic knowledge of agile values/principles/practices. They need to have someone to guide them. Examples from Lyssa Adkins:
“Follow these rules. I have followed them before, and I know they will give you what you want. So, for now, just follow.”
“The rules work. Anything else is an impediment.”
“Everything you could need is right here, in this simple framework, so look here for your answers first.”
“Here is how this works”
Coaching - Is the next step. Here, teams have a good understanding of agile values/principles/practices, they start to interiorise them from their past experiences. They start to understand how they can use different approaches to achieve the same end result. At this stage, teams can come up with their own solutions, they just need a coach to help them finding different ways to achieve what they need. Examples from Lyssa Adkins:
“Why does this way of working work?”
“What kills it? What renews it? What feeds it?”
Advising - The last stage. In this stage, the team has fully internalized the values, principles and practices. Everything runs quite well, the role of the coach works as an advisor. For example:
“May I offer an observation?”
“That could work. Try it”
“I do not know. What do you think?”
One important thing, each successive stage contains the others. For example if a team is in “Ha” but you want to introduce a new practice or idea, remember to use a “teaching” approach because they are new to that practice so they will be in Shu for that idea. This is important because most probably you will be changing coaching styles depending on the practice or idea that you want to feed into the team.
Do you think it will help you?
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
Shu Ha Ri a tool for Agile Coaches
Hi guys, this week I want to introduce you an old Japanese martial art concept that describes the stages of learning to mastery - Shuhari. Shuhari is roughly translated to “first learn, then detach, and finally transcend.” I got familiar with this concept during a training I took with Lyssa Adkins. In this post, I want to present this concept applied to agile teams and use it as a tool to help agile coaches to identify in which stage their teams are.
As an agile coach you must understand in which stage your team is in order to help the team to perform in more efficient way. As Lyssa said, if people in a team are in the “Shu” phase they are quite immature in agile and they just follow rules. If they are more mature they will be in the “Ha”, where they can break the rules safely. The last stage is the “Ri” phase where people are so mature that they can create their own rules. Below I will show you some behaviors that help you to see where the team is on the Shu Ha Ri scale. At this point I will quote Lyssa Adkins notes.
Is the team new to agile or to one another? If so, they are at Shu.
Has the team changed or dropped agile practices and lost the intention behind them? Have they mashed up agile with something else so that their practices are not even clear to them? Do they look at you cockeyed when you bring up the agile manifesto? If any of these are true, the team may have progressed to Ha too early. They are truly at Shu and need you to guide them to practice at Shu.
Does the team live by ideals in the agile manifesto? In all they do, do they stand on the side of individuals and interactions, working software, customer collaboration, and responding to change? Do they have the basic practices working well and producing new insights that let them improve each sprint? Do they pause - really pause - to consider the ramifications before they alter, drop, or adda an agile practice? Do they face the consequences of these changes squarely? If these are true, your team is at Ha and needs you to coach them to deeper expression of agile.
Has the team altered their practice of agile and done so consciously, keeping the values and the principles of agile alive? Have they broken through walls of dysfunction in their company so that their practice of agile leads to progressively better and faster delivery and higher satisfaction? Have they imbibed the skills and mind-sets necessary to be truly self-monitoring and self-correcting? If these are true, the team is at Ri and needs you to let them go.
I will explain what kind of coaching styles you should apply to each different stage in my next post. I hope this was 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
Typical Product Owner mistakes in the organisations
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?
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
Tribes - A good exercise for team´s start up
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…
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
Using VSM(Value Stream Mapping) as data gathering for restrospectives
Hi 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.
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
Levels of Agile Coaching
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.
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
Value Stream Mapping a tool to help Systems Thinking
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?
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