BA top trends

18 Nov

We caught up with Jenny Saunders, SoftEd’s Practice Lead for Business Analysis to talk key trends, hot topics and the future of Business Analysis.

1. What’s the most pervasive trend in the BA space at the moment?

The most important is User Centred Design or Design Thinking.  UCD promotes five key steps: 1. Empathize; 2. Define; 3. Ideate; 4. Prototype; and 5. Test.  It’s all about understanding your customer through persona’s, user groups, observation etc. and then testing to see if your design solution meets their requirements.

2. What do you perceive to be the biggest issue facing organisations at the moment?

The need for speed is the biggest issue but this is coupled with risk aversion for many government organisations as they have to show they’ve spent the tax payers’ dollars wisely.  So in a nutshell – faster, better and cheaper!

3. The role of the BA is changing, how do you see the profession shifting?

I think the need for analysis skills is growing; does that mean that everyone will be called a Business Analyst? Maybe not, but you will see a great demand for analysis skills. I believe that BAs will move out of technology teams and start to work closer with the business, hence supporting the trend of customer driven development approaches.

We need to remember that not all solutions are technology solutions and I think that the world is starting to be smarter about delivering the “right” solution to the “real” problem. A business analyst will ensure that they uncover the real problem (or opportunity) and deliver the right solution, based on the constraints of the organisation.

4. What does the new BABOK® v3 mean for BA’s?

The knowledge areas have changed slightly and are more realistic in their grouping but the biggest change is the perspectives and the simplicity of the core concept model.

Perspectives are used within business analysis work to provide focus to tasks and techniques specific to the context of the initiative. Most initiatives are likely to engage one or more perspectives, and in the BABOK® Guide, they include: Agile; Business Intelligence; Information Technology; Business Architecture; and Business Process Management.

The perspectives provide a real focus on “how” to approach the work due to the lens that you have put on for that piece of work. A great BA will be able to switch these lenses “in and out” at the appropriate time.

6. How will SoftEd’s new Business Architecture course meet the needs of industry?

Firstly I’d like to answer the question “What is business architecture?”

Business architecture provides architectural descriptions and views, referred to as blueprints, to provide a common understanding of the organisation for the purpose of aligning strategic objectives with tactical demands. The discipline of business architecture applies analytical thinking and architectural principles to the enterprise level. A business architect needs to consider the business model, operating model (our processes), organisational structure, constraints and architect solutions that will deliver value to the organisation.

Our course will enable participants to learn a variety of modelling techniques that can be used at the enterprise level but more importantly how to “think and challenge” as a business architect.


Tips for testers

11 Nov

If you are lucky enough to have specifications to base your testing on there’s always a strong possibility that the author hasn’t captured the requirement as well as they could have.

Can you spot anything wrong with the following statements?

  • March planned for Next August
  • Quarter of a Million Chinese Live on Water
  • Panda Mating Fails; Veterinarian Takes Over
  • Squad Helps Dog Bite Victim
  • Stolen Painting Found by Tree
  • Red Tape Holds up NewBridge
  • New Study of Obesity Looks for Larger Test Group
  • Astronaut Takes Blame for Gas in Spacecraft
  • Kids Make Nutritious Snacks

Even though these amusing statements are not likely to be found in software specifications they do help illustrate the problem of ambiguity.

The following checklist was prepared for the U.S. Air Force a long time ago by MITRE Corporation, but the principles hold true. The authors suggest being on the look out for:

1. Incomplete lists ending with “etc.,” “and/or,” and “TBD.”

2. Vague words and phrases such as “generally,” “normally,” “to the greatest extent,” and “where practicable.”

3. Imprecise verbs such as “supported,” “handled,” “processed,” or “rejected.”

4. Implied certainty, flagged by words such as “always,” “never,” “all,” or “every.”

5. Passive voice, such as “the counter is set.” (By whom or what?)

6. Every pronoun, particularly “it” or “its.” Each should have an explicit and unmistakable reference.

7. Comparatives, such as “earliest,” “latest,” “highest.” Words ending in “or” or “est” should be suspect.

8. Words and phrases that cannot be quantified, such as flexible, modular, achievable, efficient, adequate, accomplish, possible (or possibly), correct (or correctly), minimum required, minimum acceptable, better, higher, faster, less, slower, infrequent, to the extent specified, to the extent required, be compatible, to be associated with.

9 Words and phrases whose meaning can be disputed between developer and customer, such as instantaneous, simultaneous, achievable, finish, degraded, a minimum number of, nominal/normal/average, minimum, steady-state, coincident, adjacent, synchronous.

10. Contractually troublesome phrases:
a. “Design goal.” The developer will spend money and other resources with no guarantee of goal accomplishment.
b. “To the extent practicable.” A decision in the eyes of the developer.
c. “Where applicable.” There are no criteria for judgment.
d. “Shall be considered.” The developer will think about.
e. “A minimum of X.” The developer will provide exactly X.

Most of the difficulty with the fuzzy requirements addressed by the MITRE report arises from the imprecision of the English language as written by most people.

To clarify requirements, the specification author should equations and logical relations to express constraints and computational requirements.

