Agile coach

What is an agile coach?

The true value of coaching, however, is to build the capability of the existing team. Rather than making choices for the team, the coach provides guidance about the choices available, perhaps making recommendations, and encouraging them to consider the options and choose their actions. The coach teaches the team about techniques or tools that increase their available choices. The coach offers observations about the team’s activities, and helps the team make it’s own observations and reflect on them. The coach helps the team articulate the results it wants, and generate courses of action to achieve those results. The coach partners with the team on the coaching process, but allows the team to exercise its own judgement about the software development practice. The coach does not become a member of the team, but endeavors to wean the team off of the need to consult with the coach on a regular basis.


The house of Scrum

Scrum… is a means to an end, a tool designed for a purpose: people, agility, value.

There’s no need to re-describe Scrum. If you’re on a journey to discover Scrum, I welcome you. I do advice you to learn more than Scrum, and to also discover agile & lean.

I greatly recommend the collection of articles by Mike Cohn and Alistair Cockburn.

After attending a few presentations and after reading the small book “Scrum, a pocket guide”, I pleasantly appreciate Gunter’s writing on the topics of Agility and Scrum. I do encourage you to read these articles and I equally recommend that little book. It’s written in an honest way, and offers transparent descriptions.

Hereby a bunch of excerpts and links (all text is copy paste of blogs):

Agile and Scrum, entwined and related

Agile and Scrum, actually, are not interchangeable synonyms, but two inseparable ingredients in a software development ecosystem, pure chemistry.

Agile are the principles to Scrum, Scrum is a foundation for agility.

Read more…

The Scrum Stance

People employ empiricism to optimize the value of their work.

Read more…

Agility via Scrum

Agility is a state, a way of being; of people and of organizations. It is not a process, it is not a method. It is a state from which emerges flexibility, openness for change and fast responses to market changes. Scrum has become the most important Agile framework, allowing people and organizations to achieve this state of Agility. Scrum brings the rules and principles to organizations and their people to grow into this state of flexibility.

Read more…

To shift or not to shift (the software industry paradigm)

The software industry has for a long time been dominated by industrial views and beliefs. The universally accepted paradigm was in fact a copy-paste of old industrial routines and theories.

Although it was not widely and consciously admitted, but this did put the software industry in a serious crisis.

The House of Scrum The House of Scrum

The house of Scrum offers an open view on the world, while protecting from rigid behavior. Its inhabitants remain flexible at all levels to better deal with uncertainty, and shape -not predict- the future. They sense, probe and adapt at all levels. Scrum drives building better software products, and faster. In 30 days, or less. But, most of all, it restores energy and work pleasure for all involved.

Read more…

Scrum Values

Less known and probably under-highlighted, but therefore not less important, are the core Scrum Values upon which the framework is based.

Although not invented as a part of Scrum, or exclusive to Scrum, these values give direction to our work, our behavior and our actions. In a Scrum context the decisions we take, the steps we take, the way we play Scrum, the practices we add to Scrum, the activities we surround Scrum with should re-enforce these values, not diminish or undermine them.

Scrum values:

  • Commitment
  • Focus
  • Openness
  • Respect
  • Courage

Read more…

Yes, we do Scrum. And…

An article about doing Scrum, and improving beyond Scrum. It also describes Common adoption path of Scrum.

The Blending Philosophies of Lean and Agile

Beyond the clear similarities in Lean and Agile thinking, Agile has distinct practices that match the main Lean principles.

Read more…

Maximizing Scrum

It’s not only about “scaling”. It’s about “maximizing”.

Enjoy the scaling effect of maximizing. If you run out of improvements, consider adding teams. Choose wisely where you want to invest in first.

Read more…

Accountability is a quality of agile

In a context of Scrum the described inverted form of accountability leads to exactly the opposite of the Scrum tenets; cross-functional collaboration, utilizing collective intelligence, bottom-up knowledge creation, shared goals. Yet, accountability is essential. The false application of it doesn’t reduce its importance. Removing and avoiding accountability has disastrous effects as well; no vision, no focus, no direction, no choices, endless discussions and meetings, indecisiveness; a Gordian knot.

