Daily Scrum: A Status Meeting?

is the Daily Scrum a ‘status meeting’? (trick question)

(scroll down for answer…)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

No. The Daily Scrum IS NOT repeat not a (traditional) status meeting…

…I recently fielded this question during a Scrum briefing I did for a client:

Question:

What’s the diff between a Daily Scrum and “status meeting”? The 3 questions sound like “status info”….?

Answer:

The Daily Scrum is not a ‘status meeting’ in the traditional sense of reporting to a person.

In a traditional status meeting, you report your status to a person in a role that has authority- a role like PROJECT MANAGER. A person in a role who is an ‘authority figure’.

FYI: This is a BIG deal!

In the Daily Scrum, you report the 3 questions (arguably status info) to your TEAM. Because the TEAM is the authority in that time in that place, namely: the Daily Scrum. The Daily Scrum is the TEAMs meeting. The Scrum Master (if present at all!) is NOT the boss, a “manager”, or a “project manager”. The Scrum Master is NONE of these things!

TEAM reports to TEAM. TEAM is authority in the Daily Scrum.

A subtle yet profoundly HUGE difference !

Further, the Daily Scrum is not a place to discuss solutions. Is IS THE PLACE to surface and make explicit topics for subsequent discussion. After the Daily Scrum !

If you have further questions, will you please ask me them on Twitter?

Here is my Twitter feed.

I hope this helps!

NOTE: The Scrum Guide is the ultimate authority on Scrum.

Here it is in English.

Here is the Scrum Guide written in various languages.

***

 

 

 

 

 

 

 

 

 

Tribal Leadership: Is It a Game?

 

The book TRIBAL LEADERSHIP lays out 5 stages of culture. The 5 stages are basically stories that people tell themselves…and others.

 

 

 

 

Here are the 5 progressive stories:

  • Life Sucks
  • My Life Sucks
  • I’m Great!
  • We’re Great!
  • Life is Great!

What I have come to realize is that the content of this cultural self-talk is related to games.

Games have 4 properties:

  • A goal/set of goals
  • Rules
  • Ways to get feedback on progress
  • Opt in participation (you can opt-out)

My current belief is that the 4th property, “opt in participation”, is an absolutely huge factor. It is highly correlated with levels of joyfulness, satisfaction, feelings of well-being, and overall life quality.

When you are forced to play a game, it is almost never fun.

When you opt-in to play a game, things get interesting!

Here is a summary of what I think is going on with these stories. These five stages of TRIBAL LEADERSHIP are actually stories and related self-talk, and are actually about the ability to make choices, about game structure, and about control, progress, belonging and meaning:

 

TL Stage Your Story The GAME connection
Stage 1 Life sucks! I’m forced to play games I do not want to play and/or do not understand. I have no options. I have absolutely no sense of control.
Stage 2 My Life Sucks! Some people play enjoyable (opt-in) games, but I don’t. I’m forced to play and cannot opt out. I get it, yet I have a low sense of control and almost no sense of progress.
Stage 3 I’m Great! I’ve figured out how to win. Further, I now define MY game, and now you have to play it. You ARE playing it! I’m now in control & now making great progress!
Stage 4 We’re Great! I opt-in to play a bigger, cooperative, goal-seeking game, with others. I now have a sense of belonging.
Stage 5 Life is Great! I opt-in to play a bigger, cooperative goal-seeking game, with others. And this time, we play big and intend to change the world. I now have a sense of higher purpose.

 

Summary

In my book THE CULTURE GAME, I explain the concepts and facilities available to create a good-game structure at work, a game where the enjoyment is so great that the distinction between work and play is minimal.

My current belief is that we are not nearly focused enough on using know-how about game mechanics to debug the problems we face at home, and work and in the wider world.

Culture, as it turns out, is a game.

Jane McGonigal gets it right: Reality IS Broken. And Zappos CEO Tony Hsieh also gets it right in his book, DELIVERING HAPPINESS: we all want to experience a sense of control, a sense of progress, a sense of belonging, and a sense of higher purpose and meaning. Good games deliver substantial happiness. The 5 stages of culture as described in the book TRIBAL LEADERSHIP do appear to confirm this hypothesis.

 

The Relationship to Effective Agile Adoptions

