Agile2014 Submission: Agile for Educators

  By Hala | January 15, 2014 - 2:09 pm | Agile, Agility, Scrum
4 Comments

Screen Shot 2014-01-15 at 12.24.50 PM

Agile2014 is only 6 months away!

 

That might seem like a long ways to go, but if you’re submitting a presentation or workshop for the conference, you know that last night was your last chance to propose a session. I know because I actually finally did it. It took some convincing and discussing with some good friends, and a generous agreement by Jimi Fosdick of Fearless Agility to co-present with me, but I did it!

 

The topic is one I’m really passionate about – agile in an educational setting. I had the privilege of presenting an Agile/Scrum training to a group of high school teachers in October and November of 2013, and the experience was life-changing. The teachers were all Technology teachers, meaning they taught classes like digital media, computer science, web development, networking, etc. The premise was that agile methodologies like Scrum could benefit them in two ways:

1) As a tool when planning and executing their curriculum for the year/semester

2) Providing an agile framework they could teach to their students to improve their challenges with project-based learning. I.e., the students could apply it to the projects they work on for their classes, since they worked in groups/teams

The teachers were amazing. They were engaged, interested, and willing to experiment. I can’t wait to share details of the experiment with others and continue to improve and expand upon the effort.

 

Jimi, on the other hand, has worked with educational technology for 5 years, and has also been working with education professionals and scholars on finding ways to apply agility (specifically Scrum) in an educational context. His work in this field is a critical part of this presentation – taking it from the what-if to the here’s-how-it-can-be-done.

 

Now comes the waiting game part. There are some amazing speakers, presenters, and topics that have been submitted for this year’s conference, so no matter what happens, I can’t wait to attend the conference in Orlando and continue to learn, grow, and connect with friends (old and new) along this journey of agility!

Cross your fingers for me!

Here’s our submission:

Agile for Educators

Presenter: Hala Saleh Co-Presenter: Jimi Fosdick
Track: Research Session Type: Talk Audience Level: Practicing
Room Setup: No Preference Duration: 75 minutes
Keywords: Agile, scrum, students, education, teachers, curriculum
Abstract:

This session is a real-world, where-do-we-go-from-here exploration of applying agile concepts and frameworks in the classroom.

This presentation will cover two main aspects of agile in Education:
1) Applying agile concepts (specifically Scrum) for the planning and execution of educational curriculums and teaching plans
2) Teaching educators about agile frameworks (specifically Scrum) and how to apply them in their classrooms for student projects

Hala has hands-on experience with delivering Scrum training to high school teachers and working with them to investigate and coach them on the uses of Scrum with their classrooms. She is excited about the application of Scrum in a non-software context and wants to spread the Agile Manifesto for Education.

Jimi worked in educational technology for 5 years and learned more about education and educators than any non-teacher should ever know. He was been working with his sister (a program director for a school for special needs children) and his uncle (a professor at San Jose State University) in finding ways to apply agility, specifically Scrum, in educational contexts. This presentation represents a theoretical overview of his discoveries and, more importantly, why agility can and should be used outside of software.

Information for Review Team:

The session will be split where 1/2 of the time will be spent covering research and work that has been done to figure out how agile concepts (specifically Scrum) can be used for the planning and execution of educational curriculums and teaching plans.
The second 1/2 of the class will cover a real-life scenario where Scrum was taught to a group of high school teachers, and they were given the assignment to use the framework with their own students. This will conclude with an exploration of the outcomes as reported by the teachers, and a review of artifacts shared by the teachers.

Prerequisite Knowledge:

A working knowledge of agile concepts and main methodologies is encouraged. The session covers Scrum, so a knowledge of Scrum is helpful.

Learning Outcomes:

  • Part I:
  • Describe the basic principles of primary, secondary and post secondary educational development projects
  • Describe the applicability of agility in an education context
  • Build a basic curriculum skeleton using an agile approach
  • Part II:
  • Experience Report of delivering Scrum training to high school teachers
  • Overview of materials presented to teachers and most effective use of time when training
  • Overview of format & outcomes of presentation
  • Review of teacher feedback and results of check-ins with teachers on student progress and project results