“The system shall do A. After completing A, the system shall do B. After completing B, the system shall do C. After completing C, the system shall do D. Upon completing D, the system shall do E.” If the sequential relationship between tasks A, B, C, D, and E is other than linear, then use a logic diagram: “The system shall perform tasks A, B, C, D, and E as shown in Figure X.”

Finally, a word about the often abused phrase “To Be Determined” or “‘TBD.” TBD is used as a placeholder for requirements that haven’t been finalized. TBDs are meant to be conspicuous and easy to spot. They’re a message to readers that” there’s something missing, but we haven’t forgotten it.” When used that way, TBDs serve a very useful purpose. Specification reviewers who categorically reject specifications containing TBDS are simply inviting developers to submit specifications with much more subtle TBDs which may end up being missed anyway.

I hope this list helps you in your quest to improve the project documentation in your organisation and to find and fix those defects earlier, saving both time and money for the project.


No Comments

Posted in Testing


Agile is not a noun

22 Oct

The term “agile” gets bandied around a lot today, many organisations are “doing agile” in their software development and it is rapidly spreading into the lexicon beyond IT and software into many other aspects of the business world.  There is an attractiveness to the term which makes it almost ubiquitous – as Philippe Kruchten has said “what organisation today would want to say they are not agile”?

The very attractiveness of the term has resulted in an unfortunate proliferation of “agile” for everything, often without understanding the context in which the ideas were formulated and the intent behind the approach.  This has resulted in a proliferation of “tragile” implementations which have harmed the reputation and perception of agile development in the market.

The reality is that the agile values and principles provide a solid foundation for maximizing the delivery of value and optimizing the outcomes for any knowledge intensive project which relies on human creativity to be successful. Agility in business is a necessity today as the pace of change and the rate of innovation increases.  What makes you successful today doesn’t guarantee that you will continue to be successful tomorrow, in fact you are almost guaranteed to fail tomorrow unless you are adapting constantly.

Agile for Software Development

Through the 1980s and ‘90s software was becoming a key part of most organisation’s ability to deliver value to their customers.  Software proliferated through most areas of the business world and into the personal lives of people in the developed world.  The growing pervasiveness of computing and the dependence on software brought into focus troubled projects and the challenges of building software systems.

As far back as 1968 “the software crisis” was identified, with organisations struggling to build the right products and lots of wasted money building the wrong thing.  Ideas from civil engineering were borrowed and rigorous approaches based on the construction model were applied, without much success.  Software development is not the same as building physical things and a predictive, sequential model of development does not work.

Alongside attempts to apply a predictive, sequential approach to software development, other approaches were being implemented, generally these were based on ideas of rapid feedback, learning and responding to evolving user/customer needs and technical excellence to make change easy to accommodate.  As far back as 1970 the EVO (Evolutionary Project Management) method was being applied to software development and these approaches were generally more successful than the plan-driven, predictive approaches being used elsewhere.

Through the 80’s and 90’s ideas and brands emerged which took a fundamentally different approach to building software.  Brands such as Scrum, eXtreme Programming, Adaptive Software Development, Feature Driven Development and models such as the Unified Process and RAD (Rapid Application Development) emerged.  Figure 1 shows a timeline of the various brands and ideas leading up to the agile manifesto and into the 21st century.

February 2001 was a watershed moment in the timeline – a group of practitioners got together at a ski resort in Snowbird, Utah, with the express intent of exploring areas of common ground in their practices.  They represented a variety of brands and approaches with both competing and complimentary ideas.  They didn’t have a specific intent in mind beyond exploring their ideas.  This informal gathering had a profound effect on the software development industry as it was over this weekend that the term “agile” was coined as a unifying concept across the various approaches.

Figure 1: Timeline of Agile Development Methods and Brands

Over the conversations that weekend the participants were trying to find a term which they felt comfortable with using to describe the common aspects of their approach.  Lightweight was rejected because it didn’t convey the rigor and discipline that is so important in good software engineering and some of the participants were working on life and safety critical systems where lightweight was not an acceptable concept.  After much debate “agile” was chosen as a term which conveyed both the discipline and addictiveness which was the intent of the authors.  Agile like an Olympic athlete is agile – highly skilled, highly disciplined, able to change direction on a moment’s notice without breaking the flow of the activity.

The output of the meeting was a document – a simple manifesto for software development.

The Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

- Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland and Dave Thomas.

© 2001, the above authors, this declaration may be freely copied in any form, but only in its entirety through this notice -

Principles behind the Agile manifesto

We follow these principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development.
  • Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development.
  • The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity—the art of maximising the amount of work not done—is essential.
  • The best architectures, requirements, and designs emerge from self-organising teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

This simple document with four values and twelve principles has become a cornerstone for thinking about what agile development actually means.

Agile or Tragile

There are a large range of practices and techniques which fall under the banner of agile development.  These practices come from a wide variety of sources and branded methods and are effective in their own context.  Unfortunately there is a tendency in organisations to see a practice being used elsewhere and equate the practice to the results the other organization is achieving without understanding the context the practice has been applied in.