Agile adoptions are typically implemented as a mandate. This is acceptable so long as leadership sets out the clear direction and stops short of mandating specific practices. My current hypothesis, which appears to be valid based on experience, is:

  • Mandates of practices in an Agile adoption amounts to a game without the essential opt-in feature
  • People have needs. The mandate quickly reduces the feelings of control, progress, and belonging that are basic human needs
  • Resentment and disengagement are the natural and predictable results;
  • Disengagement is death to any attempt at a rapid and lasting Agile adoption.

The solution? Check in on what people want, what people think and what people feel BEFORE embarking on the journey of Agile adoption in your company. Open Agile Adoption is one way to do that.

 

Resources

For a deeper dive into these concepts, you might consider taking a look at these resources:

Blog Post: How Games Deliver Happiness And Learning

Blog Post: Open Agile Adoption

Audio Book, absolutely free download: Tribal Leadership by Dave Logan and co-authors

***

 

 

 

 

 

 

 

 

The Global Scrum Gathering Keynote: Paris 2013

I am grateful to have been invited into (and have accepted) the opportunity to deliver a plenary (keynote) address at the Global Scrum Gathering in Paris, France. The event runs from September 23-25 and the keynote is scheduled for Tuesday, September 24. I am honored to be part of this event with Henrik Kniberg and Dario Nardi, who also are delivering keynote addresses on Sept 23 and Sept 25 respectively.

You can learn about the 2013 Global Scrum Gathering in Paris here. If you click the [Keynotes] tab and then the right-arrow, you can examine the three keynotes, including the description of my talk.

I also list it here, for your convenience:

Open Agile Adoption 
The Agile journey may be best characterized as a rite of passage. Those who are taking the next step always do so as a group. During the journey, all the participants share the same basic status. Successful participants find themselves in a new and very unfamiliar place. And lastly, anyone who wants to complete the journey must also be willing to leave many things behind.

  • In tribal societies, passage rites from start to finish are facilitated and in fact led, by a “master of ceremonies.” What has changed?
  • Is the modern journey into agile actually a passage rite… for modern tribes?
  • Is the Scrum Master in fact the master of ceremonies in a modern rite of passage for teams and organizations?

In this session, together we explore the surprising answer. We also explore how to specifically leverage Open Space as a tool for helping to create authentic and lasting Agile adoptions.

I plan to explain Open Agile Adoption, an approach to implementing Agile that I have developed over a three-year period during which I have coached inside over 20 organizations. I have coached Agile since late 2007 and began experimenting with new approaches in 2009. At that time I noticed how some very intelligent people became disengaged during Agile adoptions. I began to ask why.

I began experimenting with the use of Open Space to help encourage more engagement, in service to rapid and lasting Agile adoptions. These Open Space experiments  generated some very surprising results. I’m grateful to the many organizations in and around Boston that have allowed me to experiment with sociological approaches to solving the Agile adoption puzzle.

Sociology First, THEN Practices

For my part, I value practices…because sound practices are very important. Yet solid, sound practices implemented with disregard to what people want, what they think and what they feel is, at best, misguided. It tends to generate disengagement.

I have learned the hard way, through experience, that the people who do the work are telling themselves a story. And that story is:

  • I get paid for thinking, and
  • I get paid for solving problems, and
  • I get paid for being creative.

That’s the story. This is one reason why it is essential to value sociological factors: if we mandate specific practices, the thinking and the problem-solving and the creativity that people bring to work is suddenly dampened. Squelched. Discouraged. Even killed off. Further, and more importantly, any sense of control is diminished. A sense of perceived control is essential for any sense of well-being.

Result: The prescription of specific practices becomes a topic for resentment…and eventually, disengagement. In my experience, it doesn’t take too long for people to “check out” on mandates and prescriptions. This disengagement is death to any honest attempt to bring improvement to an organization.

In Paris, I plan to tell you the wider story of Open Agile Adoption. The story includes many interesting people…and more than one courageous leader who took a legitimate shot of greatness with their Agile adoptions. I’ll tell the stories, and present several case studies. I’ll also provide a toolkit, free to the world… that anyone, anywhere can use to repeat the Agile adoption results I am getting.

I hope to see you in Paris. If you cannot attend, you can follow the Open Agile Adoption story on Twitter and here on my blog. As we head into September, I’ll explain more and more about the concepts and facilities of Open Agile Adoption. I’ll also explain the specific components, which are firmly rooted in sociology and cultural anthropology. On September 24 in Paris, I’ll present the actual case data and experience reports, and numerous testimonials on video.

More importantly, on September 24 2013, the date of the Paris keynote, I will make available to you and everyone, worldwide, a free, comprehensive, open-source toolkit for implementing a rapid and lasting Open Agile Adoption.

Frank Zappa, the offbeat musical genius, once said: “Without deviation from the norm, progress is not possible.” I believe he is correct.

I hope you will join me in learning more and more about the details of the Open Agile Adoption technique, incorporating Open Space Technology, as we head into September. You can stay up-to-date on my writing about it by bookmarking this link.

July 24 WALTHAM MEETING: Extreme Manufacturing

Scrum is used in all kinds of environments! One of the most exciting examples is Team WikiSpeed, which designed and built a 100 mile per gallon car in just three months. The team accomplished this amazing feat using “Extreme Manufacturing” –  a set of practices that combine Scrum, XP, and modular design to deliver hyper-productivity in a manufacturing environment. This brings the Agile revolution full circle, where agile practices with roots in Toyota that formed the foundation of Scrum are transformed in the software world and injected back into auto manufacturing. Imagine a new car design process where every week the latest design can be driven off the lot!

At this event, Scrum co-creator Jeff Sutherland and WikiSpeed founder Joe Justice will discuss how you can implement test-driven hardware development within Scrum. Get ahead of your competition and learn how WikiSpeed developed component architecture and produced hardware in one week sprints.

Register:

http://www.brownpapertickets.com/event/418614

About The Presenters:

Jeff Sutherland is the co-creator of Scrum and a leading expert on how the framework has evolved to meet the needs of today’s business. The methodology he developed in 1993 and formalized in 1995 with Ken Schwaber has since been adopted by the vast majority of software development companies around the world.

Joe Justice founded and has grown WIKISPEED, a company building 100+ mpg, modular commuter cars using Agile process, to a multinational business in 18+ countries, and now applies Agile methodologies to reduce time-to-value in social good projects such as polio vaccine distribution and low-cost medical centers for developing communities. Joe Justice consults on behalf of SolutionsIQ to realize the benefits of Agile services in non-software-centered verticals such as scientific R&D, oil, entertainment, manufacturing, food service, hospitality, health care, transportation, government, merger management, and education.

Meeting Agenda:

6:30 pm Introduction

7:00 pm Food, beverages, and socializing

7:20 pm Main event

8:20 pm Done

8:30 pm Done Done

Meeting Location:

CORPORATE OFFICE PARK
200 West Street
Waltham, MA 02451

The event room is located on the 1st floor. Enter the building. Take the hallway to the left. Walk past the elevators. The door to the event room will be on your right before the restrooms.

Register:

http://www.brownpapertickets.com/event/418614

 

July 25 DOWNTOWN MEETING: Invisible Impediments to Learning – POSTPONED

We’re all aware of the many challenges to learning on agile teams: the length of the release cycle, the clarity of the goal, the ability to learn from failures, and so on. But there’s more. There are things that are in our way every single day that we may not notice or be able to express; some of are even uncomfortable to consider. For example:

  • How does my mindset affect my ability to learn as an individual and to contribute learning to my team and my organization?
  • How does my approach to ownership advance or hinder my ability to help myself and others push through challenges and recover from failure?
  • How does my respect – or lack thereof – for my peers affect my ability to build software?
  • What does it cost me or my team when I miss an agreement? And, just as important, what does it cost when when I fail to confront a missed agreement?

These are some of the invisible impediments to learning that reduce our ability to create great software efficiently.

In this session, you’ll identify these invisible impediments to learning and leave with things you can do right away to accelerate individual, team, and organizational effectiveness.

NOTE: The downtown event is being held at PayPal in Boston. To accommodate security, registration will be closed at 9:00 PM EST on Tue 7/23. Walk-ins will not be allowed to attend. Please be sure to register in advance for this event and bring a photo ID.

Register:

This event has been postponed. There is no downtown event in July.

