Agilists and Architects: Allies not Adversaries

Martin Fowler and Rebecca Parsons gave a talk at QCON about architects in an agile environment. Architects worry about their jobs and where they fit in agile. Architects try to achieve reuse, documentation, see what is happening and agile can help architects by providing:

1. Transparency and visibility into progress and therefore can react in a reasonable way.

2. Up to date specification of functionality through strong emphasis on testing.

3. Results in adaptable code. Reuse after the fact rather than planned. You at least know that it is useful once and then adopt it in other places.

To make it work in agile, we have to look at architects as the customer. As a customer, architect need to prioritize decisions and need to specify what they mean and remove ambiguity. Architects also need to participate as team members. Architects need to be able to code. This will give them more information to be able to make adequate decisions. It will increase trust between them and the developers.

This presentation is available on InfoQ at  http://www.infoq.com/presentations/agilists-and-architects

Lean Concepts for IT Professionals

At ThoughtWorks conference, Richard Durnall and Kraig Parkinson gave a talk about Lean Software development. They start out by giving a brief history on Lean and how it led to the Toyota Production System (TPS). They then describe Lean in detail and cover the 4 levels of concern as

1. Philosophy - long term thinking or challenge. How are we going to accomplish these goals given the constraints: Long term vision(looking at 5, 10, 20 years), adaptive planning as we learn more and are faced with new challenges, process based company with human focus.

2. Process - steps to take to get there: Pull systems (wait for order before starting), eliminate waste, value streams, Jidoka automation (providing humans with tools to support what they do), Heijunka (even out the work to make a balanced system), visual controls (see where the work is), stop the line (at Toyota the line stops about 27,000 times a day), build in quality.

Eliminate waste (overproduction, waiting, unnecessary transportation, over processing, excess inventory, unnecessary movement of our people, defects, unused employee creativity)

3. People and partners - Respect and work together towards the ultimate goal. Supplier and partner relations (share resources to make suppliers and partners better since they share the same ecosystem), encourage the right behaviors (point everyone in the same org in the same direction), training and personal growth.

4. Problem solving - in depth look at the real issues. Genchi Genbusu (go, see and do for yourself, get involved), 5 why’s (root cause analysis tool – ask why 5 times and at the 5th time you know the root cause), 5s (stabilize and standardize what we do as a platform for continuous improvements going forward), ishikawa (fishbone diagram for root cause analysis tool), A3 reports (get all information you can on one side of A3 paper – annual financial statement – intent that less is more), PDCA (plan, do check, act cycle).

Wrapping all this together is a sense of continuous improvement (Kaizen).

Next, they look at Lean in IT:

1. IT has a problem - mediocrity: over budget, over schedule, not delivering useful features, projects failing.

2. IT is a business process and we can use Lean techniques to improve them like value stream map to measure cycle time efficiency. The process involves walking through the process and tracking 3 metrics: value added time (amount of time to do something of value that the customer will appreciate), elapsed time (from start to finish including waiting time), and cumulative elapsed time (over all time from request until delivery). This shows IT waste like extra features, waiting, unnecessary transportation, gold plating, partially completed work, unnecessary movement, defects, and unused employee creativity. One can apply Lean practices like pull practice, eliminate waste, and adaptive planning to improve the cycle. We do not need to fix everything. We need to work on our immediate constraint and once that is fixed we can move on to the next one.

3. Further engage business and deliver better results: IT works across business units and can see the process from end to end. Focus on customer. Realign key management metrics to be more of a throughput focused vs. status focused - what is the profitability, how smooth is the process.

4. Look at other lean organizations and learn from them. Start with the customer, focus on quality not cost (and cost will drop as quality improves), find the change agents and empower them, don’t get trapped in the tool age (concentrate on philosophy, beliefs and values), and remember that anyone can introduce change.

This presentation is available on InfoQ at http://www.infoq.com/presentations/durnall-parkinson-thoughtworks-lean-it

Just You Wait

Kent Beck gave a talk at QCON about current trends and where they are going. He covers these trends in the following themes:

1. Communication: Information sharing (twitter), information collecting (logs, recordings), more frequent releases

2. Simplification: flat data(Amazon simple db, Google large table), Data parallel(Hadoop, Map reduce), Screen-less computing

3. Unintended consequences: Energy usage (small devices, sustainability), privacy (privacy is going away)

4. Disappearing: “Free” or differed revenue model (ads are out, need to pay for things we find valuable), reuse, status

5. New Approaches: design (good design valuable to enable frequent releases), tests (automated, need to catch mistakes early)

Kent wraps up by asking what have I accomplished in the past years and what will I accomplish in the years to come?

This presentation is available on InfoQ at http://www.infoq.com/presentations/just-you-wait

Crafting an Agile Adoption Strategy

