Daarnaast ervaart 83 procent van de Nederlandse bedrijven die Agile werken hebben geadopteerd, meer werkplezier en 85 procent meer teammotivatie. Dit percentage is aanzienlijk hoger dan vorig jaar, toen gaf driekwart van de respondenten aan meer werkplezier en teammotivatie te ervaren. Dus de mensen die Agile werken varen er wel bij, naar mijn mening een van de belangrijkste redenen voor het succes van Agile. Dit komt ook veelal tot uiting in een lager ziekteverzuim en grotere loyaliteit naar de werkgever toe.

Andere belangrijke effecten zijn een verkorte time-to-market volgens 79 procent van de ondervraagden en toename van de productiviteit (66 procent). Het onderzoek laat ook zien dat kostenverlaging een belangrijker effect van Agile werken is dan vorig jaar (38 procent in 2011 tegen 21 procent in 2010). Niet zo vreemd natuurlijk in deze economisch zware tijden. Maar dit betekent wel dat Agile steeds meer wordt ingezet als onderdeel van een kostenverlagingstraject. Dan is het wel heel belangrijk ervoor te waken, dat met het (meer) sturen op deze doelen de Agile gedachte niet ten onder gaat in de zoektocht naar kostenverlaging. Indien kostenverlaging wordt neergezet als primair doel met Agile als middel, is de kans groot weer te verzanden in ‘ouderwets’ contract en KPI management waarvan we in het verleden nou juist geleerd hebben dat dat niet effectief is.

In de overgang naar het Agile werken is de bedrijfscultuur net als vorig jaar de belangrijkste bottleneck voor veel organisaties (49 procent). En ook dat is geen nieuw inzicht. Maar het is wel iets dat te vaak onderschat wordt, zeker door belangrijke personen die juist onderdeel zijn van die bestaande bedrijfscultuur. De adoptie van Agile vereist veel focus en energie voor langere tijd en de daadwerkelijke borging vindt plaats juist via een inbedding in die bedrijfscultuur.

Door het verbeteren van kennis, kunde en bovenal mindset van Agile zal de uitrol een grotere kans van slagen hebben. De ondervraagde organisaties erkennen dit gegeven zelf overigens ook, want volgens 36 procent is een gebrek aan kennis en kunde de belangrijkste beperkende factor in de (verdere) implementatie en uitrol van Agile. Door juist in deze economisch uitdagende tijden in kennis, kunde en mindset van Agile te investeren zullen organisaties meer rendement kunnen behalen. Het verbeteren van bedrijfsresultaat is nu bijvoorbeeld voor veel financiële instellingen in Nederland een belangrijke reden om Agile te gaan werken: zo kunnen zij namelijk effectief hun te hoge kostenstructuur aanpakken.

Agile belooft dus veel, maar maakt dit ook waar. Zeker gezien de huidige generaties Y en Z die nu opgroeien en de toekomstige werkbevolking van Nederland gaan vormen, is er geen ontkomen meer aan (iets als) Agile. Regelmatig spreek ik diverse (jongere) sollicitanten die Agile, en de manier van werken en omgaan met elkaar die daarbij hoort, heel normaal en gewoon vinden en die gruwelen bij een beschrijving van het traditionele waterval model en bijbehorende werkaanpak. Het aantrekken van jong talent en een werkwijze die niets met Agile of elementen daarvan te maken heeft, staat bijna haaks op elkaar. Blijvende continiuteit en succes op langere termijn voor ieder bedrijf bestaat voor een belangrijk deel uit het aan kunnen blijven trekken en behouden van jong talent. Agile worden of zijn, lijkt hier een belangrijke voorwaarde voor te zijn.

Ik ben benieuwd wanneer u op de succesvolle trein stapt die Agile heet!

The desire to change

Suppose one day, after a particularly bad hangover, you decide to change your life.  You long for a trim body, a balanced spirit, lots of energy and no more headaches. In short, a happy mind in a healthy, good looking body. But how do you get there?

Well, we all know that there are many practices that will help you achieve those goals.  Exercise three times a week, stop smoking, reduce your alcohol intake, and change your eating patterns. Oh, also, get more sleep, less stress, no more pills, and drink herbal tea instead of espressos.

But you hate sports, you love chocolate and smoking is your way to reduce your stress.  So what do you do?

The daily fruit practice

