Sometimes it’s hard to be in multiple places at the same.  Ok, it’s not possible to be in multiple places at the same time so with 10 teams and 100 or so people in the organization I’m working with and only myself and another coach I’m working with, I decided to create a retrospective room so teams can get some helpful tips and advice when we’re not able to help facilitate.

I had one goal in mind when creating this space which was to make it safe for teams retrospect in an environment where not all folks were accepting of doing retrospectives.  As a coach sometimes the best thing to do is back away and let the team figure things out on their own.   I had just finished facilitating a retrospective with a new team and could sense they wanted help improving but the ‘gotta have it all by this date‘ was too strong to influence them to try new things.

In the spirit of trying something new, I decided to just flat out ask them if they wanted me to sit with them for the next sprint and help out with a finger vote.  A few people had 5 fingers up and the rest averaged about 3 fingers.  I asked them again, but this time be honest and don’t worry about offending me.  “I am here to help, if you don’t feel like you can accept help based on the deadline just tell me“, I said.  The folks with 5’s kept the 5’s in the air but the average dropped to 2 fingers.  I thanked them for being honest and kept the door open in case they decided they wanted help later.

I figured creating a retrospective room was a good way for teams like this to experiment on their own in a safe environment.

The room:

The room is a nice, big open area with lotsa wall space.  It’s also the first thing people on the teams see when they come into the building.  This is near the backdoor entrance that only the team members use.  The point is, there was no need to advertise or tell people to use it.  People naturally came in and looked at the stuff on the walls to see what the hub-bub was about.

What’s in the room: Getting Started with Retrospectives

There’s an area that has info on the value of retrospectives, a sample meeting format and a sample checklist of things to do before getting started.   Posted on the papers are:

• The Agile principle for retrospectives (At regular intervals the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.)
• Outline from Esther Derby’s and Diana Larson’s Agile Retrospective book (set the stage, gather data, generate insights, decide what to do, closing)
• A section to post questions that myself and the other coach will answer
• Kerth’s Prime Directive (summary: people are doing the best they can with the situation at hand)

What’s in the Room: Sample Agenda

This area is helpful for teams to find a focus for the retrospective.  It’s marked as a sample, not the rule and the sample follows these steps:

1. Decide on a focal point
2. State agenda and do appreciations
3. brainstorm what went well, what didn’t go well in context of the focal point
4. brainstorm stop/start doing things
5. create action plan
6. re-usable area for well/not-well stickies

There’s also a basket labelled “Retrospective tool kit” that contains the stickies, markers and handouts of various techniques teams can try from Agile Retrospectives.

It also happens that there is a kitchen in this area off to the side so it becomes a great conversation piece when I grab my morning coffee.  When talking with folks I can reference the value of retrospectives and use fancy techniques like pointing to Kerth’s Directive to re-enforce the importance of retrospectives.

At the end of the day, it’s about doing anything I can think of to help my client and I love the creative aspect of what I do.  Oddly enough the team that inspired me to create this room has asked for help after that first retrospective.  While the whole team is struggling to accept change, there are a few people on the team that want to improve how they work and hopefully this room has shown them that I want to help while at the same time helping them feel more comfortable and safe about these changes.

Of course, now that the room has been in use for a couple of months it’s time for a refresh, Retrospective Room, Phase II is underway.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

“Wait a minute, I thought we were Agile?  What aren’t things better and why do we have more problems now?”

What happens after the honeymoon is over?  Going from blank walls and cubes to a lots of stuff on the walls and a nice wide open space and should have made a difference by now shouldn’t it have?

There’s a lot of noise on Linked In, Google Groups and twitter (to name a few) that all seem to try and find fault in a person, team, organization or practice because the results aren’t matching the rhetoric.    So we’ve been at this Agile thing for a while, we found a shitload of problems, came up with a plan to fix them, didn’t see results right away because we chose to not prioritize actually fixing these problems, blamed the methodology and decided to go back to the old way of just ignoring said problems.  Voila!

I remember that fantastic exciting and new feeling when I first met my wife some 15 years ago.  It was fun.  New.  Exciting.  Fast forward to marriage and kids and after the honeymoon was over life got hard and complex.  It takes work to manage our house and family.  Real work.  Any problems we have are our problems and if we chose to ignore them, we suffer the consequences.

