Enterprise Agility Q+A-EN

In partnership with the IIBA, our Senior Instructor, Ali, recently presented a webinar: 10 Tips to Facilitate Business Agility. During that webinar, she received some awesome questions – actually, lots of them! Since she wasn’t able to address them all during the webinar, she’s provided her feedback on them all below.

If you weren’t able to attend the webinar, a recording is available on the IIIBA’s website.

I heard this recently from a project sponsor: We have mature agility, so we don’t need BAs. Our great developers can talk to SMEs. What is your response?

I have found that the typical product owner does not have the essential skills of business analysis (nor have they been trained) to be able to fully understand how to analyze business needs, ‘translate’ them to functional/nonfunctional needs, get the appropriate level of detail to the developers, and ensure that the requirements deliver the value expected and intended. While the title of Business Analyst might not be necessary, the role is CRUCIAL. I consistently see it cited in many surveys as one of the top skills needed and missing on IT projects. With the VUCA world I mentioned in the webinar, it is needed now more than ever. We need those critical thinkers to help understand the changes, to identify the solutions needed to address them, and to understand the value those solutions should/can deliver.

How can Agile methodology remove conflict and increase efficiency during collaboration?

It’s not the Agile methodology that will help most with this, it’s the mindset. While the ceremonies of the Scrum framework (for example) can help direct teams on the cadence and structure of collaboration, it’s really the mindset that counts. The mindset entails:

• Collaboration (delivery team and business working together daily)
• Communication (with face-to-face conversations)
• Self-organization (teams decide how best to work together, including a working agreement on how to treat each other)

That mindset, I believe, takes training to learn and lots of practice to figure out what works best for any one team.

I work as Business System Analyst. I had to move a project from Traditional SDLC to Iterative Model into breaking it down to Iterative MVPs to be developed, just because my company policy does not have agile mindset due to issuance of change request to our client? My question is, as you said, most of the company wants to freeze the requirement, is the company doing the same thing here?

There’s a difference between agreement on what a team is going to deliver in the next few weeks (2 -4) and what they are going to deliver over many months or even many years of work. So, if you are required to plan out and commit to what you are going to deliver over more than 1 to 3 months, yes, the company is probably really still under a waterfall mentality. But there are many flavors of agile and some hybrid methods are actually better for the circumstances. For example, if a client requires you to deliver against a strict contract or statement of work, the client needs to ‘buy into’ agile for it to really work well.

How is Enterprise Agility different from Scaled Agile?

Scaled Agile, for example – SAFe or LeSS, is typically used to coordinate multiple Scrum teams working toward the same initiative, or sometimes multiple initiatives, so that when they go into production with their solution, they aren’t stepping over each other and all the solutions are tested well. It is even more helpful when multiple initiatives are putting in products at the same time.

Enterprise Agility is actually not just around initiatives or projects, but around the whole organization embracing the agile principles and mindset toward continuous learning, continuous improvement, collaboration, and self-empowerment (self-organizing teams).

Scaled agile could be part of an enterprise’s agility strategy.

With respect to culture, what are the key constraints that must be observed for successful agile mindset change?

To me, the key things that we want to focus on are:

• Empower people to do their jobs and do them well. Instead of a command and control approach that tells employees what work to do for x hours a day, the employees say – give me the goals and vision, let me tell you the best way to get it done since I am the one actually doing the work.
• Enabling employees within the organization to collaborate well – be sure they have the tools they need to collaborate. If they aren’t co-located, give them the tools to enable that collaboration as if they were.
• Foster a learning environment. Make sure that people have the opportunity to learn and experiment. Along with that, don’t punish mistakes or failures. Embrace some of those failures because that is where you learn. This allows people to experiment and learn (and not be afraid of consequences when they make a mistake once!).

Is there any priority for the tips you provided?

I would say that I put them in the order I think important. Notice that “Understand Your Customer” and “Understand Your Business & Stakeholders” are kind of a repetition! It all starts with understanding why you are doing what you do and for whom. So, you could take them from 1 to 10 in priority, but they are all important! For a quick re-cap:

