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

BA’s are often pegged as the person who simply writes down the requirements stakeholders ask for, but they do so much more. Great BA’s 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 BA’s 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

BA’s 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 BA’s 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 BA’s 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 BA’s 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. BA’s 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 BA’s 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.


Scrum Solo Considered Harmful

22 Apr

Guest post by Horia Slușanschi 

What is “Scrum solo”? It is the situation in which people think that simply requiring their teams to follow the guidelines of the Scrum Guide is enough to achieve customer delight, engineering excellence, and sustainable continuous improvement.

Scrum is an attractive framework for organising work in situations in which there is sufficient inventory of work items to establish a steady cadence of planning and development. It gives the Product Owner the ability to direct the efforts of the Development Team in order to create product increments assembling the most valuable items from the Product Backlog first.

Scrum provides an effective way of harnessing the energy of self-organising Development Teams, keeping everyone in sync through Daily Scrums, and continuously improving through effective Sprint Retrospectives. The Scrum Master is of service to the Development Team (as chief obstacle remover), the Product Owner (as a coach and facilitator), and the Organisation in which the Team operates (as a leader and ambassador).

Scrum is designed to be lightweight and simple to understand. As a positive consequence, Scrum is directly applicable and has also proven effective in fields other than software-intensive systems development as well.

However, Scrum is difficult to master, and by itself (solo), is not quite sufficient for long-term economic success and effective technical and organisational improvement in a software development context. Other influences must be blended in to complement it.

For example, Scrum is completely silent on the many engineering aspects that provide the foundation for virtually all effective agile software development teams. Without engineering excellence, Teams can get rapidly mired in technical debt, and customer delight turns into disappointment, leading various people to mistakenly attribute failure to Scrum and by extension agile methods in general.

The Scrum Guide is mute on topics like Continuous Integration, Pair Work, Test-Driven-Development, and so on. As a result, most of the best Scrum teams also draw inspiration from and practice many of the techniques of Extreme Programming.

Scrum also says nothing about how work might flow through the Team during the bounds of a Sprint. It is assumed that Development Teams will just figure out an effective Sprint plan.

Depending on the level of professional maturity and work habits of the Team members arriving consistently at effective plans is not always a foregone conclusion. To fill this gap, and develop a steady habit of improving the work process, most of the best Scrum teams draw inspiration from Kanban, visualising the flow of work, limiting the batch size of the Team’s efforts, and creating a smooth flow.

As yet another example, as currently defined, Scrum focuses on a single Development Team, with one Product Owner and a Scrum Master. Due to its need for simplicity, Scrum does not tackle the concerns of scaling the use of agile methods to multiple teams or across portfolios, programs or product lines and many product releases. To address such needs, a range of frameworks have emerged, such as SAFe (Scaled Agile Framework),LeSS (Large Scale Scrum) and DAD (Disciplined Agile Delivery).

The bad news is that in this Universe there can be no “perfect” agile team, with a “perfect” composition and work process, so even a Scrum+X+Y+Z work process cannot be expected to be the “perfect” answer. The good news is that life is full of change, and there is always room for improvement. Perfecting agility is a journey of continuous improvement, rather than a destination.

Notice how Scrum solo cannot address the full range of concerns involved in effective software-intensive systems development. If you are passionate about creating organisations that delight their customers and at the same time make work joyful for the professionals engaged in them, you cannot be content with just Scrum solo. When pursued exclusively, and especially in Teams and organisations with many inexperienced practitioners, Scrum is harmful, because it leaves too much open to mistakes, false starts and failure.

As an effective countermeasure, consider broadening your learning and practice horizon, embracing and experimenting with ideas, techniques and habits from some of the other sources mentioned above. Strive to develop a habit of identifying promising learning opportunities, run improvement experiments, measure the results, then reflect, adapt accordingly and repeat.

There is no universal “best practice” learning path. There is no single, comprehensive “recipe” for developing high-performance Teams and organisations. What works well for one Team may not be equally suitable for another. People have different attitudes, skill-sets and levels of expertise.

By all means, master the elements of Scrum, strive to use the Scrum Artefacts well, and learn to execute the Scrum Events smoothly. Then, make sure to keep learning and improving, expanding your Teams’ and organisation’s range of capabilities, skills and habits beyond the natural limits of the Scrum framework.


Author Bio

Horia Slușanschi is trained as a Lean Six Sigma Black Belt, holds a PhD in Computer Science and serves as an Agile coach and mentor helping numerous organizations transform their thinking, organizational and action habits to achieve better outcomes, with improved professional satisfaction.

Horia’s mission is to help organizations to delight their customers and make work joyful in the process. He is a SoftEd instructor who teaches classes in the Agile curriculum, and works to continuously improve it in the spirit of kaizen.

Follow Horia on Twitter and Linkedin

No Comments

Posted in Agile, Scrum


Robots are coming for our jobs – How Testers Can Win The Battle Against The Automatons!

15 Apr

