At CommuniTech, Jeff Patton gave a talk about agile software development. Jeff starts by giving an introduction to agile. He mentions that it is nothing new. Scrum (1986), Crystal (1997), FDD(1998), XP(2000) all lead to the agile manifesto was in 2001. Agile development describes a class of approaches and not just a single approach. It combines elements of Scrum, DSDM, Crystal, FDD and XP.
Jeff then gives a primer on Scrum. A product owner sets product goals and adds requirements or features to a product backlog, he then takes highest priority items and elaborate them into details and start a development cycle of 2 to 4 weeks. Team has a daily stand up meeting to follow progress. At the end of the iteration, they evaluate the working software and get feedback which might affect the product backlog and the next iteration.
Jeff shows how the picture of the scrum process looks like a snowman. The head is stories that get packaged into an iteration. Every iteration does not have to result in a releasable product. It’s a number of iterations that form a release, and a number of releases form the product. Each cycle feeds into planning. At the iteration level, feedback is used to better understand the problem and to reduce risk. At the release level, the feedback ensures proper planning for releasing value. At the product level, the feedback is to update the roadmap.
Next Jeff presents 3 very entertaining scenarios (using personas and music lyrics) which demonstrate some practices that might lead to problems when using an agile model. He concludes that iterate does not mean increment. In incrementing we are piecing things together and it calls for an early well formed idea. Iterate builds a rough version, validates it, and then slowly builds up quality. Quality here refers to look and feel, characteristics and features. The client needs to prioritize the goals that generate return on investment. The developer needs to know what the client wants but always keep in mind what the ultimate goal is. They also need to push decisions to the last responsible moment and build up feature quality iteration by iteration. Instead of writing stories about what to do, write stories about what it intends to accomplish. Have a goal, take action, evaluate the action, and then evaluate if the goal got accomplished. Push decisions to the last responsible moment. Each story has the following characteristics:
1. Necessity: The minimum needed to get working software.
2. Flexibility: what are some alternative ways of doing it, what additional data we want to capture.
3. Safety: better validation rule to avoid ugly error messages.
4. Comfort, luxury, and performance: more usable, sexier to look at (animation), hot keys.
Jeff recommends starting out with the necessities and then slowly build up the product.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Uncertainty-Jeff-Patton
Monday, December 29, 2008
Wednesday, December 17, 2008
Introduction to Project Estimation
At Devoxx08, Giovanni Asproni gave a talk on Project Estimation. He emphasized the need to distinguish estimate from targets and commitments. Estimates are approximate estimation of the value, number or quantity of something (2 to 4 days, 10 to 20 million). A target is a desirable business objective (Support x users, do not exceed 1 million dollars). Commitment is a promise to deliver functionality with a certain quality by a certain date (search functionality will be available in next release). These three are independent of each other, but you should set targets and commitments based on your estimates. The estimates are not negotiable. But the targets and commitments are. The estimates are used to determine if the targets and commitments are realistic. Usual estimates include size, effort, time, cost, risk. Given some constraints (time and cost), estimate the other.
Estimates should be accurate and not precise. This means use the correct measurement unit. If something will take years, do not estimate in days or hours. Hours will be more precise, but it will be less accurate than a more appropriate measurement unit like years.
The cone of uncertainty shows that your estimates are off by a margin of error at the beginning and gets more and more accurate as the project moves along. The cone is the same for sequential or iterative projects. Do not commit at the beginning of the cone, but at a later date after several iterations or at the product design specification.
People who do the work should create the estimates. All assumptions should be taken into account. All tasks should be included. Make sure to plan for leave/absence and side tasks such as phone, email, meeting, browsing.
There are several techniques for estimation:
1) Count, compute, judge: count if you can, compute if you can’t, judge as a last resort.
2) Mathematical (COCOMO): Tools available but based on “knobs” (inputs unknown/inaccurate).
3) Historical: Industry, company or project data. Can be accurate, avoids wishful thinking.
4) Analogy: Compare to similar projects, simple to implements but subjective and less accurate.
5) Proxy: Use proxy to effort like story points or t-shirt size. Can be highly accurate but require experience.
6) Decompose and recompose: Split into small chunks and aggregate. Can be accurate but be careful because sum of individual chucks will not equal whole.
7) Expert Judgment: Individual or group (Delphi, planning poker). Can be highly accurate, but need experts.
More than one can be used at the same time as a sanity check. Start with historical data if available. If not use, expert judgment, proxy, or analogy. Keep track of your data and use it to improve as you go along. Estimation is an ongoing activity. Refine the estimates as you go along and remember that estimates will always be wrong!
This presentation is available on Parleys at http://parleys.com/#st=5&sl=1&id=14
Estimates should be accurate and not precise. This means use the correct measurement unit. If something will take years, do not estimate in days or hours. Hours will be more precise, but it will be less accurate than a more appropriate measurement unit like years.
The cone of uncertainty shows that your estimates are off by a margin of error at the beginning and gets more and more accurate as the project moves along. The cone is the same for sequential or iterative projects. Do not commit at the beginning of the cone, but at a later date after several iterations or at the product design specification.
People who do the work should create the estimates. All assumptions should be taken into account. All tasks should be included. Make sure to plan for leave/absence and side tasks such as phone, email, meeting, browsing.
There are several techniques for estimation:
1) Count, compute, judge: count if you can, compute if you can’t, judge as a last resort.
2) Mathematical (COCOMO): Tools available but based on “knobs” (inputs unknown/inaccurate).
3) Historical: Industry, company or project data. Can be accurate, avoids wishful thinking.
4) Analogy: Compare to similar projects, simple to implements but subjective and less accurate.
5) Proxy: Use proxy to effort like story points or t-shirt size. Can be highly accurate but require experience.
6) Decompose and recompose: Split into small chunks and aggregate. Can be accurate but be careful because sum of individual chucks will not equal whole.
7) Expert Judgment: Individual or group (Delphi, planning poker). Can be highly accurate, but need experts.
More than one can be used at the same time as a sanity check. Start with historical data if available. If not use, expert judgment, proxy, or analogy. Keep track of your data and use it to improve as you go along. Estimation is an ongoing activity. Refine the estimates as you go along and remember that estimates will always be wrong!
This presentation is available on Parleys at http://parleys.com/#st=5&sl=1&id=14
Sunday, November 2, 2008
Technical Practices Turning the Agile Dial to Eleven
Craig Smith and Paul King gave an experience report at Agile 2008 about technical agile practices. They started out with an initial goal of 100% of code coverage for unit test, all production code paired and test driven, minimal design up front with appreciation for when such design made sense, customer focused outcomes, full continuous integration, daily pair rotation, continuous improvements through retrospectives, high levels of automation (installers, vmware instances), and light weight metrics to monitor progress.
Using quality metrics forced team to have a common way of doing things. They tracked duplications, and enforced 0% duplication (4 lines limit). They also tracked method and class complexity & size and kept extremely simple classes and code with approximately 10 lines per method, 80 lines per class.
For testing boundaries used for 3rd party apis, they used an IDE plugin to create static boundaries, used Groovy to automatically eliminate checked exception through a language feature, and used auto boundaries of an interface
To ease the use of mock objects, they built a framework to avoid boiler plate code. They had the IDE convert code into expectations, and used annotation for instance/mock creation.
They implemented auto checking for nulls for public methods and public constructors, auto checking getters and setters, and checked for project wide rules to do with final, equals and hashcode. Other numerous types of classes had further checks for immutable, serializable, data, and domain.
They disposed of interaction based tests. The IDE could recreate them whenever refactoring was required.
They wrapped up by discussing future direction of acceptance-TDD or functional-TDD, evolving how they use TDD and CI (groovy, easyB), leveraging a broader base of testing approaches (jester, AllPairs, Theories, Grids), further using DSL, and further using Groove, or Scala.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Super-Agile-Craig-Smith-and-Paul-King
Using quality metrics forced team to have a common way of doing things. They tracked duplications, and enforced 0% duplication (4 lines limit). They also tracked method and class complexity & size and kept extremely simple classes and code with approximately 10 lines per method, 80 lines per class.
For testing boundaries used for 3rd party apis, they used an IDE plugin to create static boundaries, used Groovy to automatically eliminate checked exception through a language feature, and used auto boundaries of an interface
To ease the use of mock objects, they built a framework to avoid boiler plate code. They had the IDE convert code into expectations, and used annotation for instance/mock creation.
They implemented auto checking for nulls for public methods and public constructors, auto checking getters and setters, and checked for project wide rules to do with final, equals and hashcode. Other numerous types of classes had further checks for immutable, serializable, data, and domain.
They disposed of interaction based tests. The IDE could recreate them whenever refactoring was required.
They wrapped up by discussing future direction of acceptance-TDD or functional-TDD, evolving how they use TDD and CI (groovy, easyB), leveraging a broader base of testing approaches (jester, AllPairs, Theories, Grids), further using DSL, and further using Groove, or Scala.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Super-Agile-Craig-Smith-and-Paul-King
Monday, October 20, 2008
Sunday, October 12, 2008
Measuring Agile in the Enterprise: 5 Success Factors for Large Scale Agile Adoption
At Agile 2008 Michael Mah discussed Measuring Agile in the Enterprise. He starts by mentioning that Business will have to soon make a decision to reduce costs. 1) ship development to India, 2) adopt agile or 3) ship to India and adopt agile.
Michael then shares metrics (size, time, effort, defects, and productivity) collected from agile projects against industry averages. The data was mainly from BMC and Follet and looked at cost, schedule, defects, and staffing showing better results for the mature agile teams. Then Michael did a trendline assessment of staffing, schedule, effort, and defects. The data showed the agile project team size is fairly typical, bug rates are significantly lower (they start out higher but fall way down as team matures), and as a whole achieve faster speed. Productivity index (size/(time*effort)) improves the longer you’ve been doing agile, so the sooner you start the better.
Finally Michael interviews Walter Bodwell and describes the BMC secret sauce for success:
1. Buy in: need VP or higher senior executive sponsor, scrum master training, and core team energized and passionate
2. Staying releasable: have nightly builds/tests, 2 week iteration demos, frequent, rigorous code reviews
3. Dusk to dawn team work: Communication techniques for information flow, Wikis, video conferencing, periodic onsite meetings, collocated release planning, scrum of scrum meetings
4. Backlogs: One master backlog and multiple backlog management, one setup for user stories across teams, requirements architect to interface product management and R&D
5. Holding back the waterfall: Use Test Driven Development, retrospective meetings to not regress into old waterfall habits, outside source to audit the process
This presentation is available on InfoQ at http://www.infoq.com/presentations/5-Success-Factors-Michael-Mah
Michael then shares metrics (size, time, effort, defects, and productivity) collected from agile projects against industry averages. The data was mainly from BMC and Follet and looked at cost, schedule, defects, and staffing showing better results for the mature agile teams. Then Michael did a trendline assessment of staffing, schedule, effort, and defects. The data showed the agile project team size is fairly typical, bug rates are significantly lower (they start out higher but fall way down as team matures), and as a whole achieve faster speed. Productivity index (size/(time*effort)) improves the longer you’ve been doing agile, so the sooner you start the better.
Finally Michael interviews Walter Bodwell and describes the BMC secret sauce for success:
1. Buy in: need VP or higher senior executive sponsor, scrum master training, and core team energized and passionate
2. Staying releasable: have nightly builds/tests, 2 week iteration demos, frequent, rigorous code reviews
3. Dusk to dawn team work: Communication techniques for information flow, Wikis, video conferencing, periodic onsite meetings, collocated release planning, scrum of scrum meetings
4. Backlogs: One master backlog and multiple backlog management, one setup for user stories across teams, requirements architect to interface product management and R&D
5. Holding back the waterfall: Use Test Driven Development, retrospective meetings to not regress into old waterfall habits, outside source to audit the process
This presentation is available on InfoQ at http://www.infoq.com/presentations/5-Success-Factors-Michael-Mah
Thursday, October 9, 2008
Forging a New Alliance
At ThoughtWorks quarterly conference, Scott Shaw and Martin Fowler discussed the communication gap that exists between IT and the business side. Originally, IT department was created to centralize desktop administration and to gather MIS data. IT managed billing systems, accounting system or data processing on a centralized computer system. Things changed with the introduction of the PC. A broader range of business functionality came under IT functionality. Martin predicts that custom application provision will see IT department effectively disappear. Commodity standard stuff will move to the cloud and get hosted in a data center while custom software will move closer to the business side and the way to thrive in the IT world is to move closer to the business people.
Next they discuss some disturbing trends in IT that result in this communication divide between business and IT.
1. Slow to market: They note statistics that show about 34% of IT projects are successful. Here success is defined as on time and on budget. Martin notes that success should really be measured as providing value. They also show an input value stream that shows a typical example in which out of 90 days, 18 days are spent adding value and 70 days are spent in waste (waiting for handoffs). To have a successful rapid feedback loop, you need to have minimal latency.
2. Bloatware: This investment in large software platform that is intended to make it more responsive to the business. They give examples showing the same platforms growing to 200x their original size over the past 15 years, yet they mostly still provide the same business value.
3. War for talent: People fleeing the industry. The job is really boring. We took thinking and the design part away from people writing the code. There is no sense of ownership or context around what they are doing.
Next they cover some encouraging trends:
Collaborative team: Face to face communication, joint ownership of outcome, multi skilled people where developers can code and learn business domain (Make jog more interesting because of variety of task), and continuous improvements (plan, do, check). This results in better responsiveness, richer communication, higher quality, and improved staff retention.
Rise of craftsmanship: Master apprentice relationship. Attention to tools and quality and simplicity. Polyglot programmers. Software is all about design. Design is important because of its role in the long term of things. We should not see software as a cycle of building something and then it is delivered and we do not see it again. There should not be a disconnect between building and supporting something. Looking at long term brings out importance of design. It is important to have a code base that can absorb changes and gives the right degree of long term horizon to think of investments.
Perpetual beta: get software out there for people to try, fund things incrementally. Get away from project mentality and move towards product support mentality.
User experience design: 65% of features are rarely or never used Standish group. Bring user experience design into the iterative cycle of user needs analysis, collaborative design with users, design refinements, and test with users.
Domain Driven Design: enhance communication of internals of software. Use same language between business people and developers.
Domain Specific languages: makes the code readable to the business side making it easier for them to understand the code and improves communication.
They also gave several examples of case studies where these trends have helped out. They conclude that today business and IT are separate. In 2020 business and IT will come much closer to together. How are we going to survive the post IT world? What techniques and approaches are we going to use?
This presentation is available on InfoQ at http://www.infoq.com/presentations/New-Alliance-Shaw-Fowler
Next they discuss some disturbing trends in IT that result in this communication divide between business and IT.
1. Slow to market: They note statistics that show about 34% of IT projects are successful. Here success is defined as on time and on budget. Martin notes that success should really be measured as providing value. They also show an input value stream that shows a typical example in which out of 90 days, 18 days are spent adding value and 70 days are spent in waste (waiting for handoffs). To have a successful rapid feedback loop, you need to have minimal latency.
2. Bloatware: This investment in large software platform that is intended to make it more responsive to the business. They give examples showing the same platforms growing to 200x their original size over the past 15 years, yet they mostly still provide the same business value.
3. War for talent: People fleeing the industry. The job is really boring. We took thinking and the design part away from people writing the code. There is no sense of ownership or context around what they are doing.
Next they cover some encouraging trends:
Collaborative team: Face to face communication, joint ownership of outcome, multi skilled people where developers can code and learn business domain (Make jog more interesting because of variety of task), and continuous improvements (plan, do, check). This results in better responsiveness, richer communication, higher quality, and improved staff retention.
Rise of craftsmanship: Master apprentice relationship. Attention to tools and quality and simplicity. Polyglot programmers. Software is all about design. Design is important because of its role in the long term of things. We should not see software as a cycle of building something and then it is delivered and we do not see it again. There should not be a disconnect between building and supporting something. Looking at long term brings out importance of design. It is important to have a code base that can absorb changes and gives the right degree of long term horizon to think of investments.
Perpetual beta: get software out there for people to try, fund things incrementally. Get away from project mentality and move towards product support mentality.
User experience design: 65% of features are rarely or never used Standish group. Bring user experience design into the iterative cycle of user needs analysis, collaborative design with users, design refinements, and test with users.
Domain Driven Design: enhance communication of internals of software. Use same language between business people and developers.
Domain Specific languages: makes the code readable to the business side making it easier for them to understand the code and improves communication.
They also gave several examples of case studies where these trends have helped out. They conclude that today business and IT are separate. In 2020 business and IT will come much closer to together. How are we going to survive the post IT world? What techniques and approaches are we going to use?
This presentation is available on InfoQ at http://www.infoq.com/presentations/New-Alliance-Shaw-Fowler
Tuesday, September 30, 2008
Fostering Software Craftsmanship in a Corporate Setting
Scott Dillman gave a talk at Agile 2008 about fostering software craftsmanship in a corporate setting. Scott defined software craftsmanship as taking responsibility, continuous learning, rejecting specialization, pride in quality work, passing on knowledge, and meeting professional standards (test driven development, continuous integration, coding patterns and practices).
Next Scott described 3 steps to evolve a novice software developer into a craftsman.
1. Evaluate the current state of the organization through interviews, surveys and metrics. Surveys can be reused at a later date to evaluate progress. Collecting metrics from automated builds like % passing builds, builds/day, build duration, fail build reasons, code coverage, code complexity. Track historical trends.
2. Educate via pair programming, centralized resources (wiki, educational content, knowledge base, moderated technical forum, book reports, tools and code repository), educational sessions(teasers, lightning sessions, tech talks, workshops), craftsmanship day, 10% time and on team mentoring. To get upper management buy in, highlight benefits, cite case studies, link to corporate goals. Upper management has to allocate time and recognize and reward participation.
3. Measure success by interviews, surveys, metrics, and performance reviews. Make sure reviews have goals that motivate and educate, are relevant, specific, actionable, and verifiable. Have the right people perform the reviews, do 360 reviews, and encourage and reward participation.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Craftsmanship-Scott-Dillman
Next Scott described 3 steps to evolve a novice software developer into a craftsman.
1. Evaluate the current state of the organization through interviews, surveys and metrics. Surveys can be reused at a later date to evaluate progress. Collecting metrics from automated builds like % passing builds, builds/day, build duration, fail build reasons, code coverage, code complexity. Track historical trends.
2. Educate via pair programming, centralized resources (wiki, educational content, knowledge base, moderated technical forum, book reports, tools and code repository), educational sessions(teasers, lightning sessions, tech talks, workshops), craftsmanship day, 10% time and on team mentoring. To get upper management buy in, highlight benefits, cite case studies, link to corporate goals. Upper management has to allocate time and recognize and reward participation.
3. Measure success by interviews, surveys, metrics, and performance reviews. Make sure reviews have goals that motivate and educate, are relevant, specific, actionable, and verifiable. Have the right people perform the reviews, do 360 reviews, and encourage and reward participation.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Craftsmanship-Scott-Dillman
Subscribe to:
Posts (Atom)