Right now, I am sitting in my loft apartment, trying to work. I write "trying" because on the roof above me is a jack hammer (and operator) removing the roof. I'm excited that the building I live in is going to get a 14,000 sq ft roof deck that I will definitely be using next year; however, I'm not happy about this noise or how I can't use the rooftop pool. My tan is seriously fading.

But I doubt you really care about this faded tan…so what's my point?

Under construction = inconvenience

And inconvenience can vary.

However, when you think about it, everything in life is under-construction and nothing is "final." Roads are always being repaired. People are always doing home improvements – or self-improvements, practicing more patience, understanding, or acceptance.

Even Web sites, apps and customer experiences are always under construction.

Talk to anyone working at some dot-com, app or in a corporate Web team and they are always working on the next release. No one can see the "construction" (development) team, but back at their offices on a staging environment, there are a number of updates and enhancements being tested by team members, busy making sure things work.  

Or else, people are launching new features as a "test." There may be 2, 3 or more versions of a page or workflow out there that users are actively using to give active feedback. Version testing can make users comparing their experience go mad – how can a site have 2 looks? But it is a great way to see which approach is best for an audience.

It's under construction. Workflow. Page design. Color palette. Word choices.

Call centers are also always under construction. Someone may redo the IVR to optimize call routing, or a script may get updated to resolve caller issues faster. New processes are always being tweaked and adjusted based on metrics and performance. 

But should under construction mean inconvenience if everything is always changing? Shouldn't we expect a good experience – or at least a notification of the inconvenience – so it can be avoided? Imagine if Web changes were happening on the fly, all the time, all day long. And I'm not talking about refreshed news articles – how about navigation updates by the second? Or let's say a purchase flow on an e-commerce site that breaks when you purchase because they keep fiddling with it?

We are inconvenienced with construction updates because that is "expected." It's ok to have weird, ill-labelled detours. It's ok for dirt and dusty to fly around. It's ok for these equipment items to be noisy. What if we were in a world where construction was quiet and it didn't make noise? What if a building went up quietly without a lot of fuss? Just something to think about…

What if we didn't expect anything under construction to be an inconvenience anymore?

What are your thoughts?

Agile Methodologies have revolutionized application development AND influenced how business operates today. 

Day-to-day marketing, product management, finance and other activities can be overwhelming because there are so many competing priorities. The introduction of Agile principles such as prioritization, iterations, and sprints (moving planning to be quarter-to-quarter rather than an inflexible year-to-year) has helped businesses choose which opportunities to pursue and nimbly respond to market shifts and changes. Adopting Agile approaches has been a game changer for businesses worldwide.

However, there is little guidance in the Agile methodology for helping the business gain a clear vision and goals for a proposed product or project.

Iteration 1 typically starts with setting up the dev environment and writing infrastructure/core functionality stories, but if the business hasn't figured out what they want to do or what they need – nevermind what the priorities are – how can they get to Iteration 1 and write a story?

New projects aren't "born" neatly scoped with a clear strategy, goals and ROI. From my experience, new projects come from 4 places:

• Most common: An executive tells the team that there is a market need for a new site or app and the team needs to figure it out. Often, that's all the direction the team is given – they really do need to figure out what the project/product should be.
  

• The team or a team member realizes that there is a market need for a new product – and this needs to be defined further. The project needs to be sold internally, so the vision is developed during the buy-in process with the larger organization and other teams. 

• Organic creation – the team realized that the super-product should be broken into two (or more) parts. Sometimes, a product gets so big, it just makes sense to split it up. But where does that split happen? That often needs to be defined and scoping typically happens during the buy-in process with the larger organization and other teams. 

• Start-up case: A visionary has an idea, knows the market really well and knows what needs to happen next. This is the dream case for Agile – the project can kick-off right away. However, a lot of behind-the-scenes activities happens for the visionary to know his market and what they need. He has done his research and has a lot of data to support what needs to happen. 

Scoping a project and defining its goals is a unique activity that can take a month or two. However, it's not a project with tangible results; it is a project that results in an organizationally accepted PowerPoint presentation, site maps/wireframes/sketches, a few projection spreadsheets, and defined target metrics. 

To get to that vision, the business team often needs to get into the details and create a vision for what they want to do. Sure, we should be thinking about what we want to do as we go along in Agile ideology, but if the business team doesn't have a focus for what they want to do – the project will fail.

I have seen this happen too often. Technology decisions rather than business strategy starts to define the project if the business leaders don't have a strong vision. The business leads need to be focused on what they want this product to achieve.  