According to these stats, 1 out of 2 marriages in the US and Canada fail.  Why is that and what does it have to do with Agile?  Plenty.  When stuff gets hard, we as humans give up.   This Business Week article talks about 5 reasons why we tend to give up on our goals.

• Ownership: thinking “I’ll give this a try and see what happens” instead of thinking “this will work only if I make it work”
• Time: holy cow, I didn’t think it’d take this long, is it worth it?
• Difficulty: This is waaaaay harder than I thought!
• Distraction: Sorry, can’t work on my goal, have a bunch of other stuff to do.
• Maintenance: ah, good enough….I don’t have to keep working at it do I?

Adopting Agile is no different than any change in a company.  It’s a change.  A big change.  A really big change and change is hard.  All the mental models, coaching models, change models, methodologies and such are fine and dandy but sometimes you just need good old fashioned gumption.

Sometimes it’s time to nut-up or shut up.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

My wife and I were working on our monthly budget last night and were looking at where we could free up some dough so we could put more money aside for un-expected stuff, debt, vacations and so on.

Seems like every once in while we talk about the same ideas for managing our budget without anything coming of those discussions.  Sound familiar?  How often in your personal life or work life do you have the same conversations over and over again only to never realize the benefit?  What’s the problem?

Discipline.  For us, there just hasn’t been any sense of urgency to change anything about how we manage our finances.  We know we “should” do something differently but we’re not disciplined about executing on it.

What I often hear from teams is that ‘we have no time’ to do our improvements.  There is just too much work to get done.  Bullshit I say.  What they are really saying is we haven’t made improving a priority.  Discipline is really, really tough.  It forces organizations and teams to prioritize and make real decisions instead of simply deciding not to decide.

A colleague I used to work with brought this phrase to my attention. If we keep doing what we’re doing, we’re going to keep getting what we’re getting. If you want your outcome to change, change your behavior and be disciplined with your approach.  If you choose not to behave differently and use “no time” as the excuse for not being disciplined the only results you’re likely to get are metrics that mean absolutely nothing.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Peter is bitter.  He admits he’s never worked on or heard of an Agile project that actually worked so it must be the methodology right?  Yesterday I tried to cut my steak with a spoon and that goddam spoon sucked-ass.  Why the hell would anybody ever use a spoon for anything?  They are completely useless!

Peter is confused and grossly mis-informed about what Agile practices are so I crafted a response (as brief as a could given how much bad information in his article) to his statement: “Agile software development methodology sucks ass. Big time. Totally. 100%. Entirely. Gosh, I hope I‘ve stated that clearly enough.”

Come along for the ride won’t you please?

Most of the rants in the article (here’s the full article) appear to be about the execution mechanics of Scrum and Scrum doesn’t really speak to the full life-cycle of a project or visioning.  Scrum is about execution which isn’t to say planning, chartering and product discovery aren’t equally important.

He starts out with the “stupidity of its (Agile’s) three most important tenants:”

A maniacal emphasis on just getting something working as opposed to thinking something through,designing how it should work, and getting something working correctly.

This is often the thinking of novice Scrum folks.  People tend to inaccurately think that ‘potentially shippable software‘ means just build some shit and see what happens.  Not the case.  The sprint goal is based on getting a functional piece of software done and it doesn’t imply there is no upfront planning or design.  Scrum says do enough that makes sense to get started sooner since each project has it’s own unique attributes.  Think incremental delivery based on a product goal or vision, not just getting something to work.

Scrum doesn’t specifically talk about project charting or product discovery since it’s focused on what happens in the sprint.  The Agile community in general, however, understands the importance of this.  Have a look at Jeff Patton’s stuff.  He knows, ahem, a little bit about Scrum and how to use Agile to build kick-ass products.

Requiring detailed estimates of how long it’s going to take to implement some piece of functionality.

Scrum actually de-emphasizes detailed estimates and favours sizing and measurement instead.  That means use story points to relatively size the stories since an estimate is just a guess.  It’s best to spend less effort on sizing since we all suck at it anyway.

Us crazy Agile people understand software is complex and it’s an art as opposed to a science.  Scrum uses real data and real progress to figure out how long the project will take, just ask Mike Cohn.

An insane reliance on – and limitation to implementing features for – user stories (AKA scenarios), which yield fragmented feature sets as opposed to designing for well -reasoned comprehensive functionality.

