Pragmatic Personas: Putting the User Back in User Stories

At Agile 2009, Jeff Patton gave a workshop about how to design and build software that has a better user experience. Jeff starts out by reviewing the different ways that software is built.

• FUBU: For Us By Us. Start with idea to build something for us. Product is built to solve a certain problem we face. Then audience diversifies and product evolves and no longer becomes for us
• FMBY: For Me By You. We take down requirements and hope that everything comes out OK.
• MSU: Making things up design.
• FTBU: For Them By Us.

Jeff explains that if a product is good, it is built for the people that will use it and that is not us.For them by us is user centered design. To build a good product we need to care about the user. Another way is to keep asking users what they want.

Jeff defines a pragmatic persona as a quick exploration of what we know about our users. We want to build them to start discussions about what we know and don’t and help drive mapping your user experience using stories.

Next Jeff goes over the process of creating a persona by walking through an example of a restaurant review application:

1. Identify kinds of users (user types or roles)

Determine the criteria that makes each type distinct. Identify high priority or focal types.
Think of different kinds of people that will use your product as user types (college students, business professional).
A user role describes the relationship a person has with your product. We change roles like changing hats. Think thing-doer (late night pizza buyer, daytime lunch seeker, penny pinching pizza buyer, married daytime lunch seeker). Isolate aspects that are relevant.
Next prioritize. The user types that are the most relevant to design depends on the business and product goals. Figure out which user types are most critical to achieve the goals and objectives. Refer to these user types as focal or primary. A typical system will have 2 or 3 focal users and several more that aren’t (make sure these are listed as well).

2. Profile Users (start with assumptions about users and then add additional info by doing research). Identify information about users relevant to the product. Profiling adds general information to user types like sizing, gender, domain knowledge, pains, goals, motivation, general activities, context, frequency, collaborators, and other products they rely on.

Kanban Adoption at SEP

Chris Shinkle gave a talk about Kanban adoption at SEP during the Agile 2009 conference. Chris described the Dreyfus Model of Skill Acquisition and showed how the team at SEP progressed from one stage to the other as they learned and applied Kanban.
Stage 1 – Novice: Little or no previous experience. It is about following context free rules. No discretionary judgment. Want to accomplish a goal, not learn. Team had clear understanding of project, clear priority of work items, and clearly see progress from the introduction of Kandan boards and standup meetings.

Stage 2 – Advanced Beginner: Still rules based, but start understanding rules within context and based on past experience. Team understood WIP (work in progress) limits, began to collaborate and identify bottlenecks and areas for improvement.

Stage 3 – Competent: People recognize patterns and principles. Rule sets become more rules of thumb. They start to establish guidelines and seek out and solve problems. They see actions in terms of long term plans and goals. The team felt a sense of ownership. They started pulling in alternate practices to optimize the process and solve specific problems. They began to discover and understand lean principles themselves. Things like cause and effect of flow, value, quality, quality, and waste.

Stage 4 – Proficient: People seek out and want to understand the big picture. They perceive a complete system instead of a set of individual parts. They can learn from the experience of others and take full advantage of reflection and feedback and correct previous poor task performance. The team starts to focus on throughput and reducing cycle time. They began to focus on optimizing the whole and reducing the cost of delay and WIP limits. Kaizen moments became more common place.

Stage 5 – Expert: They can look at each situation immediately and intuitively take appropriate action. They know what to focus on and can distinguish between important details and irrelevant ones. Chris’s teams haven’t reached this stage yet.

Chris believes that it is ok to talk about principles but teaching principles does not equate to acquiring a new skill. Kanban provides a framework where principles can be introduced. Then the process in and of itself is going to help encourage those behaviors and allow people to understand them at their own pace.

Next Chris shares the lessons learned:

1. Start by teaching practices, not principles

2. Don’t set WIP limits too low for a new team

3. Keep rules about moving tokens/cards simple

4. WIP is strongly correlated to product quality.

Finally, Chris concludes by stating that Kanban teams mature in a way consistent with the Dryfus model. Kanban is an effective tool for teaching lean principles and managing change in an organization. There multiple levels of maturity and at each level certain behavior guide your focus.

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

