Antony Marcano's Blog - Latest Comments

Re: From Scrum to Kanban – good and bad reasons to switch…

Paula — Thu, 31 Oct 2019 20:08:03 -0000

Obviously, it all depends on the situation. But even if you choose something, you can always convert! Here are some tips on how to convert from Scrum to Kanban: https://kanbantool.com/kanb...

Re: Segue Steps

Paul Littlebury — Sat, 23 May 2015 21:54:38 -0000

BDD and the tools were kind of scrappy for a while, but over the last 18 months, the pace, adoption and improvements have been ever-increasing.

Re: Segue Steps

Paul Littlebury — Sat, 23 May 2015 21:52:37 -0000

(Very) belated comment, but Gherkin is very flexible. Common misunderstanding is it's not, but if you look at it as code (which is what it is), it becomes a programming type exercise. It's just another layer of abstraction (the next layer up from the acceptance test code). Multiple "should"'s for example, can be treated as an array, in Gherkin. Common steps can be bundled as one Gherkin statement, when specifying complete steps are unnecessary. Forms can be processed as tables, rather than lengthy "I fill in this with that". Developers appreciate the well-structured scenarios, as it guides them better too. BDD a commitment thing, and so is the Gherkin - it does take time to build up, but you end up with a suite of executable natural language features, and strict QA. It kept a good project momentum going too. The Gherkin art is in keeping it readable, but not letting it stand still. And of course documenting, and alerting others to new Gherkin available to use. The out-the-box Gherkin is a bit mundane, but picks up on many common steps - we are not as original as we think. Where the value becomes apparent, is as the test application grows, and more custom Gherkin(DSL) is created. The value even better demonstrated when integrated with the app it is testing. Becomes it's own development/testing machine ;)

Re: It starts with a story…

Paul Littlebury — Sat, 23 May 2015 21:34:22 -0000

I should add that in the recent projects I have been working on, we derive a Feature (one of many) from a User Story, then break that down into Scenarios (i.e. Capabilities). The Features/Scenarios are written in DSL, and executable as accurate acceptance tests. Just trying to tie out two worlds together. BDD/Kanban has warped/moulded my perceptions somewhat ;)

Re: It starts with a story…

Paul Littlebury — Sat, 23 May 2015 21:25:31 -0000

The issue you highlight, of people thinking of user stories as “what the user will have”, is a very pertinent one. This no doubt leads to vague user stories we have all seen. Like reading an answer, before you know the question. Or the uncomfortable shoe-horning, of the sometimes chaotic human thought process, into the standard user story template. This is a reason I am such an advocate of Behaviour-driven development, as the focus is on capabilities (to borrow your term) or scenarios (I believe these are in similar area). Whereas techies tend to look for path(s) and caveats, by default in user stories, clients tend to go straight for the destination, loaded with assumptions. That long-acknowledged, but narrowing gap in translation of requirements to code was improved by evolution of Agile, but the skill of writing user stories is still very underestimated! On projects, I think it is very important for people to push back on user stories, if clarity isn’t there. Surprisingly how little this happens - perhaps it’s a confidence things, and fear of a user story review, coming across as criticism. But I guess that is another discussion :)

Re: What do special forces teams have in common with agile teams?

Gabriel Oliveira — Thu, 13 Nov 2014 13:25:58 -0000

Nice parallel !

I'm all in for the idea of "tags" instead of "job titles" and was agreeing with the whole text until that phrase:

"the task that is the most relevant and valuable to the
team at that time, within the context of the project’s goals, rather
than just the tasks of most relevance to my job title"

Sometimes, the project goals may be harmful and blind the team to some other tasks that someone "knows" has to be done (like a new tool to analyze some data or the POC of some technology that no one in the team have expertise yet and they may need in the future). A "responsible specialist" may use some "free time" to tackle some of those tasks, while someone "following the goals" would pick up the next Sprint story...

Of course, If the PO is a nice person and the team has a good relationship with him/her, those tasks can be made visible and emerge in the next planning meeting and may even have a higher priority than a Story would :) In that particular case, the "just follow the goal" approach would work well

Re: It starts with a story…

tuexss — Thu, 29 May 2014 16:27:33 -0000

There's an easy test for your user story: Will it make sense if the "user" is blind and quadruplegic?
Or another test: Will it make sense in a technology-free fantasy-book?