This is often a result of mis-using stories for what they were designed to do.  Depending on the nature of the product or project, ’shooting a tracer bullet’ means doing the simplest thing that can possibly work.  In the case of building a search engine, for example, the simplest thing that could possibly work is having a basic text search in Sprint 1 followed up by fancy stuff later on.  This helps reduce risk by making sure you can work within your technology stack and after Sprint 1 you have tests that will make sure as you add more functionality you don’t break existing functionality.

Think 80/20 rule.  No need to over analyze or over  engineer something when most of the functionality isn’t going to be used.

Planning Poker is for mentally defective 6 year olds

Peter says planning poker is great if you like “being treated like a mentally defective 6 year old“.  This is precluded with:

“And, that brings me to the second thing that makes Agile suck so badly: The whole ‘estimation’ process. Every time somebody insists that I estimate how long it‘s going to take me to implement some particular functionality, and in Agile it‘s not uncommon to have to do these estimates with great precision, I realize I am dealing with an idiot. Worse, I realize that I am being asked to lie. And I don‘t like lying. Well, at least not to most people and not usually very much.”

Again, Agile focuses less on estimates and more on sizing and measurement.  Size the stories, start sprinting and use your velocity to see how it’s going.  Story points imply less precision by their very nature since they’re based on effort, not time.  Effort drives your duration.

In a nutshell, size the stories, take a bunch of them to start working on, see how much you got done (your velocity) and use that real data to estimate your release.  This process of course would have been precluded with some product discovery (also sometimes called ’sprint 0′) or some initial modelling.

Next on Peter’s hit list are user stories:

“And that leads me to the final Agile precept that fries my potato: User Stories. Every time I hear somebody say I’ve entered that as a user story I want to puke. Why? User stories are just that: Stories. They’re data. They’re not wisdom from the ages. And, the way I see them used in most cases, they’re not even necessarily fully representative of what the majority of users want or need to do. When your development process is focused entirely on implementing functionality based on a handful of user stories, you more often than not end up with a random, inconsistent, poorly integrated, mess.”

The problem here seems to be his experience of not using Stories correctly.  Stories are meant to convey a users’ intent within a context.   This context is captured in things like themes and story maps which help teams understand the full context of the software.

If you aren’t using stories to satisfy your users, you’re probably not involving the users in their creation and you’re probably not getting feedback soon enough from your users when you’ve created a prototype of the software. Agile’s #1 principle is to ’satisfy the customer with early and continuous delivery of valuable software.’

I realize I could go on for a few more pages about how much is completely wrong with Peter’s impressions of Agile.  Of course based on his negative experience, I can’t say I blame him.  After all, my dad still won’t buy Ford products since our 1985 and a half Mercury Lynx.

Getting burned by that lemon ruined his whole experience with Ford.

“You code to these particular stories. No, you don‘t get a chance to think through the overall experience for any user. This is Agile software development. You don‘t get to think. You‘re not allowed to design. You‘re allowed to get some code working? so you can try things out. And that code just needs to meet the user stories, and pass the tests that were so lovingly crafted and stored with those stories.   Anything else? Well, that‘s for next sprint.

So, in Agile what you get are ridiculously incomplete requirements, driving a development process that emphasizes sloppy implementation over design, that‘s tracked using a long list of bogus and irrelevant milestones. The only thing that‘s left to wonder about is why everybody doesn‘t think Agile development sucks ass.”

All Agile practices are empirical and focus on the value of a whole team.  That means a cross-functional team of business folks, programmer and testers.  The customer/stakeholder sets the vision, the team executes.  Scrum, as a methodology, doesn’t talk about the vision part, it focuses on execution.  Executing without context is just dumb no matter what methodology you’re using.

Great design in implied in XP.  Simple design, test-driven development and incremental delivery get you to good design.  It doesn’t happen magically, it takes hard work and sometimes teams need to do some upfront modelling or planning.

Peter, we in the Agile community have worked with you before.  I’ve coached many teams with “Peters” on them and what usually happens is “oh, so THAT’S why it didn’t work for us” syndrome.   I can relate based on why I got into Agile in the first place.  Many years back I was told “you don’t understand Agile” because I asked the team to roughly let me know how much I should charge the client to build what they were asking for.

They answered with thoughts similar to your rants.  You just start building stuff and see what happens.  I decided that was dumb so I got trained, started going to conferences and started talking to other weird and crazy Agile people.  Books helped too.

