As part of that session, I asked the attendees – people interested in business analysis, business process, and business rules – to propose questions they were hoping the session would answer. We didn’t get a chance to discuss those questions during the session, so I’m addressing these questions in the newsletter. This is part 2 of 2 that answers the rest of the questions we received.
What makes your agile info different than the rest?
One of the good (and bad) things about agile is that there is a lot left up for interpretation. That’s good because it opens up the opportunity for people to try things out and share what did and did not work for them.
It’s bad because people can put themselves out there as experts even when they have not had experience using the practices they are talking about.
I don’t claim to be an expert, but everything I write about I share from a position of experience – mostly mine, but also from others whom I trust are speaking from their experiences.
I also do not prescribe to any one true framework and am not beholding to espouse the views of any certifying or methodology organization. If I’ve tried something and it works, I’ll let you know.
If I’ve tried something that didn’t work, I’ll let you know that as well.
And I’ve changed my opinions and perspectives as experience has shown that my original ideas were not correct, or at least applicable in some situations where I thought they applied.
Applying Agile in different situations
Can agile support business architecture?
If so, how?
How do I apply agile for process analysis?
Can I do (practice) Agile alone?
There were a set of questions about agile and its applications in particular contexts. As a general answer to these questions, I’ll refer back to how I describe agile: a mindset where you focus on delivering maximum outcome with minimum output, and seek to continuously learn.
If you can approach your particular context in way that you stay focused on delivering maximum outcome with minimum outputs and learn continuously, then sure agile applies. Except I suspect the people who asked these questions had a different view of agile in mind. Probably the specific framework hat their organization was asking them to use. Scrum or SAFe are the two most likely culprits.
If you find yourself in that situation, ask the people who are helping to “transform” your organization what benefits they think you’ll get from doing business architecture or process analysis using Scrum. Chances are they haven’t necessarily thought of it in those terms and are simply requiring all teams/processes to “use agile.”
Should you do business architecture and process analysis in an agile manner? Certainly!
Think about what outcome you’re going to get from doing business architecture, and think about how you can accomplish that with the minimum output (ie artifacts).
Process analysis is a complementary activity to agile activities. Done properly, the results of your process analysis can be used to identify a candidate for work that is done by development teams apply an agile framework. Process analysis also provides something that most agile approaches don’t – insight into what not to do.
It’s also possible to work with an agile mindset on your own. In fact, I’ve even worked with an agile mindset as part of a group where others didn’t initially think that way. In many cases, I was able to demonstrate that way of working and convince others to adopt similar approaches without mentioning the word “agile”. In fact I’ve been more successful in driving a lasting change to working in an agile mindset by acting by example rather than telling.
As to whether you can practice a specific agile framework by yourself, the question to ask is: do you need to? Most of the agile frameworks are built specifically to provide techniques and practices for how teams work together, so they represent an awful lot of overhead for a person working by themselves.
That said, you find the ideas in personal kanban particularly helpful. As its name implies, it was intended to help individuals organize their work.
How do you set up an Agile team?
Understand what outcome you want the team to accomplish.
Determine what skill sets you need to accomplish that outcome.
Identify a small group of people (the fewer the better) who among them possess all the skills you identified.
Make sure there’s a shared understanding of your expectations for the team. Do they understand the outcome they are expected to deliver? Do they know the constraints they are working within? Do they know where they can call their own shots versus where they need to follow specific practices?
Get them the environment and the tools they need in order to be successful.
Get out of their way.
Be prepared to remove obstacles that show up.
How do you handle dual product owner one dev group with both biz & dev backlog items – we have PO’s for each
Ultimately, you need some way to have clarity on the priority of the backlog items. Your PO’s are probably providing priority for the items that they “own”. You’re probably lacking clarity about priority when you combine the two types of items together. It’s up to those two product owners to figure out how to give your team a consistent view of priority.
They may need your help to come up with a way to make those priority decisions. It may be identifying someone as the ultimate decision-maker.
It’s also helpful to understand what the ultimate outcome is and using that as a decision filter for all the items. There will be business-related items that don’t move you closer to that outcome. Throw those out. There will be development items that don’t move you closer to that outcome. Throw those out also.
With the items that are left, encourage an ongoing dialog to evaluate the business and development items against each other to determine how they help you get the outcome you seek.
How do you establish an effective agile culture
Answering this question effectively probably requires a bit more than a couple of paragraphs in a blog post and insight from people more experienced in shaping agile cultures than I am.
So I’m going to refer you to the ideas of Pollyanna Pixton, Paul Gibson, and Niel Nickolaisen. They suggest that in order to establish an effective agile culture, you need to:
- Establish and maintain an environment of high trust.
- Help teams take ownership and don’t take it away from them.
- Align the goals of your teams with the goals of your organization.
- Deal honestly with ambiguity and uncertainty.
You can read more from Pollyanna, Paul, and Niel in their book The Agile Culture: Leading through Trust and Ownership (Affiliate Link)
I feel like all of our agile projects are delivered late
This is usually a sign that your organization has adopted an agile framework, but has not coupled that with a closer look at how progress is measured and success is defined. Usually, projects appear to be late when there is a specific deadline and scope is defined as a list of deliverables or scope items. The problem with that is the list was most likely put together when everyone was at their point of maximum ignorance about the project – the beginning.
I’m working on a project now where the stated goal was to replace an existing system by April 2020. System replacements can be some of the most problematic projects if you are not willing to restate what success looks like and to make tough decisions along the way.
When I face a deadline, I like to change how I define the scope. I make a scope agreement on the Outcome the team is going deliver by a certain date, with the specifics on what we do to get there left open.
So in the case of the project I’m working on, the outcome is reducing manual processes, reducing the cost of error and making a system that can be maintained by more than one person. We need to have something up and running by April, but there isn’t a hard and fast list of features that it has to have. The product needs to have the features that are necessary to support the business process that already exists. We defined success this way because the system we’re replacing is twenty years old.
As with every legacy system, there is a lot of functionality that is no longer needed. There are a lot of features that exist solely because of the way the system was originally built. The system we’re building does not necessarily need all those features if we change the process (by streamlining it). To have a specific list of features at the beginning removes our ability to improve the process and get to the outcomes we’re looking for.
So to get away from having late projects, you not only need to adopt agile, but you also need to define success from an outcome perspective, and you need to be able to make the tough decisions about what you are and are not going to do in order to get to the desired outcome.
How to get PO to adhere to MVP?
The answer to this question is similar to the previous one. The TLDR;
- Define success in terms of outcomes.
- Make sure your PO has a very clear understanding of Maximum Outcome with Minimum Output.
- Be clear on what you mean when you say “MVP”. (There seem to be as many understandings of that as there are about “what is agile”)
Want to understand more about how testing fits in. Timing, expectations
Here’s a description about how the team I work on now handles testing. I think that may address this question.
How do you address “business” perception that agile is just doing more faster?
First off, make sure there’s no one in the IT part of your organization that’s fostering that perception. This happens when people claim “that if we just adopt agile, we’ll be able to get this impossibly long list of things done.”
As mentioned in the session, agile alone will not get you to better, faster, cheaper. You need to pair a finely tuned development organization with an overall organization that is willing to define success based on outcomes achieved rather than outputs delivered. This allows you to minimize the amount of things that you have to deliver.
You also need people in your organization to be willing to have the difficult discussions and make the hard decisions about what you are not going to be able to do.
You aren’t going to get everything done that everyone wants done. Stop trying. Stop claiming that agile alone will help you do that.
Adoption & Transformation
How other companies handle the transition to Agile
How to transition to agile from waterfall with ease
Transitioning BA’s from traditional to agile thinking
How do you build up the agile org from scratch?
Does the whole organization need to be ready to start agile?
How can I use/apply Agile in a traditional environment?
A good way to get answers to these questions is to look at the stories from those who have done it and lived to tell about it. A good place to find those stories is the Agile Alliance website. Specifically, the experience reports focused on agile adoption.
How to scale?
As with the adoption & transformation topics, I’m going to let the people who have scaled an organization and lived to talk about it share their stories. Here are Agile Alliance experience reports focused on scaling.
Is SAFe really safe?
Unless you have several teams all working on the same product, in which case there may be some helpful practices. SAFe contains everything you could do, but you need to apply you understanding of your context to figure out what you should do.
Remember what Alistair Cockburn described: A framework is the structure for something that has enough present to force the final shape but enough missing so that different people can choose different variations. A Methodology is the set of conventions the team agrees to follow.
Even an organization as large as the United States Air Force would prefer not to use SAFe.
I’m really liking the writing on this slide. I hadn’t thought of it that way, good to see. pic.twitter.com/TgkkBjY1fU
— Alistair Cockburn (@TotherAlistair) December 10, 2019
Which leads nicely into the next set of questions.
Kanban vs Agile
Difference between Scrum & Kanban
What is the difference between Agile, Kanban, Scrum
There were some questions about the difference between X and Y.
Let’s start with the difference between Agile and Kanban or Scrum.
Agile is a mindset. It describes the way in which you can approach work.
Kanban and Scrum are two frameworks that give suggestions on how you can work in an agile fashion.
In other words, Scrum is a subset of agile, not an alternative.
The main difference between Kanban and Scrum are how they organize work (Kanban organizes work in a flow, Scrum uses timeboxes) and how they help drive adoption. Kanban uses a start where you are approach and Scrum drives some fairly significant changes to teams and structure.
How to overcome negative bias toward agile by people who have experienced poor execution in the past
Stop using the word agile. Instead, say “Hey, I think we’re having a problem with X. Let’s try Y to see if we can fix that problem.” Where Y is some agile practice that seems appropriate for your context.
You’re not trying to be agile, you’re trying to be more effective. Agile values, principles, and practices can tend to be good ways to help you be more effective. But it’s not because they have the label “agile” it’s because other people have tried them and found that they work.
Dev Team alignment with PMO/PM for other project-related deliverables
PMO/PM and other related deliverables are outputs. If you look at this question from a maximum outcome with minimum output perspective ask yourself do I need to do these outputs to arrive at that outcome. Most likely the answer to that question for most PMO/PM questions will be no.
But you also need to look at proper stakeholder interactions and what parts of your organization request in order to stay informed. There will be times that you need to do extra work to keep those parts of your organization informed. When you get those requests, ask what they are using that information for so that you can figure out the least effortful, least disruptive way possible to provide that information.
You need to provide your stakeholders information. The effort to do so shouldn’t be overbearing.
What are the 7 things?
This question was asked at the beginning of the session. Hopefully the session itself answered this question.
If you need a reminder, here’s the material from the session.
And here’s an update collection targeted toward product people in general.
How do I keep Scrum from feeling stale to the team?
I’m not sure it’s that important if Scrum feels stale to your team. I’d be much more concerned if people on your team do not feel that your team’s methodology is working for them. If you find that is the case, it’s a sign that your approach to inspect and adapt is not working.
When you find yourself in that situation, it’s a sign that you need to try to get serious about action-focused retrospectives.
If I am on an agile team or project should I be on other projects?
If you are on any team you should be on that team and no others. One of the biggest failings of IT over the past few decades is the idea of resource pools and partial allocation to multiple teams. The cost of context switching is a major contributor to ineffective IT projects.