The Tyranny of the Plan

Mary Poppendieck gave a talk on lean software development at the UK Lean Conference. Mary started out by describing the process of building the empire state building. The building was exactly on time and 18% under budget:

· 9/22/29 – demolition started

· 1/22/30 – excavation started

· 3/17/30 – construction started

· 11/13/30 – exterior completed

· 5/1/31 – building opened

Mary next explained how they managed to do that before there were computers, GANTT charts and PERT charts. The builder focused on workflow. They did not need to figure out the details and lay out a plan. There was no design when contract signed. They used deep experienced on a fixed priced contract. They focused on key constraint which wasn’t labor, steel or stone. It was material flow of needing the right stuff at the right time (500 trucks a day delivering materials, no storage on site). The building was designed to be decoupled. There were 4 pacemakers which were independently scheduled workflows. They avoided having cascading delays. They understood that it pays to invest money to save time (cash flow thinking). Every day of delay cost 10K (about 120K today). Schedule was not laid out based on the details of the building design. They created the schedule and created the design to fit the schedule. The building was designed based on the constraints of the situation (2 acres, zoning ordinances, 35M capital, laws of physics, and May 1, 1931 deadline). Traditionally we start by figuring out what you are going to do, break it down into pieces (WBS), sum up the total and there is your schedule. Instead here they started with the constraints and created a schedule that can fit within the constraints.

Mary summarized the lessons learned. Design the system to meet the constraints; do not derive constraints from the design (budget, time). Decouple workflows; break dependencies from architectural point of view and scheduling point of view instead of organizing them on a schedule (PERT chart). Workflows are easier to control and more predictable than a schedule. For control and predictability establish a reliable workflow instead of establishing a schedule that needs to be followed.

Next Mary explains that there are 2 reasons that we schedule. The 1st is to control when things will happen. However, detailed schedules are deterministic and do not allow for normal (common cause variation). Machines break down, weather, no way to deal with variations unless we add slack. Attempting to remove common cause variation from a system will cause it to oscillate wildly. Flow systems on the other hand build in slack whenever they need it. Managing a level workflow is a lot easier than following a deterministic schedule.

Scaling Software Agility: Best Practices For Large Enterprises

Dean Leffingwell gave a talk at Agile2009 about best practices for enterprises to scale agile.

He talks about his experience consulting for a company wanting to apply agile at a large scale. There they took the extreme agile approach by throwing away all current practices and starting out fresh with pair programming and slowly adding items as deemed necessary. They started out with minimal tooling and some coaching. They had a commitment to Agile from top to bottom. At the end, the results showed reduced cycle time from 18 months to 4-5 months, productivity increased by 40% and defect density remained the same (meaning new development had lower defect rate than older development, since more was getting done).

Implementing agile involves enhanced project management practices (SCRUM) and enhanced software development practices (XP) along with modified social behavior (face to face communication).
Agile Focuses on developing value to the customer. Agile empower teams to more rapidly deliver quality software explicitly driven by intimate and immediate feedback.

Dean moves on to compare the agile cycle to the waterfall cycle and explains how agile delivers value faster by giving the iphone example. When the 1st version of the iphone was released, it retailed for about $600 and ran on a slow network, did not include apps and there wasn’t even an app store. Later newer, enhanced versions came along at a lower price.

Dean moves on to describe 7 team practices that scale and 7 enterprise practices.

7 team practices that scale:

1. The define define/build/test team
2. Mastering the iteration
3. Two-levels of tracking and planning
4. Smaller, more frequent releases
5. Concurrent testing
6. Continuous Integration
7. Regular reflection and adaptation

1. Define/build/test team
Organizations have to move from function silos to cross functional teams of 5-9 members. Instead of having separate teams for product management, architecture, development, and QA, have many smaller teams each composed of developers, testers, product owner, tech lead, and scum master. In an enterprise of say 400, that makes about 57 teams. Each team is a self organizing team that can define, build and test something of interest/value. Teams will interface with architects as well as QA and Release management.