Typical Pitfalls in Agile Development

Jutta Eckstein gave a talk at JAVAPOLIS 06 where she covered 8 typical pitfalls in agile development:

1. Practices over values. Do not insist on specific practices over values. Use practices that support the team and the team’s value system. Figure out what the goal of the practice is, is this our goal? Does the goal support our value system? How can we achieve this?
2. Iterate then measure. You need to learn from the iteration. Get feedback, improve and adapt
3. Missing result-orientation. Slice features so that they can be completed in an iteration and they can provide business value.
4. Release plan. At end every iteration, check and update release plan
5. Interruptions are norm. Keep iterations length the right size to be able to handle interruptions.
6. Importance of integration is often ignored. Ensure integration has always the highest priority and has dedicated staff.
7. Wasted times. Keep stand up meeting on short and on track. Avoid endless meetings, status meetings, etc.
8. Missing courage. Unable to deal with dependencies of time, scope, quality, resource. Clarify dependencies and show options. Learn to say no.

How To Design A Good API And Why It Matters

At Javapolis, Joshua Bloch gave a presentation about designing a good API. Joshua starts by defining why designing a good API matters. An API is as asset. A public API if forever. You have once chance to get it right. If it is well written, it will capture and hook customers, while a badly written one will result in an endless barrage of support calls. Good software is modular and each module should have a well defined API. A good API is one that satisfies the requirements of the appropriate audience. It is easy to learn and use while hard to misuse. The code is readable, maintainable, and extendable.

Next Joshua explains the process of API design. Gather requirements in terms of use cases. Start with a short 1 page spec. Bounce it around as many people as possible and flesh it out as you gain confidence. Then write to your API early and often, even before it’s implemented or fully specified. The code will act as examples to use in unit tests. If writing an SPI (plug-in for multiple interfaces), make sure you try on 3 different implementations. You can’t please everyone so instead aim to displease everyone equally. Expect to make mistakes and flush those out after a few years of real use.

Then Joshua covers some general principles:

· API should do one thing and do it well. Functionality should be easy to name.

· API should be as small as possible. When in doubt, leave it out, as it is easy to add it later, but you can never remove it. Look for a good power to weight ratio.

· Implementation details should not impact API

· Minimize accessibility of everything. Make classes and members as private as possible. Allow classes to be used, understood, built, tested, and debugged independently.

· Names matter. Avoid cryptic abbreviations. Be consistent. Strive for symmetry.

· Documentation matters. Document religiously. Document every class, interface, method,

constructor, parameter, and exception.

· Consider Performance consequences of API decision on performance. Bad decisions include making types mutable, using constructors instead of factories, and using implementation instead of interface



· API must coexist peacefully with platform. Obey naming conventions, avoid obsolete types, mimic patterns and take advantage of core API and language features while avoiding language pitfalls.

Next Joshua covers class design and emphasizes minimizing mutability, subclassing only when it makes sense (Liskov), and designing and document for inheritance, otherwise prohibiting it.

For method design:

· Don’t make the client do anything the module could do

· Don’t violate the principle of least astonishment

· Fail Fast- report errors as soon as possible after they occur.

· Provide programmatic access to all data available string form

· Overload with care: just because you can does not mean you should.

· Use consistent parameter ordering across methods.

· Avoid long parameter lists

· Avoid return values that demand exceptional processing: return zero length array or empty collection instead of null

Finally for exception design, throw exceptions to indicate exceptional conditions and don’t force clients to use exceptions for control flow, favor unchecked exceptions and include failure capture information in exceptions

This presentation is available on InfoQ at http://www.infoq.com/presentations/effective-api-design

Agile Quality: A Canary in a Coal Mine

At Agile 2006, Ken Schwaber gave a talk about Agile Quality. Ken starts by describing the way product owners and teams should work. He mentions some statistics showing that on average, 35% of requirements change and 65% of what is delivered is rarely or never used. So product owners have to be skilled in requirements management and make sure the product backlog focuses on the highest value, importance, and risk stories 1st.
Traditionally customers have no visibility into what’s happening until the project is almost done.
In iterative developments, customers have visibility into the project and can control risk
Every sprint, some cumulative business value is delivered. At some point, enough ROI is achieved that the customer can get rid of functionality of lowered earned value.

