Venkat Subramanian gave a talk on Pragmatic factors for agile success at NFJS. The talk addressed team member’s attitude towards different aspects of software development. He starts out by comparing the attitude of team members to those of drivers sharing a highway. The ride can be tense and lead to road rage or it can be respectful and pleasant. Venkat discusses these aspects using devils vs. angels’ advice along with how to keep some balance between the 2 opinions.
Work for outcome: The devil suggests the 1st and most important step is addressing a problem is to determine who caused it. Find that person to blame and point at them. The angel suggests being a part of the solution and not the problem. Blame does not fix bugs. Use the problem as an opportunity to learn. To keep a balance, remember that it is everybody’s fault. There will always be problems. Just fix them.
Criticize Ideas, Not People: The devil suggests that you have a lot invested into the design. You have a lot of pride. Stick to your design and don’t listen to anyone else. They just don’t get it. The angel suggests sharing your design with others and asking for help on improving it. Take pride in arriving at a solution rather than proving whose idea is better. To keep a balance always contribute ideas, but know that they will not always be accepted. Be realistic and fair, unemotional but not indifferent or unconcerned.
Keep up with change: The devil suggests that technology changes so fast. It’s overwhelming and you can’t possibly keep up. Just stick to the language you know. The angel suggests that it’s in your best interest to keep up to date. You don’t have to be an expert in everything. Learn iteratively and incrementally by attending local user groups, workshops or conferences, and reading. Spend at least 30 minutes each day learning something new. To keep a balance, ask what’s the value of the new technology? What it does? And what it solves? Don’t convert an application to a new technology just for the sake of learning.
Invest in your Team: The devil suggest that you keep things to yourself. Don’t share what you know. It’s to your advantage to be the smart one on the team. The angels suggest having regular brown bag sessions to raise the awareness of the team. Each member has different expertise and strengths and it’s to your benefit to be in a mature and qualified team. To keep a balance don’t turn the meeting into a design session. Pick a book and stretch beyond technical books.
Feel the rhythm: The devil suggests having a code review once to review the entire code base. The angel suggests not letting tasks add up and tackling them regularly. Have constant code reviews (pair programming) or small task code review. Constantly evolve the code and maintain using TDD. It’s like walking, left foot code, right foot test. Walk while keeping a balance. The key is to set small reachable goals, celebrate your success.
Friday, May 30, 2008
Thursday, May 29, 2008
The Agile Enterprise: Real World Experience in Creating Agile Companies
Jeff Sutherland discussed some real world scrum successes at Agile 2007. He starts by defining some of the characteristics of real scum as companies having agile as a strategic imperative, institutionalizing scrum and xp and not only in development, passing the Nokia test, and having senior management and developers totally involved.
He defines the Nokia iteration test as having timeboxed iterations of less than 6 weeks with tested and working software at the end of the iteration (unit and functional testing). Also, the iteration must start before the specification is complete.
Then there is the Nokia Scrum test which mean you know who the product owner is, the product backlog is prioritized by business value, the estimates are created by the team, they generate the burndown charts and know their velocity, and there are no project managers disrupting their work.
Next, Jeff gives several real world examples of companies he consulted with that are doing real scrum and are producing incredible results.
One company only hired an experienced scrum product owner and managed to cut their product cycle from 18 months to 2 months.
Another was too hyper productive that management ask developers to slow down. Sales could not keep up with the products. They needed a way to get the whole company agile.
Another company was distributed with 567 developers in many locations:
Jeff discussed outsourcing and gives an example of a 2 million project that would cost around 1.6M if outsourced (usually outsourcing save about 20%). Instead, the project was implemented with a local scrum that increased productivity by 240% (can probably even get up to 400%). The local cost was 0.83million without the risk associated with outsourcing such as inability to stadd the project on time, inability to keep staff on project once it starts (turn over running between 35% to 50%), and poor communication due to distance, time zones, lack of formal process, and language barrier.
Jeff gave another example of a company that created a team in Russia doubling the development team size and as a result doubled productivity. The company used distributed agile with teams split between US and Russia. At the end of the project, the company cut the Russian team, but was able to retain knowledge because the US team members remained. This was an example of a distributed, outsourced hyper productive team that resulted in linear scale when using Scrum. By doubling the work force, productivity doubled. On the other hand, in the waterfall model, it is well known that increasing team size when project is late will decrease productivity and make the project even later.
He defines the Nokia iteration test as having timeboxed iterations of less than 6 weeks with tested and working software at the end of the iteration (unit and functional testing). Also, the iteration must start before the specification is complete.
Then there is the Nokia Scrum test which mean you know who the product owner is, the product backlog is prioritized by business value, the estimates are created by the team, they generate the burndown charts and know their velocity, and there are no project managers disrupting their work.
Next, Jeff gives several real world examples of companies he consulted with that are doing real scrum and are producing incredible results.
One company only hired an experienced scrum product owner and managed to cut their product cycle from 18 months to 2 months.
Another was too hyper productive that management ask developers to slow down. Sales could not keep up with the products. They needed a way to get the whole company agile.
Another company was distributed with 567 developers in many locations:
Jeff discussed outsourcing and gives an example of a 2 million project that would cost around 1.6M if outsourced (usually outsourcing save about 20%). Instead, the project was implemented with a local scrum that increased productivity by 240% (can probably even get up to 400%). The local cost was 0.83million without the risk associated with outsourcing such as inability to stadd the project on time, inability to keep staff on project once it starts (turn over running between 35% to 50%), and poor communication due to distance, time zones, lack of formal process, and language barrier.
Jeff gave another example of a company that created a team in Russia doubling the development team size and as a result doubled productivity. The company used distributed agile with teams split between US and Russia. At the end of the project, the company cut the Russian team, but was able to retain knowledge because the US team members remained. This was an example of a distributed, outsourced hyper productive team that resulted in linear scale when using Scrum. By doubling the work force, productivity doubled. On the other hand, in the waterfall model, it is well known that increasing team size when project is late will decrease productivity and make the project even later.
Subscribe to:
Posts (Atom)