If yes, than the user story probably describes actions and interactions of agents.
Otherwise you describe features of some software behaviour within a certain technological device.

Re: It starts with a story…

Antony Marcano — Wed, 21 May 2014 03:16:45 -0000

Thanks for your comment Coyote. Indeed. Mike also pointed this out in his book, "User Stories Applied", in the chapter "What Stories Are Not". He summarises this again at the end of the chapter: "It is more important to think about users' goals than to list the attributes of a solution."

I suspect that many people who make the mistake of feature-orientation haven't read Mike's book, certainly not properly. So, I thought I'd try to provide a shorter explanation that gets the point across in a different way.

I think that part of the problem is that many people look at the apparent simplicity of user stories and just do what they've always done except with a superficial application of the Connextra template (As a...I want...So that...). They may read literature on the web and find plenty of examples (written by people with the same assimilation bias) that support their assumptions and association with their past experiences of 'requirements'.

This focus on features is natural. I'm pretty sure there was a time where I also thought of stories in this way. This is explained quite well by a quote from Udi Dahan:
'Users ultimately dictate solutions to us, as a delta from the previous set of solutions we’ve delivered them. That’s just human psychology – writer’s block when looking at a blank page, as compared to the ease with which we provide “constructive criticism” on somebody else’s work.' -http://www.udidahan.com/201...
Quote Highlighted: https://diigo.com/01uzg5

It's not just users, it's also those who may represent the users such as Product Owners and Business Analysts. So, I thought I'd try to help people see the impact of feature-oriented stories rather than goal-oriented stories on their agility (as in the dictionary definition of the term). I hope people see this article and see the opportunities for increased flexibility and speed-to-market as an incentive to better understand the subtleties of user stories.

Thanks for reading.

Re: It starts with a story…

Coyote Agile — Tue, 20 May 2014 12:32:16 -0000

Spot on! A friend of mine just sent me a link to this post because it's one of my biggest pet peeves in Agile. I think it's Mike Cohn that has a recording of a class on user stories where he points out that the difference between Waterfall specs and Agile stories is that the specs describe attributes of a system. The stories explain how the user's experience will be enriched.

Re: Segue Steps

Nilesh — Mon, 05 May 2014 09:23:59 -0000

Great trick. Thanks for the post

Re: To hack, or not to hack

Antony Marcano — Thu, 22 Aug 2013 20:36:57 -0000

Sorry it's taken so long to get back to you on this Salim. Somehow I missed this comment.

Indeed, that gives us a formalised approach.

It still requires the discipline to put an experiment that has worked into the backlog in order to repay the debt. This is not immune to the pressures I outlined in the article above.

Kent Beck talked of how he went about writing JUnitMax, a commercial IDE plugin that continuously ran unit tests in the background. He didn't write any tests for it in the first month because he wanted to get feedback from people as quickly as possible [1]. He, of course, had the discipline to go back to it later. He was also 'the business' and 'the developer' and had all the understanding necessary to generally make the right choice... sustainable or disposable.

When we were working on http://papyr.me, which is now on hold indefinitely [2], James Martin started out in much the same way as Kent Beck did. Everything we were doing was an experiment. He soon encountered a situation where progress on evolving an experiment became very difficult and this meant slowing down in order to speed up again by writing tests and refactoring because it was no longer safe to progress that experiment.

The problem that arises is when you want to add an experimental feature where the feedback needs you to evolve it again and again and again. Suddenly realise that it works the way your customers want it to. Should we then write tests and refactor it? Will the demand for the next experiment to evolve allow us to do this? This can be solved using continuous-rewriting [3] but there may come a point where having unit tests and well factored code will make each evolution faster and faster. So, having some guidance around when to have disposable experiments and when to have evolving experiments (where we write tests and refactor) would be useful for many. For me, if the experiment has resulted in feedback such that I'm evolving it, it should go through the sustainable 'backlog' route in the forked Kanban approach. If I have no basis for an idea then that would go down the disposable experiment route.

There is also the challenge of untangling experimental code from the core code. If, however, you have evolved a sustainable approach to feature toggling then this is much easier to do and will improve the speed at which you can migrate experimental code to become part of the product's core or ditch the code altogether.

This all ignores the value of trying to express our understanding as tests which in itself can evolve our ideas or quickly highlight the gaps in our thinking.