1. Implement Good Practices
2. Mindfully Select Appropriate Tools
3. Understand Your Business + Stakeholders
4. Know Your Data + Tell Stories With It
5. Hone Business Rules for Good Decisions
6. Focus on Value
7. Adopt a Kaizen Mindset
8. Encourage Knowledge-Sharing + Transparency
9. Support and Encourage Collaboration
10. Understand Your Customer

If you are not a leader, how can you promote an Agile culture? My company’s software development team uses Agile practices and mindset, but we are limited by the practices of the rest of our company.

That’s a great question to which I’m not sure I have a great answer. It’s hard to implement agile practices and mindset if your leadership and the business side don’t buy in as well. But showing successes is one of the best ways to get noticed and get people asking, “Hey, what are they doing to make themselves so successful?!”.  When you do have successes, try to call attention to why you are successful if it can be attributed to your agile practices.

What is the one thing that can help drive culture and mindset change?

It is hard to say just one thing, but I’ll try. Agility needs to be pervasive throughout the organization. You have to have leadership involved. They need to understand that you can’t just say “go do agile” – they have to champion it and actually be agile themselves. They have to understand what agility means.

There is a great book and video by David Marquet – Turn the Ship Around that talks about servant leadership in the military that I use a lot with our clients. I recommend taking a look!

Have you been involved in any project related to sales and its adoption of agile? Can you tell us how it was?

We actually use agile throughout Netmind and with our sales teams. Our salespeople are empowered to make decisions about clients, given certain parameters (for example, the margin that is expected from a proposal or sale). We also have collaboration between sales and delivery (for example, me!) to ensure that we understand the customer problem, what they are trying to achieve, and that we match the proposed solution with solving that problem or achieving that goal. I’ve also been involved in client training to help sales and marketing teams use the Scrum and/or Lean Kanban framework for projects (like building SOWs or a marketing campaign).

Can you elaborate more on how a “working agreement” would be valuable – i.e. several specific points?

A working agreement is something I recommend for any team. We commit as a team to abide by certain norms and behaviors. Here are some examples to add to an agreement:

• When and how we meet daily
• How we treat each other (respect, honesty, openness, transparency)
• For a development team, what is our Definition of Ready and Definition of Done?
• What do we do with impediments, issues, blockages?
• What do we do if someone is breaking this agreement?

How best do I convince people in my organization that Agile doesn’t mean no documentation, no requirements to be analyzed?

Number one: analysis is not just the documentation; it’s the critical thinking involved to build the correct solution and deliver the value desired. Requirements help us understand the true business purpose and need. For documentation, I think the best argument is proof. So, figure out what documentation is really need on the project and make it as visual, communicative, and slim as you can. Prove its worth. Documentation doesn’t have to be overly formal; it just needs to be there! Why do we document? To:

• Understand how decisions were made.
• Clarify and agree on a shared understanding of requirements (yes, requirements!). Requirements contain the why and what the solution needs to contain. Without it documented, how do we know if we’ve fulfilled them? How do we not forget details? How do we remember why and what we did for the next project?

What are some ways to measure value other than story points completed per sprint?

I recommend understanding how your customer reacts to what you are delivering. You can do things like surveying the customer and product manager to see if the product is actually solving the problem you are trying to solve.

Also, measure back against the objectives of the project. Just delivering a product doesn’t mean that you are solving the problem. It’s really about determining if the problem is actually being solved.

I also recommend taking a look at this article my colleague, Jacqueline, wrote for some specific agile metrics: Do Your Agile Project Metrics Measure Up? Why Traditional KPIs Won’t Work.

Could you describe “persona” as a method to empathize with team and customer?

Yes, a persona is just one of the ways you can empathize with the customer. I think I talked about how I’ve used LEGO® Serious Play® to empathize and understand the customer and the journey they have had with our product. To empathize with the team, see the question about the working agreement. We have exercises for empathy in some of our trainings that are very powerful. I have one exercise I do there that I, as well as most people in the group, end up teary-eyed with empathy for another participant. That’s pretty powerful!!

Can you elaborate on retrospective?

The retrospective is a ceremony or way for a team or organization to look at themselves to figure out how to get better. Basically, it’s the team or organization getting together to discuss these typical questions:

