For a long time, all I was doing was counting pages as the presentation moved on. I was really interested in the material, and I really wanted to learn it and digest it, but that first impression took me out of the right frame of mind. Trainers spend a lot of time thinking about how to create and hold an environment that is best conducive to learning/discovering. Getting back in that space is hard, and can only be accomplished with the help of everyone involved. It took a conscious effort on my part to go back and I noticed a lot of other people had already “checked out”. An opportunity lost.

Whether in training, or a meeting, one of the most important elements is the ability to engage the audience and keep them engaged throughout. Imagine it like a dance, everyone has to move together, or it will probably be the last one. Two elements come to mind when trying to establish that level of engagement: make it interactive and make it visual.

The visual aspects enhance our abilities to remember and associate objects with relationships and patterns. That is what thiking is based on. If I have learned anything from my years in college (on both sides of the desk, so to speak) is that the old and overused saying is tremendously true: “a picture is worth a thousand words” and a lot easier to remember. When we remember our dreams, we do not remember written words, only images.

The interactive aspect forces participants to think, imagine and explore more. Visual thinking not only helps people learn better on their own, but enhances the learning ability of the group.

Imagine the possibilities!

If you couple that with a powerful, simple and purposeful goal, you have the potential to create a great meeting (or learning) environment that feeds on itself.

A good source for understanding how to empower your meetings and presentations is the book:

A great compendium if visualization techniques can be found in the following link, thanks to my colleague Alex Singh (Click on image for the interactive chart):

Anyway, several people asked for slides, which I’m happy to make available: http://www.bigvisible.com/wp-content/uploads/2011/02/Your-First-Agile-Project-v1.0.pdf. Hope everyone there had as much fun as I did.

This calls to mind Stephen Colbert’s infamous criticism of modern media

The president makes decisions; he’s the decider. The press secretary announces those decisions, and you people of the press type those decisions down.

Make, announce, type. Put them through a spell check and go home. Get to know your family again. Make love to your wife. Write that novel you got kicking around in your head. You know, the one about the intrepid Washington reporter with the courage to stand up to the administration. You know–fiction.

–Stephen Colbert, 2004 White House Correspondents Dinner

Business analysts aren’t reporters, but I see a similar dynamic. We see and touch the final document – or article in the case of a reporter – but that isn’t the real value that was created. The real value was the uncovering of details, careful synthesis of multiple points of view and creation of new perspectives and evaluations of the environment. Indeed, we don’t want analysts to be stenographers, but rather to push back and challenge those people saying what they want in order to help them better articulate and understand it themselves.

The Stenographer Analyst

In the world of the “Stenographer Analyst”, the worth of an analyst is directly related to the size, complexity and general impressiveness of their requirements documents. Sadly, experience tells us that the more “impressive” the requirements look, the less people will actually read them. Thus, we create a system of local optimization where an analyst is motivated to create a big document that may actually undermine project success. However, it may protect them or the team later if the project gets into a fight about what’s “in scope” for the project. I think this is the essence of what the writers of the Agile Manifesto meant when they said “collaboration over contract negotiation”. Intuitively, we can sense this is wrong. If we could align our objectives, we could spend time and energy building out the best idea, rather than fighting with each other.

However, many of us do not yet live in this world. We are surrounded by managers who want to validate that everyone’s doing a good job, and they want to see proof that people are working hard. This is where the idea of the big document is so seductive to an analyst. It is (relatively) easy to write a document detailing a process or a system. It does require work, but producing a thorough analysis and putting it into a document is a very achievable thing that can be done and is within the sphere of control of an individual business analyst. What we’re doing when we talk about Agile Software Development is asking that analyst to let go of their document and cast their lot with the entire team and the business; to agree that we will all measure our success based on business outcomes. No more can we say, “it wasn’t my fault, I clearly documented the requirements”. Indeed, we are now responsible not only for capturing that information, but for distilling it, and communicating it. This is incredibly powerful, but also scary. We can be part of something much grander, we are working towards achieving real meaningful outcomes, but on the other hand it also means we will be held accountable for achieving real outcomes. We will only succeed if those around us do as well, we aren’t individual masters of our own destiny. It’s easy to talk about collaboration and team work, but this is the real thing: we can’t do it on our own and if things don’t work out, there is no discrete “deliverable” to fall back upon.

The Value of an Analyst

So in this environment, how does an analyst help out? Presumably the business analyst is not the actual customer, and now we are inviting those end users to work with us directly. Did we just make the analyst role obsolete? Not at all. As most analysts know, good business or systems analysis is much more than simply asking, “what do you want the system to do”. Inviting end users to come in and share their perspective doesn’t immediately solve this problem. I recall working with one group of call center operators. They were happy to be invited to our Agile project and keen to give advice. They were so excited they began rattling off requirements, “would like the system to have a button that I can click which will add up these three columns and apply our configurable business logic”, one person said.

I slowed them down, and walked them through user stories and that we wanted to capture our requirements based on a user experience. I put up the format “as a…, I want to… so that…” to reinforce the concept. The woman took it all in, thought for a moment and then ventured her first user story, “as a user of the system, I want the system to have a button that I can click which will add up these three columns and apply our configurable business logic, so that we can process transactions according to our procedures.”

This game played out for another hour as we tried to crack exactly what the summing of these attributes would do, what made up the company’s “configurable business logic” and why any of this was valuable. As the conversation matured, the manager for the department came to realize a lot of what her people were asking for was not really consistent with the stated goals of that call center. The conversation eventually moved into a discussion of business processes, which were important and how we could potentially improve them with a new system. Had we simply viewed the role of the analyst as a stenographer, we would have ended up with some nicely typed requirements that would have reinforced the organizations currently flawed system and failed to help the business understand how their operation was working.

But that is only half of the value we can get from facilitated and interactive sessions like these. Let me offer you another example, I was working on a different project at a different company where we were building a rules engine that would measure and report on a fund’s adherence to different regulatory rules. Periodically the business would come and ask for new attributes or functions with which they could build new rules. I was still fairly new at the company, and when dealing with one request that we got for a new function and supporting fields, I naively asked, “what do you want to do with this new functionality”. The business partner was taken back by the question, apparently they weren’t used to having to explain things on that level, but it came out there was a specific test they wanted to run. As we talked through what this test was, we realized they could replicate that test using some attributes and functions already existing within the system. We were able to end a 3 month project in a one hour meeting and implement the change that day for them, because we were able to re-frame the conversation.

I’m not arguing that these are activities which other analysts don’t do today, indeed this is the bread and butter of good business & systems analysis. It’s not about writing down what people say, it’s about helping them understand what they really want and broadening the perspective by bringing in more stakeholders. That is a very real activity, and getting rid of a big document doesn’t make that activity go away. In fact, it should help make it easier by changing the system into one that is more conducive for us to interact and explore an uncertain domain.

What Prevents Us From Getting to Good Solutions

Hand Offs

As children, most people get an opportunity to play the game “telephone”, whereby one person starts a message by whispering it into the ear of the person next to them. The receiver can not question what they heard, they must simply relay it on to the next person, until the message has traveled through all of the participants and the last person announces what they heard, which invariably is profoundly different from what the original person said. In spite of this well known dynamic, many projects operating in technical silos insist that we play this game with our projects.

Certainly Agile practices help here, as they tend to break down the large silos and force people to work closer together with smaller pieces of functionality. Still, the idea of walking through a decomposition of business requirements to detailed requirements, to designs, to tests introduces massive risk that something can be lost in the numerous translation. Even in small chunks, we are basically giving each audience the chance to frame the problem according to their perspective. The business will frame the problem through their eyes, the analyst will craft use cases or flow charts, the developers will build detailed designs, and the testers will identify concrete scenarios to validate the functionality. Of course we invite others to look at our work, but now we are in the domain of the second major challenge, the curse of expertise.

The Curse of Expertise

