The Impending Extinction of Testers

11 Jan

If you are a tester, there is a meteor heading your way, and that meteor is called automation.  Your very survival will depend on your ability to adapt to life with automation.  Fail to make that adjustment and you will join the dinosaurs in the museum as the new exhibit, “apatosaurus tento”, “The Non-Technical Tester”.

Testers who do not embrace this brave new world of automation run an increasing risk of being down-sized, right-sized, or whatever other euphemism you prefer to use for being made redundant.

What is the driver of this doom and gloom?  Cost!  The desire to get more bang for your buck.

A team of (for example) five testers that spends their time writing test scripts and then following those test scripts against a system is in the unenviable position of joining that species on the edge of extinction.

As the manager of that team, I would retain one member of the species to write the test scripts and analyse and interpret the results, but down-size (use your preferred euphemism here) the remaining four members.  Why would I pay for five testers when the simple act of following a test script can be performed by almost any semi-skilled labour at a significantly lower cost?  Especially if I can send that job off-shore to countries where the labour cost is cheaper.  After all, following a script does not require any special training, skills, or knowledge.

To those four former testers, welcome to the fate of the genus apatosaurus tento.  To the surviving tester, be afraid, be very very afraid.  That meteor is putting the remainder of your career at risk as you compete with all the other survivors for the dwindling resources of jobs available for that endangered species, the non-technical tester.

How then to survive this extinction level event?  Don’t just try to survive alongside test automation, ignoring it or hiding from it – that path simply delays the inexorable slide to extinction.  Instead, adapt and evolve!

The tester that embraces test automation has the adaptation that allows them to rise above their former colleagues and feast on the more bountiful lake of bugs available to those who are freed from the time-consuming shackles of manually following test scripts.

The tester that can automate the repetitive and mindless job of following test scripts will find that they have more time on their hands, time that can be spent on tasks that cannot be automated, such as exploratory testing.  Such techniques yield a richer crop of bugs that are not typically found by more mundane testing techniques, but rather are normally found by users in production.  When that happens, the users get angry because there is a roadblock preventing them continuing with their work, and the development team (including the testers) lose face.

As a manager, I would want testers who can offer that bit extra beyond their colleagues, who can find those more elusive bugs, who yield better productivity because they automate all the repetitive tasks that they can.  These technical testers are the ones who will survive the extinction level event of automation.  Welcome to the future of testing, to the evolution of testers into the new species of “homo tento”.


Posted in Testing


New course for 2016: Agile Test Automation

11 Jan

In 2016, SoftEd launches a brand new Agile Test Automation program.  We talk with SoftEd trainer, Colin Garlick about all things automation.

How has this course changed?

This course provides more hands-on training on the techniques of test automation and the use of some of the most popular tools.  These techniques are put into the wider context of the testing process, including why you would use test automation and what benefits you will achieve by doing so.

What skills can people expect to develop from completing this course?

As well as understanding the concepts and rationale of test automation, our goal is to equip people with the skills (and confidence) to be able to:

  • discover the state of a system from a continuous integration server;
  • retrieve the latest version of the system from the source code repository;
  • run the automated tests of the system, including the unit tests written by the developers;
  • create and run automated acceptance tests using tools like Selenium, Cucumber, and SoapUI.

Why is automation becoming increasingly important?

As I wrote in my blog “The Impending Extinction of Testers”, repetitive tasks like following a test script can be carried out by others at a lower cost.  The real value of a tester is going to be in areas like exploratory testing.  Often testers have not had time to spare in this way, but after automating the more repetitive tasks, they will have more time available which can be directed to these high-value activities.

This course teaches Acceptance Test Driven Development and Behaviour Driven Development, why is this range so important for testers?

These techniques are the proverbial fence at the top of the cliff – quality assurance as opposed to quality control.  Performing acceptance testing after the code has been written (while still important) is the ambulance at the bottom of the cliff.  It allows us to verify that the developers have the correct understanding of what is required, but only after the fact.  How much more efficient could the team be if we could ensure a correct understanding of the requirements before the developers write a line of code?

This is where ATDD (Acceptance Test Driven Development) and BDD (Behaviour Driven Development) fit in.  By defining the acceptance tests first (with the whole team) and using those tests to drive the development work we are practising quality assurance, with the result that the process of running the acceptance tests later (quality control) should be a mere formality to tick the boxes rather than a last-minute discovering of problems.