Presentation History:

Hala Saleh has presented at local PMI Chapters, as well as co-presented with Jimi Fosdick (Co-presenter) at Agile 2012.
Jimi has presented at most Scrum Gathering and Agile conferences in the past 5 years.

http://bit.ly/L5tOI8

Agile 2013, Acknowledgement, and The Reason We Do This

  By Hala | August 16, 2013 - 11:40 am | Agile, Agility, Community, Leadership, Paradigm, People, Process
Leave a comment

Yes, I am getting on the wagon and writing my Agile 2013 blog post.

Was it awesome? Yes. Were the sessions amazing? Yes. Did I meet people who totally rock? Totally. Yes.

Case-in-point: Esther Derby, Linda Rising, and Hacker Chick (Abby Fichtner). Three amazing women who I’ve read of and from, and thought to myself in all cases “She’s amazing. I need to be more like that.”

 

esther_linda

hackerchick

 

 

 

 

 

 

 

 

 

 

 

 

Before I go into all of the conference-y related stuff, I want to acknowledge a group of people who were critical to having the whole conference (with over 1700 attendees) run smoothly. A big part of these conferences is making sure people are fed and caffeinated properly. (Mostly the caffeinated part.) The staff at the Gaylord Opryland did a great job, and I can’t imagine the chaos that would have ensued without their hard work.

 

As I walked around during break times, I noticed that a large portion of the staff were speaking in Arabic – specifically, an Egyptian dialect of Arabic. I was thrilled that I could understand and engage in conversation with them. We joked, we laughed, and we lamented the sad state that Egypt is finding herself in these days.

 

As things these days seem to get progressively more violent, my thoughts remain with the staff and their loved ones, and the country many still call “Mother of the World”.

 

 

Back to the conference.

There is so much to say, and a lot of people have said the things that I probably couldn’t say better myself. I do have a little story to tell, though.

 

On the second night of the conference, I was invited to an agile training and coaching company’s customer appreciation party. At the party, I decided to sit down at a table with a gentleman who was sitting alone. We started with small talk, but quickly progressed to talking about what we do. Within 20 minutes of chatting, I was converted from being a casual chatting acquaintance to becoming a raving fan of Mr. Reynolds.

 

There are many of us in the agile community who talk about agile values for breakfast, lunch, and dinner. There are many of us who work hard to spread the word of “better ways to develop software/products.” There are many of us who make it our life’s work to know and maybe even improve upon the different methodologies, their pros and cons,  and ways to make teams really effective at what they do.

 

In contrast, Mr. Reynolds is simply Doing It. He is one of those people for whom agile values and principles just seem to flow effortlessly, without the burden of over-thinking, over-engineering, or over-reaching. By embodying the essence of People over Process and Individuals and Interactions, he is incrementally and iteratively affecting change, both at an executive and a team level, and very clearly takes immense pride in his work.

 

It was so refreshing to talk to someone whose eyes shone with the pride and joy of finding and implementing better ways of doing things in a way that is his own.

 

THIS is why we do what we do.

Isn’t it? Isn’t it all about finding better ways of <<developing software, developing products, growing sustainable organizations, innovating, growing people>>, in ways that work with our teams’ and organizations’ needs? Call it agile, call it lean, call it the purple elephant with the striped trunk. To me it’s all about how we do things better, and become better ourselves in the process.

 

When I made a statement about this on Twitter while at the conference, I was met with some comments about how this is a naive view of the agile manifesto. Maybe it is, and maybe I’m wrong.

 

Regardless, I won’t stop going down the path I have chosen, which is one of searching for ways to achieve continuous improvement, effectiveness, and helping people and organizations be the best that they can be.

Retrospectives – A Love Story

  By Hala | August 13, 2013 - 12:32 am | Agile, Agility, People, Process
Leave a comment
Do More Retrospectives

Today, I experienced one of the most heart-warming affirmations of the power of retrospectives.

Let me explain.

I am working with a great team who is ready to move forward from their proof-of-concept phase to their lets-do-this-thing growth phase. As part of figuring out the company’s strategy for world domination, I was asked to facilitate a whole-team, 3-day onsite.

