So You Think You Can Scrum?

Are you really doing Scrum? Or is it more Scrum-like, Scrum-but or semi-Scrum. To find out, try to pass the Nokia test that was developed by Bas Vodde:

1. Iteration must be time boxed to less than 4 weeks.
2. Software features must be tested and working at end of each iteration.
3. Iteration must start before specification is complete.
4. You know who the product owner is.
5. Product backlog is prioritized by business value.
6. Product backlog has estimates done by team.
7. Team knows their velocity.
8. There are no managers disrupting the work.
9. Team commits collectively to Spring goals and fights impediments.

Jeff Sutherland later modified this test and added a scoring system as explained here.

Beyond The Manifesto

It all started out with the Agile Manifesto of valuing:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

Then there are the 12 principles of the Agile Manifesto covering continuous and frequent delivery at a constant pace, embracing change, team work, self organization, trust, craftsmanship, and retrospection:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
•  Business people and developers must work together daily throughout the project.
•  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
•  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This was followed by the Declaration of Interdependence:

The Art of Storytelling

 In User Stories Applied: For Agile Software Development, Mike Cohn defines user stories as simple, clear and short descriptions of customer valued functionality. They are composed of three aspects:

1. A brief description of the story used for planning.

2. Conversations of the story that serve to flesh out the details.

3. Acceptance tests to determine when a story is complete.


User stories offer a number of advantages over requirements documents and use cases. These include:

1. Emphasis on verbal rather than written communication.

2. Encourage deferring details until you have a better understanding about what you really need.

3. Provide the right size for planning.

4. Are comprehensible by customers and developers.

5. Work for iterative development.


Good user stories should follow the INVEST principle:

1. Independent: Stories should not be interdependent as this might lead to prioritization and planning problems.

2. Negotiable: A story should be brief and it is not a detailed contract. It should encourage conversation and negotiation between the customer and the developers.

3. Valuable: A story should provide value to the customer or the user.

4. Estimatable: Developers need to be able to estimate a story. It should be written in such a way that the developers can understand it and have an idea of how to implement it.

5. Small: Not too big, not too small, but just right!

6. Testable: Stories should be testable in order to verify that a story is complete.


Additionally, good user stories follow these guidelines:

1. Start with Goal Stories: For each user role, identify the top priority goal for that user.

2. Use Templates:

• a. Use the following template to incorporate User Role and Value into a story: - As a [type of user], I can [goal] so that [reason].

• b. Use this template for acceptance tests: Given [context] And [some context] When [event] Then [outcome] And [another outcome].

3. Slice Vertically: Stories should represent some level of end to end functionality. This reduces overall risk and delivers some value to the customer.

4. Annotate Stories with any constraints.

5. Keep the UI Out for as long as possible: This avoids mixing requirements with a specific solution.

It is important to remember that the main purpose of a story is to act as a reminder and encourage conversation to flush out details the closer we are to implementing a story. Also, not everything needs to be a story. Some aspects of the system might be expressed better using different formats.

From Concept to Product Backlog

At Agile 2009, Gerard Meszaros gave a talk on the steps needed to get to iteration 0. Iteration 0 is an iteration dedicated to setting up the development environment before the 1st real iteration is started. It usually includes installing development tools on workstations and team tools on servers, and priming the user story backlog so that it is ready for the iteration 1 planning meeting. A secondary objective includes calibrating the development team’s velocity and learning any new technologies that will be used.

Gerard shares some examples of poor upfront planning. These include situations where customer was learning on the job and they did not have the productivity to get things going and as a result they could never catch up on the story tests. Another was when fit tests kept breaking due to new logic being introduced and another was when user interface contained many inconsistencies.

Gerard attributes these problems due to lack of upfront planning leading to sub-optimal results. The big picture was missing. In agile planning these is constant tension between BDUF (Big Design Upfront) vs. LRM (Last Responsible Moment). We need to find the right balance between up front planning and decision deferral, and the right balance between high ceremony just because and just enough, just in time. Some ways to achieve this is by prototyping or staged style funding.

Agilists in general are familiar with the five levels of agile planning: Product vision, product roadmap, release plan, iteration plan, and daily plan. However, there is planning that needs to be done before we even get to this stage. Concepts need to be broken into ideas and then into core features. There needs to be an elevator statement and a description of the behavior of the product as well as a high level architecture, cost estimates, and eventually user stories. Gerard describes this as:

· Product Envisioning: concept, major features, and product design

· Product planning: risks, benefits, test strategy, release plan, effort estimate, cost estimate, skills list, budget.

· Project Execution: User Stories, story tests, business staffing, tech staffing, iteration plan, story tests.

Product Envisioning

The goal of product envisioning is to get a collective understanding of the product. We need to get everyone working towards a common purpose. Get everyone’s input and buy-in of the product and help everyone understand the big picture. This is done by workshops for envisioning the product to be built using brainstorming, listing functionality, users, and value. Outputs include the elevator statement, product box, major and differentiating features list, and low fidelity user interface prototype.

Strategies for Effectively Managing Legacy Systems

At ThoughtWorks Quarterly Review, Amir Uttman and Derek Longmuir discuss strategies for effectively managing legacy systems.

Legacy system have the following characteristics: Expensive to maintain, unchangeable, old-fashioned, unreliable, complicated, old, COBOL, mainframe, single point of failure, untested, undocumented, obsolete (no vendor support). However, legacy systems work, are business critical, are the system of record, and are familiar to the employees. Most importantly, legacy systems currently provide business value.

Next Amit and Derek define a legacy system as a system in which the quality has degraded to such an extent that it needs to be replaced. A legacy platform is a software or hardware system that is no longer supported. Thus, with time, the risk of using a legacy system gradually increases.