The Forked Kanban approach is a nice way to visualise and distinguish between user stories that are a certain refinement to an existing product or a potentially disposable experiment. In XP this was done with 'spike' stories [4]. The only difference being that the code for a spike was often thrown away or retained temporarily for only for reference purposes. In Kent Beck's story, he was essentially 'spiking' but actually released the code.

In a world where I have feature toggling I'd treat each user story as an experiment. I'd be more inclined to not have a fork and just place the experimental lane to the left so that there is a single, linear path. I might choose different wording...

I'd also want this to be supported by a continuous delivery pipeline.

I'd then make a judgement call on where I needed tests and where I should be refactoring in the earlier stages and, for any item that we decide to improve, agree higher expectations on tests and internal code quality.

In short, I can see the value of the forked Kanban approach. I think it doesn't necessarily solve some of the problems I've outlined in the article but it does help the team see which things probably need a sustainable approach vs those things that can be treated as potentially disposable. Either way, to be most successful, it requires a fair amount of maturity in both the people and the tech.

How do you see the forked Kanban approach? (Given that a lot of time has passed since your comment)

[1] Kent Beck's JUnitMax story: http://www.infoq.com/news/2...

[2] papyr.me – no more: http://on.papyr.me/post/324...

[3] Continuous Rewriting: http://www.citconf.com/wiki...

[4] Spike solution: http://www.extremeprogrammi...

Re: My Tack on Effective Change

Jonathan Baynes — Fri, 19 Apr 2013 13:37:32 -0000

A great article

Re: Old Favourite: Expected Exceptions

Marcel Stör — Thu, 24 Jan 2013 02:31:58 -0000

Static code analysis tools (Checkstyle, Sonar) will bite you - possibly twice. They won't like "catch (BeyondMyExpertiseException e) {}" because of the empty catch block. And they don't like "public void shouldComplainWhenNotAClass() throws Exception" because you're throwing Exception.

Re: Software Teams can Jump

Antony Marcano — Mon, 30 Apr 2012 01:46:51 -0000

Yes, I've spent over half my time in the last 5 or so years working as a coach (the rest as a practitioner – keeping my skills current and relevant). The idea is very common on Agile development teams. I first read about the idea in the early 2000s in Kent Beck's book "Extreme Programming Explained". I experienced it on a couple of teams I worked on and found it invaluable.

How does it differ from a pro-sports coach? Well, I suppose I see myself a bit like a cross between a sports-coach and a life-coach. I gain my personal satisfaction by seeing peoples' work-lives improved through the gratification they get from excelling and extending the ways they excel.

The worst coaches I've worked with act like the boss. The best coaches I've worked with create a trusting atmosphere for the teams to draw on the coach's knowledge, experience and insight. The most awesome coaches I know can take a team on a journey of discovery about their untapped potential and help them continuously exploit more and more of it. These especially awesome coaches adapt their style depending on the team[1] and are skilled and versatile enough to work with any member of the team showing them how to do new things as well as learn new things alongside the team.

If you are interested in learning more there are several books on the subject of "Agile Coaching" [2]. I'm also more than happy to have a chat. Get in touch[3] and we can set up a skype call.

[1] http://agilecoach.typepad.c...

[2] http://www.amazon.co.uk/s/?...

[3] http://antonymarcano.com

Re: Software Teams can Jump

Philip Hamilton — Sun, 29 Apr 2012 22:46:30 -0000

Very interesting the concept of a coach in a work environment. I guess you've been hired as a coach for a software dev team. How does a coach integrate into the team? and its a little different than a sports team because I would imagine you are not the boss whereas in sports the coach is the boss. So how do you define your role versus the boss/manager?

Re: This is not a manifesto: Valuing Throughput over Utilisation

Antony Marcano — Wed, 15 Feb 2012 01:37:34 -0000