1. What are we doing well? We always want to talk about what we are doing well because there is the chance that if we don’t talk about it, we might not continue to that do that thing. These are good things to expose.
2. What can we do better? This is not a point fingers or blame, but to look at what, as a team or organization, can we do better to improve.
3. How can we plan for improvement? Look at those results, prioritize them based on value, and then let’s tackle those things one at a time. Typically, you want to come out of a retrospective with a plan for attack for what you have discovered when you have looked back on what you’ve done.

How can you convince a Product Owner to let you participate in more of the data definition, analysis and backlog grooming to improve user stories when they don’t understand the IIBA’s definition of Business Analysis (i.e. BABOK and The Core Concept Model, etc.)?
See the answer around documentation above.
Can you have a non-Agile business analysis team working with an Agile development team?

You can, and you probably end up reworking requirements to fit changing needs or newly discovered requirements that come out of development, and the entire team is not really agile. Usually this means that you do all the requirements work up front, and then the design/development/testing is done in sprints or iterations. That’s not horrible, but you probably aren’t leveraging agility like you could if you focused more on ‘just-in-time’ detailed requirements.

Who defines the “value” (at the enterprise level) that has to be realized by adopting enterprise agility?

Value is different for different organizations. Here are some examples for companies that I’m working in and with right now:

• Children’s Cancer Research Hospital: reduction in the death rate for cancer
• Bank: number of new accounts opened in the past 6 months
• Insurance: number of new policies

What are your thoughts on Agile chartering the project?
Here are my thoughts on the basics (this could be a long discussion!): A charter for an Agile project should include most of the typical scoping activities that a traditional project has. You still need:

• Project purpose (why are we doing this?)
• Measurable objective(s)
• Shared understanding of risks, both business and project
• Stakeholder impacts (systems, people, parties involved)
• High level data and process impacts

The difference in the charter would be items such as the project plan and milestones. Those should be focused on incremental development (and typically iterative as well, depending on how well known the potential solution is). A roadmap instead of a typical Gantt chart, for example, would be included.
How can a Project Manager be effective in delivering when there is a Product Manager? How do the two differ and how can they collaborate to wow the customer?

A Project Manager, if they have the right agile mindset, can serve as a great Scrum Master or ‘guider’ of the team. I hesitate to still say ‘manager’ here because that indicates more of a command and control mindset, rather than a facilitator of success. But I consider what they do to be project management, the goal of which is to help a team of people to successfully fulfill the delivery of a solution. It’s all about the mindset!

Can you give example of BA participation in the DevOps Venn Diagram?

The BA is the bridge to help facilitate the understanding of the business need throughout the entire team, including the development team (which includes testing) and the change management team who needs to deliver to and hand over to operations.

I like that Ali said to meet with the client on EACH iteration product owner. Sometimes this stops due to too many changes wanted. Is there a good way to keep the client’s focus on this release and not the end product?
A project still needs scoping (see the previous question on the project chartering). That helps focus on the scope. To focus on the release, scope the release. So set release objectives and themes and set a working agreement with the product owner to work within those parameters. Of course, things can change, but if you are disciplined and try to stick to the agreement, people tend to fall into line once they learn and practice it.
Does agile test in an UAT environment too? Test the release and fix immediately and then send to end user testers? Or is this step eliminated?

No testing is eliminated in agile. If anything, there should be more frequent, more iterative testing. A perfect world in agile testing is maximizing the amount of automated testing you do, so that testing is facilitating smooth implementation. User acceptance testing in agile is typically done within the sprint, with the final acceptance perhaps done in the sprint review/demo. If you can’t get the stakeholders to be that involved, which often happens, I recommend you do two things:

• Make the issue transparent, stressing the importance of UAT, which includes…
• Highlight the risks of delaying or not performing UAT

The main risks are that anything not UAT tested has the potential of perpetuating errors or missing requirements into the next sprints AND delayed testing delays release.

This whole conversation changes a bit if you are in scaled agile. I would recommend looking at the SAFe recommendations around scaling (coordinating multiple teams and perhaps multiple applications).