Amit and Derek then cover some options for replacing legacy systems. These include the build vs. buy option, the hiding the complexity option (usually does not work – nice front with spaghetti code behind), or the big bang replacement option(usually fail due to trying to create a prefect replacement). They give real word examples like Hershey’s ERP system, FBI Virtual Case Files, and Windows Vista.

It is important to remember that the real cost of systems is 10% to build and 90% for maintenance.

Amit and Derek next discuss effective legacy system replacement strategies and techniques:

1. Technology asset portfolio: Figure out where you are right now, what is the current state of the technology system(platform and software), what skills you have to maintain that system (operational, technical, and business skills). Based on that, you can figure out what kind of risks you face. How long is the system going to be around? How old is it? Who are the vendors that can support it?

2. Governance: Continually review your assets

3. Systems Health Check: Use several tools to visualize code complexity and ensure you have the basics of Source Control Management and Automation.


Some problems of migrating legacy systems:

1. Tendency exists to take existing logic and recode it as is on the new platform. No thought is put into new features. Sometimes, same bugs are ported over.

2. Code that no one knows what it does.

3. No benefit in investment until way later in the project.

4 Challenges and 5 Guiding values of Agile Software Development

At Agile 2009, Brian Marick shared challenges and guiding values in agile software development. Brian1st covered 4 challenges that we face when starting with agile development:

1. Courage: ScrumMaster should have the courage to create an open workspace even if it is against company policy. There job is to move immovable objects for the good of the team. ScrumMaster, business analyst, programmers (learn new languages), testers (learn automation) all need courage.

2. Working software: Open workspace appears to the outsider as noisy, messy, undisciplined, uncontrolled, and unprofessional. They will have the urge to restore order. As ScrumMaster, you have to resist that and the best way is to deliver frequently working software that is better than what was delivered last week.

3. Naiveté: Pair programming, test driven design work. Do not prejudge before trying it out. Have an eagerness to believe in the ability of the absurd. Much of agile is deeply counter intuitive.

4. Slicewise Design: Always taught to 1st build infrastructure and then drop features on top of it. Problem is that infrastructure comes too late. By that time, client has become inpatient about not seeing working software. 2nd new feature come up that do not fit in the infrastructure. Instead build a feature and try to delight the client. If not delight then work on the little changes to satisfy the client and then move on to add another feature. As you go along, you will end up incrementally (refactoring) building the infrastructure with the features on top of it.

Next Brian covers 5 guiding values of agile software development:



1. Reactive: Agile teams value fast feedback, and visibility, but also value being reactive. We have always been taught to be proactive. When coding and later we discover a better way to doing things, we can back up and go in a better direction. However, using version control, we need to know when to take a snapshot to enable us to back up to the right spot. Another approach is to have smooth programming process where we can code forward towards a better path instead of backing. We need to become good at reacting to new knowledge that we did not proactively deal with. Each time we do that we improve our skills and increase our opportunity to learn.

2. Ease: Image hammering with a hammer that has a loose head. You will constantly be concentrating to make sure the head does not fall off instead of simple hammering away. Typical software has short cuts and workarounds. Agile teams clean up awkward code to make it easier for the next person. It is uncompensated near term work for a teammate’s medium or long term advantage.

3. Solidarity: We will all fail or succeed together. Foster solidarity with the platinum rule instead of the golden rule of do unto others as you would have them do unto you. The platinum rule says do unto others as they would have you do unto them.

4. Decency: React to irritation or difficulty by treating fellow with decency. Don’t be afraid to lose an argument. In agile it is not a threat to be wrong. You can always adjust back in the right direction.

5. Joy: “This is the greatest project I have ever worked on” is the reaction we should have when working on an agile project instead of “We suck less now”. You should have the courage to bend your work in a joyful direction.

Brian concludes that you should drive the environment instead of having the environment drive or limit you. You should seek to gradually add ease into your work and make it fun.

This presentation is available on InfoQ at http://www.infoq.com/presentations/4-challenges-5-values

Lean Product Discovery

Jeff Patton gave a talk at the UK Lean Conference 2009 on Lean Product Discovery. Jeff starts by sharing a story on how the most influence moment in his life came when he sat behind someone using software he created. He discovered that understanding what people wanted is critical to delivering value to them.

Jeff mentions that in software development we are balancing 2 concerns:

1. Delivery: building of a software product. Analysis, design, coding, testing, documenting… This side is visible.

2. Discovery: learning about the outside world and our product in it. Understanding the world, understanding the product, what problems it solves, what value it provides and how it fits in the word. Understanding customers, market, competition, users. Prototype and validate user experience, create UI, validate working software.

Discovery (problem customers have) and delivery (the solution) work hand-in hand and overlap as we deliver product increments.

Jeff notes that healthy delivery process build software incrementally. It requires a fully formed idea (up front discovery), accurate estimation and upfront product assumption. If we don’t continually ask if this is what we want to build we might end up off in terms of quality and final result.

We need to balance delivery with discovery. Traditionally we are out of balance. We do a lot of upfront discovery and then do only delivery. However, after delivery we learn more from users using the product and then we are back in balance between discovery and delivery, but this re-balance happens very late in the game. Jeff gives an example of drawing a painting, starting and completing one section and then moving on to another section and so on until we finish the last section.

Iterating and incrementing leverages discovery to iterate as we deliver. This allows us to move from vague idea to realization making course correction as we go along. Jeff gives an example of again drawing a painting, however this time we start with a rough sketch of the entire picture, then we fill in more details, and then we add some colors, etc...

Next Jeff discusses how to break things down in a way that lets us balance discovery with delivery. He recommends breaking down large features using these four splitting heuristics: