Beyond Requirements

Agile 2011 – Agile Thinking for Business Analysis: Beyond User Stories

After an inexcusably long delay, here is another post on one of the sessions from Agile 2011. This one, Agile Thinking for Business Analysis: Going Beyond User Stories was presented by Steve Adolph & Shane Hastie.

The premise of the session was that although User Stories are the "industry standard" way of documenting requirements in agile approaches, they by themselves are insufficient to fully explain the problem space and solution constraints, by design. To get a full picture of what the team is trying to deliver, you need to progressively elaborate the information, starting with an understanding of the scope & context, the proceeding to epics and stories, which act primarily as a planning mechanism, and finally providing greater detail through the use of acceptance criteria.

The key points I pulled from the talk:

1. When it comes to analysis, don't through the baby out with the bath water. In other words, there is still some use for models in agile to drive understanding, just don't spend a lot of time making them look pretty. They are tools to aid conversations, not the only means of communication.
2. The questions we are trying to answer should drive the model we want to use. Choose wisely.
3. Write use cases at the level of intent, not content (thanks Shane for that poetic nugget of wisdom)
4. A handy way of remembering quality constraints (non-functional requirements): "PERFUM"

• Performance
• Efficiency
• Reliability
• Functionality
• Maintainability

My favorite quote coming out of the session, Shane's reference to a 200 page specification document as the "Tome of uncertainty".

A Veterans Day Tribute to My Great Uncle Max

In honor of Veterans Day, I thought I would post the transcript of tape recorded by my great uncle Cecil "Max" Cox about his experiences in the Pacific Theater during World War II.

Sometime in the fall of 1939, we able-bodied men were asked to sign up for what was called the Selective Service. I wasn't called into the service until October 1942. We went to Des Moines and took our physicals. I passed and was sent home for two weeks, then one evening we departed from Bedford on the train. It was very hard leaving your loved ones, not knowing if you were going to see them again. If you don't think so, try it sometime. We were in Des Moines three or four days, loaded on a bus, taken to Ames where we boarded a train for parts unknown. Two days later we unloaded at Camp Roberts, California. It was strictly a base for combat training. I took my basic training there. It was a nice place to spend a few months of the winter, but would have much rather been home.

They were needing men overseas real bad so we were rushed right over. I did not even get a furlough before being sent overseas. We left Camp Stoner, California March 21, 1943. Our first stop was the Fiji Islands; we stopped to unload some supplies. We were there one week. We then went to the island of New Caledonia. We arrived there April 24^th. We were put in a casual camp there until we were picked up by some outfit needing more men. I went with the 112^th Cavalry which was a combat outfit. We left New Caledonia May 13^th and arrived in Australia May 17^th. I got off the boat with Jenque fever and was so sick a week with fever I could barely walk. I was sent direct to the hospital for ten days. The first time I sure realized I was a long way from home and that there was a war going on.

We left Australia June 13, 1943 and arrived at New Guinea June 30^th. There had been a big battle there but the Japs had been cleaned out of this particular place. We had very rugged jungle training there. We left there and made a beachhead on Woodlark Island. We let the Japs know that we were coming and they took off as we had very little trouble.

We left Woodlark Island November 30, 1943 and arrived at Goodenough Island December 1^st. We joined some Marines there and did some more training. We all knew what was coming as they told us it would be hot where we were going.

We left there December 14, 1943 and arrived at New Britain two days later. That morning about three o'clock, they roused us out for a breakfast of beans, loaded us on what they called alligators. They would hold about twenty-four men and equipment. They then told us what our objective was. We were fifteen hundred men strong; they told us we were going up against anywhere from thirty-five to fifty thousand Japs. Sure made you feel good.

We went ashore with fifteen hundred men [Max was part of 2^nd Squadron] and suffice to say, some did not make it. They machine-gunned men on the landing craft; some drowned, some were hit. I went ashore in the alligator; I got hit the first day. I waded through a swamp not knowing what was in the water or how deep to a first aid station. My sergeant said he was so short of help he wouldn't send anyone with me so I said, "I'm going alone before I bleed to death."

They gave me morphine to knock me out. They operated on me the next morning. Just as I was coming to, all hell broke loose. They bombed the tent hospital that I was in, tearing it all to pieces. They took us down to the beach, put us in some foxholes for the rest of the day. That evening, they loaded us on a barge and were going to take us to another island. The barge was stuck so good they could not move it. The next morning they came over and strafed the barge. All I got was another piece of shrapnel; I was lucky at that. By this time I wasn't sure we were going to come out alive. They took us back and put us in the foxholes again. They got the barge loose and after that they put us back on and took us back to New Guinea. I went two days without food. They picked us up and flew us over the Owen Stanley Mountains to Port Moresby where it was good and safe. I was operated on again and was away from my outfit for two months. I wasn't too happy about going back because I knew there would be more combat, by this time I knew I didn't care much for that either.

We left New Britain Island June the 4th (1944) for New Guinea for troop replacement and more training. In two weeks we were ready to go again. This time it was up the coast of New Guinea to a small place the name of Aitape. Our job there was to keep the Japs from coming across the Driniumor River and we were organizing.

I had several close calls there. I had my hat knocked off while peeking around a tree and a mortar shell landed right where I had been a few seconds before. We lost lots of men in the rugged campaign. I had one of the hardest jobs of my life there. We had to move a cemetery; several of the boys were my buddies. They were buried very shallowly and all that rain and heat, there wasn't much left. We would dig down until we would hit the bodies, then throw some lime on them to kill the odor and germs; then we would finish digging them out. We had to move them down to the beach three miles away and put them on barges. From there I don't know where they went.

From there we had more replacements and on to Leyte Island in the Philippines. What a mess that was! I don't think I was ever dry, it rained day and night. Everyone had jungle rot or something wrong with his feet. Same old story – we were a small outfit so they used us to plug up some jungle trails that the Japs were using. We lost several more men by this time; we were a very small outfit.

My closest call was one night; they hit us with artillery. Everyone scattered. I ended up under the roots of a tree with two fellows I had never seen. One had been shot in the face and was in bad shape. In the night he got hard to handle. Somehow he got word to me that he had something in his mouth and couldn't swallow and he wanted me to get it out. I stuck in my filthy finger and pulled out a piece of his jawbone. Before morning he was delirious and calling for his mother. Oh, what a night. I think I aged fifty years.

After a few weeks they pulled us down to the beach and were going to have us make another beachhead on some other island. There was a medical officer who came and examined us and said that this outfit was not able for any more combat at that time. We were sure glad to hear that.

After our rest, our next move was to Luzon Island. We really had the Japs on the run by this time. Same old story – another long three-day hike back on some river for the same old job. By this time I had about had it. The first day I almost didn't make it. My legs just would not do what I wanted them to. Of course, all I was carrying was three days' rations, my sidearm, and part of an 81 mm mortar, probably about eighty pounds altogether.

We got lost, ran out of water and had guys passing out right and left due to the heat and lack of water. By this time we were a very small group and according to the report, we killed between two and three hundred Japs and did not lose but three men. When we left our positions, we dug them up and carried them three days back to where they would be picked up with the trucks. Luzon was very dry and more like the U. S. When this was over, they moved us back and more replacements.

We were getting ready to make the invasion of Japan itself. We were getting ready for bed one night when it came through that Japan had surrendered; sure was a happy bunch of people. I had a farewell letter written to my loved ones in my barracks bag because I was sure that I would not come through this thing alive.

We went ashore in Japan just where we would have landed if we had been making our invasion. We were to take this airstrip at Tateyama, Japan. It was so full of gun emplacements; it would have been a slaughter I'm sure. I was there twenty-six days when one Saturday noon they called us all out. We were so disgusted because we thought it would be a work detail. Instead, they were sending all of us older fellows home. We were on the first troop ship to be sent home from the Pacific.