Today was the first of the 3 days of analysis, brainstorming, and planning. As part of the lead-up towards product visioning and story mapping (utilizing Jeff Patton’s Story Mapping exercise),  I decided I would walk the whole team through a company retrospective. I chose to use the Starfish Retrospective model, which splits a circle into 5 parts that correspond to:

1) Start Doing
2) Stop Doing
3) Keep Doing
4) Do More of
5) Do Less of


My goals from the retrospective were many, including:

1) Personal (Selfish): Getting up-to-speed on the company/team’s historical journey to where they’re at today

2) Cultural: Establishing the retrospective as a safe place for discussion where everyone’s voice is heard, regardless of their title or role

3) Collaborative: Establishing a common ground as a starting point for planning and envisioning the product direction

 

I have only been working with this team for a short amount of time, so I honestly had no idea of what to expect from the retrospective in terms of participation, openness in communication, and patience with the process.

 

What happened blew me away.

 

I started by passing out stacks of stickies, and starting with the “Keep Doing” section, gave everyone about 5 minutes to come up with as many stickies as they could. Once that was done, we took each of the rest of the sections until we got through them all.

Retrospective

 

The team spent close to 2 hours retrospecting. We went through each of the sections, shown in the picture, and had some of the most meaningful discussion I’ve witnessed a team ever having.

The discussion was open, respectful, and provided some amazing insight into the evolution of the company.

 

 

 

One of my favorite moments happened when I saw this:

 

Do More Retrospectives
Under “Do More Of”, someone had written “these”. As in, do more retrospectives like this one.

I was peeking at the board as people were discussing a different point, and got caught totally off-guard. I couldn’t help but break into a big, goofy smile. When it came time to talk about “Do More of… these”, someone blurted out “Yeah, this is awesome!”.
“Totally!” was the response echoed around the room.
As we continued on through the rest of the exercise, we were able to maintain a high level of participation and enthusiasm.

 

I encourage you to give the Starfish Retrospective a try – you will inevitably gain some great insights and guidance, whether it’s at a project or company level.

Most importantly, make sure everyone on the team has a voice and is able to express their opinion in a way that is comfortable to them.

 

 

Ask Questions, Get Answers (And check out the link at the end!)

  By Hala | August 2, 2013 - 1:50 pm | Agile, Agility, People, Project Management, Scrum
Leave a comment

This week, I have been contemplating the power of asking questions.

 

So much goes unsaid in projects, and within project teams. Assumptions are made about requested features, technical approaches, architecture, data policies, and even communications.

How many times has your internal dialog gone something like this:

“Someone else probably knows what she means by that.”

“He’ll probably send out an email to the stakeholders about that.”

“That means I need to write a script to handle that.”

“Selection tool? That means I need to implement a radio button menu.”

 

How many times has that internal dialog been wrong, and you find that out the hard way, after your assumptions take you down the wrong path?

How many times could the above situation been solved if you had asked the right questions up front? How much more information and insight could you have gained by probing deeper, by expressing your concerns, by asking Why?

 

I’ve always been one to ask a lot of questions, and have never shied away from it. But I still fall prey to the assumption-making sometimes.

 

Today I invite you to join me in making a conscious effort to ask more questions. Don’t make assumptions. Ask, and you might be surprised at what you learn.

 

In the spirit of asking questions, I was just asked a bunch of them as part of an interview for TeamPulse, which is a company that develops an “all-in-one” project management software tool. (Check them out!)

I have to say, it was so humbling, exciting, educational, and awesome to be asked to contribute to TeamPulse’s website.

It was the perfect reminder of the importance of asking questions, since it sometimes takes getting asked a question to reflect on some things that you just assumed you knew about yourself!

Check out the interview, and let me know what you think!

 

And of course, please ask me any questions you might have – practice what I preach! ;)

Agile/Lean Thinking for Kids – Grasshoppers and Small Batches

  By Hala | July 10, 2013 - 5:01 pm | Agile, Agility, Lean, Process