This term was made popular by the Heath brothers in their book “Made to Stick“. The concept is simply that the more you know about something, the more unique references, layers or knowledge and reference points you will have that will make it more difficult to communicate your ideas to people who are not experts. I offer up the image or these Star Wars fans and ask you how effective they would most likely be if they needed to explain the Star Wars movies to someone who had never seen them. Chances are they know so much about both trilogies, the original releases, the remade versions, the coming 3d versions, and the numerous games and comics that further matured the stories, it would be difficult for them to convey all of this in a simple thought. Likewise within our organizations, those people who know the business domain best will have the most difficulty communicating their understanding to a team of technologist who will experience the same problem when they try to explain the nuance of different possible technical solutions. Much like the Tower of Babel, an inability to speak the same language can doom the entire enterprise. It is in these situations where we can’t establish a clear shared vision, that people will refer back to their own experience, which brings us to the third challenge, functional fixedness.

Functional Fixedness

Human beings are cognitively to repeat pattern recognition once they make an association. This can be very useful when we have to make quick decisions, as it allows us to identify what’s around us and make rapid decisions. However, when confronted with creative problem solving, it closes numerous doors. The impact of this effect is that once you perceive something within a certain frame of reference, it will be very difficult to see it in another one. This was famously demonstrated by Karl Duncker with the candle problem. In this case, groups were given a candle, a box of tacks, and a match book. They were instructed to attach the candle to a wall so that it did not drip on the table below. The solution is to mount the candle within the tack box to the wall. What the experiment revealed was that the context in which the box was presented had a significant impact on people’s ability to solve the problem. Giving the participants the box as a discrete object, as opposed to simply the holder of the tacks, doubled the success rate of people trying to solve the problem (Dunker, 1945).

This is how we get into the situation where when you conduct user interviews you may find that the users can’t distinguish between their business operations and the actual system. It is the poor person trying to write a user story asking for the interface they have on their current system. This is not to begrudge them, they are acting predictably irrational. Rather it is the job of an analyst to help these people break from their context and reinterpret their problem in such a way as to better solve it. The idea that there is only one way to view a tool or process brings us to the last challenge I would like to highlight, the static solution.

The Static Solution

Western education teaches us that most problems have a single, best answer. Our simple task is to navigate the challenge, solve the puzzle and determine what the “answer” is. This is dangerous for two reasons, first it may cause us to think that our first answer is the answer and move on. Or it can cut the other way, where we become convinced there is a perfect answer and we can’t do anything until we figure it out. This dynamic is very real. When Tom Wujec conducted studies of participants playing the “marshmallow challenge” – a game where participants have 18 minutes to build a free standing structure out of paste, tape and string to hold a marshmallow as high as possible – he found that one of the groups which consistently performed worst was recent MBA graduates. Conversely, recent graduates of Kindergarden consistently ranked in the top levels of performance (Wujek, 2010).

Thus, armed with our conventional thinking, we seek to break apart and solve each individual problem. In fact, this is even where the word “analysis” comes from; it derives from the root meaning “to break into constituent parts”. While some problems are indeed closed in nature and capable of being solved in this dynamic, many real business problems are not. There is no “best” way to sell books, there is probably no “best” way to even sell books online. Even if there was one right answer, we exist in a world of changing circumstances, and the correct answer today, may be wrong in the future. In order to succeed in these domains of high uncertainty, we need to adopt a mindset that is much more comfortable with uncertainty. Break through innovative teams in numerous industries confront this challenge using techniques like emergent design, where a simple solution is built and then matured, or set based design, where multiple options are developed simultaneously as a means to explore the domain and develop the best possible solution.

So What is it an Analyst Does?

In an Agile environment, a good analyst helps craft an environment to confront these challenges. They need to be aware of how humans think and work to implement counter strategies to the tricks we will play on ourselves. The job of the analyst becomes one of helping people find their bearings so that they can remain heading towards whatever the true objective is. The key question they need to ask is, “just how are we going to get feedback?”

