Brian Bozzuto, principal Agile Coach at BigVisible

The session will cover:

• The critical role project managers can play in helping agile projects succeed
• Growing popularity of agile within the PMI including agile certifications such as the Agile Certified Practitioner (ACP) and the Agile Community of Practice
• The impact of agility on organizations as they embrace agile practices across the enterprise

Bob Fischer, Agile trainer, coach, facilitator, and change agent at BigVisible

This presentation will cover:

• The role of a manager in an agile organization
• The role of a transition team supporting the transition to agile
• Bring your questions. This will be an interactive session where you’ll get the chance to address your specific concerns.

The PMI Mass Bay Chapter is one of the largest in the United States, and in the top 6% of all chapters worldwide by size with over 2,300 members, including over 1,500 certified Project Management Professionals (PMP®).

Find out even more information about BigVisible at the PMI Mass Bay Chapter Meeting.

Join BigVisible’s Brian Bozzuto and AccuRev’s Chris Lucca on Thursday, November 17th from 1:00-2:00pm for a free lunchtime webinar on Incorporating Agile Methods: Top Traps for Development Teams to Avoid.

In this session, BigVisible’s Brian Bozzuto and AccuRev’s Chris Lucca will explore several dimensions of moving to agile practices and how they can magnify the benefits possible with agile or ultimately undermine the agile adoption –depending on how they are managed.

Specifically, this webinar will explore:

• Common hurdles a team adopting agile may experience
• Team training needs to consider, including agile certifications like Certified ScrumMaster and Certified Scrum Product Owner
• Criteria for evaluating or selecting agile development tools to enable agile methods
• How Agile impacts a broader scope, such as compensation, evaluations, finance, and sales

Reserve your space today!

Visualizing Your Process with a Kanban System

• Project Manager as a Change Agent
• Visualizing Your Process with a Kanban System

In addition, we played several games:

• 60 Steps
• The Marshmallow Challenge
• The Bottleneck Game
• The Coin Flip Game

0-To-Agile-In-3-5Years

Some of the main points:

• Agile, Lean, and other improvement concepts are holistic things, and applying them to a subset of your organization or value stream is likely to result in local optimization, and miss opportunities for far greater improvement and value
• The paradigm shift required is significant- amounting to a values change for individuals throughout the organization- from team members through executives.  Such a paradigm shift can take a long time- months, even years.
• There is not a model that can be used to perfectly plan your transition (if someone tries to sell you one, then I’d like to show you a bridge I am considering selling).  Understanding multiple models of change, and constantly adapting your strategy based on learning, will improve the success of your change effort.
• Coaching can help people learn, and is best when it is available real-time, in-context, so that the most important learning opportunities can be taken advantage of.
• It is easy to fall into the trap of focusing on practice and tools compliance, and neglect ‘the learning journey’ – where the real change has taken place as teams and individuals try different things, learn about what works and what doesn’t in their context, and try to change their context in ways that will result in greater emergence.   Neglecting principles and learning can result in the same practice standardization that is similar to a fundamental flaw in more traditional approaches.
• Don’t forget to examine and change existing rules when introducing new improvements!

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):

They were ripped that such an important game as American Football was led by an obviously inferior individual.  The one person on the team with a Quarter of a Back.  Insane! they cried, questioning the competency of our species – or at least our country – to be nominated for membership in the great intergalatic sports community.

What was  the problem with us, they demanded, to have a person with a full back or even one with a half back on the field and to still insist on fololowing the person with the least capability to remain in a vertical position.    It was not just their concern either. They let it slip that our solar system was on the short list to be converted into a rest area for the new hyper way.

I felt their minds had not been quite fried enough, so I told them about a software team being led by a ScrumMaster who  had only two days of training.  I shouldn’t have done that I guess, the gelatin-like masses where the voices seemed to come from went solid, turned ocre and started to emit a slow whiny sigh.

I took pity and explained to them that the name ScrumMaster was just like the name quarterback -  two great examples of the stupid way we earthlings label important roles in our organizations.  I went on to explain that these names were the names of positions people had, and did not reflect their competency or limitations in doing their job.  I then told them of other names in sports like gully foot and shortstop.  In addition I mentioned Project Manager and Assistant associate deputy to the second vice president for paper disposal.

This seemed to get them very excited and confused, then very happy.  So happy they forgot to take me with them and put probes in me.

It turns out the combination of the names we give roles and how we make such a big deal of some stupid names and say nothing about others will be the next season’s big hit. These two are setting up galaxy wide viewing licenses of the biggest show in all of time and space. A reality show that will document that Homer Simpson (a huge name in the Galaxy) is the smartest person on earth.

As promised, I am making the resources available so that anyone  who would like can play the simulation on their own. This zip file contains both the excel spreadsheet with the backlog and the presentation walking through the rules of the game.

Having run this session a couple times, there are some emergent patterns I would like to share with people.

• Commanding Product Owners & Scrum Masters: I have seen several teams now, at first glance appear to be making great progress. However, when you look closer, what you see is that one or two people (usually the PO & SM) have completely taken control of the team. What’s really interesting is how quickly you will observe the rest of the team becomes disengaged and disinterested. How many of you have seen a real project where, in the name of making progress, one or two people basically commandeer all decision making to the detriment of the team’s long term success?
• The position of your information radiators is critical: we know that people will interact better when put in an environment conducive to do so. During the last round, this was completely driven home by one poor team that had selected a small alcove to put up their task board and charts. The effect was such that only 3-4 people – out of 8 – could cluster around it. It was really incredible to see how the team accidentally cleaved itself in half with those people who could not stand around the board not being able to really contribute. What was even more impressive was how quickly the dynamic improved once we moved their task board to an open area.
• Prioritizing based on what may fit: I’ve noticed a very curious behavior begin to emerge when running this simulation with project managers. In the case of this game, we are not building a real product, so selection of features is a little less tangible. Ideally, product owners will prioritize based on the numeric value of a given story relative to the size of effort, in order to get the best “bang for the buck”. However, I’ve seen several team fall into an interesting dynamic where they team will begin to pour through detailed tasks, sizes and estimates and pulling stores from deep within the backlog based on their fit and balance to the capabilities of the team. From a PM point of view, I can understand this desire to fit work to our capacity. Of course, this is then done to the complete detriment of any value judgment. Thus, we see the PO surrender all prioritization decisions to what the team says it thinks would be easiest to do. We weren’t able to play enough rounds to take this to its logical conclusion, but I think you could see the challenge that would quickly emerge. After a couple sprints of “good” progress, the easy, balanced stuff would be used up and the team would now be facing more difficult work. Would they step up or would they look for new stories to do that are easy? This is the risk of what happens when we try to plan too much based on what’s convenient, as opposed to what’s valuable.

I would welcome others to try the simulation on their own and let me know what patterns you observe.

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.

After the presentation I thought more about our exchange of information and realized what an interesting set of challenges having distributed teams really presents to some of you and your teams.  I really liked some of the ideas that were shared and it shows some of the creativity being applied to solve the challenges of distributed teams.

As I promised, here are the slides from the presentation.  Best of luck everyone and thanks for having me.

I spoke about the topic of Agile and the Organization at the PMI’s Orange County chapter.  Attached are the presentation materials.

AgileAndOrg-PMIOC