Posted on

April 25, 2012 MONTHLY MEETING: Karen Spencer on The Psychology of Agile

Do you ever wonder why some of those seemingly corny Scrum practices work so well?

Do you ever ponder why simple experiments and short ritualized interactions are more effective than hour long meetings?

Have you ever exceeded the 7 plus or minus two members to a team rule, with negative results?

Are you amazed by the increased engagement of your team when the old use case requirements are re-formatted into user stories that answer the question why?

If yes, then you are ready to peer behind the veil of Agile at the psychology at play. Join us to not only learn how the psychology behind the rules leads us to success, but to also gain insight into how  you can better apply the same psychology to the specific challenges facing you in your current circumstances.

About The Presenter:

Karen Spencer is an Agile Coach and Scrum Master living on the Boston North Shore. Karen has also held the corporate roles of Project Lead, Business Analyst and Business Manager. She has a background in Education and Psychology and a Masters degree in the Learning Process from Lesley College. An energetic and up-beat person, Karen maintains a strong user perspective and consultative focus when working with teams. She is known for her ability to clearly communicate complexity to both technical and non-technical audiences. Karen strives to “make it easy” for her associates with an attitude of shared ownership. She coaches teams in behaviors that strengthen collaboration and capture complex conversations with paper models that literally, as well as metaphorically, get teams on the “same page.”

MEETING AGENDA:

0630PM Agile and Scrum introduction

0700PM Food, beverages and socializing

0720PM MAIN EVENT: Karen Spencer on The Psychology of Agile

0820PM DONE

0830PM DONE DONE

Posted on

Scrum Master Selection

It is at best misguided to send Project Managers to Scrum Master training and make them Scrum Masters. Here are some reasons:

1. Your new Scrum team is already doubtful they actually have authority (“right to do work”) per the rules of Scrum. Your culture is not supportive of the idea, and every signal the team is getting from higher-ups is telling them to hedge their bets on Scrum as described around the web and in the Scrum Guide. The team will therefore ask the Scrum Master (previously: Project Manager) what they “should” do.

2. The Project Manager-turned-Scrum Master is going to have a hard time not telling the team what they “should” do…..

a. The Project Manager-turned-Scrum Master is probably an authority-seeking type of personality. That’s why they they were drawn to Project Manager role in the first place!

b. Even if the Project Manager-turned-Scrum Master comes back from Scrum Master training an enlightened and transformed creature, THE TEAM has no clue about this and is still projecting authority on the Project Manager-turned-Scrum Master. This pattern might persist for some time.

c. Even if the Project Manager-turned-Scrum Master comes back from Scrum Master training an enlightened and transformed creature, this new Scrum Master is clueless about executing in the role. This person has no experience.

All of this works against success with Scrum.

Usually, the Scrum Master is selected by the higher-ups. This is why the selected person is usually a PMP, or a Project Manager. (The Scrum Guide is silent on who chooses the Scrum Master.)

Here is a better approach:

1. Train everyone in a 2-day agile/Scrum class. Have the course delivered by your eventual coach.

2. During training, make sure the Scrum Master role is clearly explained. make sure it is explained from a servant-leadership point of view. Make it plain the Scrum Master identifies and removes impediments, and does drive schedule, cost, quality or features like a traditional Project Manager.

3. During the training, do some simulations of Scrum where someone can play the Scrum Master role. Offer the role to all the folks in the class and see who self-selects to give it a try.

4. Have the coach model the Scrum Master role when Sprints kick off. Make sure that the purpose of the coach occupying the Scrum Master role is to mentor this new Scrum Master. As soon as possible and without delay, install this new Scrum Master and get the coach OUT of the Scrum Master role.

5. Have the coach keep mentoring and guiding this new self-selcted Scrum Master in the art of occupying the role.

Summary

Instead of having the higher-ups select the Scrum Master, explain the nature of the nature of the role and see who shows up. Realize that putting a Project Manager in the role is probably not a good idea. Project Managers are typically authority-seeking and are great candidates for the Product Owner role.

Posted on

Hacking Iteration: Rehydrating Your Wetware