Scrum foresees a clear accountability for each Scrum role:

  • The Development Team is accountable for creating releasable Increments.
  • The Product Owner is accountable for maximizing the value of the work.
  • The Scrum Master is accountable for the understanding and application of Scrum.

These accountabilities are separated, yet all are needed. It is why these roles need to collaborate as a Scrum Team with a shared responsibility toward the organization, its customers and the wider ecosystem.

Read more…

Done is a crucial part of Scrum, actually

Done Increments are THE way to achieve agility through the empiricism of Scrum.

The empiricism of Scrum only functions well with transparency. Transparency requires common standards to work against and to inspect upon. The definition of done sets the standard for releasable.

The definition of done is essential to fully understand the work needed to create a releasable Increment and for the inspection of that Increment at the Sprint Review. The definition of done serves the transparency required in Scrum in terms of the work to be done and the work actually done.

Read more…

Scrum, actually

Scrum, actually, in itself is not the purpose. Scrum is a tool. Scrum enables people to live the art of the possible, to make the most out of every single day constrained by their means, to maximize the value of their work in the face of uncertainty.

Scrum, actually… is a means to an end, a tool designed for a purpose: people, agility, value.

Read more…

Releasable in Scrum, actually

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. (…) This Increment is useable, so a Product Owner may choose to immediately release it. (Source: The Scrum Guide)

In Scrum, actually… releasable means all work done to release to the market. Instantly.

Read more…

Agile and Scrum, actually

As with Agile, the Scrum Values and Scrum’s fundamental roles and rules as described in the Scrum Guide don’t change with scale. But scaled implementations of Scrum require different tactics in implementing the rules.

In Scrum, actually… Agile is the DNA driving the behavior throughout the software development ecosystem.

Agile and Scrum, actually, are two inseparable ingredients in a software development ecosystem.

Read more…

Meetings in Scrum, actually

Scrum’s events serve the empiricism that Scrum brings to software development. Empiricism thrives on inspection & adaptation. Inspection & adaptation happens at a frequency, in regular intervals. Adaptation only makes sense when inspection is done against reality, when the actual situation is made transparent.

In Scrum, actually… meetings are opportunities where people meet to change their mind.

Read more…

Team size in Scrum, actually

Try something you believe might work for you. Inspect it, adapt to your findings. Repeat. When heavily constrained in doing this, sticking to the guidance of having 3-9 people in a Development Team is a good idea.

In Scrum, actually… team size is a team decision.

Read more…

Velocity in Scrum, actually

Velocity in Scrum actually is an indicator of productivity, an indicator of how much software, preferably releasable software, a team has produced in a Sprint. That in turn is not a promise, nor a contract for the future. Predictions are fragile. Empirical process control has the potential of antifragility. We embrace complexity.

In Scrum, actually… velocity makes most sense if a measure of a team’s capability to create releasable software.

Read more…


Personal reflections: the world of software development

10 years ago I’ve entered the IT world with the exciting expectations to create truly amazing software. Nowadays, the possibilities are endless, the technology advances fast, there are plenty of opportunities for innovation. It’ an exciting world!

Unfortunately, from time to time, the process to create software (for internal or external use), is clogged down by overly-prescriptive processes, coordination chaos, organizational barriers, technical mediocrity or simply the unwillingness (failure) to understand that software development is a complex adaptive system. In summary, an approach of an old industrial paradigm applied to software creation.

Humans are complex creatures, and as humans we want to create complex products. Unless you’re a solitary developer working end to end alone to create a piece of software – for your own use; you will need to talk (at some point in time) with a colleague developer and / or the user of that software.

Humans like to create complicated things to manage complicated things to end up in a lot of complications. Anyway, the world always will be divided by different streams of thinking; including the software world, moreover as it offers countless possibilities to create solutions.

In today’s fast paced world, software needs to be spot-on, well-engineered, valuable and simply said: great!

A piece of software has its use: it solves a problem, it answers to a need, it offers some entertainment, or it was a learning journey. In the real word (business or non-profit), we need to seize opportunities, respond to challenges, and control risk – and all this in a timely manner. The software developed needs to support this, it offers a solution, and it gives us a competitive advantage. Needless to say, in today’s fast paced world, software needs to be spot-on, well-engineered, valuable and simply said: great!