And what needs to exist for the business strategy and vision? A set of goals and ROI isn't enough. The business needs to:

• Understand the market
• Know who the customers will be and understand the market
• Be able to quickly identify the competitors (and speak to their strengths and weaknesses)
• Know what issues the product will solve (or does solve)
• List the core functionality this product needs to have at launch – understand the nice-to-haves vs must-haves
• Understand the general technical challenges to build the product – specifics happen during the process. But to make some initial scope decisions, the business team needs to be informed.
• Have metric targets and goals to prove the product is a success – and have a general idea of what will happen if those goals aren't met.

Often, user or customer experience will invited to the discussion to be sure that user/customer needs are addressed. The development team will be invited so the business team can better understand scope and costs and the technical barriers to entry. It takes a team to scope a project. 

Often there are sketches of what this project could be. This helps the business team have a visual to better understand what they want. By the time a story is written, there were a number of sketches that the business team created with user experience to develop their plan. Their process to get to a vision is iterative.

Some may call this getting into the details; I call this research to understand what you want to get. It's like building a house. 

How do you figure out what you want in a house?

• Visit a lot of houses
• Create a list of what you want in it
• Make sketches
• Talk to architects and designers
• Talk to builders
• Make more sketches
• Figure out how you want to feel in your house

You don't build a house as you go along with zero vision to guide it (or you can, but you may end up with a weird house!). The business needs to do a little research to understand what they want to "live in" before they start building anything. 

I'll be talking about this more at Agile 2014 in my session: Go From a Nebulous Vision to Iteration One in 3 Steps. Hope to see you! 

Feel free to contribute to the conversation about scoping Agile projects. I look forward to hearing from you.

“Our greatest glory is not in never falling, but in rising every time we fall.”
–Confucius

I decided to return to my series – how improv belly dance is a lot like Agile. I know, it's a weird comparison; however, both have something in common – how do you respond to a sudden, unplanned change? That is the nature of Improv! And Agile is a framework that addresses this too.

Here are some past articles that make the connection:

• Improv and Agile Part 1: Being Prepared
• Improv and Agile Part 2: Teamwork makes the experience
• Improv and Agile Part 3: Limits

Whenever I perform improv I'm experimenting, even if I'm dancing to a song I know really well. There is always some nuance about the performance:

• The musician switches up the song to include something I have never heard before
• The floor has something on it that it didn't have a couple of days ago
• The audience is different, sending out a different vibe – some may not want to watch me, or the audience is thrilled to be there
• My costume may be reinforced not to break, or I may have forgotten to check it (or check a part of it) and it loosens

Every dance experience has something new to experience – either artistically or logistically.

And when you experiment, you have to have 2 things: self-confidence to try and  preparation to succeed or fail.

I have been told that some of my best performances came out of my improv work. I think it's because I'm not overly thinking about what I'm doing – I'm responding to the current situation. Sure, I think about what I could do a few moves out, but mostly I'm just responding to the music. I shut down my ego and focus on being in harmony with the musicians. 

Improv performances are a lot like Agile – the business requirements change and you respond. You and the team have enough confidence to pick up a story, try to solve the problem, and just do it, making sure you keep the solution open ended enough to add more features. Usually, this works out well.

However, not every decision you make is going to be awesome. Mistakes are made. 

• For improv: You land on the wrong foot and get off-balance during a spin. Or you don't read your audience right and respond to the music in an awkward way. Or you stop – for no reason. Your brain just stopped.
• For Agile: The prioritization was wrong. There was incorrect technical direction and the team wasn't able to scale the product. Someone on the team didn't collaborate as much as he should have and worked by himself and inadvertently blocked the team. The UX approach tested poorly and has to be completely rewritten.

And you may think this is a result of the nature of improv and Agile – if you planned better, this wouldn't have happened. However, no matter how much planning you do – you can't avoid failure. There is no possible way to think through every situation. 

As an analogy, if we were to think through every situation before taking action – driving would be impossible. We would need to memorize a 4-inch manual that documents what to do in every situation with another car. Needless to say, this would make more accidents – people would be trying to remember exactly what to do. It's just not realistic. You have to trust your instincts and intuitions sometimes to make changes now.  

According to Adapt, “success comes through rapidly fixing our mistakes rather than getting things right first time.” 

—99U, "Why Success Always Starts With Failure," Sarah Rapp

However, not all failure is bad – failure can be a good thing.