About The Presenter:

Amr Elssamadisy brings together individual human dynamics, environment and cultural engineering, and agile software development practices to produce immediate and lasting results for his clients.  With a hands-on approach, and infectious can-do attitude, Amr leverages his years of experience (both success and failure) to hold up a mirror to the organization and then guide and teach his clients to make incremental, measurable improvements.

Meeting Agenda:

6:00 pm Introduction

6:30 pm Beverages and socializing

6:50 pm Main event

7:50 pm Done

8:00 pm Done Done

Meeting Location:

PayPal
1 International Place (6th floor)
Boston, MA 02110

Register:

This event has been postponed. There is no downtown event in July.

 

No Estimates

There’s a meme getting traction in the Agile community: #NoEstimates [1]. It’s the idea that putting effort into estimating user stories is mostly a waste of time. I agree that, in general, in most cases, estimates are inaccurate.

Especially early in a project, these estimates can be a total wild-ass guess (hereafter “WAG”) and have no basis in reality.

Prominent blog posts that explain and advance the #NoEstimates idea are listed at the end of this post. [4,5,6].

Value, Cost and Risk

Projects are funded and authorized by those who have an interest in value, the cost of obtaining that value, and the risk associated with attempting to obtain that value.

  • The value is the benefit, advantage or other gain that occurs as a result of building a feature, eliminating technical debt, and the like.
  • The cost is the total sum of cash and non-cash payments required to create value.
  • The risk is the possibility of loss of cash and non-cash assets (example: employee morale, employee retention, time, etc) associated with investing time and effort in the creation of value.

Now, for most typical organizations who are new to Agile, it is unlikely that authority will enjoy being told “estimates are a waste of time, so we are not doing them.” The most progressives organizations are already OK with this idea. The problem of course is that 90% of the Agile work going on is going on inside relatively unprogressive organizations, inside orgs that are learning. Selling #NoEstimates is a tough sell in that spot.

Risk

Few if any people in the Agile community discuss risk when discussing value and cost. (Chris Matts, a man who works on trading systems for a living. is one notable exception here [2].)

Regarding risk, the main thing risk managers do in (for example) hedge funds is define the risk [3]. This is usually defined by ‘stops’ that limit loss to a known, predictable number in dollar or percentage terms. Key to getting this number is knowing the cost of the trade. For example if you want to limit risk to not more than $50 and not more than 10% of the trade, the dollar cost of the trade cannot be less than $500. That’s the cost of creating and maintaining the trade. Without knowing the total cost of the trade, it is hard to manage (“limit”) risk in any rational way.

The Larger Concern

The larger concern is the fact that team members gain a substantial amount of team learning via discussions about estimates. During estimation, a given item in a backlog gets discussed, and the team members learn about that work (and each other) as they discuss it. One may say with some certainty that the estimation task is actually a ‘cover story’ for the wider task of team learning. If estimates are 100% eliminated, how is this team learning replaced? Team learning is obviously essential. Discussions during the estimation task create many team-learning moments.

Summary

It’s true that most estimates are waste. It’s rational to believe this, and there are many good blog posts elsewhere that explain “why”. You can examine them by investigating the Twitter hash tag #NoEstimates (see below).

People behave irrationally and of course project sponsors and people who fund these projects are no exception. Many organizations in fact have built up various departments and policies that support and in fact demand information like estimates before a project is funded.

The problems that remain to be solved are:

  • How exactly to explain to project sponsors that the cost component delivered as an estimate is not really valid, and therefore is waste?
  • How to encourage the same level of team learning that takes place during the estimation process?

Most estimates may be waste, but for most coaches and clients, estimates are a necessary fact of life, especially in the early part of any move to Agile.

Related Links:

[1] #NoEstimates Tweets on Twitter

[2] Chris Matts blog (blog posts and links)

[3] Trading Risk: Enhanced Profitability Through Risk Control (book)

[4] Five Reasons You Should Stop Estimating User Stories (blog post link)

[5] Story Points Considered Harmful (blog post link)

[6] #NoEstimates HashTag Explained (blog post link)

Mandated Agile, Part 2

I have a lot of heat around how Agile gets implemented in typical organizations. I’ve been ranting about the evils and oxymoronic nature of mandated collaboration [1]. Let me explain.