Another trap which seems to be prevalent in the business world today is “silver bullet” thinking – if we just do X then we will get outcome Y, even if we don’t understand why and how X is supposed to work.  Perhaps because the language of agile is so attractive and the perception of “doing things fast” there are lots of organisations and teams within organisations who have taken a cursory look at “agile” and decided that they can adopt some of the practices without understanding the dependencies and context for the practices and somehow hope to get good outcomes.

Statements such as “we don’t need requirements – we’re agile”, or “architecture doesn’t matter – we’re agile” have left a sour taste in the mouths of many project managers, resulting in a level of distrust and skepticism in the community.

This is “tragile” – tragic agile and a cause of much pain and angst among the practitioners who are encouraging a measured and sensible adoption of agile approaches taking into account the context of the environment, the skills of the teams and the goals of the organization.  The goal should never be to “go agile”, there must be a broader organizational need which having an agile approach will help us to achieve.

Benefits and Outcomes – not Process and Practices

Adopting a new way of working should be based on a clear understanding of what the organization needs to achieve as a result of the change.  It’s not about “going agile” rather identify the benefits which will flow from the new approaches.  Is time to market the challenge? If so then agile practices focusing on rapid delivery and customer feedback (including short iterations, MoSCoW prioritization, MVP identification) could be useful.  If there a challenge in the maintainability and robustness of products, then some of the practices which aim to build quality in (such as TDD and pair programming) could be helpful.

Define the goals and outcomes then look at the combination of social and technical practices which will enable agility in mindset.

Doing Agile vs Being Agile

It’s easy to teach someone a new practice or a set of practices, and with luck they will understand the rules and apply the practice faithfully.  The challenge with the agile practices is that just adopting a practice or set of practices will not achieve the desired outcomes.  Doing agile may result in some benefits, some of the practices when applied diligently will definitely change the result of some aspects of the development process.  However merely doing agile doesn’t bring about the true transformation that organisations need today.

In order to really get the benefits of agility people in the organization need to be agile in their approach – embracing change for the customer’s competitive advantage, maximizing the amount of work not done, collaborating effectively in cross-functional, self-organising teams, honestly examining the nature of their work and changing their approach based on constant ongoing learning through retrospectives, listening and adapting to the evolving needs of the marketplace, taking pride in the technical excellence that is so crucial to product development today.

This needs a different mindset at all levels in the organization, a flexible, adaptable, agile mindset.

Agility in Mindset

Generally we have two viewpoints about our ability, either as an individual or as part of a larger whole such as a department, division or organization.  The fixed mindset says that our capabilities are fixed and limited to a specific set or level, that potential is limited by the inherent capabilities we were born with and cannot change.

People and organisations with a fixed mindset exhibit some common characteristics:

  • Desire to avoid failure and look smart in every situation and prove myself.
  • Avoids challenges and obstacles because risk of failure.
  • Stick to what they know and can do.
  • Failure is an impression of lack of talent, therefore quick to blame and be defensive.
  • Feedback and criticism is personal as it impacts self-image.
  • They don’t change or improve so to this confirms that “they are as they are.”

The agile mindset is focused on constantly learning, believes that there is always a better way to achieve an outcome and is never satisfied with the status quo. This can be an uncomfortable place to be for people who take a fixed view of the world.  Adopting an agile mindset allows us to learn from failure, adapt to the current situation, respond to customer needs and elicit honest feedback.

Characteristics of a flexible mindset are:

  • Desire continuous learning. Confront uncertainties.
  • Embracing challenges because will learn something new.
  • Not afraid to fail – an opportunity to learn.
  • Put lots of effort to learn and master something new.
  • Feedback and criticism is not about them but about current capabilities.
  • Elicit feedback since it is a source of new information and learning.

When enough people in the organization adopt a flexible mindset you have the potential to achieve true business agility.

Business Agility

Adaptive, learning, agile organisations are constantly looking for ways to improve, maximizing the value they deliver to customers and stakeholders, creating an environment of joy in work.

They share a number of common viewpoints and aims:

  1. Optimise value and eliminate waste, organisational and team impediments: handoffs, partially done work, delays, unnecessary or overly complex features, waiting for approvals, others.
  2. Inspire and empower the team: create autonomy, inspire confidence and belief, support mastery and set a clear purpose, hold team’s accountable for delivering results and regulate tension for innovation.
  3. Deliver fast: MVP, limit context switching and WIP and enable flow.
  4. Optimise the whole: focus on the entire value stream to deliver a minimum viable product: reinforcing that we all win together.
  5. Build quality in: Detect and fix defects early, build a “mistake-proofing” culture that eliminates waste at the source (to re-invest time for innovation).
  6. Defer decisions: Maintain options, decide at the “last responsible moment” and delegate decisions to those closest to the work.
  7. Amplify learning: Get feedback early and often, learn through retrospectives and continuously experimenting, inspecting and adapting.

Agility in Project Management

For projects to be successful in the changing environment, project management needs to adopt an agile mindset, too.  We need to change some of the underlying assumptions of project management.  Aspects such as the iron triangle need to be rethought, yes the triple-constraint matters and we can’t ignore it but that is just one aspect of the value equation.

Figure 2: Revisiting the Iron Triangle

Project management changes in agile environments.  We need to take a different perspective when looking at projects.