In order to get healthy, you decide that from now on, every day, you will eat a piece of fruit at lunch.   It’s pretty easy to do, even though you don’t like fruit very much.  So now you are satisfied, you do a healthy thing every day, and you expect to reach your goals (more energy! greater happiness! better looks!) anytime soon.

Will you? Of course not! While the daily piece of fruit is a step in the right direction, you will never fully get the benefits you are seeking if you keep up your old habits of smoking, drinking and eating greasy food,. And after a while you might even get disappointed and frustrated, and you will decide to stop eating fruit, claiming that “a healthy lifestyle simply doesn’t work for you”.

Doing just one healthy practice, or even a couple of them, isn’t enough. What you really need is to change your mindset. You want to be a healthy person, not do some healthy stuff. Once the healthy mindset becomes your way of life, the practices will simply be the natural way to go. And they will be a lot easier to start with and maintain for a long time.

The daily Agile practice

The same applies to Agile. We see many companies and teams that ‘ do‘ Agile. They take a couple of practices from an Agile framework such as Scrum, and they figure that that will be enough to give them all the Agile benefits. Some teams even think that if they just do a daily stand-up, they do ‘ Agile’.  While daily stand-ups, just like that daily piece of fruit, are definitely a good practice, your are still far removed from true agility if the rest of your behaviour consists of old, non-Agile practices.

A company or team only gets the most out of being Agile, when its mindset is based on the Agile principles stated in the Agile manifesto, such as continuous learning at all levels in the organization, business and IT working closely together, delivering the highest business value first, welcoming change, and creating an environment where motivated individuals can be creative and self-directing.

So if you are doing ‘some’ Agile, expand your practices. But more importantly, change your mindset. Don’t do Agile, be Agile. And remember:

One practice a day does not keep the old habits away…

The perceived need for scaling could follow as a reaction to the scope of the project at hand. It is quite common within projects to try and do as much as possible parallel development of different semi-detached functional areas of the product. This comes quite close to how I used to manage projects in the past. Whatever in the same timebox could be done in parallel, should. I was very efficiency driven back then, but also taught and stimulated to think this way.
Within this paradigm it would be preferable, that the PO has some sort of party around him helping to create the user stories he would be in charge of. Creating big teams gives us more capacity to do more work in our timebox. Larger teams and more work create the need for more coordination, because of limited span of control, thus creating the need to scale.

Also, I think we are still very much driven by the paradigm of the chain of command. It is simply comfortable when there is someone who can make the tough decisions for us and mediate between us whenever conflicting interests arise. The need for extra coordination between and over PO’s in the same context thus fits very naturally with our needs in a growing project context.
Come to think of it, maybe it is no coincidence that the person designated CPO is more times than not the first PO that was on the project. If we look deep within ourselves wouldn’t every PO actually want their first project steps to be so successful, that the extra means are granted to grow the team and consequently rise above to lead the way as CPO? And should we be that CPO, would we ever fully trust another colleague with the work we carefully prepared and poured our blood sweat and tears into? It would be great if we could somehow keep some sort of supervision on the others. Make sure the projects success and our hard work isn’t killed off in the next sprint or two. Scaling with a CPO construction would provide means to fulfill these needs.

Of course the above reasons to scale could be valid, but there are also downsides to them.

Although doing parallel work may sound efficient, maybe validation with your customers shows that the product increment doesn’t fulfill their needs as thought up in the first place. Since you have done a lot of parallel work, the risk of waste is also greater. Should you need to radically pivot your product in another direction, it will be much harder due to the already large scale of your operation.
I thus think that scaling towards having different teams work on the same backlog potentially inhibits us from maximizing validated business value, as you are pulling forward less important features from the backlog, before actually validating and thereby knowing whether you have actually delivered value with your top items. From this angle, it would be wise considering not to scale.

When scaling from success, we run the risk of slipping into a power monger mode and form a team beneath us to gain status and control instead of branching out sideways.
When this happens we are not working towards joint company stakeholdership any more, but we trying to build our own ivory towers. When the CPO leading the PO’s claims decisive power in certain areas, I believe you would not be creating the right entrepreneurial environment in which decisions are based on arguments and value for the customer and company. Maybe, as a PO, if you already know you need a decision from the CPO, you are inclined to use other influencing methods rather than comparable and less subjective measures than for example business cases, jeopardizing the quality of decision making and therefore the success of the product.