When I say mandated collaboration, I mean the prescription of both Agile adoption and specific practices.

I am clarifying my messaging here: naming a clear Agile direction is OK. However, stop right there. Prescribing practices as non-negotiable mandates and prescriptions is not OK, precisely because it kills engagement, the very fuel of progress….

…businesses are facing all kinds of pressures. The pace of change, driven by technology, is speeding up. So not just lots of change, but the velocity of change itself is intensifying. This is making is essential for enterprises to become highly adaptive. Right away. This means lots of group/team/org learning or what I call Tribal Learning has to be taking place all the time. AGILE CAN HELP.

So: when I say mandated collaboration [1] is dumb, I am NOT saying mandating an Agile direction is dumb. FAR FROM IT. This is exactly what leadership needs to do.

Leadership actually needs to do several things:

  • Explain the business case for Agile. Explain the challenges the business is facing in terms of competition, pricing pressure, obselete products etc
  • Make it clear the enterprise is heading into an Agile journey– an epic adventure. This part is not optional.
  • Invite everyone involved into the process of writing the Agile story. Communicate that leadership DOES NOT have all the answers and is looking FOR THE VERY BEST IDEAS PEOPLE HAVE to make the move to Agile genuine, authentic, rapid, and lasting.
  • Make it plain that everything that is tried as an Agile practice at the start is an experiment, and is optional, and going to be inspected, and is not set in stone. For example, if the org is giving Scrum a try, it is an experiment, and subject to inspection. If an off-the-rack practice like Scrum cannot be tailored and customized to fit well, it will be THROWN OUT and we will try something else that might work. We might even “roll our own” practices, using the Agile Manifesto as our guidance.

By doing it this way, the people doing the work can engage, and have a strong sense of control and of progress [2]. Prescribing practices makes no allowance for what people want, what people think, and what people feel. It reduces engagement and causes people to check out and disengage.

So leadership makes it plain we are moving into an Agile stance as a company. So far so good. Next: Leadership then frames the initial use of ANY practice as an experiment, one that will be inspected for usefulness and effectiveness in service to the stated aims of the Agile adoption.

This is the exact opposite of what usually happens. Usually, the following happens, usually after a small pilot test of Agile with a small team:

  • Authority says we are going Agile
  • Authority says we are doing Scrum, or Kanban, of SAFe, or some other method. The message is that this is not negotiable.
  • A coach is selected by authority on the basis of expertise with the prescribed practices. Typically, Scrum skills. The coach is imposed on the people, just like Scrum.
  • Workers are triggered to disengage by the experience of a low sense of control and progress. They learn that the goal is fuzzy, the rules are fuzzy, the way we track progress is vague. Participating is not opt-in. The Agile adoption is not an enjoyable game because there is no opportunity to opt-in, because it’s not an invitation. Far from it. Agile and Scrum (for example) are a mandate and a prescription.

Folks, this is at best misguided. I’ve explained why in previous posts [1].

It kills engagement, the very fuel of a rapid and lasting Agile adoption.

The good news is, we can prescribe and mandate Agile without mandating collaboration. Leaders can frame the move to Agile as a necessary direction, and then invite everyone to bring the very best they have into the game, and help write the story. Authority can and must frame Agile practices as trials, and as experiments, which is code for saying that initial practices are not prescriptions from authority, and that everyone gets a hearing and will be asked what they want, think and feel about the experience of using of specific practices.

If we do not do this, we can expect the very poor results so-called Agile adoptions are getting after 12 months, 18 months, 24 months. The role of the coach is huge here. We need to stop being party to mandated Agile practices, and…

“Build projects around motivated (opted-in) individuals, give them the environment (the safe space) and support (the authorization) they need, and trust them to get the job done. [4].”

Related Links:

[1] Mezick, Daniel J. Mandated Collaboration: The Recipe for Botched Agile Adoptions. Blog Post. (link)

[2] Mezick, Daniel J. How Games Deliver Happiness. Blog post. (link)

[3] The Agile Manifesto Principles. Web page. 5th item listed. (link)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Principle 4: Apply Self-regulation & Accept feedback