Hi Squirrel,
These are great questions. Whatever you do, it's probably more about what people see as their responsibility. Individual flexibility and team autonomy will only help if the individuals and teams feel that their responsibility is to get features from concept to (production-ready) capability. If they see their responsibility as doing their bit (e.g. writing code or finding bugs) then flexibility and autonomy probably won't make a lot of difference.I'd explore ways to influence the culture of teams so they feel a shared sense of responsibility for getting working-features into production as well as looking for people who are open to being flexible and building trust to enable autonomy.With the hiring process, I think it's more a case of looking for people who are open to being flexible. This can be explored by posing questions to people that set a context where the candidate has to make a choice – do the thing most relevant to their job title or the thing that is most relevant to the team. If they choose the thing that is most relevant to their job title, explain the consequences – e.g. the release is delayed by 2 weeks. If they still don't choose to do the thing that is most valuable in completing the feature, I'd ask them why. If in the process of talking themselves through their reasoning they still are fixated on what's in their job description I'd be reaching the conclusion that they aren't flexible. That doesn't mean I wouldn't hire them because they may bring skills to the team that the flexible people can learn from and eventually use.

Autonomy is about trust. If management expectations are that people will do the bare minimum they can get away with to get paid then the biggest problem will be building that trust in a way that doesn't give the impression that 'command and control' is the reason for people working hard. Building trust is largely about transparency. Give people easy access and visibility of everything they could possibly want to know and they'll have no reason to mistrust. This is partly what end-of-iteration demos, visible charts etc. are about. Some of it is also about trusting in the skill of the people. I've had many conversations where, even C-level execs, try to tell teams how they should do things. A good CTO is like a good scrum-master. They protect the teams and steer others towards prioritising 'what' people deliver and fiercely guard the team's autonomy on how to deliver. In the same way that a CFO wouldn't appreciate the CTO saying what accounting methods should be used, the CFO isn't really in a position to tell the CTO what delivery methods should be used.

Some people may experience fear of having autonomy if they're used to being told what to do all the time. This is another thing to consider. So, introducing autonomy can be done in small experiments with small and increasingly frequent change.

One key thing to look at is organisational values. I'd be asking: What are the actual values today (not the ones written down but the ones people actually share in)? What do we want them to be tomorrow? How do we state those values? Are they a list of expected behaviours or the values that drive those behaviours? How can we influence people to care more about the things that will make us more effective? How can we find more people who already share in our values?

Thanks for sharing the questions that crossed your mind... I hope some of my thoughts have helped anyone wondering similar things and I hope I've added, in some small way, to your own thoughts on the subject :-)

Additional resources:

On company values: http://antonymarcano.com/bl...

On making small changes: http://antonymarcano.com/bl...

On autonomy: http://www.youtube.com/watc...
I recommend the related book "Drive" by Dan Pink

Re: This is not a manifesto: Valuing Throughput over Utilisation

Squirrel — Tue, 14 Feb 2012 18:02:58 -0000

Food for thought Antony. I wonder what hiring practises (filter for flexibility?) and cultural messages (exercise autonomy vigorously?) one might use to enable a team to adopt the changes you describe when needed.

Re: This is not a manifesto

Antony Marcano — Fri, 10 Feb 2012 13:13:05 -0000

I'll explain how I value quality relative to quantity. I'm not sure if that will involve a definition. Hopefully it will still add something useful to your thinking.

Re: This is not a manifesto

Richard Durham — Fri, 10 Feb 2012 10:23:28 -0000

I quite like that! Matches up well with my own drivers - although, as usual, you have expressed it much better than I could!

Looking forward to the elaboration around Quality specifically. I have been spending a lot of time recently (more than a year so far) trying to delve into what Quality is - what people mean when they use the word, specifically in terms of software but generally as well.

Richard

Re: This is not a manifesto

Antony Marcano — Mon, 06 Feb 2012 04:38:54 -0000

Thanks for the feedback Bob.

I can't promise definitions but I can promise an elaboration of the feelings that those words represent for me :-)

I like the idea of "progress", although it doesn't connect with me as well as "advancement". I had considered it and chose advancement instead.Mostly I chose it because it connects with how I feel. I completely understand your concerns about the message it might send. I hadn't considered the 'selfish advancement' issue... And I would hope that my team-mates wouldn't be thinking that way. My experience on teams is a sense of fellowship where this sort of thing generally isn't a concern. We advance as a team. I recognise that this isn't always the case.

Advancement, for me, is more than progress. It's about making advances in progress and our ability to make progress.

Thanks again for taking the time to give me feedback. The more I get, the deeper my understanding of these ideas gets.

-Antony

Re: This is not a manifesto

Bob Marshall — Mon, 06 Feb 2012 04:16:50 -0000