Amr Elssamadisy gave a talk at QCON 2008 about agile adoption strategies. He started out by defining what is valuable? Is it being agile, design, requirements, time to market, user satisfaction, meetings? Value is different based on the context. It is what you want to get out of it. It should be your goal for adopting an agile practice. This is how you will measure your success.

Next Amr talk about a learning cycle of 1) goal, 2) process, 3) test, stop, and learn, apply lessons learned, and repeat until success. He then simplifies agile software development to recognizing and responding to change (learning, requirements, team structure, new practices), feedback practices and communication practices for the team (iterations stand up meetings, retrospective), and technical practices for developers (TDD, refactoring, pair programming).

Next Amr gives examples of some business values: reduce time to market, increase quality, increase flexibility, increase product utility, increase visibility, reduce cost, increase product lifetime. This is followed with some examples of some smells: Us vs. Them, Customer asks for everything, direct input from customer unrealistic, management is surprised, bottlenecked resources, churning projects, hundreds of bugs, hardening phase needed.

Each of these problems is addressed by different set of practices or patterns. A pattern is a problem solution pair within a context.

Amr then goes through some patterns:

1. Decrease time to market: We need to apply Iterations. For that we need a product backlog and a well defined definition of done. The backlogs improve product utility and increase visibility by enabling high quality feedback as the goals are met and reviewed regularly. They decrease time to market because the prioritized list enables negotiation of scope and early release with the most valuable functionality.

• a. Backlog context: You are on a team that decides to adopt agile including iterations. You decide to go away from big upfront design. Team has needed expertise to expand and evolve requirements
• b. Backlog adoption: Customer flushes out coarse grained requirements ahead of the iteration planning meeting. At the beginning of each iteration, team should have enough info to roughly estimate and begin development. Items chosen for development make up the iteration backlog.
• c. Backlog smells: Estimation paralysis, techies take over, multiple non cross functional teams have trouble working from one backlog

2. Increase quality: implement test driven development which needs refactoring which in turn needs collective code ownership and automated developer tests (Test first development or test last development). Refactoring increases flexibility and the product lifetime by enabling and encouraging developers to change the design of the system as needed. Quality to market and costs are reduced because continuous refactoring keeps the design from degrading over time, ensuring that the code is easy to understand, maintain, and change.

• a. Refactoring context: Development team is practicing automated developer tests. Requirement is not well supported by the current design or you want to make the design cleaner.
• b. Refactoring adoption: Just do it keeping in mind that it is a practice not a tool. Start automated developer tests until you are comfortable writing tests for all of the code. Adopt team code ownership. Agree on how to handle broken tests that result from refactoring. Read Martin Fowler book on refactoring and a book on TDD that is exercise driven.
• c. Refactoring smells: don’t get carried away and refactor just for the sake of refactoring. It does not deliver direct business value. Many missed small refactoring build up over time causing the need for a large refactoring. Beware of code ownership issues and pride that might lead to “commit wars”.

This presentation is available on InfoQ at  http://www.infoq.com/presentations/adopting-agile-practices

Responsive Design

Kent Beck gave a talk at QCON 2008 about Responsive Design. Kent starts out by defining design as beneficially relating elements. Design has elements. The elements have relationships, and the relationships can be beneficial or not. He states that there should be an ongoing investment in design. Design should happen at the right moment to enable a steady flow of features.

Kent moves on to briefly cover some design values, patterns, principles strategies, refactorings, successions and data that help achieve the goal of steady flow of features.

1. Values: simplicity, feedback, community

2. Patterns: most decision are not based on the domain, but are based on dealing with a computer. Having access to a wide library of patterns makes me more effective (vocabulary, efficiency). Do not waste time on originality for problems that do not require it.

3. Principles: There are universal principles like don’t repeat yourself, and then there more specific ones.

4. Strategies: Move your design in safe steps.

• a. Leap: break it up into tiny steps so you can make a leap in safe steps.
• b. Parallel: Operate 2 designs in parallel for a while.
• c. Stepping Stone: If cannot do something in a safe step, build a little component or service to help make progress towards a safe step.
• d. Simplification: Solve a simplified version 1st without any constraints, then slowly add constraints and continue to solve problem

5. Refactoring:

• a. Bidirectional: extract method and inline method, extract component and inline methods. All refactorings are bi-directional.
• b. Fluid: It is not from here to here, but more a sequence of steps.
• c. First class: Refactoring are 1st class.

6. Succession: important sequences of design that happen over and over again. Like if you know that you need to deal with n elements, deal with one element now and then transform it to deal with n elements when you need to.

7. Data: understand metrics patterns to justify advice.

Kent concludes by reminding us that the goal is to find a way to continually invest in design to more closely approximate this steady flow of features to create value.

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