This is one is a series of post on the application of the 12 principles of Permaculture [2] to organizations, and other social systems.  The posts are being generated by members of the Organizational Permaculture [1] group on Facebook. If you like this post, consider joining the group and adding to the  conversation with your own blog post on 1 or more of the 12 Principles of Permaculture [2]

Principle #4: Apply Self-Regulation and Accept Feedback

Principle #4, “Apply Self-Regulation and Accept Feedback” speaks to self-discipline, psychological safety and being open. It is important to note that these personal and system-level properties are a means to an and, not an end in and of themselves. The principle “Apply Self-Regulation and Accept Feedback” mean in part that we intend to tune and tailor our social systems to be highly receptive to feedback. It means we intend for our social systems to be aware.

It also means we work to actively create and then maintain the ability of the entire system to rapidly identify and respond to change.

This is the essence of organizational agility. The agile world uses the slogan “inspect and adapt” to express the importance of accepting feedback and applying self-regulation.

Self Discipline

Collecting observations is essential to responding to change. Observations can be proactive or reactive, active or passive. Reactive observing is what happens after taking an action, such as introducing an experiment.

Proactive observations are observations of the system as it is, without introducing anything new except your own presence.

Feedback as a Resource

Responding to change can be formal or informal, and frequent or infrequent. As a norm, it can even be absent entirely. There is no adapting without inspecting, observing or otherwise experiencing the environment. This plays out in social systems by using any practice that operationalizes the proactive and reactive styles of observation.

Psychological Safety

Technically, Jay Forrester describes social systems as “1st order nonlinear feedback systems” in his paper, Designing the Future. [3] . For an entire social system to become adept at responding to change, a high level of what Amy Edmondson calls ‘psychological safety’ [4] which is the willingness to take ‘interpersonal risk’ during interactions with individuals, in front of the group. Psychological safety in social systems is important for individuals. When the level of psychological safety is low, levels of self-regulation and acceptance of feedback at the level of individual and group will also be low.

Openness

I’ve written on Openness previously when discussing the Five Scrum Values [5]. Openness includes accepting the best idea, regardless of source. Discussing ideas is a way to express the identification of changes, and also a way to discuss a rational and well-reasoned set of possible responses to that change.

Practical Steps

Any activities that formalize frequent generation  and inspection of feedback are directly supporting Principle #4 of Permaculture: “Apply Self-Regulation and Accept Feedback.” Scrum [7] and Open Space [8] both define feedback systems with formal structures. Scrum is a complete framework, while Open Space is a meeting format. Both feature explicit loops of feedback with specific guidance on how to best process the feedback generated.

 

 

 

 

 

 

 

 

Figure 1. Small Session In Open Space.

 

Practical patterns and processes that can support this principle have certain common characteristics.

First, they share a formalization of frequent feedback loops. Scrum is a good example; it has a daily feedback loop (the Daily Scrum) and feedback loop (the Sprint Review) at the end of each iteration of work.

Second, they have an opt-in aspect, the people in the system choose to participate in using the pattern or process, and are not compelled to use it. Open Space is a good example; everything about it from the beginning to the end is an exercise in opting in or out.

Another good example is the Core Protocols. The Core Protocols [9] are structured interactions that have mechanisms for sending and collecting feedback. (Perfection Game and Investigate protocols respectively). Open Space is a 100% opt-in meeting. Scrum defined the Daily Scrum and Sprint Review as formal observe & inspect points.

 

Summary

To be self-regulating, there must be feedback. The more frequent, the better. The frequency of sampling the environment for feedback by observing in social systems can be monthly, weekly, daily or continuous. Teams and organizations that focus on identifying sources of feedback (and who also become adept at processing it) are in position to learn much faster than organizations that do not [6]. This learning in social systems is essential if we are to Obtain a Yield [10].

 

References:

[1] Organizational Permaculture Group on Facebook. (link)

[2] 12 Principles of Permaculture on Wikipedia (link)

[3] Forrester, Jay. Designing the Future at Universidad de Sevilla, Sevilla, Spain 1999 (link)

[4] Edmondson Amy, Harvard University. Paper: Psychological Safety in Work Teams” (link)

[5] Mezick, Daniel J., “Scrum Values”, blog post (link)

[6] Mezick, Daniel J. , “Culture That Learn are Superior”, blog post. (link)