Now I don’t blame the methodology.  Agile doesn’t fail.  People fail when they fail to understand the tool or methodology they are using and it’s too bad you’re experiences have led to to this great epiphany that Agile sucks.

Maybe one day you’ll get a chance to experience an Agile project done right and maybe one day I’ll convince my dad that Ford builds way better cars now than they did 25 years ago.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I was on vacation last week and was working on a blog post when my 5 year old barged into my office asking me to play dominos with him.  I figured I needed about 10 minutes to finish up the post so I asked him to go look at his clock and tell me what time it was.  He rushed out, came back and said, “daddy, it’s 9.25” so I said, “I will play dominos with you in 10 minutes.”

Expectation set.

At 9.35 he comes back in, grabs my arm and says “ok, its 9.35, lets go play dominos!”

“Hang on dude, I need a few more minutes…”

“NOOOOOO he says! I want to play dominos!”

Trust broken.

The great thing about kids is how they live in the now.  I set the expectation that I would play with him in 10 minutes and I broke that commitment.

So what happened?

Bad estimate finishing my post I suppose.  Maybe I gave an estimate based on what I thought was a realistic time frame for a 5 year old to wait regardless of the effort left on the task.  As a result that time-crunch probably led to lack of focus and it all went downhill from there.

Bottom line is I set an expectation, I broke the commitment and the consequence was the dreaded “5-year old melt-down.”

There’s a lesson here, well, a few actually.

1) Trust: When a team sets an expectation with their Sprint commitment they’ve largely said “trust us, we’ll get this stuff done in 2 weeks”  If teams get into a habit of setting expectations and not delivering, that trust will be broken and that has consequences that are much more serious than “oh well, we’ll do better next time“.  The product owner, stakeholders/customer or whoever, won’t believe the team when they estimate stories or when they make Sprint commitments.

Without trust you’ll end up piling more process on top of already existing dysfunctional process to account for the lack of trust.  Sometimes we like to call these “gates” and mask our distrust as “accountability or responsibility”

2) Team Responsibility: When a team sets an expectation, they are responsible for living up to that expectation.  If the team misses the commitment they should be pissed off they missed it.  Of course, when they nail it, it feels good.  It feels good to finish something and present the work to others in the organization.

Without team responsibility you’re just breaking work into 2 week chucks and not behaving any differently.

3)  Personal Satisfaction: Personal satisfaction is a great motivator.  Harvard Business Review posted an article on what really motivates people and progress was the number one factor.   Setting an expectation in the Sprint Planning session and showing the result at the Sprint Demo shows progress which is a great way for team members to feel a sense of personal satisfaction.  This is more important than managing by fear (the STICK approach) or managing with carrots (the REWARD approach).

These 3 factors are closely related.

Lack of personal satisfaction can lead to lack of team responsibility.  Lack of team responsibility can lead to commitments being missed which will lead to a lack of trust between the team and the organization/customer/stakeholder.

The difference between my story of breaking my commitment with my 5 year old and a team breaking their commitment is that I can re-gain that trust easily by saying I’m sorry and by taking him out for some ice-cream.

Chances are a team only has so many ‘get out of jail free’ cards and a pattern of missing commitments isn’t only going to kill your Agile initiative, it’s going to do damage to your business.

Related posts:

1. Learn the Secrets of Collaboration…From Your Kids One of the simulations I like to facilitate during...

Related posts brought to you by Yet Another Related Posts Plugin.

Yesterday I mowed the lawn because I felt had to.  Our neighbours lawn company had taken care of their lawn and my wife was, um, re-enforcing her desire to have me get the yard-work done.

Since I’m on ‘vacation’ I wasn’t particularly motivated to get it done, but obligation was calling so I caved even though I would have much rather done just about anything else.

It was hot, I was tired and not motivated and ended up doing a really crappy job.   I didn’t do the trimming or weeding and took shortcuts to get it done as quick as possible and as a result, I now have some yardwork-debt.   Oh, there’s a point…wait for it!I generally enjoy doing yard-work. There’s something about the accomplishment of getting it done and seeing a nicely manicured yard that feels pretty good.   Sometimes people walk by our place and I hear nice comments about how great the yard looks.  It may sound nuts, but it feels pretty good.

The shortcuts I took yesterday have made sure I have extra work to do next time.  The grass around the edges will be higher and will take longer to trim, there will be more weeds in the garden so it’ll take more time to pull them out.  Maybe that’s an extra 30 minutes or so next time around but the more serious effect is how bad I feel when I leave the house and see the half-assed job I did.

