NOTE: This article is written by Dave Chaplin, an IT Consultant with 10 years experience. He leads and mentors teams of developers on agile .NET projects and has extensive experience in agile development techniques, particularly Test-Driven Development. Dave can be emailed atdavechaplin@byte-vision.com.
Date: Sunday, October 06, 2002
And it was taken from the following URL: http://www.byte-vision.com/TeamLeadingTipsArticle.aspx
==================================================================================================
Successful Team Leading |
This article describes some practical tips for successfully leading a team of software developers. It defines what success means and then describes some very common sense tips for achieving that success.
What deems a project to be successful?
The primary goal of any software project is to meet the user requirements and make sure the users are delighted. If something has been built that nobody wants, it makes no difference what happens to staff turnovers, budgets or training. If requirements are not met, the project is a failure. The next goal after requirements is probably to complete the project within the required budget. After that, there might be others requiring staff to be trained, and so on.
Here are a number of tips for team leaders to help them achieve success in their own projects.
Meet the correct requirements.
Getting the right requirements from the client warrants an entire article itself and is out of the scope of this article. The key once you have a set of requirements is to make sure that you only build those, nothing more and nothing less. Very often you find developers who like to ‘guess what the users want’ and ‘build things that are ‘very cool’. I’m sure you know the type. You need to build a culture where creativity and suggestions are actively encouraged, but ensure that those suggestions are relayed to the requirements manager, and not immediately built by the developers. To drill this into developers I often ask them how they would feel if they went back to a garage to pick up their car after a basic service, to find that the garage had decided to upgrade the engine to a new one, and that it would cost 5 times as much and not be ready for another week.
Tip 1: Stick to the defined requirements. Don’t guess them yourself. Don’t spend time and someone elses’ money building something that isn’t asked for, and very probably isn’t required.
Getting the right requirements from the client warrants an entire article itself and is out of the scope of this article. The key once you have a set of requirements is to make sure that you only build those, nothing more and nothing less. Very often you find developers who like to ‘guess what the users want’ and ‘build things that are ‘very cool’. I’m sure you know the type. You need to build a culture where creativity and suggestions are actively encouraged, but ensure that those suggestions are relayed to the requirements manager, and not immediately built by the developers. To drill this into developers I often ask them how they would feel if they went back to a garage to pick up their car after a basic service, to find that the garage had decided to upgrade the engine to a new one, and that it would cost 5 times as much and not be ready for another week.
Tip 1: Stick to the defined requirements. Don’t guess them yourself. Don’t spend time and someone elses’ money building something that isn’t asked for, and very probably isn’t required.
Manage Risk Early Focus entirely on the risks of the project and mitigate them. This is the role of the team leader. Building a piece of software is like trying to rob a bank. You don’t want to get caught by the cops. The cops in a software project are all the risks that will stop you achieving your goal. These risks will range across the board from requirements risk, to environment risks, to technical risk. Example1: You finish the entire code base on time, to find out that you needed to raise a change request two weeks ago to get the software released into the live environment. Example2: If you cannot integrate with Bloomberg for currency rates, then it makes no difference whether you write screens for cross currency transfers.
Tip 2: Write down all the project risks, and make sure everyone in the team knows what they are. Mitigate them as early as possible.
Tip 2: Write down all the project risks, and make sure everyone in the team knows what they are. Mitigate them as early as possible.
Keep it simple
Keep the design of your code simple. Build only what you need now, and avoid ‘future proofing’. Again, this is a change of culture for many developers. Most developers like to try and design the most flexible solution to a problem that will future proof them should the user ask for a, b, c and d etc. This is wrong. Complex flexible solutions take longer to write, are harder to debug, and the user hasn’t asked for them. How many times have you found future proof code written which was never used. Think of how JIT (Just In Time) manufacturing works. You start to build things just in time for them being required. If you hold stock (over engineered code) it costs time and money to maintain it. Build the simplest thing that will work. It is cheaper and will be released quicker enabling you to get feedback from the users sooner.
Tip3: If the users ask for a Mini, build a Mini. Don’t build a Mini with a Rolls Royce under the bonnet. Keep it simple and build the simplest solution that meets the requirements.
Keep the design of your code simple. Build only what you need now, and avoid ‘future proofing’. Again, this is a change of culture for many developers. Most developers like to try and design the most flexible solution to a problem that will future proof them should the user ask for a, b, c and d etc. This is wrong. Complex flexible solutions take longer to write, are harder to debug, and the user hasn’t asked for them. How many times have you found future proof code written which was never used. Think of how JIT (Just In Time) manufacturing works. You start to build things just in time for them being required. If you hold stock (over engineered code) it costs time and money to maintain it. Build the simplest thing that will work. It is cheaper and will be released quicker enabling you to get feedback from the users sooner.
Tip3: If the users ask for a Mini, build a Mini. Don’t build a Mini with a Rolls Royce under the bonnet. Keep it simple and build the simplest solution that meets the requirements.
Feedback, Feedback, Feedback
The majority of money spent on software projects is spent after they have been released, and are spent on changes and enhancements to the software. This is due to a number of reasons. One often cited reason is that users don’t know what they want until something is built that they can use. This is why prototyping can be useful. [Beware of prototypes too early in the requirements extraction stage though. Prototypes focus the user too much towards system requirements, rather than business requirements and business goals.] Still, getting software released as early as possible, and getting continuous feedback from the user is key. It mitigates the risk of building the wrong thing.
Tip 4: It is very likely that the requirements will change, so get something out quick and get feedback as soon as possible. Engage the users as often as possible.
The majority of money spent on software projects is spent after they have been released, and are spent on changes and enhancements to the software. This is due to a number of reasons. One often cited reason is that users don’t know what they want until something is built that they can use. This is why prototyping can be useful. [Beware of prototypes too early in the requirements extraction stage though. Prototypes focus the user too much towards system requirements, rather than business requirements and business goals.] Still, getting software released as early as possible, and getting continuous feedback from the user is key. It mitigates the risk of building the wrong thing.
Tip 4: It is very likely that the requirements will change, so get something out quick and get feedback as soon as possible. Engage the users as often as possible.
Know your team
Get to know your team. Every software developer is different. The productivity rate of one developer could be up to ten times quicker than another. Some developers are good and enjoy repeatative tasks, others don’t. Some will tell you the task will take ‘another 5 minutes’, when in fact it will mean a week. Some will like to build a Rolls Royce when a Mini is required and will take 10 times less time to build. Some will write poor quality code that isn’t fit for release. Others will spend too much time focusing on fixing minor bugs rather than moving onto show stoppers. Some developers don’t test their work. And so on.
Tip 5: Know your team. If you don’t know your team then their ‘surprises’ will present a risk to your deadlines.
Get to know your team. Every software developer is different. The productivity rate of one developer could be up to ten times quicker than another. Some developers are good and enjoy repeatative tasks, others don’t. Some will tell you the task will take ‘another 5 minutes’, when in fact it will mean a week. Some will like to build a Rolls Royce when a Mini is required and will take 10 times less time to build. Some will write poor quality code that isn’t fit for release. Others will spend too much time focusing on fixing minor bugs rather than moving onto show stoppers. Some developers don’t test their work. And so on.
Tip 5: Know your team. If you don’t know your team then their ‘surprises’ will present a risk to your deadlines.
Time Estimates
Most developers do not factor development, build, integration, debugging and testing into their estimations. To avoid surprises at deadline dates make sure the developers give you time scales that include the whole life cycle. Write down their estimates and get buy in from them. Use them to feed into subsequent estimates.
Tip 6: Make sure estimates from developers include the whole lifecycle.
Most developers do not factor development, build, integration, debugging and testing into their estimations. To avoid surprises at deadline dates make sure the developers give you time scales that include the whole life cycle. Write down their estimates and get buy in from them. Use them to feed into subsequent estimates.
Tip 6: Make sure estimates from developers include the whole lifecycle.
Refactor The Code
Hopefully you are no longer building complicated frameworks from the start and are focusing on keeping the code as simple as possible to meet the requirements. This gives you quicker delivery and mitigates the risk of building the wrong piece of software. However, you need to make sure that you also continually refactor the existing code base to avoid it rotting. This means changing the structure of the code internally, without changing the external behaviour of the system. You are now evolving the design of the system along the way, rather than trying to guess the whole design up front. Note though, that in order to go down the route of evolving design with refactoring, you really need automated tests.
Tip 7: Refactor your code to avoid it rotting. Back this activity up with automated tests.
Hopefully you are no longer building complicated frameworks from the start and are focusing on keeping the code as simple as possible to meet the requirements. This gives you quicker delivery and mitigates the risk of building the wrong piece of software. However, you need to make sure that you also continually refactor the existing code base to avoid it rotting. This means changing the structure of the code internally, without changing the external behaviour of the system. You are now evolving the design of the system along the way, rather than trying to guess the whole design up front. Note though, that in order to go down the route of evolving design with refactoring, you really need automated tests.
Tip 7: Refactor your code to avoid it rotting. Back this activity up with automated tests.
Automate Testing
Show me a developer who always tests their code and I’ll introduce you to Father Christmas! They just don’t do it. Automating both your unit testing and system testing makes you develop quicker. You have exhaustive sets of tests that run quickly, are documented, are standard, and are repeatable. They also support the refactoring activity. For more on this see my other articles on Test Driven Development , andDeveloping Tests With NUnit 2.0 .
Tip 8: Automate the testing of the application. It massively increases quality saving you an enormous amount of time having to do manual ad-hoc testing and debugging. It also enables you to do effective refactoring.
Show me a developer who always tests their code and I’ll introduce you to Father Christmas! They just don’t do it. Automating both your unit testing and system testing makes you develop quicker. You have exhaustive sets of tests that run quickly, are documented, are standard, and are repeatable. They also support the refactoring activity. For more on this see my other articles on Test Driven Development , andDeveloping Tests With NUnit 2.0 .
Tip 8: Automate the testing of the application. It massively increases quality saving you an enormous amount of time having to do manual ad-hoc testing and debugging. It also enables you to do effective refactoring.
Manage Your Problems
Make sure you keep track of all the issues and risks on the project, and also track your bugs. Prioritise them and deal with them accordingly. If you don’t formally log them, they will get lost and you run the risk of not resolving some important issues raised.
Tip 9: Log and manage the project issues, risks and bugs.
Make sure you keep track of all the issues and risks on the project, and also track your bugs. Prioritise them and deal with them accordingly. If you don’t formally log them, they will get lost and you run the risk of not resolving some important issues raised.
Tip 9: Log and manage the project issues, risks and bugs.
Justify New Technology
Don’t use technology just because it is new. Developers like to open all the new presents that the market constantly tries to claim as the next silver bullet. Some new tools are great, but make sure that developers justify their use in terms of the value they will bring to the project. Being ‘cool’ is not a business reason.
Tip 10: Use new tools only if they provide business benefit.
Don’t use technology just because it is new. Developers like to open all the new presents that the market constantly tries to claim as the next silver bullet. Some new tools are great, but make sure that developers justify their use in terms of the value they will bring to the project. Being ‘cool’ is not a business reason.
Tip 10: Use new tools only if they provide business benefit.
No comments:
Post a Comment