Initiating the project:

  • We want to understand who our stakeholders are and how to engage with them.
  • We get stakeholder feedback throughout the process to understand their actual needs at a specific point in time.
  • We believe we need to facilitate the joint discovery of the outcomes / strategic goals and the constraints we need to operate within.

Planning the project

  • We plan the project using a map of progressively elaborated outcome level estimates
  •  We bring the project to an appropriate team of experts to manage the nuances of a detailed solution, tasks and their durations and dependencies

Delivering the project

  • We manage dependencies and risks ahead of the delivery team.
  • We ensure there is a list of valuable deliverables available for the delivery team to work on.
  • We aim to make decisions as late as possible to ensure the best possible information for decision-making.

Monitoring the project

  • We monitor progress by delivering working increments.
  • We gather continuous feedback to allow early identification of overruns.
  • We use adaptive planning to mitigate overruns.
  • We provide teams with context and guidance for good decision making.

Closing the project

  • We use the feedback from continuous transitions to BAU to improve handover processes.
  • We use the feedback from retrospectives to improve delivery processes.
  • We use lessons from the previous iteration(s) to forecast. We use feedback to evolve the roadmap.


Agile is not a noun – you don’t do agile, you take an agile approach to doing something.

Agility is necessary in today’s business environment because of the pace of change and the flood of innovation happening around us.  Yesterday’s solutions don’t fix tomorrow’s problems.  We need to build adaptive, learning, evolving, joyful and productive workplaces using modern management thinking and project management practices suited to the creative knowledge-worker economy of today.

Being agile in our thinking is necessary for long term success in todays marketplace.


Acknowledgement: The title and “Agile is not a noun” badges and image come from Joseph Flahiff –

The six signs of a great Business Analyst

06 Oct

What separates a razor sharp Business Analyst from the rest? And how does one go from good to great? Here’s the skinny on the six signs of a great BA.

1. Great Business Analysts are critical thinkers

BAs are often pegged as the person who simply writes down the requirements stakeholders ask for, but they do so much more. Great BAs are integral in assessing the feasibility of a given solution – they will be the first to say if we don’t need a Maserati convertible we won’t build one … even if it’s way cooler than a push bike!

2. Great Business Analysts are expert communicators

Part advocate, part advisor – great BAs combine business know-how with communication can-do. They engender trust by working with the necessary stakeholders to show them what’s in it for them, and they ensure the right level of detail is uncovered so they can get straight to the nitty gritty of a situation.

3. Great Business Analysts are problem-solvers

BAs don’t wait for the answers to come to them. They aren’t afraid to go hunting for solutions to the tough questions and are masters at weaving their way through complex situations to pinpoint a problem. Great BAs ensure they understand a problem to guarantee the solution provides maximum benefit to the organisation.

4. Great Business Analysts don’t look for cookie-cutter solutions

Great BAs find the real crux of an issue which is unique to the project and the organisation. Not content to do things the same way they always have, instead they assess the situation and pick the right solution for the job. No copy and paste mind-sets here.

5. Great Business Analysts are collaborators

From time to time BAs face disagreeing stakeholders, unrealistic timelines and shifts in scope. Often this means being the meat in a conflict sandwich and ensuring all parties are on the same page and working towards a singular vision. BAs bring others along with them by being objective and negotiating conflict without making it personal. They get buy-in through asking the right questions and validating ideas through careful analysis.

6. Great Business Analysts focus on the big picture as well as the small details

Great BAs are always thinking about the ‘what’, ‘why’, ‘how’, ‘where’, ‘when’ and ‘who’ when they’re analysing problems. They ask the right questions to help elicit, refine, validate and implement requirements and are always looking for ways to uncover value by linking solutions with big picture strategic goals.


Reflections on Agile2015

27 Aug

Earlier this month I was fortunate to be able to join 2300 fellow agilists for the Agile 2015 conference, held at the Gaylord National Resort & Convention Center in Washington, DC. The Agile 20XX conference is the Agile Alliance‘s flagship event every year and this year the event was a huge success. Registrations were closed in July as the conference places were sold out.

There were 17 tracks covering topics in four areas: People, Process at Scale, Technical and Special. The Special topics covered Government (part of the reason for putting the conference on in the DC area), Stalwarts (invited speakers who are recognised leaders in the agile community in a fishbowl style) and Agile Boot Camp (introduction to basic concepts for people new to agile). The full list of tracks and the track hosts can be found here. The Agile 20XX conferences have an open submission process for talk selection, with reviewers providing feedback to submitters and working with them to hone the talk proposals. This year there were over 2000 talk proposals from which the reviewers and track hosts had to whittle them down to 220 sessions over the 15 tracks. This meant the participants were spoilt for choice with a wide range of excellent talks going on in any timeslot.

Feedback on the sessions was generally very positive. The talks were mainly targeted at a practitioner audience who had already adopted agile approaches. In marketing terms agile adoption is now in the late-majority takeup phase. Most organisations who build software have adopted agile for at least some of their projects.  Traditional “waterfall” development is clearly out of favour globally with less than 20% of organisations now saying that waterfall is their preferred method for software development (Forrester research).