Leave a comment

The latest trend in bedtime stories at our house has consisted of me trying to find ways to impart an agile/lean mindset onto my 6-year-old, while wrapping it up in an entertaining package.

Note: This is not an easy task to accomplish with a 2-year-old squirming in my lap, and with potty humor being The Most Important Thing Ever at this phase of my 6-year-old’s life. (Something tells me this phase is going to last for a LONG time.)

 

Last week, as I myself was contemplating how to stay true to the “Small Batches” concept on a project, I decided to make small batches the theme of that night’s bedtime story.

 

(To those of you who are intimately familiar with the life cycle of a grasshopper, please ignore any inaccuracies – I pretty much came up with the story on the fly, without doing any research and/or pre-architecture. Which, if you consider that the point got across to my son regardless, could be an interesting argument against Iteration Zero, don’t you think?! Alas, I digress!)

Read on for details of the grasshopper story (and for a few modern-day insect surprises!). Telling this story was so much fun for me, and my son was engaged the whole time (eyes wide open, little body leaning in to listen), and he and I talked afterwards about other things we could think about doing in small batches. Geek on!

 

The Agile/Lean Grasshopper:

Once upon a time, there was a hoppitty-hop-hop grasshopper who was getting ready for a long, cold winter. To make sure he didn’t starve (because that would make him REALLY cranky), the grasshopper had to put together a packet of food for each day of winter. Each packet needed to have 1 piece of grass, 1 piece of wheat, and 1 piece of corn in it to keep the grasshopper happy (and to keep his family and friends safe from his crankiness! Ahem.)

 

Now in the place where this grasshopper lived, winter lasted for 90 days, and the grasshopper had to make sure he had enough food for the whole winter. Because this grasshopper was super-smart, he decided to plan for having enough food for 10 extra days, just in case winter decided to hang around for a little bit longer than usual, or in case he wanted to just be a little lazy for a few days after winter ended. So, the grasshopper started figuring out what he needed to do to get 100 packets of food ready.

The next day, the grasshopper started his work! First, he went out and picked 100 pieces of grass, then picked 100 pieces of wheat, and although he still needed to pick 100 pieces of corn, he decided he needed to stop and take a break.

By the end of that day, the grasshopper was POOPED! <<Insert big sigh/sound of exhaustion>>.
He was also SUPER-bored of picking stuff. So he decided to take a break before picking the 100 pieces of corn.

For his break, the grasshopper surfed the web and checked out his friends’ Insectbook updates. Insectbook was HILARIOUS, and he couldn’t believe what he found on there – something called LOLants which he just couldn’t stop looking at.

He got so sucked in that he spent half of the next day on Insectbook before he realized what time it was.

The grasshopper scrambled, and was barely able to get the 100 pieces of corn picked before dark. Phew! He got it done, but kind of felt bad about wasting time on Insectbook earlier.

 

The next day, the grasshopper decided he needed to start putting the packets of food together.

Hmm.. He thought and thought, and decided that the best way to do this was to line up 100 little sacks, then go across and put a piece of grass in each of the 100 sacks, then a piece of wheat in each of the 100 sacks, and finally he would put a piece of corn in each of the 100 sacks. At the end, each of the 100 sacks would contain 1 piece of grass, 1 piece of wheat, and 1 piece of corn, and he would be done!

 

And so the grasshopper started to work.

 

The grasshopper worked hard, and only checked Insectbook 3 times until he was done. A few days later, he finally finished making all of the 100 sacks of food, and he was so happy he decided to celebrate by eating one of them!

 

The grasshopper carefully chose one of the food packets, and sat down to eat it. He started with a piece of grass, which was absolutely delicious. Next was his favorite, a piece of yummy wheat. He closed his eyes and put it in his mouth, waiting for the smooth wheaty taste. Suddenly, the grasshopper’s eyes flew open, and he started going “PUTHUP, PUTHUP, PUTHUP”, spitting everywhere, and trying to wipe off his tongue! The wheat was bad, and it tasted absolutely DISGUSTING!

