It certainly depends on what kind of career you are looking for. But sometimes if you want to become a leader you may find that being an expert on a non-leadership subject can actually keep you from being successful.
Some authors - I don't want to give reference here since I was looking at German authors - use a model that takes different thinking styles as a starting point. The knowledge focused thinker tries to become and stay an expert on a particular subject. And a person that is an expert may even have the fear that someone comes along who is an even better expert. So they frantically work on become and staying the "best". They may start to defend their beliefs and knowledge, ultimately coming across as defensive, academic, or even arrogant. Non of these perception will help if you want to become an agile leader.
As a leader you are still a subject matter expert. However, instead of being an expert on Crystal, Scrum, XP, or the like, you become an expert on agile leadership. You can delegate the agile practices to people in your team. After all: If you have coached your team over an extended period of time there should be more than enough methodology champions in your team anyways.
So you can let go without losing influence. You are no more under the pressure to create the perfect implementation of Scrum or XP regardless of what "perfect implementation" means. If XP or Scrum doesn't work perfectly it is not you who has failed. The team as such has not yet managed to adopt and adapt it sufficiently. Depersonalize the particular area from yourself.
A question that might help you to make this change towards re-inventing yourself could be: How do you define success? Is it to get pair programming rolled out through-out the organization? Or is it something different? Maybe you want to provide the best possible service to you customers. Maybe you no longer think in terms of black and white, right or wrong, works or doesn't work. Maybe you want to introduce a third category saying: it helps.
Bottom line: To make the shift towards an agile leader you might actually have to let go of trying to be an expert on an agile methodology to be successful!
Showing posts with label agile project leader. Show all posts
Showing posts with label agile project leader. Show all posts
Thursday, July 17, 2008
Tuesday, February 12, 2008
Supplyside Agility
Relationships with suppliers can be organized in more than one way. For instance you could just buy certain components of the shelf. Or if you need a very specific component for your product or project you can gather the requirements and then create a formal RFP (Request for proposal) and invite potential suppliers to submit a bid for the work.
But there are many different factors to play with.
For instance if you have created an RFP there are still a lot of different ways how you work with your supplier. For instance you might decide that for a simple (software) component you specify the interface and a number of tests. These might be functional tests only, or they might also include non-functional tests such as performance or load tests. Then you invite different suppliers to bid on that work and based on criteria such as cost, speed, reliability, etc. you commission the work with a particular supplier.
A different option for the same type of work could be that you slice your system or product in such a way that a development partner becomes responsible for an entire functional area. This responsibility would include not only the implementation but also the testing, the user interface design, and the performance engineering. The development partner might also be required to acquire sufficient domain knowledge for that functional area.
Regardless which option you choose, the more options you have the better you can tailor the setup to your needs. Or in other words you adapt the working relationship according to the type of work, the type of supplier, and possibly other factors. Some work you might even consider to put on a site like RentACoder or similar. Other, more complex work you would either do in-house to preserve the capability or to protect your intellectual property.
The more options you have at your disposal, the more adaptible you are, the more agile you will be and the more likely your project to be successful. Agility is not only about JUnit or XP or Scrum. Agile principles can and should be applied to all other areas of project management as well, including the supply side.
But there are many different factors to play with.
For instance if you have created an RFP there are still a lot of different ways how you work with your supplier. For instance you might decide that for a simple (software) component you specify the interface and a number of tests. These might be functional tests only, or they might also include non-functional tests such as performance or load tests. Then you invite different suppliers to bid on that work and based on criteria such as cost, speed, reliability, etc. you commission the work with a particular supplier.
A different option for the same type of work could be that you slice your system or product in such a way that a development partner becomes responsible for an entire functional area. This responsibility would include not only the implementation but also the testing, the user interface design, and the performance engineering. The development partner might also be required to acquire sufficient domain knowledge for that functional area.
Regardless which option you choose, the more options you have the better you can tailor the setup to your needs. Or in other words you adapt the working relationship according to the type of work, the type of supplier, and possibly other factors. Some work you might even consider to put on a site like RentACoder or similar. Other, more complex work you would either do in-house to preserve the capability or to protect your intellectual property.
The more options you have at your disposal, the more adaptible you are, the more agile you will be and the more likely your project to be successful. Agility is not only about JUnit or XP or Scrum. Agile principles can and should be applied to all other areas of project management as well, including the supply side.
Saturday, February 09, 2008
Agile and Free Flow of Information
In his February 07 blog post ManagePro's CEO Rodney Brim discusses the relationship between being fast and managing information.
I like his post very much. However, ... in my post I'd like to discuss one particular aspect that I think needs some further discussion.
Rodney writes: "...the relationship between being fast or Agile and how..." - I think that being fast is not the same as being agile. I think that agile is about adaptability while being fast is about efficiency. Agile is about the ability to adapt for keeping the business fit in an fast-changing environment. Learning about changing environments and learning from past experiences requires the storage, retrieval, and distribution of information.
A lot of companies use paper or it's electronic equivalent for storing and transmitting information. While this has it's benefits for long-term storage - with proper backups it lasts forever - it has also it's drawbacks.
For instance, if I need a piece of information and I can easily recall it from my memory then this is the fastest to obtain it. If I have a colleague sitting next to me who I can ask and he has the information available then that's probably the next best solution. If I have to sit in front of a computer and enter a query I might get pages and pages of search results, even if I am fortunate enough to have a specialized search engine or even if the body of knowledge is stored in a good intra-corporate wiki. So this type of search tends to be very slow.
So depending where information is stored and what kind of access path I have, information is easy or harder to obtain.
But there is at least one more aspect. When two or more people communicate they again can choose different media to exchange information. After all, whatever one person is saying to a different person is nothing more than sending a small piece of information even if the content might be very simplistic. "How are you?" might carry the information about me caring about the other person. Saying "How are you?" in a face-to-face situation has a different effect than saying the same words on the phone, writing the same sentence in a hand written letter, or writing them in an email.
When I work with my people from my team or people from other teams, e.g. stakeholders, suppliers, customers, I am always on the lookout for difference in understanding of different people. When I spot such a difference I try to organize a face-to-face meeting of those people. I try to get them into one room and make them talk to each other.
I also share with my team as much information as I can. Although this certainly has it's limitations where privacy reasons of individuals or confidentiality of company information gets into the game, but it is an important factor for establishing trust.
Here is another way to describe my approach: In order to make my team more agile I try to "grease" the free flow of information. Only if the important information gets to every team member as quickly as possible the team can react in a timely fashion.
The same applies to reporting. I create reports on a weekly basis for the projects I'm responsible for. The stakeholders are informed at the earliest possible time of opportunities and challenges. Giving enough heads-up time with accurate information is probably one of the best things you can do to support your manager and other stakeholders.
So in that sense a lot of the information we circulate in my teams becomes tacit knowledge in the brains of the people.
As that is not always the best way to store information we also employ a wiki for information that we believe is valuable for long-term storage. And there are other media that we use as well such as spreadsheets, pion-boards, white-boards, etc.
So to become an agile organization it is important to use the most appropriate medium and channel for distributing and sharing information. As a collateral it is interesting to see that an organization that is very adaptible - that is agile - is at the same time also very lean and as a consequence very efficient and fast. In contrast a fast organization might be highly efficient and might be able to process service requests, product manufacturing, or software development tasks extremely fast. But if the environment changes that very same organization might have tremendous difficulties to adapt to the new conditions.
There is (at least) one more way of looking at this: Being fast is about optimizing towards efficiency while being agile is about optimizing towards adaptability. Both can be competing objectives at times.
In summary: I believe that an agile organization is very likely to be fast. But a fast organization is not necessarily agile. The other item I learned from practice: Free Flow of Information improves an organizations adaptability.
I like his post very much. However, ... in my post I'd like to discuss one particular aspect that I think needs some further discussion.
Rodney writes: "...the relationship between being fast or Agile and how..." - I think that being fast is not the same as being agile. I think that agile is about adaptability while being fast is about efficiency. Agile is about the ability to adapt for keeping the business fit in an fast-changing environment. Learning about changing environments and learning from past experiences requires the storage, retrieval, and distribution of information.
A lot of companies use paper or it's electronic equivalent for storing and transmitting information. While this has it's benefits for long-term storage - with proper backups it lasts forever - it has also it's drawbacks.
For instance, if I need a piece of information and I can easily recall it from my memory then this is the fastest to obtain it. If I have a colleague sitting next to me who I can ask and he has the information available then that's probably the next best solution. If I have to sit in front of a computer and enter a query I might get pages and pages of search results, even if I am fortunate enough to have a specialized search engine or even if the body of knowledge is stored in a good intra-corporate wiki. So this type of search tends to be very slow.
So depending where information is stored and what kind of access path I have, information is easy or harder to obtain.
But there is at least one more aspect. When two or more people communicate they again can choose different media to exchange information. After all, whatever one person is saying to a different person is nothing more than sending a small piece of information even if the content might be very simplistic. "How are you?" might carry the information about me caring about the other person. Saying "How are you?" in a face-to-face situation has a different effect than saying the same words on the phone, writing the same sentence in a hand written letter, or writing them in an email.
When I work with my people from my team or people from other teams, e.g. stakeholders, suppliers, customers, I am always on the lookout for difference in understanding of different people. When I spot such a difference I try to organize a face-to-face meeting of those people. I try to get them into one room and make them talk to each other.
I also share with my team as much information as I can. Although this certainly has it's limitations where privacy reasons of individuals or confidentiality of company information gets into the game, but it is an important factor for establishing trust.
Here is another way to describe my approach: In order to make my team more agile I try to "grease" the free flow of information. Only if the important information gets to every team member as quickly as possible the team can react in a timely fashion.
The same applies to reporting. I create reports on a weekly basis for the projects I'm responsible for. The stakeholders are informed at the earliest possible time of opportunities and challenges. Giving enough heads-up time with accurate information is probably one of the best things you can do to support your manager and other stakeholders.
So in that sense a lot of the information we circulate in my teams becomes tacit knowledge in the brains of the people.
As that is not always the best way to store information we also employ a wiki for information that we believe is valuable for long-term storage. And there are other media that we use as well such as spreadsheets, pion-boards, white-boards, etc.
So to become an agile organization it is important to use the most appropriate medium and channel for distributing and sharing information. As a collateral it is interesting to see that an organization that is very adaptible - that is agile - is at the same time also very lean and as a consequence very efficient and fast. In contrast a fast organization might be highly efficient and might be able to process service requests, product manufacturing, or software development tasks extremely fast. But if the environment changes that very same organization might have tremendous difficulties to adapt to the new conditions.
There is (at least) one more way of looking at this: Being fast is about optimizing towards efficiency while being agile is about optimizing towards adaptability. Both can be competing objectives at times.
In summary: I believe that an agile organization is very likely to be fast. But a fast organization is not necessarily agile. The other item I learned from practice: Free Flow of Information improves an organizations adaptability.
Sunday, January 27, 2008
Setbacks
What do you have to anticipate when you have a large number of new members on your team? This doesn't necessarily mean that the new member are really "new". They might have worked for an extended period (several months) on a different project or product.
One likely consequence is that people may no longer be as familiar with how your team works. Or in the case that they are in your team for the first time, they don't know at all how your team works.
At the beginning of this month quite a few new people joined my team for the next release cycle. They are all good engineers, keen to deliver good quality. Yet, this week it happened that although the continuous build was broken, a few more commits of the code base were made.
This was definitely not their fault, and it also was resolved very quickly. The team leads chose a good way by simply talking to the people and explaining to them why it is important to stop committing more change sets if the build is broken. Apparently some of them came from a background where this was not as much encouraged as it is in my team.
In my view there are more than one lesson to learn from this:
One likely consequence is that people may no longer be as familiar with how your team works. Or in the case that they are in your team for the first time, they don't know at all how your team works.
At the beginning of this month quite a few new people joined my team for the next release cycle. They are all good engineers, keen to deliver good quality. Yet, this week it happened that although the continuous build was broken, a few more commits of the code base were made.
This was definitely not their fault, and it also was resolved very quickly. The team leads chose a good way by simply talking to the people and explaining to them why it is important to stop committing more change sets if the build is broken. Apparently some of them came from a background where this was not as much encouraged as it is in my team.
In my view there are more than one lesson to learn from this:
- If there are new people - either from other teams or new hires - you have to expect setbacks, even if you conduct a proper induction to the new team members.
- By working in a co-located team, and by using pair programming as a default, such setbacks do not go unnoticed for very long.
- If you have helped your team to become self-organized, you don't need to step in. The team will take care of such issues themselves. They will find good approaches to resolve such issue immediately.
So, don't be afraid of such setbacks. It pays off to have the courage - one of the agile values - to delegate decisions to the team. They become much more self-sufficient, and setbacks are handled much faster and without your intervention.
I think my team did a great job here. Although they were not "hoping" that something like this would happen, they behaved exactly as expected. They simply helped the new team members to learn and that way to become even better team members.
Wednesday, January 23, 2008
A Nice Story On Estimates
The stereotypical conversation between a manager and a software engineer in a more traditional company goes as follows:
Manager: "I have this piece of work. How long does it take you to complete this?"
Engineer: "It'll take me about 2 months."
Manager: "That's great but let's push the envelope. I think you can do it in 1.5 months."
This is overruling the estimates, and in my experience a big no-no. It is ok and depending on circumstances even helpful to ask guiding questions. E.g. you might want to ask: "What if we implemented this using [xyz] ?" or "Did you consider [abc]?"
Guiding questions help avoiding over-engineering or misunderstandings in the first place.
Today I experienced a different dialog. The manager in the following scene was me:
Manager: "I have this piece of work. How long do you think will it take to complete this?"
Engineer: "It will take about 2 months."
Manager: "Ok, so to be on the safe side, should we say it takes 3 months?"
Engineer: "It will take about 2 months."
And then he went deep into the details to explain to me what tasks would be required for the job.
Bottom line: I observed something extremely positive here. The engineer insisted on his estimate, and I think he was right. He was the person closest to the problem and with the best expertise to make the call. How could I dare to question this if I didn't have better arguments?
Ben, who was the engineer in this particular case, showed me that the above rule also works the other way round. Don't just change the estimates if your best engineers give you an estimate. And this applies for both, decreasing and increasing the estimates. Thank you, Ben! I shouldn't have questioned your judgement in the first place.
Manager: "I have this piece of work. How long does it take you to complete this?"
Engineer: "It'll take me about 2 months."
Manager: "That's great but let's push the envelope. I think you can do it in 1.5 months."
This is overruling the estimates, and in my experience a big no-no. It is ok and depending on circumstances even helpful to ask guiding questions. E.g. you might want to ask: "What if we implemented this using [xyz] ?" or "Did you consider [abc]?"
Guiding questions help avoiding over-engineering or misunderstandings in the first place.
Today I experienced a different dialog. The manager in the following scene was me:
Manager: "I have this piece of work. How long do you think will it take to complete this?"
Engineer: "It will take about 2 months."
Manager: "Ok, so to be on the safe side, should we say it takes 3 months?"
Engineer: "It will take about 2 months."
And then he went deep into the details to explain to me what tasks would be required for the job.
Bottom line: I observed something extremely positive here. The engineer insisted on his estimate, and I think he was right. He was the person closest to the problem and with the best expertise to make the call. How could I dare to question this if I didn't have better arguments?
Ben, who was the engineer in this particular case, showed me that the above rule also works the other way round. Don't just change the estimates if your best engineers give you an estimate. And this applies for both, decreasing and increasing the estimates. Thank you, Ben! I shouldn't have questioned your judgement in the first place.
Monday, January 07, 2008
Reasons for Staff Turnover
People are joining your team. People are moving on. Both can be good or bad. In all cases staff turnover has an impact on your team and also an impact on the relations to other teams, including customers and other stakeholders.
People leave for different reasons. In some cases it might actually be the best option for both the person and the team, if the person is leaving. Sometimes people simply prefer a different working style that is not compatible with that of the team.
A few years ago I had a team member who preferred to work alone and who preferred to work on very complex items. He saw these tasks as unique opportunities and challenges. He was an excellent engineer. The solutions worked and when you took a closer look they turned out to be excellent solulutions. Almost beautiful. However, the person was very introverted and he wasn't able to fully leverage his potential to the rest of the team. In addition the code he created despite being excellent from an engineering perspective as too complicated for the average engineer. The solution was complex, elegant, and still hard to understand as some of the concepts were too abstract for some people. In the end he decided to move on to a different company. It turned out a good development. He was better off because he moved into an environment more suitable for his working style, and the team was better off because the proliferation of the highly abstract code was avoided.
And even more years ago, I had a team member who wasn't able to adopt a new programming paradigm. It was when we introduced object-oriented programming. That was in the early 90s. The engineer tried for many months to come up to speed. Finally he and his manager had to realize that he wouldn't be able to make the required mindshift. We then decided to try finding a different role. Fortunately we found a solution that was beneficial for both the team and the engineer. Instead of simply developing software, he took on a role that contained elements from marketing and presales support. We preserved his experience for the company and at the same time opened up a development path for the struggling engineer.
Fortunately when people leave most of them leave for good reasons. For instance people may choose to move to a different country. Here in New Zealand it is part of the life style to go on an overseas experience (OE). Over several years I saw people leaving for Europe, US, Canada, Singapur, Australia.
Another reason to leave might be that people would like to pursuit a career that is not available within the current company. Sure, you probably would keep people within the company but sometimes it is simply not possible.
Compensation might be a reason as well. My personal preference would be that people don't leave just because of the compensation package. And similarly I don't want people stay just because of the compensation package. I guess I am trying to say that you should be very careful with the compensation package. You don't want just the geniuses (see example above) but on the other hand you don't want to pay just bananas and peanuts either (otherwise you shouldn't be surprise if you are surrounded by monkeys). Compensation is a hygiene factor. You have to have an eye on it.
In my next post I'll explore a little more on the impacts of staff turnover and how to mitigate them using agile principles and techniques. I wish you a Happy and successful New Year!
People leave for different reasons. In some cases it might actually be the best option for both the person and the team, if the person is leaving. Sometimes people simply prefer a different working style that is not compatible with that of the team.
A few years ago I had a team member who preferred to work alone and who preferred to work on very complex items. He saw these tasks as unique opportunities and challenges. He was an excellent engineer. The solutions worked and when you took a closer look they turned out to be excellent solulutions. Almost beautiful. However, the person was very introverted and he wasn't able to fully leverage his potential to the rest of the team. In addition the code he created despite being excellent from an engineering perspective as too complicated for the average engineer. The solution was complex, elegant, and still hard to understand as some of the concepts were too abstract for some people. In the end he decided to move on to a different company. It turned out a good development. He was better off because he moved into an environment more suitable for his working style, and the team was better off because the proliferation of the highly abstract code was avoided.
And even more years ago, I had a team member who wasn't able to adopt a new programming paradigm. It was when we introduced object-oriented programming. That was in the early 90s. The engineer tried for many months to come up to speed. Finally he and his manager had to realize that he wouldn't be able to make the required mindshift. We then decided to try finding a different role. Fortunately we found a solution that was beneficial for both the team and the engineer. Instead of simply developing software, he took on a role that contained elements from marketing and presales support. We preserved his experience for the company and at the same time opened up a development path for the struggling engineer.
Fortunately when people leave most of them leave for good reasons. For instance people may choose to move to a different country. Here in New Zealand it is part of the life style to go on an overseas experience (OE). Over several years I saw people leaving for Europe, US, Canada, Singapur, Australia.
Another reason to leave might be that people would like to pursuit a career that is not available within the current company. Sure, you probably would keep people within the company but sometimes it is simply not possible.
Compensation might be a reason as well. My personal preference would be that people don't leave just because of the compensation package. And similarly I don't want people stay just because of the compensation package. I guess I am trying to say that you should be very careful with the compensation package. You don't want just the geniuses (see example above) but on the other hand you don't want to pay just bananas and peanuts either (otherwise you shouldn't be surprise if you are surrounded by monkeys). Compensation is a hygiene factor. You have to have an eye on it.
In my next post I'll explore a little more on the impacts of staff turnover and how to mitigate them using agile principles and techniques. I wish you a Happy and successful New Year!
Tuesday, December 18, 2007
Tools
No engineer can exist without tools. Tools come in many shapes and sizes. This is no different for software engineers. And there are tools for agile project leaders as well.
For a software engineer most tools are pretty obvious. For instance a compiler, an editor, or a test framework (e.g. csUnit, JUnit, etc.), etc. But then there are other tools that are less obvious. What about the index card that you use for writing your story? What about the cards you use for planning poker (TM)? They are all tools in a wider sense.
An agile project leader has tools as well. Again some are more obvious like a reporting tool that gives him/her the latest financials for his/her projects. But there are others such as if you detect that a group of people is not on the same page in terms of information sharing. Then your tool of choice might be to get these people into one room and get them talking. Communication and collaboration are agile principles and so getting people to do both of this is a tool that an agile project leader has at his/her disposal.
It is important to use a broader definition of the term "tools". If you do you will discover many more tools you are using. Experiment with them. Try out new ones. Drop the ones that don't work for you. Listen to your team members. Often they have the best ideas anyways. Don't put tools away completely that didn't work at some stage as maybe at a later stage their time might actually have come.
Equally important is to look for tools that are simple and easy to use. Keep them as simple as you can get them. No need for an elaborate version control system if you can get away with a simple one like CVS or Subversion which have essentially little more features beyond update, commit, label, or branch.
Simple and small tools are much more flexible. They are easier to learn. They are easier to integrate with your existing environment. They tend to be easier to operate. And you can combine them forming more powerful solutions. If you select a good set of light weight yet efficient tools you can almost use them like Lego (tm) blocks to build the environment you need. And still you stay flexible and can adapt as needed by recombining or reconfiguring your toolset.
An Example
As an example for a simple yet efficient tool let's look at how you evaluate the engineers on your team. Many options exist. In large companies I have found systems (probably running on expensive hardware) which the managers are supposed to use for their evaluations. But there are simpler options. First of all, are you as the manager in the best (or only?) position to evaluate your team? What if you would delegate that task to your team and perform a peer review? What if you could use a simple tool to do that, e.g. a spread sheet that you send to all your engineers to evaluate each other?
You can find such a tool for free here. And here are a few things you can try out:
So always THINK before you start using a tool.
And finally: The agile community would love to hear about your experiences. So I'd like to invite you to participate in the tools stage at the Agile 2008 conference.
For a software engineer most tools are pretty obvious. For instance a compiler, an editor, or a test framework (e.g. csUnit, JUnit, etc.), etc. But then there are other tools that are less obvious. What about the index card that you use for writing your story? What about the cards you use for planning poker (TM)? They are all tools in a wider sense.
An agile project leader has tools as well. Again some are more obvious like a reporting tool that gives him/her the latest financials for his/her projects. But there are others such as if you detect that a group of people is not on the same page in terms of information sharing. Then your tool of choice might be to get these people into one room and get them talking. Communication and collaboration are agile principles and so getting people to do both of this is a tool that an agile project leader has at his/her disposal.
It is important to use a broader definition of the term "tools". If you do you will discover many more tools you are using. Experiment with them. Try out new ones. Drop the ones that don't work for you. Listen to your team members. Often they have the best ideas anyways. Don't put tools away completely that didn't work at some stage as maybe at a later stage their time might actually have come.
Equally important is to look for tools that are simple and easy to use. Keep them as simple as you can get them. No need for an elaborate version control system if you can get away with a simple one like CVS or Subversion which have essentially little more features beyond update, commit, label, or branch.
Simple and small tools are much more flexible. They are easier to learn. They are easier to integrate with your existing environment. They tend to be easier to operate. And you can combine them forming more powerful solutions. If you select a good set of light weight yet efficient tools you can almost use them like Lego (tm) blocks to build the environment you need. And still you stay flexible and can adapt as needed by recombining or reconfiguring your toolset.
An Example
As an example for a simple yet efficient tool let's look at how you evaluate the engineers on your team. Many options exist. In large companies I have found systems (probably running on expensive hardware) which the managers are supposed to use for their evaluations. But there are simpler options. First of all, are you as the manager in the best (or only?) position to evaluate your team? What if you would delegate that task to your team and perform a peer review? What if you could use a simple tool to do that, e.g. a spread sheet that you send to all your engineers to evaluate each other?
You can find such a tool for free here. And here are a few things you can try out:
- Before you send out the actual sheet ask you team to review the categories or the descriptions of them.
- Try out different cycles, e.g. once a year, at the end of each project, every three months, etc.
- Try to expand it to non-engineering roles
- Ask people to also fill in the column with their own name. Is there a big difference between their self-perception and how they are seen by the team?
I'm sure you can find more factors to play with. Let me know how it goes and whether you find this type of tool useful. And always remember:
"A fool with a tool is still a fool." (anonymous)
So always THINK before you start using a tool.
And finally: The agile community would love to hear about your experiences. So I'd like to invite you to participate in the tools stage at the Agile 2008 conference.
Subscribe to:
Posts (Atom)