Recently I wrote about a technique for gathering requirements as a group. The technique is called rehydration and involves a very short meeting every day for 5 days. The idea is that the people in the meeting actually think about the meeting topic during the entire 5 days, not just the one hour each day.

The basic idea is to get the group thinking together over multiple days. Each short meeting constitutes a rehydration event. Such as event refreshes the neural pathways of your wetware (your brain). When a group of people execute on this kind of thinking together, the result is a substantially higher level of group cognition.

My friend Dave Logan wrote about this about a year ago. I was just up on his Facebook and I found this link:

The Single Best Time Management Tip Ever

…your brain is brilliant at running processes in the background, but is awful at multitasking. While you’re driving to work, in the shower or answering email, your brain will be working in the background on the task, so that when you’re ready, it’ll drain through your fingers, into your computer or notepad, for about 20 minutes. The break allows your brain to restock the supply of brilliance. Each time you go through the process is a “productivity unit.”

This idea of a short burst of front-of-mind focus followed by a break that is much longer (and used for back-of-mind thinking) is a super-powerful technique for doing sense-making with a group of people.

The technique is really very simple:

1. Gather the group with the collective intelligence to make sense of the problem (example: the definition of software requirements)

2. Schedule a 1-hour meeting for each day for at least 4 days

This is a special form of iteration, where the break is much, much longer than the iteration itself. Use Rehydration when you need to make sense of something very complex with a group of people.

Posted on

April 2012 Meeting: AGILE REQUIREMENTS PART2 (4/3/2012. 6:30PM)

AGILE REQUIREMENTS: PART 02. This is a multi-part series on gathering requirements. Do not worry if you missed PART1, you can hop right in.

Without good requirements, you cannot do good Agile. You need to know how to collect, gather and define requirements. Attend this meeting to learn how to build a real Product Backlog !

Everyone wants to know how to define requirements at the start of an Agile project. Old-school requirements insist that we do analysis, get PERFECT requirements, then do design, then development, then test. Sound familiar??

The results are in: this is a very ineffective approach to creating GREAT software.

The mechanics of creating requirements in an Agile way is very visual, tactile and collaborative. How we do requirements is the very heart of Agile. To really understand software Agility, you must experience how we gather and define requirements.

WARNING: Agile Requirements Gathering might cause discomfort and/or pain in the neck. May cause shortness of breathe in some individuals in Business Analysts and Project Managers using ‘waterfall’ approaches to requirements gathering.

Attend to find out how to start gathering requirements in an Agile way!

====================

REGISTER HERE

AGILE REQUIREMENTS: PART 02. This is a multi-part series on gatehring requirements. Do not worry if you missed PART1, you can hop right in.

====================

WHO SHOULD ATTEND

All who have an interest in great software with others can attend this meeting. Persons not comfortable creating great software with others may not enjoy this meeting.

Managers, directors and project sponsors as well as executives will get a great deal out this meeting.

Team members and project leaders new to Agile who are looking to really get going with Agile projects

Everyone in Connecticut who cares about genuine and authentic Agile adoptions in their workplaces may want to be at this meeting.

 

Everyone exits this meeting ready to go with Agile Requirements Gathering teachings, knowledge and direct experience.

 

WHAT YOU LEARN AT THIS EVENT:

  • How to generate enough good requirements to actually start coding in as little as 2 hours
  • How and why using index cards and facilitated meetings create great requirements
  • Why “user stories” make perfect sense for gathering requirements
  • What a “persona” is, and how to leverage them to create requirements
  • How to generate 60 ACTIONABLE requirements per hour
  • What a User Story Map is good for, and why you care
  • How avoid soul-sucking death march meetings, and replace them with fun, energizing and productive episodes of learning as you gather requirements
  • How to teach Agile Requirements Gathering to others in your organization

 

ABOUT THE SPEAKER

DAN MEZICK

Dan Mezick

Dan Mezick is an expert adviser on Agile who delivers Agile coaching and guidance to teams, departments and corporate executives. As skilled Open Space facilitator, he has pioneered the use of Open Space in Boston and is the Open Space facilitator for the Agile NYC Open Space 2012 conference held February 27, 2012.