The grasshopper started to freak out, worrying that all of the wheat was bad! He decided to try another packet, and told himself it was probably just that one packet that was ruined. So he pulled out another packet, opened it, closed his eyes, and put the wheat into his mouth.

“PUTHUP, PUTHUP, PUTHUP”! Oh no, this one was bad too!

“PUTHUP, PUTHUP, PUTHUP”! So was the next one!

The grasshopper went crazy, opening up one packet at a time, trying the wheat, and in every packet he tried, the wheat was spoiled and tasted absolutely horrible! He also noticed that the spoiled wheat pieces all had little black spots on them, which he didn’t notice before.

 

Finally the grasshopper flopped down in the pile of opened food packets, and all he could do was cry. He was so sad – he had worked so hard on those 100 packets of food!!

After crying for a few minutes, he wiped his tears off, and decided he needed to find a better way. He thought and thought, and came up with the best idea he’d ever had.

 

The grasshopper decided that instead of making the packets the way he made them before, he was going to make them one packet at a time, and he was going to inspect each piece before putting it in the packet. He felt good about this decision, and went to bed feeling optimistic.

 

The next day, the grasshopper started working. This time, for each sack, he put in 1 piece of grass, 1 piece of wheat, and 1 piece of corn. Before putting each piece in the sack, he checked how it looked, and pulled off a tiny piece to taste. As he was going, he found a few pieces that were spoiled, but was quickly and easily able to replace them with pieces that were good.

A couple days later, the grasshopper was done. He had 100 packets of food, and he KNEW that each packet was good, and was ready to be stored.

The grasshopper didn’t even need to try any of the packets to make double-sure that they were ok, and as a bonus, his belly was already full because of all the little pieces he tried when he was making his packets.

 

That winter, the grasshopper met some other grasshoppers who didn’t check their packets the same way he did, and who were hungry because they ran out of food. Since he had some extra, he shared, and told them how he made his food packets.

After listening to his story, the now-not-so-hungry grasshoppers decided that he was so smart he should be their leader, and they made him Grasshopper President!

 

I call that a Super-Smart Agile/Lean Grasshopper. Don’t you?

Want Results? Get Uncomfortable

  By Hala | May 11, 2013 - 10:39 pm | Agility, Leadership, People, Project Management, Scrum
9 Comments

It’s May.
We’re almost done with half the year, and I haven’t stuck with my publicly declared commitment to be more regular with my writing.
This is not an apology, though.
It’s a declaration of peace, made from me to me, and maybe it’s even a bit of a pat on the back.
Why pat on the back, you ask? Because this year I’ve had to adapt to what has been the equivalent of getting on one of those roller coasters at an amusement park that you’ve never been on before but you get on anyway assuming you’ll be FINE because how different can it be from all of the other roller coaster rides you’ve been on before in your life?
Then the roller coaster flips you upside-down as you head backwards down a spiraling track and you realize: this is NOTHING like ANYTHING you’ve ever been on before.

So, how are you all?
Some of you I’ve been connecting with on Twitter via the #PMChat,  #pmot, #agile or #scrum hashtags. Others of you I’ve been connecting with in person or through email, and some of you have probably been on your own roller coaster rides.

There’s been an underlying theme to this year that I’ve wanted to share with you all time and time again, and it’s one that I really truly want you all to take to heart:

In order to see results, you MUST get uncomfortable.

Whether you are looking to see a change in your career, get on a new growth path within your current career, or even see a physical change in yourself, you must get uncomfortable to see the results you want.

By “get uncomfortable”, I don’t just mean “step outside your comfort zone”. What I’m talking about can’t be wrapped neatly into 5 words and presented as though it were an exercise in pacing yourself and moving forward one step at a time.

I’m talking about flinging yourself straight out of your boundaries and limits and landing squarely in the middle of something that may freak you out so enormously that you feel like you have no way of ever regaining your footing and standing up again.
I’m talking about consciously removing yourself from what you know and placing yourself in situations that give you that sinking feeling in your stomach when you look up and realize you’ve never seen a mountain that huge before, and have no physical proof you can find your way up.