How would you manage scope creep in consideration of customer collaboration over contract negotiation?
See the previous answer to project chartering. We have training on how to scope a project or initiative; this should happen in every project. Scoping a project is not necessarily a ‘contract’. It’s a way to minimize non-value-adding changes (so encourage ‘good’ changes, discourage ‘bad’ changes).
Any advice for a team to be more agile in an environment where a 9-person team develops apps for a 2000+ employee business across different business unit?

Without knowing where you are at in agility, if it is just 1 team delivering for multiple business units for a medium sized organization, the enterprise needs to understand that they have a limited number of people delivering solutions for everybody.

You have to look at which initiatives or projects are going to deliver the value you are looking for, what are the prioritizes within those things that we are going to deliver based on that value, and then have the business agree to these priorities. Otherwise, I am guessing that this 9-person team is getting thrown a lot of things at the same time and being pulled in a lot of different directions.

It really takes leadership of the enterprise to get together and ask, “What is it that we really need to get done, what is the order of what we need to get done, and, based on value and risk, how do we limit what we are throwing at this team at one time?”

What are more challenges that executives have with change management?

I find that the mindset is the major challenge. Many executives say, “Yes, let’s go agile!”, but they themselves either don’t really understand what it means or are simply too ingrained in the traditional ‘command and control’ management. Following on that thought, many executives don’t have the knowledge or training to know how to implement agile practices and methods. Part of agility means experimenting, and they have to be willing to experiment with what works in their organization and what doesn’t. It’s not one-size-fits-all. If you can address these things, the rest is relatively easier.

[We have an excellent class to help executives overcome many of these hurdles: Management 3.0: Agile Management and Leadership.]

Why are so many large organizations hesitant to let Agility get down to the front lines— where customer interaction takes place?

I think a major problem is that agile is seen as something technical instead of something organizational. And it isn’t even organizational, it is a mindset. Business agility is still not there yet – people still haven’t embraced it, but I am starting to see it more and more. It is more than just the CIO asking questions, I am now getting questions from CEOs, COOs, and even CFOs.

I am currently working on project with a large bank transforming to agility across the bank. They are doing things like teaching all teams (not just technical teams) how to do Scrum. For example: their audit and marketing teams are using Scrum, and customer care area and other operational areas are using Lean Kanban to better understand how to deliver their daily activities and solutions.

Are there challenges with decentralized teams, i.e. outsource model?

Yes! I think the biggest challenge is that many times those teams don’t have the tools (or the right times of the day) to collaborate well or face-to-face. I work on teams right now where we are just 6 hours difference. But what we do is talk about how to accommodate both sides of the ocean – sometimes this side gives a little, sometimes the other side does. If you can work through that well, you have a better chance for success. Having a working agreement within the team is very important.

How should one plan a transition from waterfall to agile? I’m really finding it tough to convince the team to go agile.

We actually have a Quick tip on Transitioning from Waterfall to Agile that includes some great tips!

What is the best method to measure story point?

There’s no one best method. There are a few considerations that a team should talk through (and maybe test out and adjust, of course!):

• Should our story points be relative? Or should we use hours? (I prefer relative.)
• If using relative measurement:
  • If a new team, look at your backlog and agree on a story that everyone thinks is a ‘medium’ size. Assign that story the number of points that is medium on your scale. If you are using Fibonacci from 1 to 21, for example, maybe the medium is 8.
  • Size the other stories relative to that ‘base’ story.
  • Ensure that EVERYONE understands that your story pointing is for your team and your team ONLY. It shouldn’t be compared to other teams. The pointing is there to help the team manage its work. It’s not a measurement of how good a team is!!
• Other basic tips:
  • Adjust for things like people being gone, other ‘urgent’ work that distracts people.
  • The goal is to set your capacity (or the number of points you think you can complete per sprint) to a sustainable number. I would rather under-promise and over-deliver than the opposite.
  • Adjust your capacity based on your velocity (what you actually got done in a sprint or sprints). Don’t keep overloading (or underloading) yourselves. Use empiricism to adjust and improve.
  • Talk frequently about your points and how you are using them. Is it working for your team? If not, why? How do we adjust?

Are there any specific tools to assess the Agile maturity of a project/program?

Funny you should ask, I am actually working on something now… stay tuned! 

Do you have a question about enterprise agility?

Let us know and we’ll get you an answer!

Submit Question