Ken moves on to describe the place that product owners and teams come from using waterfall and discusses some of the bad techniques for delivering on time and on cost:
1.    Reduce quality
2.    Change definition of done to somewhat done and add stabilization, user acceptance, alpha and pre-release phases

Next Ken describes how scrum falls apart if these habits persist and how organizations have fallen apart because of these habits.

He starts by listing some of quality reduction techniques:
1.    Overtime (studies shows that increasing a working day increases defects)
2.    Cut unit testing, acceptance, and performance testing
3.    Skip design and code reviews
4.    Don’t follow standards
5.    Don’t refactor

These techniques lead to a scrum only including analysis, design, coding and some testing. Every sprint something is left behind and not done. Instead it should be optimized so that in every sprint everything is done. Ask the team to define done for every sprint and daily scrum. And done should include everything.

Ken mentions that a major problem most organization face is how to add new functionality tied to legacy system or to synchronize new functionality to core functionality. The main problem is that the core functionality has no test harness, is very fragile (a simple change breaks something else), and usually only few people still know and are willing to work on it. Thus, the velocity of core functionality team is a lot less than velocity of new functionality team.

Investigating this problem further reveals that as teams bend to pressure to meet dates, they drop quality and deliver incremental crap, and within 4 or 5 years, the team’s velocity is down all the way to 1 because the software is in such bad shape.

Ken emphasizes that we should have the courage to do the right thing and not drop quality. Dropping quality to meet a date is not a customer or product owner decision. It’s a CFO decision because of the impact on the company. Software is an organizational asset and decision to cut quality must be made by executive management and reflected in financial statements.

To get out of this mess, companies end up rebuilding core functionality into each function, building new stuff and not worrying about core functionality, dropping functionality, or allocating more developers to the core team in an attempt to build up and increase the velocity of core functionality.

To undo these habits, Ken suggests that the ScrumMaster teaches the product owner how to manage by value and that he not allow the team to present anything that is not done. The CEO should be apprised of the root cause of the problem and should provide support.

Ken finishes by giving an example of SCRUM being used at Primavera and concludes that one should have the courage to do the right thing and that it is a professional responsibility that makes you feel better and is for the good of the company.
This presentation is available on InfoQ at http://www.infoq.com/presentations/agile-quality-canary-coalmine

Roots of SCRUM - How Japanese Manufacturing Changed Global Software Development Practices

Jeff Sutherland gave a talk on the Roots of SCRUM at JAOO 05. Jeff starts by describing the influences in his background that led to the creation of SCRUM. Next Jeff refers to Takeuchi and Nonaka’s paper and their definition of 3 project management styles. Type A (NASA), the traditional waterfall model of isolated cycles of work like requirements gathering, analysis, design, implementation, and testing. Type B (Fuji-Xerox), where work is overlapping. Processes are collapsed and handoffs eliminated. Type C (Honda), an all at once process.

Then Jeff discusses Toyota’s mission in North America and how it relates to SCRUM. The mission statement focuses on the growth of community, the stability and well being of members, and on adding value to the customers.

Toyota production is based on a different way of thinking. Through knowledge creation by synthesis of contradiction, Toyota pushed the envelope to produce high quality, high variety, and low cost all at once.
Toyota uses ba, the zen of SCRUM and Japanese manufacturing. Ba involves getting the right people at the right time and in the right place so the magic happens. Team members create new points of views and resolve contradictions through dialogue. The people get together and have dynamic interactions that create a synthesis. This environment creates emerging ideas.

The Toyota Way is Learn by Doing. It includes placing the highest value on actual implementation and taking action. If one doesn’t understand then just go ahead and take action.
You realize how little you know and you face your own failures and redo it again and at the second trial you realize another mistake … so you can redo it once again.
So by constant improvement … one can rise to the higher level of practice and knowledge.