• To do good work, you have to try a lot. And when you try, you may not get it quite right. According to Malcolm Gladwell, it takes about 10,000 hours of doing something to be an expert – that's a lot of chances to fail. It's about trying and practicing. Even after that 10,000 hours of training to be an expert – you can still try and make a mistake.

• It shows that you stepped out of your comfort zone to innovate. When you are in your comfort zone you are doing something you have done every day. There are certain moves that I'll do during a performance – my signature moves so to speak – and every now and then, I respond to the music with something out of character. Sometimes I bomb. Sometimes I do something amazing. Same with Agile. I've been on teams that try something new – and it works out great. Sometimes – not so much. Trying something new shouldn't be punished because who knows what could happen from it. There could be a great discovery for a product or an amazing efficiency.

• Something good could be created out of the failure. Post-its are a great example of this. Here is the story from Wikipedia:

In 1968, a scientist at 3M in the United States, Dr. Spencer Silver, was attempting to develop a super-strong adhesive. Instead he accidentally created a "low-tack", reusable, pressure-sensitive adhesive.^[1][2] [3] For five years, Silver promoted his "solution without a problem" within 3M both informally and through seminars but failed to gain acceptance. In 1974 a colleague who had attended one his seminars, Art Fry, came up with the idea of using the adhesive to anchor his bookmark in his hymnbook.^[4][5] Fry then utilized 3M's officially sanctioned "permitted bootlegging" policy to develop the idea.^[5] The original notes' yellow color was chosen by accident, as the lab next-door to the Post-it team had only yellow scrap paper to use.^[6]

Without this "mistake" or "failure" – we wouldn't have these delightful yellow sticky notepads to place on computers, desks, books, etc.

• And when you fail, it's not about the failure – it's how you respond to and recover from it. Sometimes we fail and sit in our misery, contemplating the fail. Sometimes we fail and bounce back by changing direction and still trying to make something happen – and that's the response we should have. When I dance and do something wrong, I just don't stop and stare at the audience. I keep going as if nothing ever happened. And most times, the audience don't even know it was a mistake. Technical teams joke about such things being "features." And sometimes people don't even notice what happened – in fact, they like it.

• It can be a lesson to the team to be open to all options and ideas rather than basing a decision upon 1 or 2 voices. Sometimes failure happens because there are only a few strong voices on the team – not enough minds are involved in creating a solution. When I dance, this happens when I don't really listen to the music and expect what will be next (I listen to the melody more than the beat) rather than live what is next (possibly a neat twist to the song). Same with Agile projects – an off-beat idea may be rejected by a few because the rest of the team doesn't see what that person sees. When the "plan" fails, the team usually comes around and learns to listen to that person more.

• Then again, is it really failure? Isn't it really learning? There is a belief that everything we do is perfect and leading us to where we need to be. Our ability to achieve great things is only limited by our knowledge. And the path we take to reach a solution is most important to reaching a "better" answer. It is a powerful idea and repositions what "failure" is. We all don't know everything – and every day we learn something new. And maybe we need this failure to get to something else? 

• It shows that we have enough self-confidence and trust to take responsibility, admit we were wrong and change. It's easy to continue down a wrong path and keep making mistakes. It takes guts to admit that you were wrong, someone else is right and you must change direction. When an Agile team changes direction – the team is taking responsibility for the problems and correcting course to make a great product. When I perform and I mess up on stage, I own it and fix it and salvage the performance. 

There is a perception that a well-defined, detailed plan will give you automatic success because you thought through everything. That's just not true. Depending on how you define success or failure, you may stop a great innovation from happening, stop team learning, continue a team structure that doesn't include the entire team, or a number of other lessons. 

The beauty of improv and Agile is that you can always repair a mistake or "failure." It's how you respond to that mistake or "failure" that can make you shine.

_________________________________

I just realized that I write about my belly dance activities quite a bit but never really share them with you. 

If you are interested in this part of my life, here is my performer Web site (fayruzdallas.com) and my Youtube channel. Enjoy!

As you probably noticed, I took a break after Day 2 of my challenge with Linux. It wasn't because I got bored quickly, didn't want to do it, or just got unfocused. I'm not really like that and this is something I really want to do.

There were some outside forces influencing my drift away –  circumstances with my day job, a shift with personal and work priorities, and some health challenges. The break just really needed to happen. I didn't have the mental space to give this project the proper focus it needed. I would have half-baked it – and that's not fair.

However, after Thanksgiving I plan on going back to this and follow my original plans. I feel bad that I had to take a break, but things became a little more overwhelming than usual. At least now things are getting back to normal – and this should be a fun activity.

More soon!