Click to find out more about the course!


6 Things the Agile Business Analyst Should Know

11 Jan

There is a lot of confusion about the role of business analysis in agile development – some people say we don’t need analysts, others tell us “analysis is so important we do it all the time”, others say the Product Owner does all the work of analysis, others suggest that business analysts are part of the cross-functional team.

Of course my answer is “it depends”.

Irrespective of the job titles of the roles involved, I agree with Scott Ambler that analysis is so important that we do it all the time.  This means we have to constantly think about the big picture, and the short-range view, explore the meaning behind our user stories and be ready to delve deeper and explain the intent and design of the product we are working on.

So what are some of the important things that I have to understand and possibly do differently if I am working in an agile development team?

1)     Don’t throw the Baby out with the Bathwater

Just because I’m working in an agile team it doesn’t mean that my existing skills and knowledge are now invalidated.  Yes – there will be some things I do differently and some of the documents I used to produce are no longer needed, but a lot of my skills and techniques will still be useful and applicable.

2)     Let go of Ownership and be Comfortable with Sharing

In the “old world” I had a lot of hidden power as the “owner” of the requirements documents.  Whatever I chose to write down would be in the document and would probably find its way into the product. In an agile team I will be responsible for bringing the right people into the workshops and collaborative story identification and elaboration sessions – building stories and elaborating them as part of the development is a team activity, I need to learn to let go and be comfortable in the facilitator rather than arbiter role.

3)     Value Comes Before Everything Else

I have to find and express the value in the user stories, standing up for value over technical expediency and “gee it would be great if…” urges.  Value must be traceable back to the goals, objectives and outcomes of the initiative and aligned with organisation strategy.  This means I need to deeply understand these goals and objectives at every level and advocate for them constantly.

4)     Relationships and More Important than Requirements

I know that most of the requirements identified early in the initiative will change as our understanding evolves I need to be comfortable letting go of a feature or user story, instead focusing on building strong collaborative relationships with the people who have the needs and the people who will work to fulfil those needs.

5)     Flow Matters

Rather than the large batches of work we used to do (build the full requirements document and hand it over to the designers, etc) agile analysis requires us to take a continuous flow perspective – having the big picture in mind and slicing off the small pieces of value as we build the product, slicing and dicing the epics and stories to identify the right pieces of value just in time.

6 Governance Matters

Just because we’re in an agile project doesn’t mean we can disregard organisational governance – there is (normally) a valid reason behind those governance rules which we sometimes rail against.  Compliance and audit are not our enemies, they represent a part of the business that have legitimate needs we need to meet and protect.  Find out what the underlying reason for that compliance report is, then figure out how to meet it with the least cost in time and effort, cultivate allies and get them involved in defining DONE so everyone understands what must be part of the working solution.

There’s lots more to this topic and I’d love to talk to you about it – come along to the Agile Business Analyst class and we will delve deeply into the topics together.


Bring Agile Beyond IT

06 Dec

In the nearly fifteen years since the Agile Manifesto was written, agile software development has slowly and steadily become the most prevalent approach to building software. The values and principles of the agile manifesto have been an inspiration to software development teams across a multitude of industries. The practices and techniques that align with these values and principles have resulted in better project outcomes, higher customer satisfaction, more engaged team members and higher quality products.

So, in software development we are definitely getting the benefit of these modern approaches to product development.  What about the non-IT areas of our businesses, do these ideas also apply in marketing, or finance, what about customer service?  The reality is that yes, agile ideas can and do work in almost every area of our organisations today.  Forbes magazine calls Agile the “The Best-Kept Management Secret on the Planet” and talks about how organisations that adopt agile thinking are achieving benefits such as improved time to market and increased customer satisfaction (customer delight!) with their products and services.  Harvard Business Review encourages us to “Bring Agile to the Whole Organization” and talks about the changes that will be needed to embrace an adaptive, responsive, creative way of working.

At SoftEd we have worked with many organisations helping them bring agile thinking and practices into their way of working, mainly in the information technology areas but more and more frequently we are working with teams outside of IT helping them adapt the ideas to their specific context.  This has included insurance and banking product design, medical device prototyping, people engagement & talent management, finance and accounting, building hardware devices, business process improvement and even radio crystal cutting.