During my study, I was taught “there is no one best way to organize”. I think of this line as a universal truth, that in my opinion also applies to scaling the PO role. I therefor think that form is less important than the route taking you there. Knowing that there are risks involved in scaling and consciously dealing with them helps you along this route to find a form that works for you.

(*)Scaling is also common in productline contexts (for instance a CPO over a group of PO’s managing a product family) or within business units where you would have various strategic themes that the CPO would like to have implemented over the same time period.

Getting a view on innovation
When a company fills in a portfolio tool like a Boston Consulting Group (BCG) matrix, it gets a view on its product market combination (PMC) portfolio. You can tell a lot about the company and its business from how a BCG matrix (*) develops over time. One of the most fun things in my eyes is the amount of question marks turning into stars. A question mark being a PMC in a high growth, low share section (e.g.; doing something relatively new), a star being a PMC in a high growth, high share section (e.g.; being successful in doing new stuff).

The amount of question marks in the portfolio illustrates the amount of newly launched PMC’s on to target markets. When you also consider the amount of ideas not becoming question marks, and turn this into a ratio, you could get some idea on how innovative the company is. Add to his the amount of question marks turned into stars and you really get a sense of outward successful innovation. I distinguish outward and inward innovation, because I believe that experiencing a commercial hypothesis to be proved wrong is at least just as valuable as seeing it proved right.
This doesn’t mean that innovation can’t be applied in other quadrants, just that it might not be the smartest thing to do when for instance handling dogs. In many cases adding features to cash cow products can be a brilliant strategy. Take for example razors, where adding more razorblades, self-adjusting blades and other sleight handling improvements constantly extends the product lifecycle.

Innovation flavours
To get an idea of how scrum could accommodate for innovation, first we have to get an idea on the various sorts of innovation like “additive innovation” out there. In general there are four forms of innovation a company can venture into:

Incremental innovation: small improvements leading to slightly better results

Additive Innovation: adding product features, customization, new products in existing business lines

Complementary innovation: creating new offerings new in current business, but adjacent to current product lines

Radical innovation: doing completely new things, unknown to business and/or target markets.

Using agile to suit innovation
In the following section I will highlight a couple of alternative ways in which you could use agile and scrum mechanics to shape and facilitate these forms of innovation:

Incremental innovation:
1. Spend a retrospective or a section on this product improvement; try to get in one small improvement each sprint. Maybe this will ease the team into providing more input for the backlog.
2. Agree with the team that every sprint every individual team member comes up with at least one idea to improve the product in some way.

Additive innovation:
1. Create spikes in sprints to prototype new features, validate these with customers;
2. Hold demo like meetings with your target audience; ask them what they think about the product.

Complementary innovation
1. Keep key options open, have stories worked out in two variations and do validate these paths in spikes and demo meetings;
2. Invest time in finding the appropriate product owner for the job. Market and customer knowledge is important here as the company is going to serve adjacent and different markets than before;
3. Take care that the entire DMU is taken into account in the story map. Also look at internal impact of providing new services and products, for instance customer service needs.

Radical innovation
1. Make sure the innovation team is freed from all organizational gravity. Pull them away from status quo and peer paradigms;
2. Reserve time for existing teams to work on a free format project. This could be a once every month time box of a day for example. It can be whatever they would like, as log as results are made transparent. Let them the same social objects as in scrum (boards, graphs, backlogs);
3. Take care that you have means to measure relevant metrics early on. Every addition should increase sales, market share and other relevant metrics. Use retrospectives to find root causes and steer through story map;
4. Keep all options open, incorporate A/B tests, multi-variant tests, prototypes, feature polls and so on. Sprint goals are hypotheses you would like to see validated.

What I love about scrum, is that it so lightweight and adaptable. On the incremental- to radical innovation scale, there is no step in which scrum can’t be adapted to accommodate for innovation while remaining to move fast.

The above list is just a brain dump of what I quickly came up with. I am convinced that there are many more creative ways in which we could adapt agile and scrum practices towards innovation. Please view this blog as an open invite to share your thoughts on this subject.

PS: Merry Christmas and a very Happy New Year!

(*)A BCG matrix says nothing about profitability of the PMC, so market share in a growth market could be labeled as a vanity metric. The matrix also builds on the premise that you know a market to put question marks in. Sometimes however you don’t know what your market is going to be. Furthermore, the BCG matrix can be filled in numerous ways depending on how you define for example the market scope.