In the software industry (and nowadays also outside it), there exists a way of thinking and acting that embraces the above; it grass rooted long time ago and has gained adoption as time passes.

To me it makes no sense to act otherwise, to create complex (software) products in different way. One need to realize this way of working is more than a process; it’s more than yet another development framework. It addresses basic principles of values, it embraces humans for their nature; it embraces creativity. I am in no way brain-washed or sponsored (I hope); I do know that other ways of creating complex (software) products has failed too often. I like simplicity, I like productivity. I think there’s a way to have it in the world of software.

Source featured image:

Getting out of the deliverables business

Once upon a time, there was a marketing guy, with great ideas for a new software application.

He hired a business analyst, who described all those ideas in formal fully documented business requirements (including use-cases, business rules, exceptions …). This deliverable was handed over to a User Interface / User Experience expert who created detailed the User Interface (including wireframes, site maps, screen flows, mock-ups,…) and described all the user interactions. Next, a functional analyst translated those requirements to a functional specification, and trying to figure out how to connect it to existing infrastructure and systems.

Meanwhile, based on that User interface specification, a visual designer, individually, made stunning pixel-perfect visual designs for each and every screen of the application. Given the functional specification, a technical analyst created a technical specification and application design trying to capture all the given information, in a deliverable that would make sense as input for development. Sometime later, a copywriter was given the assignment to write on-screen text labels and copy, based on the wireframes. And even some times later, a tester was given the assignment to understand the requirements and write test scenarios.

Development was about to get started!

Sometime later, during development, some concerns rose about the User Interface of the application and a usability engineer reviewed the User Interface specification to give some advices and remarks.

So, what do we observe?

  • The work goes sequential
  • Individuals doing their own thing, producing output: deliverables, documents!
  • Time passes by
  • Handoffs, with potential gaps for misunderstandings, misalignments, information lost in translation

Let’s retrospect.

Silo teams

The goal was to create a new software application – with probably a fantastic idea in my mind and initiated by a great business case. Where is our software?

Focus on outputs, not outcome. People are appreciated for their output: mainly documents and the quality of those documents.

Those documents are written by an individual, or a group of individuals of the same expertise – documents are passed on (with or without explanation). Output of one phase, is the input of the next phase. Lack of common understanding (not by the fault of the individuals), each individual needs to re-interpreter the work of the previous. No real sense of ownership.

It’s a very time-consuming process. From inception to actual start of development, it can take months – depending upon the size of the project.

Assumptions, lots of assumptions! Hypotheses based on those assumptions. A requirement spoken by the guy from marketing – as great as it might be – remains an assumption until proven by the market: feedback from real end-users: the customer.

There is little to no opportunity to react and correct the design of the new software application, when new insights or market conditions come up meanwhile developing.

Probably the whole process is overseen and controlled by a commanding officer.

Where’s our marketing person? Out of sight

A chain is only as strong as it weakest link.

Teams used to a sequential process have become accustomed to handoffs between specialists. Each team passes off their work to the next team. Each of these handoffs includes overhead in the form of meetings, documents to review and approve, waiting time, etc. Anything which does not directly contribute to the goal of the project: creating software – is waste.

Let’s reconsider.

Once upon a time, there was a marketing guy, with a great idea for a new software application.

A team was gathered with expertise in IA/UI/UX, usability, customer engagement, front-end/back-end development and testing. The team together made this set of skills, not an individual for each required expertise. Together with the marketing guy, the team formulated the business goal and desired business outcome of the new application.

The team focused on the outcomes that would address the main customer need of our application. In a lightweight manner, the idea was conceptualized: the team formulated some hypotheses: valuable features that they considered as a good collection for a ‘minimum viable product’ and a set of metrics to verify those hypotheses. Next the team draw some UI sketches on paper. The team set out a test by linking together the UI sketches to an “interactive” prototype for internal validation. Taking into account the received feedback, the team refined that small set of features to the level of user story with the main acceptance criteria.

