Nothing lasts forever and there`s always the next big thing. Has Agile won or is it dead already?
Angela Prentner Smith

Something I’ve been pondering for a while is what’s the next big thing in project delivery? Agile has been around for a while now, and businesses are still struggling with its adoption. I asked the IIBA (International Institute of Business Analysis) LinkedIn group what they thought, and I got about 40 differing opinions. I did some research and again I got a typical mix of views.
 
‘Agile is dead already.’
‘Agile was never meant to be used for what it is now.’
‘Agile is the only way.’
‘Businesses need to be agile, but that doesn’t mean they need to adopt a specific ‘agile methodology.’
 
The conclusion I’ve come to is that actually all of those opinions are right. Most importantly - there isn’t an ‘Agile’ silver bullet that you can implement into your business and make everything better. There isn’t a methodology that you can stringently adopt that will mean all your projects get delivered effortlessly. Indeed the very premise of agile, as a word, a concept and a manifesto, is about being adaptable and responding to change. A strict project or development methodology breaks that very premise. 
 
The Agile Manifesto
 
The Manifesto for Agile Software Development was just that. A manifesto for software development. The problem with that? It was never written to extend beyond software development. As those of us with war wounds from projects know - a large business project never starts and ends with just software development. Agile was developed to improve software development methodology. The original 17 founders of the agile manifesto, are still trying to do that. Some have moved on from the original manifesto and are looking at new and better ways of developing software. 
 
Death by Popularity
 
Yesterday I attended a conference on family friendly working. The word agile was used frequently to refer to flexible working in terms of hours and locations. I also heard agile used in reference to hotdesking. Whilst these applications of the word aren’t actually wrong - agile just means nimble and flexible - they do muddy the water when we have projects of work using Agile methodology. The popularity of the word agile and its potential overuse just adds to the confusion. 
 
There’s also the Agile Marketing movement, and more generally discussions on agile cultures.  Again both meritted uses of the word and potentially successful ethoses. However they may further add to the confusion when business leaders, technologists and marketeers come together to deliver a project - whose agile is this anyway?
 
Design vs Development
 
I’ve personally been stuck in the middle of this argument. What a design sprint entails in an agile world vs a front end development sprint don't deliver the same things, don’t have the same rates of execution, the same stakeholders and beyond. Sprint - that simple concept within the agile nomenclature can cause masses of confusion, and honestly they don’t really align. Design sprints need to test features with users quickly, and so does development, but front end to back end development don’t follow the same creative cycle of design and they have different gestation times.  Sprints are just time periods during which specific work has to be completed and made ready for review, but you can’t get the same amount of development done as design in the same timeframe.
 
Design methodologies
 
Service design, user and customer experience design, user interface design and all the rest could be described as methodologies themselves. But once the design has been done, and technology is required, the agile software development lifecycles begin. These should still iterate, test and learn with users, and business counterparts. They needn’t be at odds, but what is needed is clarity between the design methods and the project approach or development lifecycle. De-risking design and de-risking development can both be achieved through iteration - a key premise of agile, but not necessarily within the same sprint cycles.
 
Beyond Agile
 
I’ve read a bit on DevOps and think this might be where to hedge your bets on the future of software development at scale. Scaling is certainly one of the key criticisms of agile project methodology. What works to build a small app doesn’t necessarily scale to an enterprise wide programme. That said traditional waterfall methodology is flawed, as Mike Gill discussed in Seeing the Light and Go Agile or Go Home. 
 
Where that leaves us
 
So businesses need to be agile - that is flexible around the needs of their teams, their customers and logistically in line with the digital age. But that needn’t be confused with agile software methodology or design methodologies. The most important point in developing a project approach is:

1. That there is an approach that is communicated and understood by all participants
2. That it is not delivered in silos
3. That it is designed around the needs of the customer and that co-creation is looked for
4. There are common goals
5. It is open to change when things don’t work.

 
Meaning it matters less whether we call it agile or anything else and more that everyone knows what’s happening, is working together and willing to be progressive rather than dogmatic about the methodology.
 
I do believe agile is better than waterfall, but I don’t think that’s the last word on the subject.  There will be the next wave of software development methodology and beyond that businesses will be more agile as they are enable by technology and respond to the demands of the workforce and their customers.

We have launched an innovative, industry led solution to embedding people centred project disciplines into businesses to aid 'agile adoption' and 'digital transformation'.  We'd  love to share that with you.

What business leaders can gain  from our Horizon Watching service
​Denis Yordanov

 
​Information has always been important - not only for business, but to society as a whole. And information has always been around us, be it in the form of books, newspapers, or word of mouth. However, in recent decades, the amount of information available to us has increased exponentially and is increasing at even faster rates.

The way we access information has also changed. Through digital means, we have endless content at our fingertips. In fact, there’s so much information that it’s becoming increasingly hard to sift through it all and distill the most important pieces on which to base your decision-making. This is especially true for business leaders today - the rate of change has increased proportionally to the amount of information available.

It’s no longer sufficient for business leaders to gather information about what has happened to their business. In order to prosper, they need to know what is currently happening and more importantly what will happen in the future. They need to know what changes are taking place, what innovations there are, what their competitors are doing, and what the current and upcoming trends are. None of these exist in a vacuum and all of them act in constant reciprocity, it becomes almost impossible for individual business leaders to keep on top of all this. It's hard for them to justify spending their time and efforts  on forecasting what 'might happen' to their  business in the future opposed to what is happening to their business right now.  But the fact is that if you don't, you risk falling behind your competitors as you scramble to keep up. 

Horizon Watching - This is Milk's approach

This is Milk’s Horizon Watching service tackles this very issue.  It is exactly what it says on the tin: we aid you in discovering and assessing what’s potentially on the horizon for your business. We provide you  with information and predictions about trends, events, and changes that may take place in the future and help you examine what their impact will be on your business. We can compile a trend report for you with all the major trends that might shape your industry and we can work with you to analyse what they might mean for your business specifically. Finally, we can summarise and compile all findings and recommendations in one detailed report. This will help you to set strategy in the years to come and provide a roadmap to stay ahead of your competitors.

So how does it work?

• We look at various economic, technological, social, and environmental trends and the connections between them and analyse how they might impact your industry. Then we highlight the challenges and opportunities, all in one report.
• We host a one-day discovery day with you in which we look at the trends report and guide you and help you to think about what those trends might mean for your business specifically.
• Finally, we compile all findings and recommendations for the future and add them to the initial macro trends report.

Aim for the horizon and get in touch with us today!

The Milk Bar - Horizon Watching

The Milk Bar, our quarterly event where we discuss topics on transforming Scottish business for the better, is coming up soon! The topic of the next Milk Bar is on Horizon Watching and we have lined up some very relevant and engaging speakers and workshops.

When? Friday 5th August 2016, 17:30-19:30
Where? Snook Interchange Glasgow, 4th Floor, 84 Miller Street, Glasgow, G1 1DT

For more information on the speakers, the Milk Bar and to RSVP visit our Meet Up event page

Learn more about Horizon Watching and our other services!

Angela Prentner-Smith

Change is constant, exhausting and happening quicker than ever. In business we are enabled by technology, challenged by competitors, pressured to deliver more by our customers, and expected to offer more to our people.  
​
It’s a pressure cooker - if we let it be.  

And sadly, what I’ve seen in our industry (and by this I broadly mean those we call business analysts, project managers, change consultants and so on) is an inability to meet these demands. Projects fail. They fail in meeting their objectives, often fail to deliver - or deliver meaning - and the people involved often have little faith in the project and leave with war wounds, demoralised and jaded.  To quote a business associate “I’ve never known a happy business analyst”. What a sad state of affairs. I could quote lots of research in the field of failed projects, but just do a quick google and it's all there. 

Then there’s the new world and small businesses, where I’m beginning to gain useful insights. There's sometimes little thought given to how best to approach a project or how to define what suppliers should do for them.

The desire and pressure to get things done quickly, often leaves re-work, as insight hasn’t been gathered or analysed and the change therefore, hasn’t been defined with a view of actual user needs. For example, I frequently hear – “I need a website”, or “I need SEO”.  Yes you do need these things, but they aren’t ‘it’. You need to look at who you’re talking to, what you are trying to achieve, what you are selling and how you are going to build and maintain it first. Your website and your SEO are just a part of the puzzle, and require a lot more than just visual and technical design.  
It's often just a lack of the skills required to effectively manage every element of a project, where key people are stretched beyond their skillsets - which is great for personal development, but sometimes we all need a bit of outside perspective and experience to define what a business needs. It is a skill, and it's what business analysts should be able to do. 

Or alternatively change just happens organically. To some extent this can’t be avoided. We can’t plan for every eventuality, we don’t have crystal balls, and we need to be flexible. But without foresight, design and management of your business’ change, you build in inefficiency, leave much to chance and often fail to measure how your business is doing.   

To quote Francis Bacon: 

So why aren’t businesses coming to business analysts and project managers for help with the change? I think there are two answers.

1. Our industry has an acknowledged competency issue.
2. There’s too much confusion about what we do. 

The term business analyst has become loaded, unclear and taken on way too much. People don’t know what we do, and if they do, they don’t think we’re generally good at it.

​This is quite an impassioned subject for me. I set up a whole business based on the belief that “Change, needs to change”.  I’m a passionate person. I want to deliver for the companies I work for.  I want to make things better, and I’m working out how to do this. I won’t get it right first time. I don’t think that’s possible. Change is an evolution. We learn as we go, it’s about capturing, and acting on this knowledge and empowering those around us to make decisions for the betterment of whatever it is we are doing. 

Here are my thoughts on why there is a poor perception of this industry. 
​
Change “management” is outmoded

The current industry for change professionals is huge, as we said – change is essential and certain. The people who have carved a career in project change are generally paid well, often on day rate contracts and have often stepped away  from permanent employment promising personal development, a hierarchical ladder to climb and empires to build. They are forming a buoyant contractor market that if played correctly they can float around in for a lifetime. However, projects themselves still have massive failure rates, lack satisfaction for the people working on them and generally are not progressive. 
​
Change is everything

It’s as broad a concept as you can get. Change management however is not. Change management could be defined as structures of people, with tools and methods of controlling change – generally speaking.  However, where I often see an issue is a clash between designing of change and delivery of change. It’s often a clash of cultures, for example, the architects seen as lofty, designers seen as whacky creatives, with no grip on the reality of delivery, and the delivery teams and change function seen as controlling and inflexible.  If not a creative clash, often it's the clash between "the Business" and "Technology".  I've always found this is a strange dualism - isn't everyone in a company "the Business"? 

Every team in your organisation should be working towards a common goal. That goal should be communicated, and embedded in your culture. Change management needs to embrace communication, innovation and creativity. The world is moving too quickly to stay with our current modes. 
 
Culture, customer and clarity are often absent in change frameworks

I have never - and I mean this - seen any focus on culture within  a single project I’ve worked on.  There are some good eggs out there that genuinely do focus on the customer and can produce clarity through their deliverables and their socialisation, but they are sadly not in the majority and rarely have the right project culture to support them. To my mind, the 3 key elements needed for a successful project are: 

• A culture of willingness - to learn, to work together, to be collaborative and to leave a legacy.
• Customer focus – at every stage, and for every project participant, the customer needs should be elicited, designed for, tested against and communicated. 
• Clarity – of roles and responsibilities, of approach, of deliverables, of success measures, drivers and objectives – and of the desired customer outcome.

There’s often vision and strategy and business objectives defined. Most usually by a person or group of people who are incentivised to build something that makes a profit, increases efficiency or just bring in a new system, but this somehow seems to get lost once a project is mobilised. Suddenly outcomes for the customer and the business are lost in jargon, change frameworks, project plans, politics and delivery pains. 


The industry has lost its competency

Demand has outstripped the ability of the market to deliver quality. 

Although there are many people in this industry with admirable skills, great personal resilience, subject matter expertise, experience and more – there are still fundamental competency issues in the profession. Even some of the most broadly accepted concepts within project delivery are not understood by those claiming the titles of business analyst, project manager or their ilk. For example- Agile – it’s not new, yet I still see masses of confusion over its definition, its implication and its application. I’ve heard several times “its Agile with a small a” – I’m sorry that’s just nonsense.  Agile is a methodology, a well-defined set of methods in fact – if you have to say its Agile with a small a – I doubt you understand what that means, and are attempting to excuse the point that you have a poorly defined project approach.

Defining and communicating a method for delivering your change is key to success, be that Agile or otherwise - these methodologies still have a place, when understood. 


We’ve made ‘change’ too hard to be good at. 

It’s as if we’ve tried to make business analysis (specifically), esoteric. We’ve come up with all these different languages for what we do, and you know what – they’re confusing.  If it’s really hard to understand the difference between business requirements and functional requirements – then I think the distinction has no place.  If it’s too hard for analysts to learn, how on earth can we expect our stakeholders, subject matter experts and delivery partners to understand what we are doing, why we are doing it and to fully respect our role? 

To my mind, our key role is communicating.  If the methods and the words we use to communicate aren’t understood by us or other project participants - we’ve failed.  


Change refuses to learn. 

There is an irony in our inability to genuinely learn from mistakes and build them into future projects and future change within a business. This inability isn’t a physical or systemic issue, it’s an unwillingness borne of culture based on blame, empire building and inflexibility. Often a lack of leadership and a loss of sight of the vision for the organisation, a lack of association with a community have led to individuals fighting for their own little piece of land, and defending what they are doing, pointing fingers and looking for blame. 

Instead shouldn’t we take a shared ownership approach to projects?  

What can we do about it? 

Despite the air of negativity here, I am a positive person. I believe in making things better, and I believe in our industry. But I genuinely feel it needs an overhaul, a progressive look at the new, and a new way of working. This is what I think we can do: 

• Develop new talent, with a focus on delivering for people and for customers. With a recognition of the skills and training required to effectively and dynamically deliver change for business. Mentor and lead this new talent to take pride in their work, be excited by the prospect of delivering for customers, listen to them and change Change as we go.
   
• Create clarity through avoidance of industry jargon, overly complex frameworks and get back to the nitty gritty.  If the people doing the jobs can’t understand what they are doing, how on earth can their customers, or the suppliers?  Define approaches, scopes and deliverables in ways people understand and in reflection of the goals that the change, the organisation and the people involved, are aiming to achieve. 
  
  
• Create projects and businesses that people want to work for. Inspire them through leadership, mentoring, career and personal development. Be cognisant of what people want from the workplace. I doubt very much if it's land grabs, hierarchy and power struggle.  Involve people in the definition of the workplace culture, allow them flexibility to grow personally, and have lives outside work.
  
  
• Embrace change in change – if something isn’t working - try something new.  Change is an evolution. It’s as broad a concept as they come, and a one-size-fits-all methodology just isn’t working. So let’s change, and build change into change. Let's stop being afraid of learning from mistakes. Every project has its own personality – it’s own DNA, dictated by the company culture, and the make up of the people involved, so why do we think a stringent change methodology will work every time? It won’t.
  ​

Well that’s what I think right now, but as I keep learning and gain more experience, I’ll embrace that and change my views.  I’ll change, and my business will change – and that’s good. Good for change, and good for businesses. 

Find out how we can help you deal with change!

Angela Prentner-Smith

A pretty bold statement, coming from a business analyst, right?  But, I believe this 100%. I better back up my statement then.  Let’s look at how we can improve the perception of business requirements.

What is the problem with business requirements?

I have heard countless times, and probably even said myself, things like:

“These requirements are crap.”

“That isn’t even a requirement.”

“If you put sh*t in, you get sh*t out.”

This needs to be addressed. Why are they so open to criticism?

Let’s take a quick look at what I mean by requirements.  I’m talking about business requirements - in a broad sense covering user stories, high level requirements, use cases and anything else used to define a business need.  That’s all a requirement is – the capture of a business need.  My statement is equally true however of system requirements – the capture of what a system needs to do.

My background is working on large programmes and projects of change – and it’s with this background I make my assertion.  However, I believe the same statement is true of any change.  My belief is that, even if your business isn’t “engineering requirements”, you still have business needs, and are most likely eliciting and capturing them in some way.  Within small companies, you probably deal with changes in these needs quite pragmatically.  The issue comes about when change methodology, corporate culture and stringent gateways, with a lack of a fluid change control method turn the business requirements into a gospel.  A gospel to be tarnished with blame, dispute and to become a fighting ground for stakeholders and delivery teams.

Now, I’m not saying that requirements aren’t necessary – I believe quite the opposite.  Any business should and would benefit from understanding their needs before embarking upon change.  Indeed, how else would we tell suppliers what we need them to do, how else would we estimate scale and cost, how else would we assess impacts?  Business needs should be captured and managed, enough said.

So when I say they will always be wrong, let’s look at how we get to business requirements.  Business requirements, user stories, or however else you are documenting your needs, generally come after the vision, strategy, scope etc. of a project.  Stakeholders are pulled together, or a product owner is defined, and whether you are using agile or waterfall methodology, or something else you’ve come up with, requirements are elicited by the business analyst. 

Why are they always wrong?

There are 3 things with this process that lead to requirements always being wrong:

1.       They are written at a point in time.  They were gathered based on the knowledge of those involved at the time.  Everything moves on.  So why on earth would you expect a document of needs captured at one point in time to be the truth? As projects progress, knowledge gathers, needs change.

2.       They are only as good as their input.  You have a room of stakeholders and subject matter experts, and sponsors and delivery partners, all with diverse backgrounds and differing viewpoints.  They all have their view of the world, and are unlikely to all be on the same page, of the same level of knowledge, and in complete agreement.  Therefore your requirements are only as good as the input they give you, which will be variable in quality.  Additionally your requirements are a compromise from the very start.

3.       They are produced by humans.  The one thing all of your requirements have in common – they were produced by a human.  Therefore open to human error.  End of story.  They’ll be wrong.  You can’t possibly expect every line of what can be hundreds of business requirements not to contain any errors.

So what do we do about it?

Stop – and I mean everybody - stop doing these things:

Expecting the requirements to do everything
Requirements are just one project artefact.  They document business need.  Do not expect them to define the design, the test strategy or anything else.

Expecting the requirements to be immutable
They were captured at a point in time – of course they are going to change, as knowledge develops and change matures.

Expecting the requirements to contain solution
They should never.  I repeat, requirements should never contain solution.  And by solution, I don’t just mean technical.  They should not contain the wording of a question, the heading of a web page etc, etc.  There’s a good reason for this!  If you put solution into your requirements, you do 3 things that you want to avoid.

1. You constrain your design.  I’ll give an example.  You know a question in an online app is difficult to understand and needs to change.  So you write the new wording into a requirement i.e. the solution.  Seems simple enough?  No harm right? Wrong!  What if the new wording is wrong, and through some customer engagement you validate that yes, the question needs to change, but your wording was wrong and customers don’t understand it?  You’ve constrained yourself with no need.  Suddenly you have a requirement being pushed through build and test, but it’s wrong – so you need to change it – which can create a new change process.  Just don’t constrain yourself in the first place.  
2.  You muddy what requirements do.  Requirements are business needs, if you start putting some solution in, you set the expectation that the solution or anything else will be contained within the business requirements.  All those other things you need, are someone else’s job, or are a different document.  Keep them clean people, and please stop doing everyone else’s jobs!  
3. You stop focussing on the real need.  When you stop focussing on the need, and start to look elsewhere, you aren’t doing the job right.  You stop questioning properly, and this is bad.  So when a stakeholder says to you we need System X to do ABC – that isn’t a business requirement.  You need to ask why they need that, and what benefit that would bring.  Then you will get the real business need.  That may be that they need a process to be completed quicker, or a method of recording an element of data.

Methodology:  Define what needs to be done and who is doing it.

First of all – define your project roles and responsibilities, and the associated deliverables.  You let everyone know what their job is, what their role in the production of deliverables is, and what the purpose of the deliverable is.  Make sure you communicate this clearly, and get everyone’s buy in.

This will:

1. Create clarity of the purpose of deliverables, therefore avoiding the problem of the requirements being expected to define anything other than a business need.
2.  Ensure stakeholders and recipients of the requirements are engaged and understand their role in the production of the requirements and the project.  Create a sense of shared ownership.
3. Clarify the role of the business analyst – and stop them doing everyone else’s job.

Create a method to change the requirements.

The next step is to create and communicate a method to change the requirements.  Regardless of your overall methodology, you need a change control mechanism to track and communicate changes to requirements.  The best change control processes are nimble and quick, but still provide traceability.  I won’t go into this too much here – I think that’s maybe another article.  Like everything else, make sure everyone knows the process and has bought into it.

Foster a good project culture

Part of the issue in projects where statements like those I first quoted – is culture.  A culture with a lack of empowerment and decision making, and one where people are not working towards the same objectives, only produces blame and finger pointing.  A culture where everyone is working towards a common goal, feels shared ownership of success and failure and is empowered to make things better, make decisions and move on will help your requirements do a better job.  Not because your requirements are better but because the people using them are all on the same page.

Learn and improve

And back to my initial point - stop expecting the requirements to be right in the first place.  They can’t possibly be.  So stop blaming the requirements for your project’s foibles.  Yes, there are bad requirements out there – but you know what – there’s bad everything.  Expect some duffs in there, and move on.  Don’t waste time and effort with criticism, and if there are genuinely things that can be done better, debrief, record your lessons learned and build the learnings into your future projects!

Find out how we can help your business learn and improve!