In the third annual Western Australian testing conference, TestWest 2015, organised by Bankwest, 200 attendees from 45 different companies were greeted with a shock and awe keynote given by digital entrepreneur Thor Essmen.   In his keynote ‘Speed is the New Black’ Thor explained that: “Mobile is now the primary channel in the consumer space and constitutes greater than 55% of all consumer interactions with banks. Security is expected – it’s no longer a feature. Online access is a requirement, and availability is paramount. Our ability to respond to consumer needs as well as opportunities are now measured in real time or near real time.” In order to rapidly respond to our customers we must embrace automation (i.e. the robots) and continuous delivery.

A theme that held true throughout the conference was that traditional roles such as Project Management, Business Analysis, Testing, Development and Infrastructure are changing and the lines are beginning to blur – with that in mind many of us need to think about multi-skilling, and from a testing perspective to change from being gate keeper to trusted advisor and ultimately change the conversation from testing to quality. Quality is everyone’s responsibility.

The opening address by CIO and Executive General Manager of Bankwest, Andy Weir was just as poignant – there’s no escaping the fact that our environment is changing around us and it no longer matters which industry we belong to. Testing needs to evolve and become an enabler for great products, awesome quality and it needs to add more value earlier in the value chain.

TestWest began its story from testing but this year it went beyond just testing and covered topics , such as Autism, DevOps, User Experience (UX), Mobility and the Cloud, Infrastructure as a Service, and the  future of Performance Testing – all of the topics were relevant to our changing environment.

With the need to evolve and transform, it is increasingly important for the testing community to engage, share, learn and adapt.

SoftEd were sponsors at the event, I was privileged to once again be co-MC for the TestWest Conference and our representatives Jenny and Bernd spent an enjoyable day with customers asking them about their training needs – with the broad suite of courses on offer we got a feel for the type of training, testers and non-testers were interested in. Their requirements matched much of the focus of the conference, broadening your skill-set and becoming more adaptive. With more and more companies working within an Agile style framework there was interest in what the future tester will look like and what will set them apart from the Robots. We are in the process of building courses that will encompass the following topics:

  1. Advanced and Critical Thinking skills
  2. Exploratory testing – exploratory thinking
  3. Communication skills – soft skills, learning the domain, coaching/mentoring skills, facilitation skills, problem solving and collaboration skills
  4. Business Analysis skills – engaging with business stakeholders
  5. Technical Awareness

SoftEd trainers have a combination of experience-based knowledge and excellent communication skills, aligned with a suite of courses that cover a broad spectrum of the software development life-cycle – we leverage this pool of knowledge to build the courses that help our clients improve their capabilities so they can stay relevant and valuable in an ever-changing landscape.

Check out our website for more about our range of software development courses and further your career with SoftEd!



Trust Me, I’m an Architect

31 Mar

Isn’t it time we took a moment to consider not what we do as architects, but how we do it?  There is plenty of discussion about the various practices of architecture, but often we put others (and the development teams in particular) off the architecture by our own practices or character.  In the next few posts I want to propose a world view for IT architects – an architecture manifesto.

Any world view should start with values, identifying what we regard as important.  It is the values we hold that determine our thinking, our behaviour, and our decision making.  Here are five values that I believe should drive us as architects.

We value the people whose lives are impacted by the architectures we produce.  Architecture exists to meet the needs of its customers, so those customers and their needs should be of paramount importance.  Who are the customers?  Firstly, there are the development teams who want us to help them deliver quality solutions for their customers – the business users and stakeholders – typically by providing structure, principles and guidelines for design.  Secondly, there is the business itself, in particular the users and stakeholders whose lives will be impacted by the solution.  They want to be sure that IT is meeting their needs, and they want to be able to verify that we have understood those needs and our architecture is appropriate.

We value the big picture.  Understanding and communicating the big picture allows us to make better decisions – better for the wider solution, and better for the longer term.  It is easier to get “buy-in” from those who can see the big picture, and such people are typically more motivated.  In the decades since he first wrote his book “The Mythical Man-Month”, Fred Brooks has only become more certain than ever of the need for the big picture of architecture.

We value humility.  Architects are technical leaders – practitioners who have a good range of experience behind them.  This can lead to inflated egos and arrogance, which is unfortunate because much of the success or failure of a leader is determined by their attitude.  In his book “The 21 Irrefutable Laws of Leadership”, John Maxwell points out that leadership is about inspiring, not controlling.  Architects need to enable and inspire the development team to provide a quality solution using the architecture.  We should be practicing servant leadership.

We value teamwork.  Each of us has different experience and skills.  None of us individually have the complete set of skills, but all of us together have a more rounded set of skills.  We can learn and get ideas from each other.  None of us is as smart as all of us.  Working as a team will typically yield better results than a single person working on their own.  We need to accept and even actively solicit input from others.

We value integrity.  As architects we need to enable the IT development teams to meet the needs of their customers, and we do this by providing the big picture.  But if we don’t prove ourselves trustworthy in the small things, who will trust us with the big picture that is architecture?  As a key component of leadership, we need to demonstrate integrity in everything we do, whether big or small.

These values are cultural in nature – as Peter Drucker said, “Culture eats strategy for breakfast”.  Strategy achieves the desired result in the short term, but in the longer term culture inevitably wins.  Taking the above values on board should yield a culture with positive results.

While the values drive our behaviour, they are somewhat abstract, making it a challenge to apply to real-world scenarios.  In the next post, I will identify some principles that build on the values and provide practical guidelines for applying them.