All these questions could and probably will play a role in the consumer
buying process of complex products and therefore ultimately decide whether product “a” is bought or competitor “b”. It’s not said all of these questions get asked and answered by the same person(a). Most buying decisions of complex nature are made by a so called decision making unit or DMU.

Decision Making Unit theory indicates a number of roles with regards to
buying decisions such as the:

- initiator : identifies problem/ need to solve;
- gatekeeper: regulates info for decision;
- influencer: influences decision;
- buyer: buys solution;
- decider: decides what product to buy;
- user: actual user of product;

We build storymaps based on pragmatic personas, which are primarily users. Selling our product however, as decision making theory shows us, may mean tactically taking into account the entire decision making unit, not only the users. I encounter a lot of releasable walking product skeletons, neither shippable nor marketable.
Too thin a walking skeleton, means releasable, but no one will buy it. Too fat a walking skeleton, means putting in too much and missing crucial market windows.

A sellable increment, which if possible is of course also a first release, means fleshing out your skeleton just a bit more making it more of a sellable Frankenstein than just a bag of bones.

A sellable increment or marketable feature set, in my opinion is your
kano threshold attributes + a well thought-out and implemented set of performance attributes, resulting in the product being a viable option in the customers consideration set of alternatives. Next to that, we need a good usp, or a unique set of these, positioning your product from all others. All of these product properties, or a specific set depending on your product marketing strategy, will need to be translated to DMU needs, to be able to hone the product for sales.

My advice would be to start thinking about the DMU and how this works for your product. Get marketing involved and see what they already know about the composition of the DMU. Create some peronas and try to involve them somehow in demos and future plans to get the feedback you need.

Heidegger uses the doctrine of the four causes¹ that Aristotle described, which can also be applied to organizations. The first cause is the causa materialis, the material of the organization. In organizations, people, capital and material are together forming the causa materialis. The second cause is the causa formalis, which is the shape of the organization. This is the organizational structure, the processes of an organization and the way the office rooms are organized. The third cause is the causa finalis, the goals that an organization has. These goals can be at the organizational level (f.e. mission, vision, strategy), or at the personal level (the goals you make on your own and get from your boss). The last causa is the causa efficiens, which is the activity of being an organization. It is the resultant of the other causae and added to that the activity of being an organization. The causa efficiens adds the time-factor to the equation.

What makes this theory useful? It proves that every organizations should give attention to these four levels in order to stay a healthy and balanced organization. First, an organization has to work to keep his resources healthy, especially human ones. Mark that humans should not be treated not merely as a means to an end, but at the same time as an end in itself. Second, an organization should improve his form, in order to maximize the outcome (not just output!) of an organization. Third, organizations should define their vision and their goals. It is important to align these goals in such a way that they conflict neither horizontally nor vertically. Too often I have seen managers fighting for resources because their goals conflicted with each other. Sadly, the result is that neither of them reach their goals. Fourth, organizations should have their focus on these three causae and continuously improve them. There is not such a thing as an ideal organization. Time changes things and you need to adapt to (or even initiate) these changes.

Heidegger and Aristotle make useful distinction between causations in organizations. This distinction enable us to focus on the right thing. Healthy resources require attention. This applies not only to materials, but also on your employees. You have to find high qualified developers and treat them as real craftsmen. People are able to take far more responsibility compared with the amount of responsibility organizations give to their people. The organization should be shaped in such a way, that the material (people) could reach their goal in an optimal way. A fundamental condition to execute this is a well designed mission, vision and strategy that is aligned both horizontally and vertically. Steven R. Covey writes in ‘The 8th habit’ that only four of the eleven people know their goals, and only two of the same eleven do actually care. Although most companies do have a mission, vision and strategy, most people cannot answer the question how their activities contribute to them. But most of all, to be committed to do all these items continuously. Agile and Lean can help with this, enabling your organization to adapt changes.

Heidegger and Aristotle are both dead, but their thoughts are still invaluable.

(1) Aristotle, Metaphysics, Book 5, section 1013a