Who cares, it’s just the lawn right?

Wrong.

Obligation can yield the exact opposite results that it is designed to get.  I felt ‘obligated’ to do something I had to do, but didn’t want to do.  I had a choice.  Do it right or don’t do it.  I chose to do it wrong.  I chose to not communicate with my wife and tell her I knew I’d do a crappy job because I was hot and tired.  I chose to not defer the task until later in the day.

So how does this relate to Agile?  Well, I learned something.  I learned that next time I feel obligated to do this, I’ll take an extra 5 or 10 minutes before I start to clear my head and remember how crappy I felt after doing a half-assed job and then make my choice in a responsible way.

Responsibility and discipline are the magical ingredients for being successful with Agile.  All the process, metaphors and skills don’t matter if responsibility and discipline are missing from recipe.   When your team has improvements that come out of the retrospective, it takes responsibility and discipline to follow through with them.  They aren’t going to magically happen and your manager isn’t going to force you to do them.

Responsibility and discipline are the magical ingredients that make a difference between writing good code and crappy code.

Responsibility and disciplines are the magical ingredients that make a difference between building the right thing and building the thing we “have to” build.

What I personally find useful to be responsible and disciplined, is to simply take 30 seconds to re-boot my brain when faced with obligation.  I literally shut my eyes, take 3 deep breathes and say to myself:  ”what do you want to do?  You know ‘it has to get done’, take an extra couple of minutes and sort out your thoughts“.  While I’m doing the thing I chose to do (even when starting with feeling obligated to do it), I remind myself when feeling the need to take shortcuts: “Remember, you chose to do this.  Do it right.”

It’s quite possible I do that because I’m an introvert and I think mentally preparing yourself can go a long way towards doing the right thing, not the thing you feel obligated to do.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I had a great conversation with a colleague the other day about how “agile ain’t what it used to be” (fodder for another post)  and recently it seems like I spend a great deal of time either replying to people or having conversations about the proper use of “methodology or practice X“.

Technically I’m on vacation and since I don’t really consider what I do a ‘job‘ (read: I love what I do), I’ve been catching up on email, forums and other conversations on Linked In.

Is the Agile community sending the wrong message?  Do people just not get it? Why does it seem there is this overwhelming need for something to give the gold stamp?  Are Agile values and principles at odds with fundamentally how the humans behave?

Dramatic?  Maybe.

From metrics to methodology, what seems to get lost is doing the right thing or doing what’s necessary for a project/product to succeed.  Reflecting back on previous lives of being “in charge“  I don’t know how many times I’ve either talked out of my, ahem… or flat out asked the team what they think we need to do in order to be successful.  It hasn’t always worked of course but I’ve worked with some great folks who could take the data presented to them and do what they felt was the right thing at the time.

Stakeholders, project sponsors and customers really don’t give a shit if you’re using XP or Scrum or Waterfall or Shabadoo Methodology (that one is mine, TM pending…), they want results.  Whether the goal is project success, more money or whatever, however you get there doesn’t matter.  Chances are the next situation will be different so doing the same thing again probably won’t work.

This has been a source of confusion and frustration for me a few times with clients, but I think there comes a time when you work for a boss or organization that seems to get it.  Sometimes you find a boss or leader who is very much a catalyst, somebody with that “it” factor.  Somebody that knows the direction of organization whether is be selling off the company so we all get rich or somebody who understands the market and is trying to blow a vertical wide open.   I feel lucky enough having experienced this rare phenomenon  twice and whatever the goal was in those situations, it was loud and clear.

Strong leadership and a purpose seem to drive how we get results, not a process or methodology.   So what’s the point? Am I just rambling on or what?  The point is, the manifesto was created for a reason.  Use it as a guide, not the rule.  Sometimes you need less rules and process, sometimes you need the reverse.  At the end of the day, people are complex.  Teams are complex.  Throw them into another system (read: the organization) and the waters get even muddier.

That’s why I love what I do.  Each situation is unique, each challenge is different and I really dig that.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

This was a hot topic at one point, maybe I’m missing the boat. Lately I’ve seen a couple of posts on Linked In about Agile Maturity Models and I guess it does sound like a really fancy, neat thing however is it really necessary?

Let’s keep it simple.

Are you using the data made visible by adopting Agile to make better business decisions by accepting reality?