Except you will. Because your determination and abilities are greater than you ever knew they were, and when you take the first few steps up, realize you can keep going, then end up traveling a few miles towards your end goal, you will wake up one day feeling ridiculously sore but ridiculously giddy to get back at it and keep going.

This year I have found myself getting into situations that I feared I would not know how to navigate. It seemed to all come together and manifest in different areas:

Physically, I decided my routine had become stale and failed to provide me with real results or any kind of real difference or challenge. I started a crazy military-style bootcamp program that I initially planned on doing only for a few weeks.
For every day of the first week, I had to wear a 30 pound vest while doing all the same exercises the rest of the class was doing. By the third day I was shocked that I hadn’t yet hurled my guts out as I hurled out every curse word I knew (in multiple languages). My body was in some kind of shock, and I had never felt so worried that I would just fail; that I would just not be able to make it through the hour without quitting.
But I came back for the next 3 months, and got into the best shape of my life. (I recently stopped going to bootcamp because it was time for me to fly away and leave the security of the nest, and figure out how to stay challenged and fit on my own.)

Career-wise, I moved from the security of being a traditional full-time employee of a company, where there was a clear career path, a pretty stable (for the most part) cast and crew, and a known subject matter to being a consultant. I suddenly had to define who I was, who I wanted to be, and then figure out how to take control of how far and where I was going to go. It’s no secret that I am passionate about Agile Product Development and about helping organizations learn how to be effective and produce results using agile methodologies.

I decided when I made this move that I was going to be true to my beliefs in this role – which ultimately means not being a Yes woman, and (maybe frequently) delivering messages that a client might not want to hear. As a consultant, that comes with a higher risk of being told to leave the client’s offices and never come back because, well, there are no strings attached. They have no obligation to keep me around. That scared me. I’ve stumbled a few times and realize I will again, but when things go well, it makes up for the stumbling in such a big way.

I recently traveled and spent an intensive week at a client site to help them with some issues they are having as part of their adoption of agile methodologies on one of the largest projects (really a program) they have ever undertaken. These issues are normal and natural as an organization attempts to change the way they work and view things in such a big way, especially when combined with the fear of “Will We Ever Get There?”

One week is not a lot of time. I had so many questions and a growing anxiety about whether I would be able to do a good job, provide REAL value, and really HELP them achieve their goals. I kept having flashbacks to the image (and queasiness) of trying not to puke my guts out while doing burpees with a 30 pound vest on. I also woke up at 4:30 a.m. for an entire week.

But it got done. And some of what we did together while I was there was extraordinary, mostly in that I saw a team coming together with renewed hope and best of all, I saw the question changing from “Will We Ever Get There?” to “We Believe We Will Get There – So What’s The Best Way To Build This Together?”

There’s still work left to do, but that first week is over. Now I can take off the 30 pound vest and keep going.

My next goal: Getting myself into my bed and sleeping past 4:30 a.m. (Hey, not all goals have to be difficult to achieve!)

Putting a Face to a Name – Personas for Better User Stories

  By Hala | January 8, 2013 - 12:36 am | Agility, Process, Project Management, Scrum
1 Comment

A number of years ago, I worked in an organization that developed and released highly successful consumer products. I was (and still am) convinced that a part of that success can be attributed to this organization’s thorough (can we say OCD?!) analysis and definition of their target end-user.

 

People, when I say thorough, I mean thorough. Like me scrubbing those little edges between the kitchen counter and the stove with a toothbrush and a flashlight THOROUGH. (Hey, no judgement!)

 

For EACH variation of EACH product released out into the market, there was an elaborate definition of the target user (i.e. Persona) which included their age, marital status, family size, interests, and yes, their name.

 

I have to admit, at the time, I couldn’t help but think that this was overkill. Come on, did I really need to know that Supermom Sally had 3 (vs. 2? vs. 4?) kids and loved scrapbooking?

(I did love finding out that she multitasked like a pro and kept everything under control while maintaining a cool exterior and perfect hair. My kinda woman.)

 

So, although I did find value in understanding the different types of end-user in a general sense, it was a stretch for me to buy into the idea of needing to know their life story in order to make product and feature-level decisions.

 