I was in the service three years – thirty months of that being overseas and practically all in the combat zone. I had no furlough in all the time I was there.

I will close by saying that the good Lord was looking after me or I would never have made it. Since then we have had the Korean Conflict and now the Vietnam War. I lost my nephew, Howard Max Cox, in this conflict. He was a Marine at the time. It hurt me terribly as I knew what he had gone through. I would like to add this poem in his memory:

If you followed your orders whatever went wrong
And did not stop your work until it stopped you
The Escorts march across the cemetery
Not in a civilian fashion, of course
But first a hundred and eighty degrees on the compass
To ___________ walkway; they formed a column left
And then marched to the grave space.
The color guard led you today; the family followed you today
The officer at the graveside saluted you today.
The soldiers carrying your casket followed their orders, too
But no one obeyed social or military degree
Only to fulfill duty today.
We respect you today
You followed your orders whatever went wrong
And did not stop your work until it stopped you
To that marine, "We salute you."
Whether you satisfactorily executed those orders
Or whether you ever began to execute, does not matter now
In the call of duty, and even above and beyond the
Call of duty, you obeyed at dear cost.
Whatever you suffered, before you forced all you could
From your body, no one but God and you shall know.
The color guard folded the flag that covered your casket.
The lieutenant presented the flag to your next of kin.
The bugler sounded the ageless refrain.
The firing squad cracked three rifle reports into the air.
Magnificent response to the comment made here.
Today we salute you, Marine.
Traffic still grinds along the nearby highway,
Oblivious to the consecration of emotions here.
A plane climbs into the sky, unaware.
Perhaps we should appropriate these as a salute to you, Marine.
Work will continue, war will continue; there will be
Soldiers as good as you who can finish the duty you began.
But there will be no other soldier who can replace you.
All is well, so to rest, God is nigh.

I will close now. I hope you have received some information from this little talk that will do you some good. As I said before I'm a poor speaker. I thank you.

Max did not like to talk much about his experiences during World War II, but I am glad that he made this recording so that he could share the type of story that doesn't always make it to books, or shows on the History Channel. He has since passed from this world, but he lives on through all the lives he touched working in the Bedford, Iowa Schools. Aside from this story, I also remember him through the American Flag that draped his coffin that I am honored to have in a special case in my house. It is through sacrifices of those like my Great Uncle Max that we are able to share ideas freely on blogs like this one. If you know anyone that serves or has served their country in the military, tell them thank you.

Attending Thinc Iowa

I am excited to spend the day at Thinc Iowa presented by Silicon Prairie News. The event is positioned as "the common ground between corporations and startups." From the minute I first heard about the event this summer, I knew it was something right down my alley. I have always had an interest in entrepreneurship and a big focus of Knowledge Bridge Partners and this blog is to explore areas that business analysis practitioners (most common in corporations) can learn from other domains. What could be a better combination?

Such a good combination in fact that not only did I decide to attend the event; I also decided that Knowledge Bridge Partners should sponsor it. Schedule conflicts prevented me from taking advantage of some of the networking opportunities offered up before and after the main event today, but I felt it was important to show my support for a gathering with the simple goal to:

"Motivate people to explore new ways of doing business, challenge them to think differently, and give them a place to network outside their normal circle. Corporate attendees will connect with startups that are developing game-changing ideas. Startups will connect with companies that understand how to successfully position and sell a product or service."

I hope to come out of the day with some great new connections and a head full of ideas on how business analysis practitioners can act more like entrepreneurs, even inside their current companies.

Agile2011 Making the Entire Organization Agile

Steve Denning, a former world bank executive and author gave two presentations at Agile 2011, both of which were of extreme relevance and importance for business analysis practitioners. I was able to attend both and found in this case at least, we were able to schedule across stages in the right order. His Making the Entire Organization Agile talk was a great overview to the ideas in his newest book The Leader's Guide to Radical Management: Re-inventing the Workplace for the 21^st Century.