He is the author of The Culture Game, a book of practices, derived from Agile, that managers use to promote more learning and agility inside their teams and the wider organization. He is a frequent speaker at Agile and management conferences and is the keynote speaker for the Northeast Quality Conference 2012.

His coaching clients include Mass Mutual, Hartford Insurance, CIGNA, Sikorsky Aircraft, Zappos Insights, Orpheus Orchestra, and dozens of mid-size organizations.

You can learn more about Dan and his Agile coaching practice, here.

 

SCHEDULE

This is a facilitated workshop. You exit with direct experience gathering and generating genuine Agile Requirements. We focus on a specific web-based application and generate requirements in small facilitated groups.

630PM Intro to Agile and Scrum (with cheese and crackers) Dan Mezick

700PM BREAK. Food, beverages, socializing

715PM  Exercise: Persona Generation

740PM Exercise: User Story Generation and Story Splitting

815PM Group Retrospective on Agile Requirements

830PM DONE

 

====================

REGISTER HERE

AGILE REQUIREMENTS: PART 02. This is a multi-part series on gatehring requirements. Do not worry if you missed PART1, you can hop right in.

====================

 

Posted on

Rehydration

Gathering and then understanding requirements is essential in software development. This piece about “understanding” is where most of the problems are. We know how to gather requirements. What we are not so good at is understanding them. However, I have found a cognitive trick that works well, and it based on starting.

I call the technique Rehydration. It’s based on the cognitive phenomenon of inattentional blindness(IB). IB says you can miss what is right under your nose if you do not pay attention. You may have seen the video of the invisible gorilla. That is an IB demonstration.

IB says you do not build perception if you do not pay attention. In experiments, people asked to watch for blue dots on a computer screen focus on them, and do not see any red or yellow dots that appear. They just “miss” them since they are not paying attention to anything but the appearance of blue dots.

Starting turns out to be good for focusing attention and this, for learning. By starting we pay attention, and by paying attention we learn. For example, software developers usually do not pay attention until they start cutting code. THEN they start thinking about the project and that thinking stays in their mind 24 hours a day. At work, the coding is in the front of mind. At home, the coding is in the back of mind. Many developers think about code and dream about it while sleeping. Many bug fixes are solved while dreaming.

What does this have to do with gathering requirements?

In a typical facilitated session, you can generate about one user story per minute with a team. This means in about one hour you can get 60 or so stories done. Same thing with generating user-types, or personas.

What I notice is the duration of the meeting matters. A 1-hour session every day for 5 days is about 10 times better than one, big marathon-like 5-hour meeting. The 1-hour-per-day-for-5-days approach is simply superior to one marathon meeting or even 2 meetings of 2.5 hours each.

What we are basically engaging in here is super-frequent iteration with a group of people around a cognitive, sense-making task.

You get these advantages:

1. More engagement. People will come to a 1-hour meeting and if you make it opt-in you get much higher levels of engagement

2. The folks know the meeting is short and they show up ready to work

3. This one is big: they think about tomorrow’s meeting today, and tonight, and tomorrow morning. The requirements gathering stays in their mind for 24 hours. It stays in the back of everyone’s mind. Some of them even dream about requirements, much like a programmer with a bug to fix dreams about the code.

4. The folks feel refreshed and have a sense of control and progress. I have already described this to you in other blog posts and in my book The Culture Game (you can order it here).

5. By having the meeting every day for 5 days, you get a better cross-section of people participating since most everyone can find a way to set aside one hour at least.

The reason this 1-hour-a-day trick actually works has to to with IB: by spreading the 5-hour meeting across 5 days of 1-hour meetings, the time in-between is spent thinking about it.

People ANTICIPATE the next meeting and the one after that and the results are 10 times better for it.

Everyone stays engaged for a week !

By starting, you pay attention (for 24 hours, not just 1 hour). And by paying attention, you build perception and learning.

This concept of Rehydration (refreshing a neural pathway periodically) can be applied to any project. Simply work for at least 35 minutes a day on the project and the rest of the time you gain perception when it is in the “back of your mind”. For free.

This technique works especially good when you are trying to gain perception as a group around a project.

Posted on

March 28, 2012 MONTHLY MEETING. Jeremy Kriegel on Agile Requirements with Personas