What puzzles me, is that if we are wired by nature to enjoy cooperating effectively in a collective, then why do we encounter problems with it in our workspace. I think the main cause of these problems lies in the lack of shared purpose that motivates us, and the ability to trust each other in the pursuit to be purposeful. Maximizing income, and therefor your own benefits, is not real purpose that is felt across your organization. This doesn’t work in complex environments like the IT companies we are used to support with agile. Real purpose, mastery and autonomy however do, as Dan Pink shows us in his illustrative video on this subject. Others, like my colleague Olav Maassen, recognize this as well, trying to channel mastery into new forms for the workspace and beyond.
Another great example of seeing Dan’s findings in action, in my opinion, is the IDEO initiative openideo.com. People can literally join forces and find solutions that actually help to solve collective real world problems. They do so for free, just because they want to. Talk about working together to change the world! Although you can score points for helping in openideo, showing off your mastery in product and idea development, I think the greater driver here is the urge to help others in a collective fashion. Wouldn’t it be great if we could have an openideo in every company out there? We have so much knowledge, creativity and willingness in-house to collectively bring our companies to the next level. We only need to truly engage our co-workers.
That’s were autonomy comes into play. We should trust each other enough to facilitate more autonomy in the workplace. Provide room to your stake-takers and become genuine stake-sharers on route to joint company stakeholdership. Why not trust on one another rather than being fearful of the negative impact on our own stakes. I guess this also has to do with purpose somehow. Idealistic purpose with no sense of realism leads nowhere and maybe even worsens the status quo.

As agile consultants and coaches we try to foster teamwork and consult in change towards sharing ecosystems. I guess we could say we are blessed to have nature on our side. I guess we can also say we need to balance idealism and realism in creating purposeful systems and that this requires a significant level of trust within our clients organization. Although this may sound pretty far away, why not start with people in your direct circle of influence. Try to be as transparent as possible towards your client. Work together and build trust through trust, paving the road to change.

Acceleration is a must

Scrum advocates the use of pokercards quoting the estimation of work items in story points. Velocity is the total number of story points a team can take on in a sprint.

Next to using velocity for planning, velocity is often promoted as a measure for improvement. Learning, solving impediments, implementing improvements, more fun and better team play all should lead to an increased velocity over sprints. Steady or even declining velocity is a signal of a mediocre, non-improving team.

The theory and actual practice of estimations in story points diverge, which makes drawing performance conclusions out of velocity records a tricky business. The question is whether velocity should be used as a measure of improvement at all. This blog explains why you should not, or at least that doing so should be reserved ‘for trained professionals use only’.

How do you like your Story Points?

In a last-summer blog (June 21 2010, its-effort-not-complexity) Mike Cohn qualifies the relabeling of story point to complexity points as ‘wrong’. He states: “Story points are not about the complexity of developing a feature; they are about the effort required to develop a feature.”

If we follow Mike, story points are a function of complexity, amount of work (‘sheer volume of work’) and expertise (of the team on the domain). Maybe uncertainty should be part of the formula as well. The consequence of this definition is that the amount of work reduces when the team gains more expertise, uses smarter solutions or can profit from structural improvements.

So following Freyr in his first comment on Mike’s blog “a story last year which was a 5, now has some process improvements and this year is a 2. The velocity of the team stays steady, story points per story decrease.” Let’s call this method A.

This way to determine story points differs from the way I was raised with: user stories are estimated relative to a fixed (set of) reference user stories. A story of 5 last year is still a 5. Implemented improvements (whether technical or on teamwork, skills, knowledge or competences) should lead to higher performance so that we can do more such stories in one sprint. Velocity increases, story points per story stay steady. Let’s call this method B.

Count on Story Points while planning

In Scrum estimations and velocity recordings are primarily used for planning purposes. User stories are estimated in story points, and the number of stories planned in sprint depends on the sum of story points of these stories and the velocity of the last sprint or two. Furthermore, story points and velocity records can likewise be used for release planning.

Whether using method A or B a team can properly predict the result of a sprint. And in both cases one can calculate and forecast the number of sprints needed to finish a selected set of user stories in a release.

However, using method A the team will need to deal with new competences leading to lower estimates, even for user stories estimated in ‘the past’. Using method B the team needs to deal with improving velocities when predicting the number of sprints needed for a set Release.

Measuring improvement is a different story

Scrum promises an increase in productivity / performance. A growth factor of 4 even up to 10 is often quoted. Soon after the introduction of Scrum management requests proof of this growth, especially after they have been baffled with all formerly hidden impediments in their organisation: Scrum does not solve your problems, but reveals them! Putting a heavy burden on the belief in reaching the benefits promised.