The Toyota way allows for redundancy and failures. Failure happens early and allows for rapid learning and faster evolution. Rational and efficient approaches to emergent solutions will cause train wrecks.
Jeff describes how Scrum cuts through cost, time, and functionality barriers. SRUM is adaptive, iterative, incremental, customer driven, and delivers frequent business functionality. It is extremely simple but very hard.

Next Jeff shares some statistics that show that scrum is faster (improves productivity), better (improves quality), and produces more for less.

Adopting agile involves cultural change, and breaking down command and control. Teams need to be autonomous, transcending, cross-fertilizing. Teams need to feel totally responsible and management needs to get out of the way. Every member of the team is focused on making the team successful instead of his own self interest. The more experienced members are always available to help the less experienced. Jeff gives the Google strategy example of getting management out of the way by eliminating management jobs and just having teams of engineers with rotating team leads.

In agile, managers need to become leaders and find and utilize spontaneously created ba or help generate more of it by helping the team by providing the right space, equipment, and goals. They need to fostering love, care, trust, and commitment. Similarly scrum is based on truth, transparency and commitment. Question everything you do and if there is no value in it then do not do it.

Jeff explains that we’ve been applying the wrong process to software development. Software development is empirical process as opposed to a predictable will defined process. We need to understand how to work and monitor an empirical process by continuously measuring, monitoring and adapting the process. It will not run the same every time.

Next Jeff describes the key roles and responsibilities of the ScrumMaster, Product Owner and team. The Product Owner defines and prioritizes product features, decides on release dates and content, and accepts or rejects work. The team is self organizing and cross functional and selects the iteration goal and specifies work results. The ScrumMaster ensures the team is fully functional and productive, enables close cooperation and removes barriers.

In the 1st SCRUM implemented by Jeff, GANNT charts and job titles were abandoned. XP engineering practices were used. There was a ScrumMaster and a product owner, daily meetings, sprint planning, review, demo and retrospective.
Some of the challenges to adopting agile include organizational resistance, manager apathy, inadequate training, lack of peer support, and lack of formal guidelines.
This presentation is available at InfoQ at http://www.infoq.com/presentations/The-Roots-of-Scrum

Agile Project Management Planning and Budgeting

David Hussman gave a talk at NFJS about agile Project Management Planning and Budgeting. He started it out by discussing the various agile paths (XP, SCRUM, Crystal, and Feature Driven Development) as well as the traits of agile. These include the ability to adapt to changing business requirements, allowing the business to select features, quality testing throughout, iterative development and deployment, and emphasis on continuous user feedback.

Then David discusses the current planning techniques which include creating a project plan with specific dates and tasks. This plan is a legal requirements document and changes have to come in the form of change requests. Estimates are done early and not updated. The developers are not the ones providing the estimates, and there is rarely enough time for testing. There are no feedback loops and metric to track the plan.



Next, David described the agile release cycle which consist of project, releases and iterations. Project duration is 6 to 12 months and starts out with chartering, roadmap, personas and a product back log. A retrospective is performed at the end of the project.
Releases are 4 to 8 weeks and include release planning and retrospectives. Iterations are 1 to 2 weeks and consist of plan, build and reflect loops.

Product/Project planning determines value. It involves chartering the project by defining the goals of the project, the value to the company, and the success measures. It also involves mapping the project community to define team roles, responsibilities and commitments to the project. Finally, a product backlog is setup.

Release planning involves business prioritization, estimating course grained stories and discussing risk and architectural decisions.

Iteration planning involves the design, develop, build loop. Work is continuously integrated. Information is shared daily and questions are clarified by the customer. Stories are signed off and progress is posted.

Finally, retrospective is performed at the end of each cycle whether at the iteration, release or project level. It is used to celebrate success and vent frustration and to determine what worked, what did not work, and what to add/change/or stop.

David spends some time going over a planning exercise with the audience for the design a POS retail system. Finally metrics collections are discussed. This presentation is available on InfoQ at http://www.infoq.com/presentations/Agile-planning-and-budgetting