This month’s meeting is about creating and generating Personas to help gather and make sense of complex software requirements. Personas provide a named profile for a user type. This profile is useful for describing a user in detail, and generating and understanding user stories and the overall requirements.
.
.
.
.
.
Presentation:  WHO ARE THE USERS IN YOUR USER STORIES ??
“As a [user], I want to…”
.
If you’ve written requirements as stories, you are probably very familiar with this phrase, but who exactly is the user we are talking about?
.
Very often we resort to generic role titles.
.
You’ve likely found that many conversations still revolve around, “I think we should” rather than about what your target users would need.
.
In the absence of having real users give feedback on a regular basis, we often resort to abstractions such as market segments, but it is very difficult to make detailed design decisions based on broad segments.
.
Personas solve this problem by creating a realistic profile that represents a segment.
In this presentation, I’ll outline what personas are, why they are useful, and how to create them.
.
By the end, you will have techniques you can use immediately to create assumptive personas and start focusing your team.
.
About The Presenter:
.
Jeremy Kriegel has been designing great user experiences (UX) for 15 years. Just as we need to understand the needs and context of users to craft a design solution, Jeremy believes that success also requires us to look at the business context to craft an appropriate design process.
From start-ups to Fortune 100 companies, as a consultant or on an internal team, he has seen a lot of different scenarios that each required their own approach. He brings this diversity of experience to bear in adapting UX to agile methodologies, finding the balance appropriate for each business.
.
Currently, Jeremy leads the UX team at Cambridge Interactive Development Corp, the company behind Everest Poker and the Everest Gaming suite.
Posted on

Triumph of the City

The ultimate cause of Athenian success may seem mysterious, but the process is clear.

I’m reading TRIUMPH OF THE CITY by Edward Glaeser.  The aforementioned quote comes from this book. Friends are reading it, and recommending the book. The book is super-stimulating and is a truly great read. One of things that is hitting me about this book is the virtualization of city life. I’m plugged into some amazing FaceBook groups now. The people I am meeting and interacting with are all in the same ‘city’ so to speak. The experience is insanely stimulating. It’s like moving to and living in a very large city, and having a core group of stimulating friends who make the place friendly and fun.

It all starts with one connection. Let me explain.

I have a friend who uses http://www.couchsurfing.org/ to do travel. He goes to Madrid that way, 2 years ago, for 10 days. Or so he thinks. He loves it so much he stays for 6 months teaching English. You might wonder how he pulls this off. It is all based on that one personal connection he makes via CouchSurfer. His CouchSurfer host got him connected socially right away, and off he went. Six months in Madrid, and he barely knows Spanish going in. From there he gets an apartment, develops his wider network of friends in Madrid, and ends up having a completely awesome time.

Same thing here with the online city-space. The new cosmopolitan city is the online space: groups of people with aligned interests. When we get truly intimate online, we move beyond interests to a more general alignment based on experience, beliefs, values, behavior, and results. We get serious stuff done together after disclosing information and getting more and more genuine alignment.

We are rapidly coming to a time where people of like mind can rapidly produce amazing results. It is all based on social introductions, dialogue and blending at EPIC SCALE. For that to happen, you must have an entry point. That entry point is the introduction, or invitation from one person to another. From there, you have proximity… and the fun begins. Once you enter the online city-space via a group of people aligned on interests, you have access to most of the social benefits of living in a large city. You have a network of support, many introductions are made, you also make introductions, and the mixing of ideas begins. You also end up attending live events when people converge in a certain place for dinner or some kind of larger context like a conference or symposium.

I am willing to argue that the largest city on the face of the earth is FaceBook. All the basic social elements are there. Yes, the form is crude. The content is not. As socio-technical systems get better, the velocity of change and creativity can only increase.

I say:

We may be entering a Golden Age of creativity, especially in the way we implement what is called society, or civilization.

As I read Ed Glaeser’s book, I am mapping what he is saying about brick-and-mortar cities to the online city-space.

This is a rich and yeasty time to be alive. We are living in a time that is exuberantly creative.

Ideas move from person to person within dense urban spaces, and this exchange occasionally creates miracles of human creativity. – Edward Glaeser, TRIUMPH OF THE CITY