There were three keynote talks by Luke Hohmann, Jessie Shternshus and James Tamm. The keynotes were recorded and can be viewed on the Agile Alliance Learning Center. The Alliance video recorded about 50 of the sessions and these will be released to the Learning Center over the coming months.

One special event was the Industry Panelist session – this is the 5th year the conference has hosted a panel discussion by industry analysts. The theme was Agile Trends and Future Direction. I wrote a news item about it here. A very strong theme from all the analysts was the growth of agile outside IT and the emergence of business agility as an important topic going forward. In answer to a question about what was not being addressed that should be:

  • Agile is broader than software development, move beyond software development to areas such as embedded systems, systems and product development. There needs to be a rigor and discipline so these practices can be applied in heavily regulated environments.
  • Challenge and resist the pressure to bring into agile the practices from the non-agile era that are trying to constrain and restrict the collaborative, self-organising ethos of agile. An example is the notion of estimation – we need to estimate and budget but we do not need to identify the “requirements” in order to do so, we have better approaches today. There are too many old ideas which are creeping back and need to go away because they don’t work.
  •  The tension between the way the organisation as a whole is being run and the way agile teams are being run. The change needed is at the organisation level and it is important for the economy as a whole as it is stifling the ability to innovate. Agile has the solution – we need to communicate these ideas to the organisation as a whole.
  • Going further than even the organisation, using agile thinking to address global problems – these ideas can be used to address the large and complex problems the world faces. Looking at the global environment as a complex system of systems and using agile ideas to empower people to tackle the big problems.
  • We need to get a better handle on what software value is – software runs the world today and we don’t examine the underlying why of our software products. There is a lot of literature on diffusion of innovation and we need to find ways to incorporate these ideas into the agile lexicon.

There were 55 commercial sponsors and 6 media sponsors at the conference. An interesting change this year was the presence of a number of sponsors using the conference to recruit people – this is the first time that has happened.

In addition to the conference sessions three organisations had video booths set up to record interviews with speakers and attendees – The Agile Alliance Vimeo channel has interviews done by Dave Prior and Solutions IQ used their sponsor booth to record interviews rather than actively promoting their services, these are available from the Solutions IQ resources page.

Craig Smith, Manuel Pais and I recorded 34 interviews for InfoQ which will be released over the period September to December this year. InfoQ coverage of the conference will be published and available on this landing page.

The social highlight of the conference is always the party on the Thursday night, and this year was no exception – the theme was Superheros and capes and masks abounded. Astute observers may recognise the heroes in this picture:

As always the Agile 2015 conference was a great event, lots of learning for practitioners at all levels of experience, wonderful networking and community building and an opportunity to share ideas with like-minded people from all around the world.

If you get a chance to attend an Agile 20XX conference I strongly recommend going.  Next year the conference will be in Atlanta, GA from 25-29 July.


Posted by Shane Hastie



The Red Pill is Not Enough

09 Aug

As architects we can take the blue pill and live in a fantasy world where we are doing a bang-up job. Or we can take the red pill, recognising that there is always room for improvement and wanting to get better at what we do. This is the basis of the practice of retrospectives – look at what we have done and identify how to do it better.

In an earlier post, I described nine anti-patterns of architecture - counter-productive practices that I have seen in the various organisations I have worked in and with, and from the different people I have spoken with. It is not uncommon for me to mention an issue and for others to say, “We’ve got that”.

Taking the red pill may allow us to see these issues, but there is no clear direction on how to avoid them. It’s all very well to regard these as obvious, as if by knowing about them we believe that we will be immune to them. Yet we keep seeing the same problems again and again. On its own, the red pill deposits us in a time loop causing us to repeat the same problems over and over despite our desperate attempts to learn from history.

Much of the problem is cultural. We think we know what we should do, but we don’t do it. Peter Drucker said, “Culture eats strategy for breakfast” (although I think it should probably be for lunch or dinner rather than breakfast, because while strategy may make short term gains, culture wins out in the long term). What appeals to our head and makes sense doesn’t take effect because culture is the ultimate power in any organisation.

Perhaps we need an approach similar to that of the Agile Manifesto, where effective agile comes from the culture developed within an agile organisation. For this reason, I propose a world view for IT architects – an architecture manifesto.

It is our values that lie at the heart of our behaviour, so to change the behaviour we need to examine and change the values. See my earlier post for more detail on the following five values that I believe we should hold as architects:

  • As architects, we are here to meet people‘s needs (development teams, users, stakeholders). Do we really value these people? Or do we view them as an inconvenience or even as idiots?
  • As architects we are not doing the low-level design as that is the role of the development teams. Our job is the big picture in order to support the detail, but do we really take that on-board? (Do we really grok that?)
  • As architects, it is too easy to develop an ego, but that can get in the way of us supporting the development teams. Do we really exhibit humility, seeing ourselves as enablers and inspirers? Or do we lord it over everyone else because of our experience and position? The latter leads to dysfunctional relationships and neuters what we are trying to accomplish in architecture.
  • As architects, do we try to do it all alone? None of us knows it all, and the best projects I have worked on have been where we have a group that is free to express their own opinions in a non-judgemental environment, allowing us to evolve the best possible solutions. Do we merely pay lip-service to teamwork? Or do we actively encourage and solicit input from others?
  • Finally, integrity is something that is easy to view as implicit – “we all know that“.  However, we tend to cut corners and cheat when things get difficult or time pressures arise. As architects managing the big picture, we have a greater impact and therefore a greater need to demonstrate integrity in everything that we do if we want our message and architecture to be heard.

