Similar to the build master role - I posted about that a few weeks ago - you may find occasionally that there are other topics that you want to overemphasize for a certain period. The build master is specifically taking care of continuously improving the engineering and build environment.
But you may have items that are either to beyond the available build master capacity or don't even fall under the build master's duties. Or you want to speed things up. Let me give you two examples.
Let's say you want to introduce a new testing tool that you haven't used in the past. The tool arrives. While rolling it out you find that there are challenges and issues that need to be addressed. Not that you are surprised but the amount of work is way beyond of what your build master (or build master team) can do within their time. So what do you do?
Or you want to migrate your build environment towards a substantially improved environment, more powerful, more flexible, maybe involving virtual machines, new technologies, and so fourth. A steep learning curve is guaranteed. What do you do?
In both cases you can create a "Mini SWAT Team". This can even be as small as one person. The mini SWAT team would be dedicate to one particular subject for a period of time and then wrapped up. In the first example the introduction of the testing tool could be sped up by working with the QA team and by working with the developers. In the second example the mini SWAT team could work with IT on the environment improvements.
Who would you put on your Mini SWAT Team? Certainly you'd look for someone who can work independently but also in a team. People who can work with different functions are certainly advantaged. But then, you also have a quite different option as well: Give it to a more junior member of your team. Provide a lot of support and you'll find that the person steps up and grows with the job, enjoys the responsibility and the opportunity to pull something through that is of value to the whole team.
Food for thought? I hope so. It's all about trying something new and then adapting as you go!
Saturday, July 25, 2009
Thursday, July 02, 2009
Taking turns in being the build master
The build master is a quite important role in an software development team. Responsibilities include ensuring the build works all the time and chasing down people who are fixing a broken build. Other items may include improving the build process which should also include the execution of comprehensive test suites in all test beds.
While on one hand it is a big help if a person in this role has prior experience with these tasks. On the other hand - and that doesn't have to be a competing goal - it is also valuable if team members take turns.
Let me explain. In all teams that I have coached I have found that different people have different strengths. For example one person might be excellent in writing Perl scripts while a different person is extremely proficient in relational database systems. By taking turns each individual can emphasize their area of expertise in the build master role. That way, if the skill is important to the whole team, the skill is also important for the build master role. Eventually all areas of expertise will get addressed eventually.
One more benefit of taking turns is that all team members walk in "the build master's shoes". There is a much better understanding of and buy-in by the team for build master related tasks and challenges. The response to being chased down because of a broken build will be tainted quite differently than if the same person is in the build master role.
At the moment I'm experimenting with swapping the build master role at the end of each release cycle (currently one month). And already the above mentioned effects have become visible.
Also check out "Manfred's DotNet Blog"
While on one hand it is a big help if a person in this role has prior experience with these tasks. On the other hand - and that doesn't have to be a competing goal - it is also valuable if team members take turns.
Let me explain. In all teams that I have coached I have found that different people have different strengths. For example one person might be excellent in writing Perl scripts while a different person is extremely proficient in relational database systems. By taking turns each individual can emphasize their area of expertise in the build master role. That way, if the skill is important to the whole team, the skill is also important for the build master role. Eventually all areas of expertise will get addressed eventually.
One more benefit of taking turns is that all team members walk in "the build master's shoes". There is a much better understanding of and buy-in by the team for build master related tasks and challenges. The response to being chased down because of a broken build will be tainted quite differently than if the same person is in the build master role.
At the moment I'm experimenting with swapping the build master role at the end of each release cycle (currently one month). And already the above mentioned effects have become visible.
Also check out "Manfred's DotNet Blog"
Saturday, May 30, 2009
The Choice of Not Being an Elephant
Lou Gerstner described in his book Who Says Elephants Can't Dance?: Leading a Great Enterprise through Dramatic Change
how to make even a very large organization more agile, more adaptive to changing conditions. IBM had no other choice since some of their old business models stopped working. When I speak with people who were decision makers in the 1970s they unanimously told me that there was a time where the sales guys in dark blue dresses almost walked in to their customers and just said "sign down here". The customer had little choice.
Even if these stories are exaggerated - I'm not a sales guy but I'm sure their stories are always true! - there is one interesting aspect to this. I'm also mentioning this since I just came back from a trade show and there I spoke to a manager of one of the largest vendors in that particular industry. Somehow that person made me think of those stories from the past about IBM.
Like IBM in the IT industry this person's company is a key player in their industry. And the way the person came across was almost as if he was saying: "We know what is good for the industry, for you. Just do what we say, sign here and everything will be right." Sounds to me a little bit like "We are the center of the universe and all other companies better lign up around us."
The conversation left me wondering by when their CEO will write a book about how she had to turn their company around? Maybe they haven't noticed yet that the downturn in the industry probably requires them changing their attitude as well. But maybe I'm totally wrong and they still have full order books and the customers are lining up to the horizon. Not long ago, however the news were saying they are in the process to make a large number of people redundant.
That doesn't sound to me like full order books... The news of redundancies along with the attitude of the person I spoke to appear more like a company that isn't yet set up flexible and adaptive enough. Maybe reading Lou Gerstner's book helps.
Also check out "Manfred's DotNet Blog"
how to make even a very large organization more agile, more adaptive to changing conditions. IBM had no other choice since some of their old business models stopped working. When I speak with people who were decision makers in the 1970s they unanimously told me that there was a time where the sales guys in dark blue dresses almost walked in to their customers and just said "sign down here". The customer had little choice.
Even if these stories are exaggerated - I'm not a sales guy but I'm sure their stories are always true! - there is one interesting aspect to this. I'm also mentioning this since I just came back from a trade show and there I spoke to a manager of one of the largest vendors in that particular industry. Somehow that person made me think of those stories from the past about IBM.
Like IBM in the IT industry this person's company is a key player in their industry. And the way the person came across was almost as if he was saying: "We know what is good for the industry, for you. Just do what we say, sign here and everything will be right." Sounds to me a little bit like "We are the center of the universe and all other companies better lign up around us."
The conversation left me wondering by when their CEO will write a book about how she had to turn their company around? Maybe they haven't noticed yet that the downturn in the industry probably requires them changing their attitude as well. But maybe I'm totally wrong and they still have full order books and the customers are lining up to the horizon. Not long ago, however the news were saying they are in the process to make a large number of people redundant.
That doesn't sound to me like full order books... The news of redundancies along with the attitude of the person I spoke to appear more like a company that isn't yet set up flexible and adaptive enough. Maybe reading Lou Gerstner's book helps.
Also check out "Manfred's DotNet Blog"
Wednesday, May 20, 2009
How Pair Programming Reduces Distraction
Pair programming is not for everyone. Some people love it, some people hate it. It almost seems there is nothing in the middle.
I'm more in the camp of people preferring pair programming. For many different reasons but I keep the discussion for a different post.
In this one I'd like to describe an example for what happened to me yesterday. I was working with one or my fellow software engineers, Jason, and while we were looking through a nasty C++ link problem we discovered a small item in an adjacent code area that we felt should be cleaned up. So I took a card and wrote it down as a story and returned back to the problem at hand.
Jason was surprised and made comment saying that by taking a note we would actually avoid being distracted. Although I have worked like that for years my colleague is newer to pair programming and that was probably the reason why he noticed what I did. For me it was just normal mode of operation. I did it unconsciously.
Based on my colleagues observation I think there is a lesson to be learned: First there is the specific case. When you come across something that should be done then just take a note (create a 'story' card). Don't let yourself get distracted. That way there is only a small interruption and then you are back on the problem at hand. Secondly, don't assume that the way you work is normal in the sense that everybody knows all the techniques you are using. It pays off to make yourself aware of this and sometimes it takes a good observer like Jason making a comment to become aware of what you are actually doing. So keep your ears open!
I'm more in the camp of people preferring pair programming. For many different reasons but I keep the discussion for a different post.
In this one I'd like to describe an example for what happened to me yesterday. I was working with one or my fellow software engineers, Jason, and while we were looking through a nasty C++ link problem we discovered a small item in an adjacent code area that we felt should be cleaned up. So I took a card and wrote it down as a story and returned back to the problem at hand.
Jason was surprised and made comment saying that by taking a note we would actually avoid being distracted. Although I have worked like that for years my colleague is newer to pair programming and that was probably the reason why he noticed what I did. For me it was just normal mode of operation. I did it unconsciously.
Based on my colleagues observation I think there is a lesson to be learned: First there is the specific case. When you come across something that should be done then just take a note (create a 'story' card). Don't let yourself get distracted. That way there is only a small interruption and then you are back on the problem at hand. Secondly, don't assume that the way you work is normal in the sense that everybody knows all the techniques you are using. It pays off to make yourself aware of this and sometimes it takes a good observer like Jason making a comment to become aware of what you are actually doing. So keep your ears open!
Friday, May 01, 2009
How fast do you adapt?
Here is a quote from today's online edition of The Wall Street Journal:
(Source and more details: The Wall Street Journal, retrieved 01 May 09)
What caught my eye was the word "adapt". By the looks of it - I agree with the assessment - Chrysler didn't adapt fast enough. Now it has filed for Chapter 11, a bankruptcy process that protects it while going through a restructuring.
I'm not happy to see anything like that because many people will be severely affected in their personal lives. However, this is an (extreme) example of what can happen if you don't move fast enough as a company. Chrysler's product mix is no longer a good enough fit for what the market demands. The economic downturn just amplified that.
What can we learn from it? If we don't adapt fast enough to changing market demands and conditions it could mean very bad times for the company or the end of the company. Need any more incentive to adapt?
President Obama said that Chrysler has been "a pillar" of the industrial economy but that the company moved too slowly to adapt to a changing market.
(Source and more details: The Wall Street Journal, retrieved 01 May 09)
What caught my eye was the word "adapt". By the looks of it - I agree with the assessment - Chrysler didn't adapt fast enough. Now it has filed for Chapter 11, a bankruptcy process that protects it while going through a restructuring.
I'm not happy to see anything like that because many people will be severely affected in their personal lives. However, this is an (extreme) example of what can happen if you don't move fast enough as a company. Chrysler's product mix is no longer a good enough fit for what the market demands. The economic downturn just amplified that.
What can we learn from it? If we don't adapt fast enough to changing market demands and conditions it could mean very bad times for the company or the end of the company. Need any more incentive to adapt?
Thursday, April 30, 2009
Can you make it right for everybody?
Yes, you can try as hard as you want. Don't we all try to provide an environment that allows people to grow and be their best professionally?
I think this is an important ingredient for a high-performing team. There are limits, however. For instance if you have a team member who isn't particularly keen to actively support changes. Not that I would be surprised by that. People have different personalities and while most are fine with change for a good reason occasionally there are people who resist all kind of change since they may have different preferences and experiences. And that's fine.
If you have a team member with an excellent skill set and huge amount of knowledge and experience that's fantastic. But what if that very person isn't able to proactively work with other team members to help them becoming better as well? What if you have a team member who doesn't attend the first daily stand-up meeting (aka daily Scrum) and comes in late once the meeting is over? What if on day two the same person comes in late but doesn't join the Scrum although it is still on? What if on day three the person is in the Scrum but doesn't participate actively? What if on top of that you observe that it even seems to have a negative impact on the rest of the team?
I think at some point you need to consider your options. Having one-on-one's for coaching is important and helps in most cases. Attempting to consider individual preferences is good, too. But once the overall team performance is affected, you need to act. And don't let anyone hold you hostage. As a leader and coach you need to keep in mind the future of the entire team and the project and objectives the whole team is working on.
An agile environment is not for everybody. There are organizations that work differently and it seems to work for them. Based on my experiences, however, I believe that agile principles work better if properly applied. In some cases this could mean that you may have an individual on your team who has a different perspective, and you should be prepared for that individual moving on. That's just fair and part of the overall change process for the team (and in fact for that individual, too!). Both the individual and the team are most likely better of.
If you have tried everything you can think of and still it doesn't work out, don't feel like a complete failure. You are not! Think of your team and about where you want to take them. And then adapt and move forward. Don't look back unless you want to learn from the past!
I think this is an important ingredient for a high-performing team. There are limits, however. For instance if you have a team member who isn't particularly keen to actively support changes. Not that I would be surprised by that. People have different personalities and while most are fine with change for a good reason occasionally there are people who resist all kind of change since they may have different preferences and experiences. And that's fine.
If you have a team member with an excellent skill set and huge amount of knowledge and experience that's fantastic. But what if that very person isn't able to proactively work with other team members to help them becoming better as well? What if you have a team member who doesn't attend the first daily stand-up meeting (aka daily Scrum) and comes in late once the meeting is over? What if on day two the same person comes in late but doesn't join the Scrum although it is still on? What if on day three the person is in the Scrum but doesn't participate actively? What if on top of that you observe that it even seems to have a negative impact on the rest of the team?
I think at some point you need to consider your options. Having one-on-one's for coaching is important and helps in most cases. Attempting to consider individual preferences is good, too. But once the overall team performance is affected, you need to act. And don't let anyone hold you hostage. As a leader and coach you need to keep in mind the future of the entire team and the project and objectives the whole team is working on.
An agile environment is not for everybody. There are organizations that work differently and it seems to work for them. Based on my experiences, however, I believe that agile principles work better if properly applied. In some cases this could mean that you may have an individual on your team who has a different perspective, and you should be prepared for that individual moving on. That's just fair and part of the overall change process for the team (and in fact for that individual, too!). Both the individual and the team are most likely better of.
If you have tried everything you can think of and still it doesn't work out, don't feel like a complete failure. You are not! Think of your team and about where you want to take them. And then adapt and move forward. Don't look back unless you want to learn from the past!
Wednesday, April 29, 2009
Projects - Do you need them?
In some companies projects are an important concept since they represent a piece of work, well defined at the beginning, maybe with a business case outlining the commercial benefits, with a project to sequence the tasks and to track progress, and with known deliveries at certain milestones and at a specific date. So far so good. There might be a problem with that, though.
What if your projects are too large? And by large I don't mean the projects that run for several years. More than a month can already be too large depending on your circumstances.
For example suppose you would like to be in a position so that you adapt as quickly as possible to changes in your environment. Customer's preferences can change. While maybe two years ago best use of limited resources was important maybe today it may be cost reduction to get through the recession.
For instance here in New Zealand the new fiscal year has started at 1 April. Many companies have taken this as an opportunity to rethink their position and options. I have spoken to many friends in different companies and to recruiters. It seems as if quite a few companies have made substantial changes triggered by the planning of the new fiscal year and as part of the approval process for new budgets.
There are many other events that change the environment in which you operate. And it appears as if those changes come in shorter intervals than maybe ten years ago.
A project of 2 months might already be too large as it might force you to lock in your team's capacity for that entire time frame. Then what do you do if something changes and you'd like to direct your team onto a different piece of work? Put the project into the bin?
Maybe there is a different notion, a different concept that you can use. What if you could split up the work required to be done by the team in even smaller chunks. For example in the company I currently work for we have many customers who work with us as a partner. Through this work, based on mutual trust and interest, we gain a lot of insights into how we can improve our products. Many small though very valuable enhancement requests are generated through this process, many of them only a few days work, a couple of weeks at most.
What if you'd look at the set of enhancement requests as a stream of small work items (one item batches) as opposed to projects that combine many such requests (large batches). Moving towards using smaller batches, ideally one item each, works better if you optimize towards processing those. Toyota calls this one-piece flow.
I think that is worth considering. Thinking small instead of massive grand schemes. There is more to that, in particular how you get started, what tools to use, and how to make it work. Stay tuned!
What if your projects are too large? And by large I don't mean the projects that run for several years. More than a month can already be too large depending on your circumstances.
For example suppose you would like to be in a position so that you adapt as quickly as possible to changes in your environment. Customer's preferences can change. While maybe two years ago best use of limited resources was important maybe today it may be cost reduction to get through the recession.
For instance here in New Zealand the new fiscal year has started at 1 April. Many companies have taken this as an opportunity to rethink their position and options. I have spoken to many friends in different companies and to recruiters. It seems as if quite a few companies have made substantial changes triggered by the planning of the new fiscal year and as part of the approval process for new budgets.
There are many other events that change the environment in which you operate. And it appears as if those changes come in shorter intervals than maybe ten years ago.
A project of 2 months might already be too large as it might force you to lock in your team's capacity for that entire time frame. Then what do you do if something changes and you'd like to direct your team onto a different piece of work? Put the project into the bin?
Maybe there is a different notion, a different concept that you can use. What if you could split up the work required to be done by the team in even smaller chunks. For example in the company I currently work for we have many customers who work with us as a partner. Through this work, based on mutual trust and interest, we gain a lot of insights into how we can improve our products. Many small though very valuable enhancement requests are generated through this process, many of them only a few days work, a couple of weeks at most.
What if you'd look at the set of enhancement requests as a stream of small work items (one item batches) as opposed to projects that combine many such requests (large batches). Moving towards using smaller batches, ideally one item each, works better if you optimize towards processing those. Toyota calls this one-piece flow.
I think that is worth considering. Thinking small instead of massive grand schemes. There is more to that, in particular how you get started, what tools to use, and how to make it work. Stay tuned!
Subscribe to:
Posts (Atom)