Nice post. Maybe would have chosen "progress" as a label in preference to "advancement" (too easy to mistake for personal advancement aka selfish ambition?). And I'd say the Quality over Quantity balance is, at least in part, context-dependent.

Looking forward to reading your definitions...- Bob

Re: Mission Critical Agility at NASA

Olu — Tue, 20 Dec 2011 17:47:10 -0000

Well said.

Re: Monsters, Names, Pot-Roast & The Waterfall Model

Jerrel — Thu, 17 Nov 2011 22:33:25 -0000

waterfall brought me here.. nice post

Re: Scenario-Oriented vs. Rules-Oriented Acceptance Criteria

Antony Marcano — Fri, 14 Oct 2011 15:30:22 -0000

I can relate to what you describe here (as in the looser way of working). That's quite consistent with teams I would be a team-member of... But then I wouldn't even be using terms like "acceptance criteria" in those situations. It would be little more than a card, the conversation and lots of collaboration - with whatever notes are necessary to aid our collective memory.

For those teams that do place a high emphasis on capturing up-front acceptance-criteria and can relate to the problems I outlined, then moving in the direction of scenario-oriented acceptance criteria might prove a useful step towards not needing them at all.

Thanks for your comments Liz.

Re: Scenario-Oriented vs. Rules-Oriented Acceptance Criteria

Liz Keogh — Fri, 14 Oct 2011 05:31:24 -0000

I'm a massive fan of BDD, yes. I like to talk about the behaviour we're expecting, then look particularly for *unusual* scenarios - edge-cases which aren't obvious.

In the cases where the scenarios are obvious from the behaviour we've discussed, I'm happy to leave it at that, unless someone wants to automate it. An example might be:

"Replaced or refunded items should be added back into to stock unless faulty."

The four scenarios you could associate with this are obvious.

However, when I ask, "Can you think of an example in which items aren't returned to stock even though they're not faulty?" someone might say, "Oh, do you remember that time when that mother came in to get a refund because the buggy was too small, but it had been recalled anyway? Yes, we need to check for recalls." And now we have another scenario. *That* one, I'd want to write down - it's not obvious, and it's easy to forget. But I'll write down that specific scenario, with a title of "Check for recalls". And then someone says, "Oh, we can't even refund earrings for hygiene reasons, unless they're faulty!" And now we have another. So I'd write these down, but I wouldn't bother writing down the obvious ones.

That's why I can say that I'm into BDD, but not necessarily driven by specification by example - there *are* other ways to specify, and they're OK! I find the word "specification" stops people questioning quite so freely as well, so I don't tend to use it.

I'm very happy for people to have the conversations around as many scenarios as they want, and pretty much insist on it if it's something new or unusually complex, but I think people are starting to put *too much* emphasis on capturing every single scenario, when some of them are really obvious. In those situations, I'm happy with rules being captured (as above) instead as proxies for the scenarios they generate. The scenarios will appear when and if we automate. In the meantime, the focus can fall on some of the unusual scenarios instead (which are frequently around new, differentiating and therefore highly valuable functionality). So we don't "replace" the rules, because often we don't even bother writing them down!

The big difference for me is that where a scenario *needs* to be captured, I'll use specific, realistic, actual scenarios with realistic names and data, rather than capturing scenario-oriented acceptance criteria. I find it pings people's imagination more, and lets us come up with the other five scenarios that we *also* forgot about.

I have done the kind of thing you're talking about before, capturing all the scenarios to use as acceptance criteria. I found it useful in low-discipline environments, where the developers sometimes forget to check what's working and what isn't. I've got away from that recently by teaching Feature Injection instead, so that everyone has a clear idea of the value of what they're doing and the risks associated with it, and is motivated to understand their work better.

I've also done it when the scenarios have been discussed during planning meetings, and needed to be captured because the people doing the work weren't always the same as the ones doing the capturing, or enough time passed for them to forget. Persuading people to step away from fine-grained estimates (also using Feature Injection) and accept some discovery in the process of software development means we no longer have to do that either, and can talk through scenarios as and when it's needed, thereby keeping the knowledge fresh.

As a result I suspect that I have a slightly looser process - and I don't think either of our approaches is necessarily wrong. We may just work in different contexts.

Have a chat with Dan North about his "Ginger Cake" pattern some time, and please invite me for the conversation if I'm around :)