Very often velocity is used to measure this improvement. This is only valid if we keep the story points for the same kind of stories steady, as shown in method B. In fact this should only be done if we restrict the formula of estimating story points to size, the size of a piece of work. This is shown by an example by Jose in another comment on Mike’s blog:

Imagine that we have a team of painters and their job is to paint walls. The team sees pictures of the walls and they estimate the wall area to be painted. There are small walls, medium walls and some really big walls. The team estimates each area using relative points. They start painting the walls and after some time, they are able to calculate how many points they can do on each sprint, the velocity. Now the customer can calculate how long the project will take, using the velocity and the product backlog.

The problem is that determining size is one of the most difficult challenges in the field of software development. There certainly are environments where this works fine. Recently we coached a team in a Business Intelligence environment, who were able to define their workitems in predefined steps, and who had derived formula’s from experience to calculate the size of work for each step. Their estimations were remarkably accurate.As soon as the painters get better tools and paint, or gain in experience and concentration they will be able to color bigger walls in the same amount of time.

For most other teams the thing coming closest is Function Point Analysis, which is far from easy and a not a common competence in Development Teammembers.

About every other team we have seen estimates effort. Better tooling, a higher grade of automation, more competences, all lead to less effort and are discounted in the final story points. Fine for planning, but using velocity trends based on these story points is a very tricky business and will not reflect the growth teams realized to the amount they deserve.

The point of this story: size matters

Story points are calculated using different methods and formulas. If your formula does not equal just sheer size, you should not use your velocity measures as an indicator for performance growth. Like you cannot learn your performance development by simply comparing the scores of two games of rugby. If there are many other factors influencing the scores you will do wrong to the team and you should stick to use these records ‘to start a conversation’ only. Measuring the improvement in performance ain’t easy.

I was so fortunate to be invited to present at the 10th edition of the QA&TEST. The conference focuses on QA and testing for embedded systems, an area I know little about. Though, when I first started testing in the late nineties, I was so lucky to work with a gentleman that had lost his job at Fokker (the airplane manufacturer had just gone bankrupt). At Fokker he used to test instruments used in the airplanes, like altitude meters, speedometers and other fine machinery. He knew very little about computers and was struggling with was to me basic stuff (being a rookie myself), but he was also one of the most structural and detail critical people I ever worked with. Besides loads of test techniques and responsibility for my work, what I learned from that experience is that testing is testing and the same rules apply in most fields. So after contemplating the above I happily accepted the invitation. What I experienced during the conference is that testing embedded systems is about software testing and lucky for me, in this field Agile methodologies and test automation can be applied just the same.

Automated Reliability Testing via hardware interfaces by Bryan Bakker

How test automation can successful be applied was highlighted by fellow speaker Bryan Bakker who did a great presentation of a case study on how his team. The team was requested to improve the reliability of a system and call it in an act of rebellion kept on increasing test automation rather than adding new functionality. This resulted in (if I remember the correct figures) a savior of over 1.2 million euro’s on damage that bugs would have otherwise caused in production. The result was so spectacular that they were granted extra budget to continue with their work, but also to apply the approach in other projects. Interesting takeaway from his presentation, that seems a bit more specific for embedded systems but might apply in other area’s as well, was a smart test-scheduler they had introduced. The product under test was a medical x-ray device that under circumstances would get an overheated engine, it took hours for it to cool down again which made it impossible to continue the test run. Whenever this was detected they would automatically switch to other types of tests, that were less dependent on the engine and could run until the engine had cooled down again. A simple but effective time-saver coming from a pragmatic mind.

Continuous Quality Improvement using Root Cause Analysis by Ben Linders

A session I unfortunately did not actually attend to, but that I had an interesting discussion about with the presenter, was the conference closing presentation by Ben Linders called “Continuous Quality Improvement using Root Cause Analysis”. He claims that a team can accurately predict the number of bugs it is going to make during a sprint and he has developed a method to help reduce this number using root cause analysis. I found this a fascinating and somewhat controversial idea, I have yet to meet a developer (specially the ones in Agile projects) that can admit let alone predict they’re making bugs. But as I understood it works in a similar way as predicting velocity, you get more accurate as you go, using historic data from previous sprints.

Runaway Test Automation Projects by Michael Stahl