The team decided to prototype directly in HTML/CSS as this was the preference by the web developers. The team organized a user test with some of the key customers and external (non-customer) people. From these tests and the earlier defined metrics, they concluded and prioritized a number of improvements. Collectively, the team came up with the adaptations. With minimum documentation effort (again: main wireframes and a list of agreed upon decisions), the prototype was improved and a next set of functionality was discussed.

Meanwhile, the needed services were encoded and deployed to connect the front-end with the back-end system. The next test showed the application with real back-end data.

Over the course of time, the team improved the product with feedback of customers, they included new insights, they dropped a few – previously considered “must-have” – features, and they integrated a new online service that appeared to be a good fit to the solution.

So, what do we observe?

The focus is on creating working software, that’s what we care for!

Documents do no solve user’s problems, working software does.

The focus are the outcomes; the focus is the vision. The team liberates itself of endless discussion regarding functional features. The attention is directed on user needs and in that problem space possible solutions (hypothesises) to address those user needs are presented and challenged.

Feature development is prioritized. There’s no all-inclusive upfront analysis, there’s no big design application design up-front. There’s no detailed product functionality roadmap. The design emerges or rather there’s a sufficient design up front.

We eat the elephant in small chunks, but we prioritize the chunks.

The team organises itself to collaborate. Insights, proposals, experiences, expertise are collected and in a healthy synergy, the team shares and co-creation happens – with the customer. The customer is central.

Instead of an open-loop system, the project is organized as a closed-loop system: actual feedback of end-users is incorporated iteration-by-iteration to evolve the application and its features. The “apply-inspect-adapt” cycle is a “probe-sense-adapt” approach. The team plans for experimentation, the team is ready to react when new insights arrive. There’s no anxiety about changes.

Lean UX

What about documentation? When required, additional application designs or an overview of architectural components is delivered. Besides that, the product (software) itself is the documentation. Visual elements are documented in the application itself. The developed front-end is the library of reusable components. The web services themselves are documented and are self-explanatory in terms of logic.

Modern software development environments and software craftsmanship practices allow this kind of rapid application design, construction, testing and delivery in an iterative and incremental way.

Yes, there are exciting times ahead!

More info on Lean UX? Read the book by Jeff Gothelf.

Descaling organisation with LeSS (Large Scale Scrum)

As you explain, the framework is simple. Likewise Scrum, it’s painfully simple.

As Ken Schwaber once said (I believe):

“Scrum is like your mother-in-law, it points out all your faults.”

Each organisation has an enormous untapped potential to deliver more value, more rapidly, more frequently. But reality is different, small and large organizations have and maintain (anxiously) the traditional organizational model.

How difficult is it to transform to a networked organization, stimulating self-organisation and a learning culture? From a scale from 1 to 10, I’d say 10. This kind of organisation design only works if management supports it, management understands and shows the example and the executive support is long lasting.

As Larman puts it: “Organisational culture follows structure” Is this new? No. Can it be done? Yes. Cf. Frederic Laloux’s book “Reinventing organisations”. Cf. Toyota’s lean culture.

Unfortunately (again) for large organisation (I’ve been working in bank); I’m rather pessimistic: it will takes years, may be decades before this kind of organisational design & culture change happens. So, the essence of a “large product” development is its simplicity.

Are other organisations fooling themselves? Those which are adopting “large scale” organizational frameworks? Will they reach the benefits? They will get some benefits yes, but then again: it’s not difficult to gain some improvements in an organisation working for years according to “a previous-century industrial paradigm” (as in manufacturing). But I guess they’ll never reach true “business agility”.

I wish the market conditions would be much tougher: those not adapting are extinguished: the sooner the better.

My impression of LeSS (Large Scale Scrum) practitioner course

Large Scale Scrum (LeSS) is for me an honest framework which embraces Scrum (for 1 team). LeSS does not introduce any additional layers of governance, it does not compromise to fit with existing traditional organization structures, it does not compromise on the delivery of value.

Indeed, LeSS is much more about organisational (re)design than about introducing Scrum. Before “scaling up” to multiple teams, an organization must be able to adopt Scrum on the team level, and proof for themselves they can organise performing teams. LeSS embraces the principles of agile and lean thinking as these are meant to be.

Read about my impressions of LeSS course

Manifest voor Agile Software Ontwikkeling