Agile projects talk about periodic demonstrations and frequent releases to production. These are good first steps, but probably are not enough. Demos in conference rooms are very constrained and many product can not be launched early in their development phases. Perhaps its bringing a version of the product to the line where will be used. Perhaps it’s usability testing or a gradual roll out strategy. These are critical questions and challenges where an analyst needs to be involved. Quite simply, the goal of a good analyst in an Agile environment should be to get the various perspectives of stakeholders and help them refine it into a single common view that is focused on valuable objectives. Good analysts will distill this by talking to all the different people, great analysts will do it by bringing those people together and creating an environment in which they can do it on their own. Once they have done that, they can dutifully play secretary and write down what everyone agrees upon.

Use of “Fairy Godfathers / Godmothers”

With so many people and only 20 stations, invariably some people had to play the role of consultant or observer. We invited those who were comfortable to play the role of “fairy godperson” and assist teams, provided they wanted help. This turned out to be an invaluable addition for a handful of teams who had able coaches. While this was not part of the original intent of the simulation, it was quite impressive to see the difference made for those teams who had good support. Mind you, these coaches weren’t helping them with the rules of the game, which were brand new to everyone in the room, rather they were helping with the basic mechanics like using a task board or running a stand up.

The ScrumMaster Makes all the Difference

Each team choose a ScrumMaster, who’s job was to “facilitate the process”. It was incredible what a difference the individual made in this role. We saw some people helping keep teams focused and support them through a chaotic, fast passed game. We saw some with their back to the team while they furiously filled out the task board and barked instructions to other team members. While we didn’t have enough time to explore exactly how this would have impacted team performance over the long haul, it was quite interesting to see the impact it had on the level of energy and each team’s ability to get through a 5-day simulated sprint.

The Involvement of a Product Owner is New to Many People

The game called for a product owner to work with the team in selecting what features to work on. I can’t emphasize how simplified we made the roll for the simulation: all stories for the first sprint were selected and put in order. In spite of this, many people at the end of the simulation came forward and talked about how powerful it was to have someone speaking on behalf of the business there for the whole simulation. The team got to feel the power and collaboration of showing a business partner real time progress and making changes based on how they were doing. For some of us who have been preaching Agile and Scrum for a while, this may sound patently obvious. However, the point of this simulation is to introduce the mechanics of an Agile project, and this is a critical dynamic to many people.

I welcome feedback and changes to make the simulation more effective. Hopefully we’ll be doing some more big runs of the game in the near future and I will keep you all posted as it evolves.

Download Agile Simulation Files

Roger worked with a local orchestra to demonstrate different concepts about organizational dynamics, leadership, and team work. The audience had the opportunity to sit amongst the musicians and observe them play. It was an incredibly powerful experience because the nature of the orchestra delivers immediate feedback. The whole group works together in real time and produces product (music) constantly.

The exercise worked through several powerful examples such as when he singled out the violins, role playing that they were in a reality show where their goal was to play their individual parts as well as possible such to stand out from their peers. I’m not an expert, but the deterioration in the quality of the music was quite noticeable. What a powerful demonstration of how a team is more than a bunch of great individual contributors trying to look their individual best. There were a number of other powerful demonstrations, but I don’t want to give away too much, you really should see it for yourself.

Anyway, I also wanted to the presentations I gave available to anyone who would like them.

Agile from the Project Manager’s Perspective – this is an introductory presentation discussing some of the planning & project management activities that happen with a day, an iteration and a release.

Agile projects within the Enterprise – one of the big challenges we face is applying some of the small team based interactions and mechanics that make Agile projects so effective and figuring out how to reconcile them with the world of enormous teams, specialized roles and multiple interrelated projects.

The pdf of the presentation can be found here:

Also, several people expressed some interest in local Agile groups so that they could learn more. I would point out three specific ones that have monthly meetings and support vibrant communities of both learners and practitioners:

• Agile Bazaar
• Agile Boston
• Nashua Scrum Club

There really is a lot of say about this, and I intend to write more,  but for now I wanted to make my presentation available. It can be downloaded here: Agile Beyond Faster, Cheaper and Less Defects