While the values drive our behaviour, they are somewhat abstract, making it a challenge to apply to real-world scenarios. I have described eight principles that build on these values and provide practical guidelines for applying them.  They are distilled from various good practices that I have seen yield results.

Some of this is influenced by agile development, but even without that, a new way of thinking is needed because what we have done in the past has resulted in problems that are all too familiar. As Einstein said, “We can’t solve problems by using the same kind of thinking we used when we created them”.

The red pill may allow us to break out of our fantasy world, but it doesn’t provide any solutions to the problems we then see. We need to recognise, as Lou Gerstner did, “that culture isn’t just one aspect of the game, it is the game”. What will our culture of architecture be?


Is Agile a silver bullet?

20 Jul

The belief in the magical power of silver, especially of weapons made from silver, is ancient.  A silver bullet was believed to be the only way of killing werewolves or other supernatural beings.  Today, we use the silver bullet to depict an action that cuts through complexity and provides an immediate, direct and effortless solution to a problem.

Is Agile a silver bullet to solve all problems related to solution delivery and ensure that organisations get value from their projects? If your answer to that question is “yes”, then my next question is how?  Is it because the business and IT/projects are suddenly talking to each other?  Is it because we’re more focussed on customer outcomes?  Are the practices and ceremonies that form part of a typical Agile implementation resulting directly in better results?

Under a Waterfall or traditional approach, nobody ever said that the business and IT shouldn’t work together.  Nowhere was it stated that extensive documentation was going to guarantee success.  Or that a detailed MSProject schedule was required to obtain a successful outcome.  That was just stuff we did in an attempt to “do it right”.  I’d argue that it was our interpretation and implementation that constrained us…. we forgot to focus on why we were doing something and became obsessed by ticking the boxes.

So what about an Agile approach?  Have you ever heard someone say “Agile says you must…..” or “you’re not doing Agile if you’re not…”?  I have. I sometimes fear we are just changing the boxes we are ticking and expecting this will suddenly enable us to better satisfy business needs.  Instead of having to complete a Business Requirements Document or Project Management Plan, we now have to do daily stand-ups, retrospectives and user stories.  Are we still too focussed on “doing it right” – this time through Agile ceremonies, practices and tools – instead of on why we are doing it? Are we being rigid instead of agile?

So, do I believe that Agile is a silver bullet? No.  If the question is can it cut through complexity, my answer is “yes, through a process of learning”.  But, do I think that it can be done immediately and with little effort?  My answer is a resounding “no”.  An organisation needs to put a lot of effort into determining the motivation for adopting an Agile approach, putting in place the structures, processes and culture to sustain it and equipping the people for the road ahead.  It’s relatively easy to implement a whole lot of practices and even to do them well.  It’s a lot harder to think about how they contribute to delivering the outcomes that our businesses require.

I challenge you to consider how you think of Agile.  Let’s not have the next generation of project practitioners and business leaders say that Agile failed to deliver only to start looking for the next silver bullet.

No Comments

Posted in Agile


Trust Me, I’m an Architect, Part 3

03 Jul

In my previous posts, I proposed a world view for IT architects – an architecture manifesto. I started by laying out five values that should drive our thinking and behaviour. Those values are: the people whose lives are impacted by the architectures we produce; the big picture; humility; teamwork; and integrity.

However, such values are somewhat abstract, making it a challenge to apply to real-world scenarios. I then proposed eight principles that build on the values and provide practical guidelines for applying them.

I now want to consider the practice of architecture, in particular those practices that are counter-productive. Here are nine anti-patterns of architecture.

30,000 feet and climbing.  While architecture is all about the big picture, it still needs to have enough detail to provide guidance for those who have to deliver solutions based on the architecture.

An architecture without sufficient detail leaves significant issues to be filled in by the designers and developers, typically while working on low-level detail. At this point, they will struggle to keep sight of the big picture and any decisions made will reflect this. Consequently, we start losing the benefits that we are trying to achieve by having the architecture.

This often comes about because of a lack of just-in-time design and communication.

Real-world disconnect. If the architect has got a wrong understanding of the domain, the architecture will have little in common with what the development team are working on. In this case the designers and developers will ignore the architecture and do their own thing. As with the previous anti-pattern, they will probably lose the big picture and thus any benefits that might have been possible with a proper architecture.

Not involving everyone and a lack of communication can cause this.

Detailed modelling. An architecture that is too low-level and stuck in the mud may unnecessarily constrain the solution.

While doing the detailed modelling, the designers and developers use the architecture to keep sight of the big picture. If we do detailed modelling in architecture, we are likely to lose sight of the big picture ourselves, rendering the architecture useless.

This can be the result of forgetting simplicity.

Gold plating.  We don’t need all the bells and whistles. Simplicity is preferred to complexity, and creates more robust and maintainable solutions.