About the Talk

The main premise of the talk is that there are five fundamental shifts that need to occur in the management in order for an organization to thrive in today's environment. These five shifts are:

1. Goal: From making money for shareholders to delighting the customer. Steve also described this as from inside-out ("You take what we make") to outside-in ("We seek to understand your problems and will surprise you by solving them.")
2. Role of the Manager: From controller to enabler to better lead the knowledge workers of today.
3. Mode of Coordination: From hierarchical bureaucracy to dynamic linking. In other words, adopt some of the coordination practices of agile approaches throughout the entire organization.
4. Values: From efficiency to transparency and continuous improvement
5. Communications: From top-down commands to peer-to-peer conversations that solve problems and generate new insights.

Let's look at some of the nuances of these shifts.

The switch in goal from making money to delighting customers represents a shift from focus on output to a focus on outcome. By understanding and helping to solve your customer's problems, you run a good chance of delighting them, and profits will come as a result. In other words, making money is the result of the organization's actions (assuming they are for profit), not the goal. A focus on delighting the customer may lead to lower profits in the shorter term in exchange for higher profits in the long term due to the strong relationships established. An example of this phenomenon is Zappos, which decided to keep its warehouses open 24x7 in order to ship orders as soon as possible.

Steve suggested several practices to delight customers, which he expanded on in his other talk (covered in a separate post):

• Commit explicitly to the goal
• Aiming for the simplest thing
• Deliver it sooner
• Evaluate what customers do, not what they say
• Let clients become co-creators
• Stop doing things that don't add value
• Measure! Customer delight can be measured by using such things as the net promoter score.

Delighting the customer means running the organization in a different way, which drives the shift in the manager's role from control to collaboration. This shift requires the change to dynamic linking, which Steve defines in a post on his blog as:

• Work is done in short cycles
• Management sets the goals of work in the cycle, based on what is known about what might delight the client
• Decisions about how the work should be carried out to achieve those goals are largely the responsibility of those doing the work
• Progress is measured (to the extent possible) by direct client feedback

That description provides a nice summary of how agile approaches, especially Scrum, organize work.

An example of the changing from value to values of radical transparency is the Ford Progress stoplights. When the new CEO took over, the senior leadership of Ford had a war room where they met on a regular basis that included stoplight indicators for all their major initiatives. Even though the company was losing $40 billion, all stoplights were green. It took some haranguing from the CEO to get people to become more transparent in their status reporting – most were concerned what would happen if anyone reported something other than green based on past experience. Finally after a couple of weeks some orange and red stop lights started showing up and CEO celebrated the new openness.

Steve also shared some ways to move communication from command to conversation:

• Authentic storytelling
• Practice deep listening
• Know the customer's story
• User stories are catalysts for conversation
• Use stories to enhance team cohesion

These ideas come from Steve's earlier book The Leader's Guide to Storytelling

Steve finished his talk with some other key points:

• Need to do all shifts at once – they are interdependent.
• Delighting the customer is the driver, conversation is the oil.
• Culture of organization is embedded in five assumptions of traditional management.

Application to Business Analysis

The content of this presentation is what business analysis should be about. Some of the key ideas are:

Take to heart the change in goal to delighting your customers. The customers we want to delight are the ones who are buying your company's products and services, not your "internal" customers. While delighting internal customers may make your job a little easier in the short run, you risk introducing sub optimization that is not beneficial for the organization as a whole. Even if you are working on an application that will support a process that may not directly impact the end customer, it's still helpful to ask "is what we are doing going to delight our customers?" Asking this question could change the way you approach a particular process or application, or help you determine that process is not needed in the first place.