Fast-forward to today, where requirements are now user stories, and the user is the center of my project world. Our success hinges on either (at a minimum) or both (ideally) of the following:

  • Our ability to get into the head of our target user and understand their needs, even those they might not know they have. (By the same token, we need to be able to detemine when something that the user might think is a need is actually, well, not.)
  • Our ability to listen to our target user when we have the opportunity to get their input and feedback throughout the life of the project.

 

Guess what I’ve found to be a great tool in achieving the above?

 

A well-defined, clearly articulated persona definition for the end-user.

 

Now, does that mean we need to determine how many kids Techy Tim has in order to be able to figure out whether he needs a drop-down or a checkbox?
Probably not in all cases, but in retrospect, for the industry I was in years ago when I was first exposed to elaborate persona-creation, it was probably a good idea.

 

Moral of the story: There is power in putting a face to a name. For better user stories, spend a little time to get to know your target end-user and create personas that your team can refer back to.

They will both (the end-user and team) appreciate you for it, and the proof will be in the success of your project/product.

Extra! Extra! Agile Headline Exercise Gets the Ball Rolling

  By Hala | January 2, 2013 - 9:00 am | Agility, People, Project Management, Scrum
6 Comments

A few weeks ago, I had the pleasure of facilitating two days of product/release planning combined with  user story gathering (although I like to call it user story “exploration” since that’s what it felt like.)

I wanted to start things off with a product visioning exercise/ice-breaker to get things going and to warm people up.
Although we gave people a couple of options for the product visioning activity, everyone ended up choosing the “Headline News” exercise, which I learned at Agile 2012 from Jimi Fosdick, Agile Rockstar.

(Note: Jimi does not call himself that, but he should. So there.)

 

The Headline News Exercise

In case you aren’t familiar with the “Headline News” exercise, here’s the gist of it:

  • Have people self-organize into groups of 3 or 4 people. If people are reluctant to get this process started, encourage them to walk over to the complete other end of the room and find 2 or 3 other people to work with.
    Get people out of their comfort zone!
  • Give the groups about 10 minutes to work together on the following:
    • Envision the project/product after it has succeeded and been released to the world
    • Imagine your project/product has made the front page of the news/relevant industry publication
    • What would the headline say? Include words/phrases that describe how your project/product has changed the marketplace/made a difference/is different than everyone else out there. Think especially about how your end-user is impacted by your project/product
  • At the end of 10 minutes, (or when you sense/hear the activity level start to die down), ask each group in turn to select a representative to read out the headline and provide an explanation of why certain words/phrases were used.

(Note: You could also do a variation of this exercise where people create a short script for a feature story for the evening news. At the end of the exercise, you have them read their script aloud.)

Within minutes of getting this exercise started, the room went from a group of 30+ people who weren’t sure exactly what they were there for, with a slightly glazed-over look in their eyes, to a buzzing beehive of activity and noise.

Music to my ears.

I literally had to stop myself from jumping into the middle of each of the groups and going “YOU GUYS ARE AWESOME! ISN’T THIS FUN?!”

 

The Headline News Exercise Bears Fruit

At the end of the Headline News exercise (which took only a few minutes), we had a basket filled with the following fruits, giving us a great head-start to the rest of our 2-day session:

1) Energized and engaged stakeholders
2) Key words and phrases that would help build the project’s success criteria
3) An objective description of the project/product’s end-goal and most important features
4) A subjective look at what would make the stakeholders/team feel proud of the end-product
5) A vision for how the project/product was supposed to impact the end-user

 

What Next?

Once we had established the product/project vision, we started down the path of getting to know the end-user better. For what better way to start to write stories for the user than to get to know that user on a personal level?

But that’s a story for another time.

 

If you are in a position to help kick off a project or product planning session, give the Headline News exercise a try. Don’t underestimate the power of allowing people to collaborate on finding the language to express their collective vision.

How to Break the Rules

  By Hala | January 1, 2013 - 5:17 pm | Business Success, Community, General, Leadership, Paradigm, People
2 Comments

“To break the rules, you first have to master them.”