[7] Schwaber Ken and Sutherland, Jeff. The Scrum Guide (link)

[8] Herman, Michael. Essay: About Open Space. (link)

[9] Core Protocols explained (link)

[10] Lloyd, Andreas. “Principle 3, Obtain a Yield”, explained. (link)

 

 

 

June 26 WALTHAM MEETING: Agile Hiring: It’s a Team Sport

Slides from this talk are available: Agile Hiring: It’s a Team Sport

When you think of hiring for your team, do you think of paperwork, and endless interviews, wondering if this candidate is really right, and the difficulty in making a decision? You know the cost of hiring people is high, and the cost of not getting the right person is even higher. You can apply agile approaches to your hiring, iterating on everything in the hiring process, getting feedback as you go, and involving the entire team. Just as agile is a cross-functional and team approach to developing great products, you can make hiring a cross-functional and team approach to hiring the best people who fit your team.

Join Johanna Rothman, author of “Hiring Geeks Who Fit”, in this talk where she will explain how to have the team review resumes, interview, create auditions, and make the hiring decisions to ensure you have people who fit with the team. She’ll also explain where and when it makes sense for the hiring manager to take the lead, such as for phone screens, organizing the interview, and the offer. If you have agile HR people, bring them, because we want them involved, and they have a place, too.

Register:

http://www.brownpapertickets.com/event/394992

About The Presenter:

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential risks, seize opportunities, and remove impediments.

Johanna was the Agile 2009 conference chair. She is the current agileconnection.com technical editor. Johanna is the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

She is writing a book about agile and lean program management. She writes columns for Stickyminds.com, Dice.com, and projectmanagment.com, and writes two blogs on her web site, jrothman.com, as well as a blog on createadaptablelife.com.

Meeting Agenda:

6:30 pm Introduction

7:00 pm Food, beverages, and socializing

7:20 pm Main event

8:20 pm Done

8:30 pm Done Done

Meeting Location:

CORPORATE OFFICE PARK
200 West Street
Waltham, MA 02451

The event room is located on the 1st floor. Enter the building. Take the hallway to the left. Walk past the elevators. The door to the event room will be on your right before the restrooms.

Register:

http://www.brownpapertickets.com/event/394992

June 27 DOWNTOWN MEETING: Agile Hiring: It’s a Team Sport

Slides from this talk are available: Agile Hiring: It’s a Team Sport

When you think of hiring for your team, do you think of paperwork, and endless interviews, wondering if this candidate is really right, and the difficulty in making a decision? You know the cost of hiring people is high, and the cost of not getting the right person is even higher. You can apply agile approaches to your hiring, iterating on everything in the hiring process, getting feedback as you go, and involving the entire team. Just as agile is a cross-functional and team approach to developing great products, you can make hiring a cross-functional and team approach to hiring the best people who fit your team.

Join Johanna Rothman, author of “Hiring Geeks Who Fit”, in this talk where she will explain how to have the team review resumes, interview, create auditions, and make the hiring decisions to ensure you have people who fit with the team. She’ll also explain where and when it makes sense for the hiring manager to take the lead, such as for phone screens, organizing the interview, and the offer. If you have agile HR people, bring them, because we want them involved, and they have a place, too.

NOTE: The downtown event is being held at PayPal in Boston. To accommodate security, registration will be closed at 9:00 PM EST on Tue 6/25. Walk-ins will not be allowed to attend. Please be sure to register in advance for this event and bring a photo ID.

Register:

http://www.brownpapertickets.com/event/395003

About The Presenter:

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential risks, seize opportunities, and remove impediments.

Johanna was the Agile 2009 conference chair. She is the current agileconnection.com technical editor. Johanna is the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

She is writing a book about agile and lean program management. She writes columns for Stickyminds.com, Dice.com, and projectmanagment.com, and writes two blogs on her web site, jrothman.com, as well as a blog on createadaptablelife.com.

Meeting Agenda:

6:00 pm Introduction

6:30 pm Beverages and socializing

6:50 pm Main event

7:50 pm Done

8:00 pm Done Done

Meeting Location:

PayPal
1 International Place (6th floor)
Boston, MA 02110

Register:

http://www.brownpapertickets.com/event/395003