If so, congratulations. You’re mature.

If not, wake up.

Yeah, it really can be that simple…if you’re mature enough…

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

For those who are familiar with some of my other posts, I seem to follow a similar pattern when talking about Agile.  Based on using Agile as the tool to help implement the Rockefeller Habits when I was working at Q4, I’ve always thought that the focus and goal is always to help an organization be successful based on how that company defines success.

This was the focus for a session I proposed at Agile Coach Camp this weekend in Waterloo.  First off, I love Coach Camp!  The energy, openness and shared learning that happens is simply amazing.  It is truly inspiration for me to see how passionate everyone is about Agile and giving back to the community.

I had originally titled the session “Focus on Success over Focusing on ‘Being Agile’” and I was pleased with the open dialogue that came out and helped me sort out the thoughts in my mind around this topic.    I’ve mind-mapped and framed a mini-book based on a post I wrote last December that I feel very strongly can help bridge the gap or remove the disconnect between organizations that want to adopt Agile with the message being communicated from the Agile community.

While I am a firm believer in the Manifesto and the principles of Agile, I don’t think that message resonates as well with clients and organizations that want to adopt Agile as much as using Agile as a tool to reach a goal does.

The whitepaper I had hope to publish many months ago started evolving into this mini-book but not having written a book before I am struggling a little!  This is a great chance to eat my own dog-food and use Agile as the tool to accomplish my goal of writing this book.  Well, I think that is enough ramblings for now, you can view the summary of the session here!

Related posts:

1. Position Paper for Agile Coach Camp 2010 Agile Coach Camp 2010 is coming the weekend of...
2. The Agile Coach Manifesto The Agile Manifesto is the heart of soul of...

Related posts brought to you by Yet Another Related Posts Plugin.

The organization I’m currently working with is suffering from ‘we have no time’ disorder.  Demand is exceeding capability which is leaving little time for ‘non-contextual’ learning for the lack of a better phrase.

While one team has been making some great strides with root cause analysis, they have been struggling to turn those learnings into actions simply due to the volume of work that needs to get done.  In addition to ‘we have no time‘ disorder, they have also been diagnosed with ‘we have to‘ syndrome.  A dangerous combination of diseases indeed.

Enter Open Space.

Now that this particular team has gathered a bunch of data that narrows the focus of what parts of the application are causing the most problems, (amongst other organizational causes that are out of scope here), I’m planning on conducting an Open Space to gather the more subjective data as well.

So why an Open Space as opposed to a typical brainstorm session?

I see this as an opportunity to teach within context which will help the team with:

- self-organization skills (facilitation, time-boxes, collaboration)
- spreading domain and application knowledge amongst the team
- gaining perspective from multiple disciplines (QA/DEV/Business)
- giving everyone on the team the opportunity to speak up (team has some dominant personality issues)
- developing a framework for problem solving and brainstorming so they can be as effective as possible with future meetings
- having fun! get folks together and excited about their work!

These are the mechanics I’m planning on using, as I think some tweaking is necessary to get this to work in context:

1. Setup the open space concept: give team members a few days to digest how an open space works and why we are trying this approach.  This will be wrapped in the business goal for this session (gain consensus on the part of the application that will become the focus for this quarterly initiative.)
2. Open Space Intro: 10 minutes – re-state how an Open Space works and state the business goal of the session.
3. Lightning Talks: 30 minutes – each team member will be allocated 2 minutes to present what they want to talk about.  Ideally we will post this in the wiki ahead of time and I suspect folks will pair up.
4. The Twist!: 1 – 2 hours – Here’s where it gets risky.  Now it’s ideal for all team members to be part of each talk since there will be actual work derived from the output of this session.  Depending on the number of ’sessions’ that are created, as a team, we may agree to do “X” number of sessions and everyone will participate or we will vote on what 2 sessions to do.  I suspect based on the hard data gathered there will only be 2 – 3 major functional parts of the application chosen by the team.  The backup plan is to use the hard data in conjunction with voting, fist of five or other consensus techniques to decide what topic(s) to drill down on.  The sessions themselves will functional much like a typical brainstorming session.
5. Retrospective: 15 minutes.  For me to see how effective this was as a coach and for the team to see if there are techniques they can use going forward to have more effective meetings.

I’ll follow-up this post after the session has been held, but would love to hear your thoughts and suggestions!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.