This sentence caught my eye the other day as I was reading something, and my brain has been going back to it constantly ever since.

This is especially poignant for those of us who are spending this day reflecting on the past year, and pondering the ways in which we want to make the coming year different.
How WE want to be different.
How we want to make a change, create waves, and make the world a better place.

This year, as you embark upon your journey of thinking outside the box and creating your own rules, make sure you first invest time and effort into mastering the existing ones. Know your way around them, and know their advantages as well as shortcomings.

Happy New Year. Let’s make it an amazing one!

Resilience: The Art of Bouncing Back

  By Hala | August 4, 2012 - 4:30 pm | General, Leadership, People, Project Management
Leave a comment

As I sit in front of my TV, mesmerized by the magic of Olympian athleticism, I can’t help but think about what it took for those athletes to get where they are today.

Years of training, learning, injuries, winning, and, perhaps most importantly (yet also most undervalued), failing.
Soul-crushing, devastating, painful failures that can break a person’s resolve and lead to giving up on one’s dream.

 

The difference between being average and being someone who succeeds at achieving their goals (and perhaps even makes it to the Olympics!) is what comes after failure.


Instead of giving up, elite athletes find a way to pick themselves up, brush themselves off, and give it their best shot all over again.

 

All of us have the ability to be elite in our jobs/fields. Becoming one of the best at what we do comes from possessing passion, a deep desire to succeed and serve others with our work, and the ability to bounce back even after looking failure straight in the eye.

 

In life and in managing projects, it’s how you deal with failures that can define your success the next time around.

 

The next time you hit a snag in the road, whether in life or in one of your projects, try following these steps to come back even stronger:

1- Acceptance:

Accept that you may have failed, or been part of a failure. Especially if you are used to winning, or always being on top, acceptance can be difficult. Your first reaction may be to fight, deny, or even project failure onto others.

When faced with failure (whether in the form of a project that’s gone completely off-track, critical feedback on your work performance, or in a personal relationship), take a step back and try to separate yourself from the event.
Rather than beat yourself up, wallow in the misery of failure, and get stuck, remember that you are not the failure you are facing.

Accept that there may be some validity and reason to what is happening; perhaps you didn’t pay as much attention to a certain phase of planning your project, perhaps you were so focused on the details that you lost sight of the big picture, perhaps you were just insensitive to someone’s needs.

Accepting failure takes courage, grace, and humility.
Congratulate yourself on making it through the hardest part of bouncing back!

 

2- Analysis:

After accepting the failure, do some (but not too much) analysis on what went wrong. Was it an oversight that you can pay more attention to in the future? Was it a behavior that you weren’t even aware had an impact on others? Was it simply lack of skill in a certain area?

One of my favorite terms in life and in project management is “root cause”. There won’t always be one root cause that you can pinpoint (how awesome would that be?), but it’s always a great educational exercise to work through the layers as you try to find one.

 

3- Damage Control:

Figure out how you are going to right your wrong. It’s that simple. What steps can you take to immediately make things better?

Can you identify someone you really should apologize to? Can you send an email to your project team showing how thoughtful you’ve been in accepting what went wrong and figuring out why it happened? Then do it.

Demonstrating your ability to handle defeat with maturity and a forward-thinking mentality will make you stand out from others, give you credibility, and perhaps even provide you with a second chance.

 

4- Remediation:

Now that you have it, take that second chance by the horns and OWN IT! You’ve done the hard work of accepting and analyzing the failure, now determine what steps you need to take to ensure you don’t make the same mistake all over again.

What things have you learned from this failure that you can apply moving forward? Once you’ve determined the steps you need to take to move from failure to success, write them down and solicit feedback if possible!

For example, if your failure involved someone else or even an entire team, choose someone who was impacted and who you trust, and run your plan by them. They may have some ideas on how to improve your outcome the next time around that you didn’t think of. At a minimum, they will have a greater appreciation for you and your approach.

 

If you want to end up in the winners’ circle, remember this:

Failures should not define us as people, but if we are deliberate, we can ensure that our failures help us become more resilient, and ultimately, define our path to success.