The Better Business Analysis Institute presence, the Better
Business Analysis podcast with Kenjan Walsh.
Hi, everybody. It's Benjamin Walsh from the
Better Business Analysis Institute.
And this is the Better Business Analysis Podcast.
Thanks for joining. This week we're going to talk
about Agile. We talk about Agile quite a bit,
but specifically the topic I want to talk to you about is the
pitfalls and optimizing workflow.
OK, so I've called this topic in this episode Agile Done right,
Avoiding common Pitfalls and Optimizing Workflow.
When I save the workflow, I'm talking about the processes
within the agile environment and what you need to have set up in
order to run a tight ship. And I am really talking about
agile delivery here. So the delivery side, not other
flavors of agile for transformation, you know
organizational transformation or or culture shift, this is really
around delivery and if you've got a development team and
you're in that environment, then you could think of your agile
development in this context. So we're going to go straight
into it. We're going to start with
avoiding common pitfalls. And so I'm going to talk about
why they're pitfalls and some acknowledgments that you need to
be very clear about so you don't fall into these holes.
I don't have all the answers here.
I'm sure there are good techniques for digging your way
out of those pitfalls. If you fool them, just avoid
them to start off with. And I'm sure you have some
feedback. So if you've got feedback, tag
me in, tag the institute in, and we can talk about your feedback
around pitfalls that you've found when using Agile.
So I've got 5 here, 5 pitfalls. I didn't want to boil the ocean
and come up with 20s. So 5 common pitfalls that I
think you need to avoid in Agile.
We're going to start with number one.
Number one is so important and it is.
Do not treat Agile as a silver bullet, OK?
The pitfall is treating it as a silver bullet.
Agile is a wonderful framework, powerful.
You know, if you think of Scrum, it's so good in terms of an
evolution of how we were doing things beforehand.
You know, people can get overwhelmed with it from a
cultural point of view, from a, you know, anti SDLC, waterfall
approach. But Agile didn't fix all the pro
program or project delivery challenges we have.
It wasn't a magic fact. Fact.
OK, it it doesn't come into the organization and fix everything,
so don't treat it like it is. Or, you know, I've got a
solution for that. Let's go agile.
No, that is not what. What problem are you trying to
solve now? There was a common problem with
the fact that requirements changed throughout the life
cycle of our project or a piece of work.
There was common problems around the fact that we weren't
engaging stakeholders enough, We weren't demoing enough, We
didn't, you know, work on the most valuable stuff up front.
We didn't time box how we did things.
There were lots of good reasons for Agile, and that was the
reason we implemented it. But it isn't going to solve
things like project risk necessarily as much as other
methods. It isn't necessarily going to
outline exactly how to write a user story with enough
information for your designers and your developers.
It isn't going to define the role of the BA, OK?
So it's not going to solve all those challenges and especially
if you're adopting very complex, maybe you've got a complex
organization. So I'm not saying complex in a
derogatory term, but if you're using for example Scaled Agile
for Enterprises safe framework, which is the type of agile
methodology, you know that that is multi layered.
It's got all sorts of things going on.
It talks about a whole lot of different methodologies now,
again because it's even bigger and more complete or robust if
you like. For an organization, people are
going to also go well. This is even better because it's
got all the processes and procedures we need and the same
way Prince Two didn't solve all the delivery problems with the
project. Agile or Safe or flavor of Agile
framework is not going to solve all your problems.
It is not the silver bullet. So don't treat it as such.
Just treat it as the way in which software which is
primarily, is delivered through a delivery team.
The other thing that happens. So flipping back to looking at
Sprint. So the if you don't know what a
Sprint is then they are the you know time box periods where
you're pulling things off the backlog which is all the
requirements and you're pulling in what we should do next in a
time box period of time which has a Sprint, has a goal and a
definition. There is a major pitfall here
and it's called waterfalling in Sprint, OK.
And it's a little bit of a nod or a bit of A to say that you
know we've we're our waterfall mindset of doing everything to
the you know from one our requirements one to 100 all on
go and kind of sneaky in waterfall.
There what happens is that people are trying to cram
traditional kind of sequential fight fight phases into short
sprints. So they're saying well and for
example for Sprint one doesn't matter if it's two weeks we'll
go over 2 weeks it needs to be 4 weeks and we need to do at least
the infrastructure set up in the first Sprint.
That is actually a wonderful project.
It is, and I'm I have nothing against for projects by the way.
But if you're deciding you're going to do Agile, you don't do
that. So what you do is you do a slice
of the solution from beginning to end for the job to be done
regardless of the the layer of infrastructure you need.
And you try and do those the most vital steps, the most
valuable steps at that point in time in the Sprint.
So another way of saying that is you're not doing HDLC where
you're going. OK, we'll do the infrastructure
1st and we'll do the design. You're not carving it that way,
you're carving it on customer value.
So if you are doing a Sprint 0, setting up infrastructure 1st
and all the rest of it, don't kid yourself.
You're not doing agile and there's no reason.
Sorry. Just be clear here, it's not an
and or there's no reason why you couldn't do an infrastructure
project if that's necessary for the product you're doing as a
for project. Separate to this and then do an
agile project to use that infrastructure to make product.
There's no there's I'm not saying you know you have to do
infrastructure in an agile way. If you know that this box needs
to be done, don't try and cram it into an agile methodology.
Just get that done and then you know in sequence or for in
parallel or after the fact. Start using delivery agile for
deliver, delivering customer facing products.
You know on top of the infrastructure you need to, you
know, emphasize the idea that you're doing iterations here
you're doing, you're not trying to implement a full solution
when you do agile. So let's talk about more of a
product, not an infrastructure mindset and say we're building a
product, a web app. Your job isn't to go, OK, well,
I need to have a login Screener, you know, a front end, the
database done and you know a landing page before we actually
do the next pieces of functionality.
And I need to do that all straight away.
It could be what that stuff's not important.
It's not important to do login straight away.
It's not important to necessarily have all those
account features or even have a database to be honest.
Sprint Zero could simply be doing some designs for Sprint
one, so there is no Sprint 0. Just to be clear, Sprint One is
showing designs to customers. It's simply a business facing
Sprint. So again, when we do our agile
delivery, in the same way that we could split out prerequisites
in a different type of project, set up methodology like
waterfall, we could equally include inside an agile project
the first Sprint or first couple of sprints may not be technology
driven, they could simply be sprints around focusing on
customer feedback and design. In case you might, your delivery
sprints might only happen at Sprint six or something.
OK so that happens commonly and sometimes those sprints are done
through rapid prototyping. They're done in big room
planning and and that for me, I actually support that it's it
gets developers involved early and tested but it's actually got
nothing to do with producing any code it's all about producing
designs and feedback from customers.
So definitely keen on that but again don't try and do all your
analysis in Sprint one, that's not the BA phase and and be
honest with yourself if you need to do so.
Sorry. Here's here's a here's a bit of
a giveaway and we talk about this at the institute.
I have a really strong belief that enterprise analysis,
strategic analysis in detailed sorry high level requirements
capture should all be done before should be done in a in a
very you know project. You could say waterfall manner
but a a series manner manner until you get funding to then
get into delivery and deliver some stuff be that mock ups or
code and then start using agile proper at that point.
So I have a that's my belief. You might work in a different
way. However, I would say that
regardless of the fact know which methodology you're using.
The other one of course, which was one of the purposes of
moving to a job but really hasn't been at all helped
through using these methodologies is scope creep.
So this can happen for lots of reasons.
One of them is the fact that the backlog just keeps getting added
to it's it becomes the project becomes a request manage, not a
request management of requirements that are on the
fly. OK?
And again that's why the method of doing some high level
business requirements and objectives basically Epics
upfront reduces that completely It it actually reduces the scope
problem that I'm talking about right now.
So you have that first layer of user stories all ready to find
before you start that produces this problem.
But if you literally say we're going to backlog, we add it to
the backlog, which is a lot of agile projects happen, then you
actually have an uncontrolled door there.
So you have effectively uncontrolled scope and that will
derail your agile project. I see it all the time.
It's to do with having you know an inbox that continually grows.
It has a problem with the value items that have been put in the
Sprint up until you run out of money not being enough to
deliver an end product that anyone wants.
It's it's the problem with not really architecting the solution
upfront in some shape or form. So to manage scope creep that is
really a project manager's job or product manager.
If you don't have a project manager working on it, they
should be looking at this. You need to manage strategies
for managing scope. There are things like backlog
prioritization. There is no reason why you can't
say, add things to the backlog with an understanding that they
won't be done probably or they won't be prioritized throughout
this process. Sprint planning can reduce
those. But again, I don't think those
two agile method or built in controls for agile completely
solve the issue. I think it's being using user
storyboards really helps here. Being clear about the jobs to be
done helps here really understanding that not only do
you need to deliver the most valuable stuff, not not chosen
by the product owner, by chosen by your customer and then
facilitated through a conversation with your product
owner, but also the fact that you've got all the critical
items that are needed to deliver at the end of your project.
OK. And I want to just clarify that
again or say that in a different way at the end of the Sprint.
You're not. You're supposed to have a
working prototype of a product that you can demo.
OK, it could be a piece of paper, OK, it doesn't have to be
a piece of software. And you should be able to demo
the progress that you've made. That's the whole point of using
Scrum. Now, that doesn't mean it's
really full release to the, you know, to the public at this
point. And just so you can demo to the
stakeholders to show them it doesn't mean you're releasing
necessarily on the final infrastructure or environment to
go live. That might be another Sprint.
So if that is the case, then you need to be careful that you've
built in enough time to get it to, you know, public release
ready if you're doing a public app and if you keep doing the
functions, you're never going to get the chance.
I'm working on a piece of work at the moment which is a startup
company working on a mobile web app for businesses and
consumers. And we're working on still
working on functionality, base functionality before it gets
demoed to some businesses. And you know it still needs some
work and it's not polished at all.
And you know, part of me wants to make it really sexy before we
show anyone, which is the opposite of what you should do
when you're building a new product that's new.
However, what I'm well aware of is there's a whole bunch of work
if we wanted to move a mobile app and a web app to scalable
architecture once we've even gone through the agile
deliveries side right? There will be a number of
sprints so I can't just estimate the development time or the
number of sprints will cap it. I know there needs to be this
pretty water fully process of releasing apps to the App Store.
You know, putting a website on scalable AWS architecture or
whatever the architecture is. You know doing testing, doing
pin testing, all the security side that is an additional piece
of work. It's pretty common, it's pretty
standardized, really needs to do it agile.
I just need we just need to do that as part of the team and
that's going to be over and above the development cycle, OK,
before release. So just think about that.
So in that case that isn't scope creep, that is stuff that you
should have in scope and be really clear that you've got
even less room for the backlog items, that the product
functional backlog items. The next one that happens even
though we the whole purpose of Agile is to try to stop the
surrounding is communication silos.
So that's still not broken down. So we used to have this big wall
between the requirements phase and the delivery phase that was
a big wall that almost like the Berlin Wall.
We've broken that down and we can now communicate you know
between West and East Germany. But we haven't solved other
communication issues which might be which might just happen, what
might happen when working on a project and then more individual
silo. So you have communication
breakdowns between barriers between teams, stakeholders,
clients, product owners and clients.
If you've got a project manager, you've got project manager
versus product manager issues if you've got both of those.
And so you really need to be more ultra transparent.
And no, because you haven't run, because everything is fluid and
agile. You need to be ultra transparent
and ultra collaborative. You almost need to document your
communication more than you would in a waterfall situation.
And you need to communicate that you don't.
When I say document more I don't mean 100 page spec.
I mean using visual communication tools like
whiteboarding online whiteboarding tools and post its
and a room and you need to have all the stuff that people can
come and look at down to ideas off because you're you're
running quickly and so you need to be better at occasion with
their job. The other thing of course is
that the whole point is that you should have this development
team that's working together and should have multifunctional
teams and all the rest of it and one that never happens.
People are on other projects. So when you you know, you've got
to think that if you're product owners across three products,
for example, you know they might not be on when you're doing the,
they might not be thinking about your product every every 5
minutes. So that's hard.
And then also you might be bringing in an architect who now
needs to, you know get up to speed about where you're at or
ABA or a tester. So you generally find the core
team is generally A scrum master and a couple of developers,
maybe a tester and maybe ABA if you're lucky.
Now that that means that all those other people are not up to
speed with you. You might, you know he might be
working really, really well. And then I've got two things to
say about that. One is I didn't like this when I
first saw it, but I now believe my current belief this week is
that if you have a highly functioned delivery team like,
you know, developers, testers, maybe you've got, maybe you
could be a a scrum master and they're like cranking it.
Don't break that model just so they're more collaborative or so
you can insert APM and and rigor into it.
Let them run fast and just understand and agree with them.
You may decide on the inputs and outputs.
They may decide they want requirements in this format.
This is the audience. They work really well this way.
Don't wreck their great working way.
You may even be jealous of it by just getting involved in their
in their jazz right and involved in their stuff.
Feed it, feed the machine. They should be a highly
functioning machine. And if you've got great inputs
and outputs in their demoing, let them run that way.
You don't need to wrap around unnecessary meetings to do that
and that's where I've seen Agile being the most effective as in a
development in that kind of environment.
And if you're in a startup company and the largest startup
company then you may and you're only working on one product,
then of course the product owners should be involved in in
everything as well. That isn't the case for most
organizations we all work at. So we've we've just covered off
treating Agile as a silver bullet.
Don't do that. Water filling and Sprint scope
creep communication silos and the NUM.
The last one I'll give you their last pitfall is around metrics
obsession. I I haven't seen this done that
much in New Zealand. I have seen this done a lot
overseas and that is using all the measurable chart charts
around which will come with agile which kind of good like
burn down charts and you know how much story points are we
doing on average. And I think it's important
insight to use. If they provide actionable
insight but they need to be aligned with your project goals
it look we're not going to we'll find room for improvement.
If we have moving we've got three, you know 3 or 4
developers then we might be able to work out some trends around
quotation or this person's really bad at estimating stories
and you should be doing that in a group setting anyway so you
know they're the group is deciding on the on the points
and not that new developer burn down has dropped.
You know there's some indicators that you should look at if
you're a great scrum master who's working in that team.
Don't get obsessed with it, OK, do not get bogged down with
measuring thing. The most important measure is,
is the customer, either internal or external, using the product
and are they liking what you're generating in the demos?
You know do they feel like you're meeting their
expectations and that you're heading in the right direction
and and you're generating value for your time.
They're the metrics that are the most important.
There are five common pitfalls that I've seen in agile teams.
I'm sure there are many more and I'd love you to ping me and tell
me about your experiences and I might do a follow up podcast to
talk about that. The next part, and again I've
got five of these items, is around optimizing your agile
workflow. So #1 is embracing cross
functional teams. You need to have developers.
Designers, I missed out before, sorry, should heavily be
involved. Designers do fit between the
BAS, you know, the designer and the tester.
It's really important they are a missing solve sometimes or an
external company. So developers, designers,
testers, you know, BAS, other stakeholders.
They work together OK. Especially if you're working on
one product. You need those people to sit
together, even if B as working on multiple things.
They should sit around that team if that's their prime focus.
They're an agile BA, for example, Then they should be
working close to their team, at least understanding what's going
on, checking in with them, coming to some of the stand ups,
being being a chicken as opposed to a pig.
And if you don't know what that is, then Google it.
But it's around who's got skin in the game and who should talk
more at stand up. So you need to embrace the cross
functional team and and that includes SMEs who might work in
the team to a point that SME I've generally found becomes a
product owner in some in some settings good and bad thing
because they need training. The next one is around refining
your ceremonies. OK so like I said you have a
highly functioning development team who's really great at doing
agile. Got a great scrum master.
Well, you should be assessing the effectiveness of those
ceremonies. OK, the stand up, the retros,
the even the demos and the way you demo, are people actually
enjoying it. You know, maybe they got a a
hiss and a bang out of the first one because I've never done one
before. But actually maybe you need to
be a bit more interactive. A PowerPoint presentation is not
enough. Maybe there will be hands on,
maybe you could bring in some customers that they could talk
to. You need to adapt those.
So in terms of measurement, it's more around the measurement of
how your ceremonies are going, how effective they are of stand
ups are always going over 15 minutes, then something's up.
If you're doing Agile proper, if you know every morning, 15
minutes Karen's telling you about her day, then maybe you
know that's you need to manage that or have a personal kind of
chinwag or before we do stand ups in the morning because
that's not what it's about or someone's just going through so
much detail about what they're doing.
You know every single test case they tested, then maybe that
isn't you know the right place for that and you need to manage
that And if you don't have an effective scrum master then you
need to do it as a team. The other one is automation.
OK, so the whole point of Agile, and I do believe that when
you're doing Agile and you Scrum, and I've looked at
requirements packages for years, I do believe, and again in 2024
using something like Jira and using something like Azure Dev
OPS, I'm going to, I'm just going to give you those two
examples because they're the most common.
They're relatively cheap. You use them.
I think Azure Dev OPS is actually even free automate the
process of, you know, Kanban. You're bored of what you're
what's in progress and what needs to be done.
Blockers automate the ticketing, automate the backlog management,
the notifications, and it will let you free up.
Like I said, it's it's the mechanics and the engine that
allows the people in the engine to to move quickly just to
automate all that stuff. It should be common.
It helps align yourself with the process so you're keeping some
of those fundamental building blocks of Agile like in place,
even if you're, you know, making them more aligned with your
organization. As long as you're doing all
those steps, maybe set that up. It doesn't take that long, half
a day a day to set it up in Jira and then you're away laughing to
a point of, you know, if someone wants to add things to the
backlog then maybe you have a use the portal side and allow
them to to send things through. It's something I do quite often
I get asked to do for organizations and I think it's a
really, really good point is to automate when you can.
The other one a little bit more soft like I can.
I'm not always a, you know, a hard ass.
I can be nice too. And the next one is really
important as AI. Don't know if this even happens
waterfall projects. But I do know like if you are
lucky enough to deliver a Big Bang project, you know, there's
usually celebrations, there's usually pets on the back.
You get mentioned it's actually it actually can be a very quiet,
sad life. Writing on business cases I have
for six months, you know with with no pets on the back.
However, with Agile, you have an opportunity and you've got to be
careful that you don't avoid any celebration because you're doing
small relations. So you need to celebrate
progress and win, OK? You need to reward and recognize
individual and team achievements to motivate people.
So instead of doing the maybe The Big Bang because you don't
have that and you still do have an ultimate relation to a
customer and you should celebrate that, you should
celebrate every time. What did we do well, who did
that really well this week? You know who did something extra
special or had a great idea that they talked to the product owner
about and now we've got a better product.
Who's, you know, adding value, who's ultimately passionate, who
stood, you know, stayed up all night testing the bug that we
just couldn't get right so the engine could continue to pump
out on Monday morning. Recognize that, you know, things
like Prezi cards, head on the back, free coffee voucher.
You know, just saying well done, Sam.
You know, that is the kind of mindset you need to have.
So that will help people feel better, motivate and and and
uplift morale. So you should be doing that.
And again if you don't have a scrum master jazz that or a team
leader who's doing that, then do it as a team also, yeah, make
it, make it substantial. Don't make it.
When I say make it, make it an effort.
It shouldn't be. I get a little bit vomity in my
mouth when I see you know there's a button you can press
and it's like celebrate Bob, celebrate Sam, celebrate Karen.
It's like well you know that that's nice, but it's a little
bit cheap. If you if, if I feel like always
feel like you should put a bit of an effort into celebrating
someone's success, not just pressing a button.
The next one. The final part to have covered
embracing cross functional teams, refining your ceremonies,
automate where possible. Celebrate progress and wins.
And the last one in optimizing workflow is continually learning
and improving. OK, this is the mantra of agile.
That's the whole point of it from a cultural point of view,
that you should do the same for your own team.
You need to embrace and encourage a culture of
continuous learning and experimentation.
Be open to trying new things. Adapt your approach based on
feedback and results. OK.
If you're the, you know, the hot development team who always, you
know, pumps a product out on time, on budget, meets
expectations, but someone comes through and goes, oh, actually,
do you know that just from a design point of view, I've just
noticed that one of our competitors is really using this
new progressive disclosure way of designing, which is when you
show information only when users need to see it, not not a whole
page of questions, for example. How can we try that, You know,
embrace that and take that feedback on board and take it as
a challenge. We should be trying new things.
If you want to have the best product on the shelf, if you've
read Power of 1, thereby Peter Thiel, then you'll understand,
you know, if you want to be the best, you need to produce the
best, best products. And we should always be looking
at improving. Now that doesn't mean that you
have to always have a polished product, but once you're in the
market and once you're just, you know, tweaking the product or
you know, adding new features to your base product, go back and
review what you've done. OK, so always learn and prove
and I do think that our recommendation is if you have a
Kanban board then you might have your blockers on there and what
you've done and what you're doing in the future.
For example, I would add suggestions for improvement
column and then as your teams are doing the stand up, you can
think of better ways of doing things.
It's not an opportunity to give other people in your team a bit
of grief. It isn't like Oh well I think
you should be but if things come up we could go, we could do
this. The opposite is true though too,
and which is sometimes development teams take it upon
themselves who inflate how long a story's going to take by using
new kit because they want to. So an example being maybe
there's a new HTMI, sorry HTML controller.
That's really cool that everyone's using and I've
decided the development team said I really want to do that.
So for the next Sprint I'm going to try it.
Now there's choices there, right?
The choice is to use the standard way we did it or the
choice is to use something that needs to be tested more because
we've never done it before and it might have a different
experience for our users. So that is a that is a question
for the product owner to make a decision about whether or not
they want to invest in that. There are some benefits using
new kit making our product better, but it should really be
their their decision. So just be aware that
development teams have a tendency to want to use new foul
fancy bells and whistle whistles and that can sneak in as well.
So that's for me not really within alignment with what I'm
talking about in terms of learn and improve.
It doesn't mean you've got a free ticket just to try new
stuff all the time without engaging with the team.
So there is some other just hot topics you need to think about.
How you can effectively manage stakeholders, expectations that
they are hard to manage, not just keeping them aware,
transparent and collaboration. Make sure you think of creative
ways to do that. Measure success.
How do you measure success of an agile implementation?
What is the ultimate success measure, especially if your
product's thrown away at the end of your releases?
That is a positive thing because it means you're not wasting any
money on that. How can you measure that is a
success? Because that is success.
But it's looked at in a different way.
Just be really clear around the boundaries of Agile and some of
the myths and misconception about what Agile is.
I I believe it's agile delivery, which we're talking about today.
And how do you ensure that those best practices are scalable and
sustainable in the long term? And that's by, you know, being
flexible, being adaptive, always open to learning.
And so that's what you should be doing to really get Agile done
right in your organization. I hope you've learned something
today. So that's agile, done right,
avoiding pitfalls and optimizing workflow.
I hope you've learnt something today.
I really want this to be a discussion.
See if you've got any feedback, let me know.
I want to hear about your Agile experiences and I'll see you
next time.