Manifest voor Agile Software Ontwikkeling

Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we

Mensen en hun onderlinge interactie boven processen en hulpmiddelen
Werkende software boven allesomvattende documentatie
Samenwerking met de klant boven contractonderhandelingen
Inspelen op verandering boven het volgen van een plan

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.


Kent Beck, Mike Beedle, Arie van BennekumAlistair CockburnWard CunninghamMartin Fowler, James GrenningJim HighsmithAndrew HuntRon Jeffries, Jon KernBrian Marick, Bob MartinStephen MellorKen SchwaberJeff 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.

Luister naar de interviews met een aantal van de personen die het manifesto mee hebben vorm gegeven:

Fixed Price Projects and Agile, or The Scariest Nightmare

Good insights on how to deal with fixed price/scope/time projects. Fixed-price, fixed-scope, fixed time contracts and projects tend toward lose-lose situations for both the customer and supplier; customers often do not get what they really need, and suppliers can easily lose money. [Agile contracts primer].

I’ve found these resources useful to learn more about the contracting:

“Agile contracts primer” by Tom Arbogast, Craig Larman, and Bas Vodde. Quite extensive and lots of advice.

10 Contracts for your next Agile Software Project (by Peter Stevens)

quote unquote

Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don’t settle.

Steve Jobs

“The old old product development game”

Disclaimer: this article expresses my personal opinion and is based upon personal experiences. You can consider this a rant, but I am open to any constructive criticism. Yes, the article shows a single view on the state of affairs and everything depends upon the context and the situation. The only thing we can do is to learn from experiences and work together to build great software products and improve the world we live in.

Traditional development is like being the passenger on a bus tearing down a serpentine mount road while being driven by a drunk

The fallacy of the perfect requirements

Let’s define all requirements up-front. Let’s create all design up front. Let’s freeze those requirements and let’s develop based upon that set of requirements.


So, what’s wrong?

Requirements do change

External and internal factors cause change. The world around us changes. Technology advances at a fast pace. Competitors arrive with new ideas. Legal requirements are imposed. We get feedback from the market: users, customers, competitors. We learn as we do.

Decay of requirements

The decay of requirements during the project life-cycle. Even in the best case, requirements will change inevitably. In the worst case, only the half of your requirements will be valid.
In case the planned delivery date is not met, the situation gets worse: it becomes more difficult to ever meet the actual business needs. Requirements further decay.

The assumption that you can design and define all requirements up front, it’s simply false.

Complex product and software creation is a wicked undertaking. Software is intangible. Knowledge is in people’s heads. Delivering an all-inclusive requirements specification document and aiming at a 100% satisfying developed software application will simply not happen in reality. It’s a self-fulfilling prophesy.

As soon as the actual end-users (customers) consume the product or software, opinions are formed and feedback is given. By using the software product, we learn about its use and instantly potential improvements emerge. The act of delivering the software causes the requirements to change. The longer it takes to get feedback about the software product, the longer it will take to converge to a solution that satisfies the user needs. In fact, requirements change while the software is being developed.

So what happens in traditional sequentially phased product development?

  • Lots of change requests.
  • Lots of defects; a large part of those defects are actually improvements based upon (testing) feedback (so, change requests).
  • Discontented business stakeholders; impatient end-users
  • Feeling of lost opportunities
  • Delay in delivery
  • Delivery of value at the very end
Project phases sequential

In a sequential phases project, the value is only delivered at the end. The risk is only decreasing at the end.

The longer the duration of the sequential phases, the larger the devastating effect will be. The longer it takes to define the requirements and to deliver the software, the more substantial the change will be. The later in the software development life-cycle the change is requested, the more costly it will be.

Cost of change

Figure 1: The cost of change in the lifetime of a project. Red line: in a traditional sequential project, the cost of change becomes increases dramatically as the project progresses. Grey dotted line: the cost of fixing defects is similar. Blue line: the ability to respond to changes goes linear down as the project progresses.
Figure 2: Red line: The cost of change in a traditional sequential project. Blue line: the cost of change in a realistic agile project approach. Grey line: the cost of change ideally in an agile project approach.

The fallacy of end-game testing