What all these areas have in common is the reliance on human creativity and innovation for success – they are knowledge worker areas of the business and they face tough problems, ones in which the solution is not clear and simple, rather solving the problems they face requires lateral thinking, ingenuity and collaboration between people with different skillsets.  This is where the commonality with software development lies – the types of problem are similar, so it is possibly to apply the same type of thinking that has been successful in software development to tackle the challenges faced in other areas of the organisation.

Let’s start with the Agile Manifesto – the founding statement and set of guiding principles of the agile software development movement.  The value statement from the manifesto reads:

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 we value the items on the right, we value the items on the left more.

So, how can we adapt this to apply outside of software development – what would the impact be of a small change, replacing “software” with “solutions” – how does it read then?

Manifesto for Agile solution development

We are uncovering better ways of developing

solutions by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools,

Working solutions over comprehensive documentation,

Customer collaboration over contract negotiation,

Responding to change over following a plan.

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


This feels fine – as someone working in pretty much any area of a business I can buy in to these values and feel comfortable about working in ways that align with these statements.

The social, technical, political and business environment today is in a state of VUCA – Volatility, Uncertainty, Complexity and Ambiguity.

“A rapidly evolving, dynamic, chaotic complex business environment is the norm rather than the exception” - David Sypnieski






To cope in a VUCA world our ways of working have to adapt, decisions need to be made faster, we need to be constantly learning new things, getting feedback quickly from the marketplace and acting on what we learn.  We need to be able to respond to the change around us faster than the rate at which the change is happening.  This requires that we adopt new ways of thinking about work and turn many of our traditional management practices on their heads.

Decision making needs to be as close to the point of customer engagement as possible – this means empowering people to make decisions and not requiring them to go through many layers of management approval before acting.  This also means we have to ensure that the people who interact with our customers truly understand the organisation’s goals and objectives, that their decisions are in line with the intent and strategy of the organisation.  Management must be able to articulate goals and strategy clearly and consistently so that it becomes a beacon which guides actions all across the value stream.

Our employment processes need to change – the skills and capabilities needed in today’s workplaces are different to what made us successful in the past.  The emphasis needs to be on collaboration, problem solving, teamwork and creativity – what Richard Sheridan (author of Joy, Inc) calls “kindergarten skills”.  Technical skill and knowledge is necessary, but not sufficient.  Because the way we do work is changing so fast, the ability to learn is one of the most important characteristics we need to employ for today.  We need to change our reward structures, instead of forcing people to compete against each other we need to have incentive systems that reward collaborative behaviours and are related to the outcome of their work, not the activities they perform.

Our approach to funding and financing initiatives has to undergo a radical rethink.  In a complex, uncertain environment it is impossible to allocate funding 12 months in advance – we don’t know what opportunities are opening up tomorrow, we have no idea how the competitive landscape will change in the next three months, yet we ask managers to identify their budget needs 12 to 18 months in advance, and then penalise them for guessing wrong.  In his HBR article Jeff Gothelf says

“Unpredictable levels of complexity, market turmoil, and shifts in customer behaviour put any product roadmap longer than four to six weeks at a high risk of quickly becoming an outdated artefact”.

Ideas such as Beyond Budgeting have shown that taking a completely different approach can result in much higher return on investment as initiatives get funded for the value they produce, and are constantly revaluated as they deliver incrementally.

The Stoos Network presents a credible alternate approach to management that is based on creating healthy, productive workplaces, rebuilding trust in business and creating better outcomes for all through approaches such as

  • Shared value built into decision making
  • Highly networked, decentralized decision making
  • Recycle, reuse, renew resources
  • Partner with Community
  • Ask Nature. Learn innovative technologies.

Our organisations need to become learning centres, rapidly responding to the new realities and adapting processes, practices, products and our people in response to the feedback we get from within and outside.  Taking a Kai Zen (change for good) approach to exploring what we can improve, what we can discard, what we should change in every aspect of our business.

Futurist and author Alvin Toffler puts it succinctly:

“The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn.”

Our organisations and the people in them need to become adept at learning, unlearning and relearning.



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?