The documentation should be lean and mean, containing just enough information to fulfil its purpose. Going beyond this point requires more effort in creation and maintenance, is going to be harder to read and understand, and is less likely to be kept up-to-date. Such effort is unnecessary and thus wasted time.

This is the result of forgetting simplicity.

Buzzword-driven architecture. Industry terms are a powerful way of conveying a lot of information with the use of a simple term or phrase. However it can also be used to mask a lack of understanding (e.g. see the pointy haired boss), sounding good but lacking the detail that the development team needs.

A lack of communication and just-in-time design can result in this situation.

Ivory tower architecture. Architects who work solo, even disallowing questions and involvement, risk creating an architecture that seems good in theory but falls apart when someone tries to apply it.

Such an approach relies on the assumption that everything can be known at the start and the architect knows it all.  Without further guidance from the architects, the designers and developers will adapt as they go, potentially losing sight of the big picture and the benefits that the architecture should provide.

This typically is caused by not involving everyone and not learning from the past.

Perfectionism. The risk is that the architecture is never communicated because “it’s not ready yet.” Remember that the architecture evolves over time and we should provide advice when it is needed.</>

The documentation should be just good enough. It should be sufficiently accurate, consistent and detailed.  It doesn’t need to be perfect.  The focus should be on content over presentation.

A wrong understanding of quality and a lack of just-in-time design can lead to this situation.

Ego-driven architecture. Decisions should be made in the best interests of the organisation, not the architect. For example, “What will look good on my CV?” This leads to whatever is the current cool technology being used, despite not being necessary or even appropriate. Some architects go for what is easy or what will make them look good, overriding the requirements of the project and the needs of the stakeholders.

This is a result of forgetting that architecture is about delivering working solutions.

Tester can’t draw the high-level design. While the tester shouldn’t be expected to know the architecture in its entirety, they should at least understand the key points and drivers.  If they don’t it may indicate a wider problem with communicating the architecture to the whole team, including the designers and developers who are supposed to be following and implementing it. Those who don’t know or understand the architecture will do their own thing, and probably introduce technical debt.

This also has a direct impact on the testers themselves, because if they don’t understand the high-level design, they won’t be able to identify the potential problem areas that they need to test. Their testing will be incomplete and we won’t be able to have the same degree of confidence in the quality of the delivered solution that we otherwise might have.

A lack of communication or focus on quality can lead to this situation.

In my earlier posts, I described five values that should drive our behaviour and eight principles to provide guidelines to help us apply those values to our work. The nine anti-patterns I have described here are common problems that I have seen across many organisations. In the next (and final) post in this series, I will explain why I have developed this approach to architecture.


What has happened to the knowledge areas within the BABOK?

07 Jun

So what has changed regarding the knowledge areas within the BABOK and how will that affect YOU?

We’d got used to version 2.0 and it felt comfortable but now we’ve got to learn a new BOK and change the way we do things or have we?

The BABOK has changed and I believe that they are great changes, so here is my take on the changes (in summary form).

Business Analysis Planning & monitoring:

It’s all about planning our BA approach and ensuring that we have mechanisms in place that allow us to inspect and adapt our approach; in order to embrace continuous improvement.

The second main component in this Knowledge Area (KA) is “Stakeholder Engagement”; this category is huge, as we need to ensure that we identify all of our stakeholders, understand their goals, and align the goals to the overall vision. It’s all about stakeholder identification, engagement and communication.

Elicitation & Collaboration:

It’s all about collaboration (and clear communication).  This delves into more depth around elicitation and emphasises that it’s not just about functional requirements.

Don’t forget those non functional requirements (think ISO25010).

I like the fact that the word “collaboration” has been linked with “Elicitation” because we are not typist or stenographers, we do not just write down what someone says.  We engage in a two way communication process in order to ensure that we understand the needs and that the requirements will fulfill that business need.

Requirements Lifecycle Management:

Emphasises that requirements are dynamic and that requirements have a lifecycle. This KA describes the tasks that we perform in order to manage and maintain requirements throughout their lifecycle.

It covers the creation, changes, prioritisation, traceability and governance processes.

The most important change for me is that it’s all about VALUE; whatever RLM process you adopt, make sure that it works within the context of your organisation and that all stakeholders are considered.

If people cannot see any value in doing something then they will resist it or blatantly ignore it!

Strategy Analysis:

Previously Enterprise Analysis focused on the up-front work the BA conducted at the start of a project.  Strategy Analysis is broader (which is great), it focuses on understanding current state, defining future state and developing a change strategy in order to achieve the desired future state.

This KA is a great step forward and emphasises that analysis skills are crucial in helping a business decide where to invest their money.

Personally, I believe that Business process management and modelling skills are significantly underutilised and when used successful they can save an organisation a fortune.

Requirements Analysis & Design Definition:

The most important aspect here is that Business Analysts ARE included in the design definition; think about service design, workflow, user interface etc.. 

Again, I believe that this is showing a maturity in the understanding that to perform the analyst role you need to understand your customer(s). By understand our customers we need to think about the context in which they may use the solution, how they may use it, why they may use it.  All of these questions require us to think about “design”.