Let’s fully develop the software product, and next let’s test everything at the end.


So, what’s wrong?

Bugs, defects are discovered late in the development process. The cause of the defect can be anything: bad design, mistake in coding, integration issue or simply a misunderstanding or misinterpretation in requirements.

So what happens in traditional sequentially phased product development?

Defects are reported late. There’s little to no time left to fix all defects. Only the functionally blocking defects are solved to get the application into an acceptable state. Any defects that “scratch the surface” or points for improvement are postponed to a “phase II” or “aftercare release”; which hardly happens, or which does not address all issues. And most importantly: this will happen way too late. In production, we call these “production incidents”.

People are pushed to work overtime and to do weekend work. Bugs must be fixed. Retesting must be done. Remember, we are in the project phase near the end (development has been done) and business stakeholders are impatient to release.

…with the software in production, fixing bugs is akin to repairing a car while it is driving down the road, long after it has left the drawing board, the assembly line, and the dealer lot. It’s as expensive to do as it can possibly be.

In sequential development learning happens late. Changing or removing requirements causes rework at a high cost and may break other functionality. Fixing defects is costly.

The fallacy of end-game system integration

Let’s define and develop all components or software layers separately. Next let’s have one phase at the end to integrate it all.


So, what’s wrong?

Big-bang system integration will not work as planned. An upfront system analysis or design will not be able to envision or control the full process of system integration. In real life complex software development, something always will pop-up or go wrong. The assumptions regarding the integration will not withhold, due to changes, constraints or simply unknown unknowns that are about to happen along the way. Real knowledge on how to integrate the system is acquired as you’re integrating: too late.

So what happens in traditional sequentially phased product development?

Integration problems at the end of the project: these demand ad-hoc and root-cause analysis but without the ability to systematically fix the underlying issue.

Delay in delivery and incomplete system integration means the risks are still high: not all potential issues have been discovered.

The fallacy of a fully planned-ahead schedule

Let’s create an end-to-end project plan, schedule all activities, plan and assign all resources, map all dependencies. Oh and additionally, we will add some buffer, as compensation if something unexpectedly happens – you never know. We also define the critical path and monitor it as a maniac.


So, what’s wrong?

We are assuming we have planned all the knowns, we have added some buffer for the known unknowns. But you cannot schedule for the unknown unknowns. We are assuming that we are good at estimating effort of all activities of the different project phases. Moreover, we estimate and schedule all activities upfront at the beginning.

Software creation is an inherently complex process. Given the multiple sources of potential changes and discovery of the unknown unknowns along the way, the project will never be executed as on schedule. In the process of creating, designing, developing, testing, new information and knowledge are constantly acquired.

Managers expect they can plan for all the variables in a complex project in advance, but they can’t. Nobody is that smart or has that clear a crystal ball.


Cone of uncertainty: variability in estimates

Cone of uncertainty

The Cone of uncertainty indicates the degree of variability in estimates during the lifetime of the project.

Humans are bad as estimating, even when given historical data. Estimates are considered as the truth, they become a self-fulfilling prophesy. The whole project is built upon those estimates and milestones are defined. Expectations are set and promises given. It becomes a dysfunctional model. The project progresses, but almost no one dares to truly acknowledge those initial estimates may be off. We don’t want to break the expectations. The whole project is built upon initial estimations which are taken as commitments. No empirical process is in place to get in touch with reality and to adapt.

So what happens in traditional sequentially phased product development?

Project managers track and update their schedule, pushing out activities ad hoc to resources. Metrics are used in waterfall because we had no idea what was happening so we try to measure anything.

  • Friction between project and sponsor
  • The blame game
  • The typical “IT projects always have delay” situation
  • Problems to actual change something about the situation: a lot of investment in infrastructure systems, development has been done. Rework causes changes to stuff already built.
  • Value is delivered at the very end of the project

The fallacy of gated phases, experts working in silos and hand-overs

Let’s ask the business owner to define the business need and a concept. Let’s ask the business analysts to translate that concept and deliver the business requirements. Let’s ask the visual designers to make stunning design. Let’s ask copywriters to write content and text labels. The functional analysts will create a functional speciation based upon those requirements. Next, a technical analysis will be performed, followed by a technical design. Those specifications will be accomplished with a set of non-functional requirements, and an architectural design. Finally, this will converge to a development specification. Let’s start development! Some period after, the testers start looking into requirements to write test scenarios.