Once you have determined that you are helping to delight the customer, then look a little closer to your own efforts and remember the shift from inside-out to outside-in. Instead of taking the attitude "you take what we make" (come on, admit it, you've been on a team that has done this in the past) approach your next project with the attitude "We seek to understand your problems and will surprise you by solving them."

The shift in the goal provides a clearer definition of business value. Instead of defining business value as something that increases or protects revenue or reduces cost in alignment with organizational strategy, define business value as something that makes progress toward organizational goals, and then define the goal as delighting the customer. Thus, instead of asking "Does this provide business value?" You can now ask "Will this delight our customer?"

Aim for the simplest thing, deliver it sooner, and stop doing things that don't add value. In the world of business analysis, this means worry more about understanding your customer's problem and solving it rather than worrying about how detailed your requirements are. Remember, requirements are a means to an end, effectively a way to describe the problem and characteristics of a good solution. Customers are not delighted by impeccable requirements. They are delighted by solutions that solve their particular problem when they need it solved.

Measure! Denning introduced the Net Promoter Score which provides a way to measure customer satisfaction. Aside from being a good technique, the important idea is the net promoter score represents a way to measure success based on outcome, not output. Success is measured based on progress toward the goal (delight the customer) rather than how quickly the effort was done, how many requirements were written, or how many errors were found. Measurements are very important and useful, but they should measure the right things. Instead of trying to measure the effectiveness of business analysts by themselves (will lead to sub optimization) focus instead on the outcomes generated by the team the analysts are on.

There are several ideas that come from Denning's work that I'll cover in later blog posts.

Agile2011 – Strategies for Agile Portfolio Management

There are two ways to look at the topic of Portfolio Management:

1. How do you incorporate projects using an agile approach into your broader overall portfolio
2. How do you manage your portfolio in an agile manner?

Kenny Rubin in his presentation Strategies for Portfolio Management explored the second, which implicitly covered some of the first.

About the Talk

The talk centered around nine strategies for managing a portfolio while taking into account agile and lean ideas. He grouped these into three groups:

Scheduling

• Optimize for lifecycle profits – consider factors such as waste, cycle time, variability, efficiency, revenue, etc in combination.
• Consider cost of delay – consider the cost of releasing something later compared with the cost of rushing to release it sooner.
• Estimate for accuracy not precision – it doesn't pay to be very precise when you are estimating, and there is a good enough level of accuracy that provides enough information for a decision and optimizes the effort needed.

Inflows

• Manage project arrival rate – review your portfolio more than once a year.
• Embrace Emergent Opportunities - Maintain some flexibility to respond to emerging opportunities.
• Smaller, more frequent releases – strive for smaller initiatives and releases to lower risk and make balancing the portfolio easier.

Outflows

• Focus on Idle work, not idle workers – this is a similar concept to optimizing on cycle time, not utilization that Jez Humble mentioned in his presentation
• Establish Work In Process Limit – determine the number of projects in flight at any one given time based on the number of teams, not the individual team members.
• Complete, engaged teams – don't start working on a project until you have a complete, engaged team to limit the amount of "getting up to speed" required, and to ensure that everyone can provide input into critical project decisions.

Application to Business Analysis

These strategies provide guidance for deciding what to do when, and how to organize to do them. Some of the ideas reinforce the thoughts shared in other sessions that you want complete, cross functional teams working on efforts and to track work at the team level rather than at the individual person level. Additionally, a key idea I got out of the talk is the difference between the output of an iteration and the output from a release.

• Teams deliver the output of an iteration (code ready to be released to production). This is a team decision when to do this and is made when the team decides the length and scope of an iteration.
• When to release the output of multiple iterations is a business decision based on when the customer can absorb change. The release impacts the economics of the effort because releasing things to the customer may start generating revenue.

One final thing to consider from an enterprise analysis perspective, portfolio planning and management is how an organization implements their strategy.

Agile 2011 – Applying the Lean Startup Model to the Enterprise

The first session I attended was Jez Humble's Applying the Lean Startup Model to the Enterprise. This session introduced the Lean Startup Model and discussed how the concepts could be applied to larger more established organizations, specifically how to organize development and operations.

About the talk

If you are not familiar with lean startup, don't worry there is going to be plenty showing up about that topic in Beyond Requirements in the upcoming weeks. In the meantime, I though Jez provided a good brief introduction in his talk:

• Create hypothesis
• Deliver minimum viable product
• Get feedback
• (repeat, pivoting if necessary)

The main premise of the talk is that enterprises tend to separate the constituencies involved in delivering the systems that support the enterprise's ultimate product or service. Jez referred to these constituencies as Business, Engineering, and Operations.

This arrangement leads to the various barriers of collaboration that lead to inefficiencies and waste. In this talk Jez focused on the relationship between engineering and operations where engineering delivers software to operations, which then releases it to customers. He described how this split leads to more complex systems, effectively proving Conway's Law which to paraphrase is: "Any piece of software reflects the organizational structure that produced it." In this scenario

Some techniques have appeared to attempt to address these solutions, such as devops and continuous delivery, which gets the enterprise part of the way to the solution. Jez suggests a more complete approach is to treat these internal systems (Jez referred to them as services) as products and combine the engineering and operations teams in product teams focused on a specific system or systems. Amazon is one company that follows this approach and is described by its Walter Vogels, the Amazon CTO, "You build it, You run it."

Once you have put that team together, the team can apply ideas from lean in general and lean startup in particular to improve their processes and ensure they are delivering the right things. For example, because the team has a broader range of cross functional skills, it is better to optimize on cycle time, rather than for utilization. Optimizing on cycle time means that some people with certain skill sets may not always be fully utilized, but it allows time and capacity for continuous improvements.

Some other interesting points from the talk that were not necessarily a surprise to me, but provided a nice way of thinking of it:

• The PMO exists to manage the portfolio – what services/products should continue/not continue.
• In a Lean Startup approach, user stories were not considered done until they led to validated learning i.e. we learned they were useful (more on that in later posts)
• Enterprise Governance is about risk management – focus on performance and conformance. I find this one particularly meaningful, and unfortunately my experience has been that most enterprise governance efforts focus too much on the conformance aspect of things as opposed to provide shared learning on how to improve performance.

Application to Business Analysis

The main points I took away from this presentation:

The project model (distinct efforts with a potentially different group of people working on a system at different times) is probably not the best long term model for maintaining software applications. A consistent, cross functional team that as a whole understands the business needs served by the system and the underlying technology may work better to minimize the work done every time a change is needed, especially in the case where the system needs to change frequently. Projects are still a good mechanism to introduce changes to a process or organization, or where the system is fairly static.

The concept of devops was an often repeated theme at Agile 2011. From my view point it seems to be where agile was a few years ago: a group of skilled people in their line of work (in this case system admins primarily) who are tired of being part of the problem and want to do things better. As with all movements in its early stages it has its share of detractors, some trying to resist change, others skeptical that a term was created to make some people some money.

There are teams that are already combining development and operations, in fact one of the teams I work with is following this exact model. Primarily because it has not grown to the size yet where the powers that be think it is wise to split up the responsibilities. Hopefully this team can maintain the idea of keeping engineering and operations together. I've worked in both structures. The cross functional team works better.

This presentation was focused on the development and deployment side of things. If you look at the presentation slides, there is still a thick red line between the business and the delivery team (which was pointed out by Mary Poppendieck who attended the talk). I think there are certainly ways to get rid of the red line between business and engineering, something I plan to explore with future posts.

Attending sessions such as this one, even though they are not focused that much on business analysis practices and techniques are still extremely helpful for business analysis practitioners to keep up with what is going on outside the realm of working with the customer.

Agile 2011 Reflections – Why Care about Positive Emotions

The first keynote at the Agile 2011 Conference was Barbara Frederickson, a professor at UNC Chapel Hill, who has done a great deal of work on the impact of positive emotions. In her talk Why Care about Positive Emotions, she discussed how positive emotions can change people's physiology and impact their effectiveness at work, in this case knowledge work.

About the Talk:

Barbara summed up the effects of positive emotions into her broaden-and-build theory, which goes something like this:

Broaden: when we experience positive emotions we tend to open up.

• We are more likely to identify global patterns
• We are more likely to see contextual data as well as detail.
• We are able to see more possibilities, be more creative and even do better on exams (something to think about for those of you out there considering chasing some sort of certification).

Build: positive emotions transform us. As we seek to have more positive emotions, we develop better resilience physically and mentally and we "become better versions of ourselves".

Barbara made an observation about the impact of positive emotions on communication that I thought was very interesting, and important to consider for people doing a great deal of work on teams:

Positive Emotions + Face 2 Face Communication + Eye Contact = Mini Mind Meld

In other words, there are a lot of factors that go into ensuring effective communication, something to consider the next time you are trying to decide between emailing someone, or stopping over at their desk to talk with them.

The other interesting thing that Barbara noted is that these effects occur after a tipping point, or what she refers to as a positivity ratio of 3:1, three times as many positive emotions as negative emotions. I think the point of interest here is not so much that you need more positivity than negativity, that point is pretty obvious, rather that there is some room for negative emotions which gives hope to all of us who can't turn into annoyingly bright and sunny Smurfs all the time (oops, did my ratio just slip to 3:2?)

Barbara closed out her talk by providing some insight into how to maintain that ratio, and guess what; it's a little more complex than just "be happy." Instead, she suggests the following actions:

• Be open
• Be appreciative
• Be curious
• Be kind
• Be real

If you want to know more about Barbara's work, check out her book Positivity.

Application to business analysis:

I gleaned a few things of relevance for business analysis practitioners from Barbara's talk:

• Maintain the positivity ratio so that you can improve your ability to identify global patterns and consider context, key skill sets when seeking the right solution
• Maintain the positivity ratio so that you can connect better with stakeholders and get the benefits of that mini mind meld
• Help your stakeholders build that positivity ratio. When you are talking to them about a problem you are trying to help them solve, start off by helping them establish some positive emotions. Ask them about their family, their weekend, or their favorite pass times (hopefully those are things they enjoy talking about). This idea ties in nicely to another talk I went to about Flirting with your customers.

These items aren't a cure all panacea, but they certainly will help you become a more effective and well-rounded business analysis practitioner.

BA Questions About Agile

On June 15^th, I had the opportunity to speak to a group of business analysts who had a lot of questions about agile. I had been asked to give a 45 minute overview of agile and was provided a sample list of questions for the presentation would cover. I quickly realized that I would never come close to answering all of the questions with a prepared presentation, so I took a different approach. I asked everyone to write their questions on sticky notes and put them on a whiteboard at the front of the room. I then proceeded to work my way through the questions.

In addition to the questions I answered during the session, I thought I would share answers here to the questions that appeared on the sticky notes. Those questions are listed below as links to the posts in which I answer them. The posts referenced below represent my initial gut level answer to the questions. I encourage you to post any follow on questions or comments in the comments of the appropriate post, and I will reply back via comments or revise my post to provide more clarity where appropriate.

I'm still working on answers to some of the questions (those which do not appear as links). Once I have an answer, I'll include the link.

• What value does the BA provide within a true agile project?
• How do you overcome the expectation for a complete product when you are delivering piece by piece?
• How do you get BA's to convert from a waterfall methodology to an agile approach?
• When introducing agile, do you suggest business unit training first?
• What is the best way to get PM's and executive stakeholders that are accustomed to waterfall on board with agile?
• How do you get your leads (with only waterfall experience) on board with attending daily standup meetings?
• How do you overcome the hurdle of "that's the way we've always done it" mentality with project participants? PM, IT, Stakeholders
• How do you go about getting the information you need to create your features?
• Have you seen vendor driven agile working well in traditional waterfall companies?
• What are some good requirement tools to use with agile? Quality Center?
• How do offshore resources fit into agile?
• How do you learn about the agile approach? How does a BA learn to manage the agile approach?
• In your experience, what are the core trends of agile? That is, what is both necessary and sufficient to have an agile development methodology?
• How do you feel about the BA being the daily Scrum Master?
• How does the PM role change in agile vs. waterfall?
• Does agile typically require greater or fewer resources than a similar waterfall project?
• What, in your mind, is the one biggest benefit of agile?
• What has been the business side's response to it?
• What is the most challenging thing about implementing and using agile?
• How and when do you stop a "features list" from growing? At some point coding and testing needs to occur.
• In a pure agile world, "user stories" are used. How do you see this evolving?
• How is agile adaptable to smaller projects eg, 20 – 100 hours?
• The agile approach uses sticky notes a lot… how do you convert this into documentation for the business?
• How do you document the agile approach?
• What is a high level overview of the agile methodology & key inputs/outputs/scheduling?
• What is agile?
• How do you describe agile to business partners?
• How do you get business buy-in on the agile process?

BA Questions: Vendor Driven Agile

Question: Have you seen vendor driven agile working well in traditional waterfall companies?

I have to date not seen a situation where a vendor was using an agile approach, and the customer was a traditional waterfall company. I'm not saying that it does not happen, just that I have not seen it.

I think the answer is "It depends" on whether the client is willing to make the behavior change necessary to working in an agile manner.

To me "vendor driven agile" leads me to believe that there is a bit of interaction between people from the vendor and people from the customer working jointly to deliver a solution. In this case, I would be surprised to see a customer allowing the vendor to dictate an approach unless they (the customer) had agreed to this ahead of time. Based on my experience as a consultant, the vendor is usually better off to follow the client's development methodology unless the client specifically ceded responsibility of that to the vendor. If that were the case, I would take that as a sign that the client is interested in learning the new approach and is looking to the vendor to pass along that knowledge.

If the client has explicitly signed up for that kind of approach, then this approach should work as long as the client is willing to learn some potentially disturbing things about their organization. One common occurrence with agile implementations is several problems that get in the way of teams being effective are uncovered as a result of the introduction to agile. Organizations adopting this approach need to realize that agile is not causing the problems, rather it is exposing the problems. If an organization is truly serious about adopting agile, they will be willing to resolve those issues as they are identified.

If the client is not serious about resolving the issues that are raised, a few things can happen. The client may believe that the vendor is heading down the wrong path and agile is causing several different problems, leading to a soured relationship between the client and the vendor. Conversely, if the vendor is afraid that the client will act this way, the vendor team members will not raise the issues that need to be addressed to make the team effective, again potentially hindering the vendor's ability to deliver and the vendor/client relationship.

BA Questions: The Scrum Master

The role of Scrum Master is specific to Scrum. Since Scrum has become the most widely known of the agile approaches, the term Scrum Master has become a common term for the person who is acting as process guardian and facilitator for agile teams.

Question: How do you feel about the BA being the daily Scrum Master?

It depends on the business analyst. If that person has excellent facilitation skills, and a passion for helping the team establish and stick to their chosen processes, then I think that business analyst could be very successful as Scrum Master. If however, that person's real passion is helping to define the scope of the project, develop a clear description of the problem to be solved, and establish a clear set of solutions, that person should not attempt to also fill the role of Scrum Master. Instead, if they have the appropriate decision making authority they should be the Product Owner. If they do not have the decision making authority, they should be a member of the team focused on the key aspects of problem definition and solution development.

 Question: How does the PM role change in agile vs. waterfall?

Sure, I made a little bit of a leap in putting this question in this post, but it felt like a good fit. Depending on which agile approach your team follows, you may not find a role called specifically "project manager" but the project management responsibilities do not go away. I'll describe what happens in Scrum, again because it is the most common process adopted. The team takes on several project management responsibilities as they as a group decide who is doing what when and keep each other up to date on status.

The role of Scrum Master assumes the responsibility for removing barriers for the team, and acting as process guardian, doing whatever they need to do to help the team be as effective as possible. In effect, the Scrum Master is really a project manager acting as a servant leader.