The presentation of Michael Stahl titled “Runaway Test Automation Projects” seemed less relevant to Agile environments (at least the once I worked in), he however pointed out lots of valid risks that exist when doing test automation. Main take away for the audience in my opinion was the point that test automation should be treated as “regular” software, creating unit tests, applying quality standards and using version control. Things that in my experience sound like common sense, but never the less very true.

Pushing the Boundaries of User Experience by Julien Harty

The presentation that was probably of the most added value to me was called “Pushing the Boundaries of User Experience”, by Ebay’s Julien Harty. He had an enlightening story on automated user experience testing. With crawlers like Crawljax analysis of the dynamic (Ajax) behavior of a website can be done. With static analysis accessibility issues can be found, stuff that can be very important if you want to comply to WCAG guidelines, which hardly ever gets proper attention. Accessibility is often seen as something to facilitate a minority, but from a development point of view it helps to improve testability of the product What makes accessibility testing feasible from a business perspective is that it actually helps to improve search engine optimization, which increases the visibility of the site in search engines.
He explained how at Ebay they run automated tests for improving usability and accessibility, but also for finding layout issues and browser dependencies in a cost effective way.
Layout bugs can be found in an extremely simple but effective way using FightingLayoutBugs. Let me describe this in a little more detail.
How does this work? First you need to know which pixels belong to text, second you need to know which pixels belong to a horizontal or vertical edge, now if text pixels and edge pixels overlap you have a layout bug. Sounds pretty simple and it actually is!
How is text detected? All text of a page is set to a white font color and a snapshot is taken. All the text on a page is set to black and a snapshot is taken. Now when the two are compared, all different pixels are probably text.
How are horizontal and vertical lines detected? First set all the text on the page to transparent (btw setting the text color is done using jQuery), so now there are only graphics, take a screenshot. Now it’s identified which sequences of pixels have a certain minimal length and the same or very similar color, only those that have a high contrast to the left or to the right are selected. The same approach applies for horizontal lines. Now compare the outcome with the identified text. When text and lines overlap there’s a layout bug (which happens to be automatically reported).

During a life demo Julian ran some of these tools against the conference website. With web-accessibility-testing pointed out how bad the accessibility was for people that rely on tabbing to navigate through the screen. Static analysis of the site pointed out the page contained url’s with duplicate or no alt texts. Stuff that seems of minor severity but for disabled people essential. He concluded by revealing a security issue that caused some hilarity. He gave away the most lucrative reduction code for registration. It turned out all reduction codes for the conference were hardcoded in the Javascript in the page source.

All together it has been a valuable learning experience, beside the fact that a visit to Bilbao alone is definitely worth the trip!

I encountered a lot of story-maps based on this principle in financial services lately. The “hello world”-first slice, or walking skeleton, comprised of nothing more than the bare minimum technical necessities to get a working chain environment end-to end. Later being fleshed out with additional functionality.

Most of the times this is the right thing to do, because in most cases there are dependencies with other systems and internal “suppliers”. The risk to see whether the system would work with these external systems later on in the project is too big to postpone, to when the features come up that possibly depend on these external pieces of the product puzzle.
Getting these dependencies out of the way, means seeing a working chain and having a better picture of how things work, mitigating the risk associated with delaying dependencies. For the external factors it means building the essentials and stubbing the rest, creating the barest technical walking skeleton possible, a working end-to-end chain.

Strangely some projects I saw with large amounts of external dependencies did see the value of this possibility, but still decided to go for a more functional first slice of the product, leaving them struggling for months before delivering end-to-end working software. How could this be?

The issue here was, that at the start of the project people all saw the dependencies but none of them could be addressed effectively. The major issue was the fact that all but one external supplier to the project were actually other internal departments that couldn’t/ wouldn’t lend resources and rather stick to their own release calendars (making them real old skool stakeholders by the way which is pretty evil). They also had a lot of problems getting their own environments from outside of the project, which didn’t help as well.

In the ideal world this project should not have started without the necessary support in place to complete the first ideal optimal technical slice in a couple of sprints. Which is actually not so different from when you create a regular walking skeleton come to think of it ☺. Remember to keep a technical walking skeleton an option when working in complex chain environment and or existing system environments. You might be amazed how fast you can get the first feedback, from customers and other stakesharers.

Should you have some interesting other slicing dimensions you would like to share, or you totally disagree with me, please leave a comment below! Many thanks in advance.