So, what’s wrong?

It’s not efficient. It’s very time-consuming. Handovers between experts in silos will be a source of misunderstandings, misinterpretations. The business owner of representative will never talk to the developer. Requirements are lost in translation. A change or gap correction in the specification will be costly, often not accepted. No ability to act upon changes, resulting in missed opportunities.

Missed opportunity for a creative product development process: different people working in the different phases of the project carry their own opinion regarding their area of expertise. The concept and the design of the product therefore will be influenced / impacted. Unfortunately the sequential nature of the project does not allow incorporating all that feedback in a meaningful way.

So what happens in traditional sequentially phased product development?

  • Lots of time (and money) wasted on handovers, alignment between teams
  • Missed opportunity for a creative product development process
  • Lack of common understanding
  • No team alignment
  • Loss of intrinsic motivation, work satisfaction

To sum-up

A believe that an old industrial paradigm can be applied to software manufacturing. A believe that defining and planning the full project in advance will lead to a successful on-time delivery of the project. After several decades of software development, many new technologies, new practices came to existence, but the traditional manufacturing approach to create software products proves to not be successful.

What do you think?

Read more:

XP Days Benelux

XP Days Benelux (3 & 4 December 2015)

XP Days Benelux (3 & 4 December 2015) is the premier agile conference in the Benelux, intended for people from all walks of life who want to uncover better ways of developing software by doing it and helping others do it. XP Days Benelux is made for, and made by, the Agile Community. It focuses on practical knowledge, real-world experience, and active participation of everyone.

This year’s theme is the ‘Extreme in Xp‘. And we want YOU as a presenter! It’s a great learning experience and you’ll meet plenty of people interested in the same topic or struggling with the same issues as you are. And you get a free ticket to both days of the conference.

Our collaborative and iterative proposal improvement process and try-out opportunities help new and experienced presenters alike to hone their session, so that we can provide a high quality program. You don’t have to have a fully formed proposal, just submit a short description of your session idea and we’ll take it from there. In return for the help with your session, we expect you to help other presenters by giving feedback and asking questions.

Programme is available at

Business analysts as a workaround for organizational problems

Business analysis

A business analyst, or more generally, a business consultant, works together with multiple stakeholders to deliver the greatest value and is equally a driving force to enable change in an organization by defining needs and recommending solutions.

As such, business analysis is a much needed practice. Business analysis is an umbrella term: many other specific job titles exist. There even exists a business analysis body of knowledge and a business analysis career path (to take you to a mgmt. level) (a pity my career doesn’t advance that fast…).

In fact, performing business analysis can be a much satisfying job.

Business analysts as a workaround for organizational problems

Unfortunately – based on my experiences, business analysts are often squeezed between business and IT stakeholders. A group of business analysts is put in place to go on with the continuous task of translating needs and requirements, communicating scope changes from business to IT, and communicating constraints and drawbacks vice-versa; and this continues for the full project life-cycle.

In fact, business analysts are needed as a workaround for organizational problems. Organisations who cannot manage to have a direct, constructive and collaborative approach with all stakeholders will need a unit of business analysts to – what’s traditionally called – bridge the gap (note: in some organisations this figural speaking “gap” is the size of the grand canyon). In such a setup, the output of business analysis mostly happens in the format of some deliverables (documents), with a handover to the next stakeholder – this handover is, by definition, a form of waste.

It’s directly related to the organizational structure. Organizations traditionally shaped have separate silos “business”, “IT”, “operations”, with often intermediate organizational units to make all these people work together.

In a setup where people are collaborating directly in the same team, this gap will naturally be smaller or even dissolve. Claiming business and non-business people cannot directly interact and collaborate is a false prejudgement and it’s even plain insulting. I strongly believe it’s in the vast interest of an organization to share experiences, to create an environment that stimulates learning and improvement, and where people are encouraged to engage in practicing secondary skills.

At the team level