Solution Evaluation:

Describes the tasks performed by BA’s to assess the performance of and VALUE delivered by a solution. An important point to note here is that this KA emphasises the need for identification of impediments and recommendation for removal of those impediments in order to optimise the VALUE of the solution.

Think about iterative and proof of concepts, incremental releases, alpha or beta releases – they are all ways to add value early.

In summary, I think these changes are fantastic, they really encourage and support Business Analysts to

deliver a solution that is fit for purpose and adds value to our organisation.

If we don’t need a Maserati convertible we won’t build one!! (even though it’s way cooler than a push bike)

Next installment: What’s happening with PMI?


Trust Me, I’m an Architect, Part 2

27 May

In my previous post, I proposed a world view for IT architects – an architecture manifesto.  I started by laying out five values that should drive our thinking and behaviour.  Those values are: the people whose lives are impacted by the architectures we produce; the big picture; humility; teamwork; and integrity.

However, such values are somewhat abstract, making it a challenge to apply to real-world scenarios.  We can identify principles that build on the values and provide practical guidelines for applying them.  Here are eight principles to help us apply the five values to our work.

Communicate.  Communicate first to understand: understand the needs of the users and stakeholders in order to create an architecture to meet those needs; understand what the IT development teams need from us and the architecture to help them deliver quality solutions.

Once we understand what the customers of architecture want from us, we then need to communicate in order to persuade them to adopt and maintain the desired architecture.  Buy-in and motivation don’t come by imposing an architecture on a team, but by persuasion and involvement.  We need to show the value of the architecture and the benefit to them in following it.

We can all learn to communicate better, and if we really do value people, that should be sufficient motivation to improve our communication skills.

Involve everyone.  Seek active participation from all the stakeholders – without them we might not identify all the needs and requirements, leaving the project prone to failure.  Seek active participation from the IT development teams.  Being handed an architecture as a fait accompli doesn’t generate buy-in and motivation, but being involved in the evolution of the architecture does.

If teamwork is important we should be actively soliciting input, comments and suggestions from others, as everyone has something to contribute.  Getting help from others is not a sign of weakness but a key differentiator of those who succeed.

Seek simplicity.  For every model we create, we should know who the model is for and why we are doing it.  Then put into the model only what is necessary for that audience and that purpose.  Anything more adds clutter and makes the model harder to read and understand.  Avoid anything that adds unnecessary complexity.  For example, patterns are powerful, but should be applied only when there is a justified need.

If the big picture is important, a simple big picture is easier and faster to understand, implement, maintain, and update.

Practise just-in-time design.  Defer making decisions until they are needed.  A decision that is made sooner than it needs to be will use incomplete information compared to a decision that is made later with more information and hindsight.  Those things that are harder and more costly to change require more up-front work than those things that are easier and cheaper to change.  Decisions about those things that are easier and cheaper to change can be deferred until later.  Be a pragmatic procrastinator.

Focussing on the big picture helps us understand what decisions can be deferred and what can’t.

Deliver working solutions.  Know your stakeholders and what their goals and needs are, as well as any constraints they may place on us.  Take advantage of existing resources and capabilities where appropriate.  Don’t reinvent the wheel when there is no need or justification.

Valuing integrity means choosing the right solution for the organisation, not for ourselves.  After all, it is their money that we are spending.

Keep learning.  Attend those post-implementation reviews, retrospectives, etc.  Take the opportunity to learn from what we have done – what has worked and what hasn’t.  This knowledge helps us improve our architectures in the future.

Humility and teamwork involve recognising that we still have more to learn and that we can learn from others on the team.

Ensure quality.  The highest quality architectures tend to be those that were designed to be testable (especially in an automated fashion).  Don’t ignore testing as not relevant to the role of architecture, but plan for it.  Trust your instincts (and those of other).  If it feels wrong, there may be a good reason for that feeling: instincts come from past experience.  Avoid gold plating your work – it doesn’t need to be perfect, just good enough to meet its purpose.

Valuing people (the business users, stakeholders and development teams) means providing architectures that meet their needs with an appropriate level of quality, but without unnecessary work and cost.

Manage change and complexity.  Understand the drivers for change and plan for it.  Don’t add complexity to enable change when there is no justification for it, only where there is a business driver.  Avoid anything that gives the impression of permanence and resistance to change in the architecture.  This includes using pre-drawn diagrams when communicating the architecture, the use of the term “draft” (what happens when the architecture is no longer in “draft”?), and the use of version numbers with decimal places (what happens when the version is 1.0?).

Provide just enough documentation to give direction and clarity.  Because the amount of documentation is minimised, it is easier to keep updated, minimising the cost of maintenance and change.  What works for today may not be able to cope with the demands of tomorrow.  Be prepared to throw away what you have and start again where appropriate – what Martin Fowler calls “sacrificial architecture”.

Change and complexity are key components of the big picture.

In my earlier post, I described five values that should drive our behaviour.  The eight principles I have described here provide guidelines to help us apply those values to our work.  There are many practices in the field of architecture, and much is written about them elsewhere.  In the next post, I will instead look at practices that are counter-productive – anti-patterns of architecture.