It’s clear that on a team level, the agile spirit translates into a cross-functional team. On the one end of the spectrum, there are small companies, start-ups and spin-offs which naturally have a spirit of cross-collaboration, cross-duties and ownership as a whole. On the other end of the spectrum, in large organizations, the challenges are profound. It’s not straightforward to create cross-functional teams and to establish collective ownership.

Different person profiles may exist in a team or by definition are not allowed to exist. A team – as a whole – will need to be able to perform the different tasks necessary to build whatever they are building – if they don’t have the skills or competences available within the team they rely upon an external resource, or more preferred: they acquire that skill or competence by learning.

The product owner is the business representative responsible and accountable for maximizing business value. That person is responsible for maximizing business value. While elaborating business needs, he’ll perform business analysis (in the broad sense of the term).

The team – together with the business representative will put effort to understand the business needs, analyse and refine and to communicate those business needs and requirements – as necessary; in any kind of format as necessary (oral or written).

As business needs tend to change quickly, we prefer to define the requirements fine-grained for the next work items (1 item in a single-piece work flow, or if working iteration-based, for the next iteration). Other items for the future remain coarse-grained defined. As we proceed with the work, the team analysis and refines, together with the product owner – who also constantly re-assesses the priority and value.

Business analysis revisited

Business analysis encompasses many other activities than simply translating business needs. Business analysis is a skill performed as a team, spreading knowledge about what the business wants within the team, and trying to minimize any hand-off. In fact, this description applies to any skill. Earlier, we wrote a post with the question if business analysis still exists in an agile team. Of course it does. But take care: we do not want to establish a business analyst who acts as customer proxy or proxy product owner. Business analysis is performed collaboratively by the product owner and the team.

More reading:

'We like to bring together people from radically different fields and wait for the friction to produce heat, light and magic. Sometimes it takes a while.'

Dynamics of a team: creating a team manifesto, defining our principles and values

When you put a group of individuals together, don’t expect them to act as a team “in a magical way” from day 1.

'We like to bring together people from radically different fields and wait for the friction to produce heat, light and magic. Sometimes it takes a while.'

‘We like to bring together people from radically different fields and wait for the friction to produce heat, light and magic. Sometimes it takes a while.’ (author: Brad Veley)

Half a century ago, Tuckman already described the different stages of group development: the team model: Forming – Storming – Norming – Performing.

Tuckman 5 stages of team development

Tuckman 5 stages of team development

Tuckman stages of group development


Let’s explore the “dynamics” and emotional intelligence of a team and how a common understanding can help the team to get to a “well performing” state (besides the emotional intelligence, it’s absolutely necessary to have good technical skills and modern day engineering practices, e.g. in the context of product / software development – but that’s not the subject of this article).

It’s known that emotions and behaviours in a group are contagious and can have a dramatic impact on a team. After all, we are humans and not robots are we? You could say, one person is more professional than the other and can put aside any emotions in a professional environment. On the other hand, some degree of emotional binding is necessary to get to an effective team.

What’s important for a team?

We would like our team to be focused, be collaborative and have a sense for common purpose.

The key is to establish a social contract: a team manifesto.

A team manifesto is a team-designed agreement for a set of values, behaviors and social norms. It’s a vision for the team built on a common set of principles and values.

An example of the characteristics of a team with high positivity / high productivity (source: team coaching international)

Team high positivity high productivity

Team high positivity high productivity
Source: Team coaching international

In general, a set of positivity strengths and productivity strengths are necessary to come to a well performing team.

A team assessment by doing some team diagnostics can reveal the current state and determine points for improvement.

How do we get going to define a team manifesto?

In case of a new team, you can do a profile card exercise so that people get to know each other.

You can also do a personal agility rating exercise. This is useful for individuals themselves and for a coach as he can use this info to improve on agility on an individual basis in the future.

Next, you let the team define what it means to be a “team”.

We also let the team define what “quality” means.

The team discusses any other principles and values it considers important.

Next, the team garters all the input on a big flipchart or board and creates a team manifesto.

Create a manifesto

Create a manifesto

Please note: when working with multiple teams, the teams could define a manifesto per team – this seems the most natural as teams will be different. You could also define a manifesto on the level of the project / programme, including a vision for the product or service being built.