WiPFlash, or How To Do Microsoft UI Automation

I’ve kicked off another open-source project, WiPFlash.

This is a little automation framework with a number of goals:

  • To let me learn how to do .NET UI Automation
  • To fix a couple of things that White doesn’t do yet
  • To automate scenarios as fast as possible
  • To provide examples that anyone else can look at, if you want to do the same thing.

The project is written in C#, and is exclusively focused on WPF Windows GUIs. Currently WiPFlash can:

  • Launch or reuse an existing application or window
  • Enter text in TextBox, RichTextBox, and editable ComboBox
  • Select values and retrieve selection in ListBox or ComboBox
  • Retrieve values from RichTextBox (and its children), TextBox, TextBlock, editable ComboBox
  • Click buttons.

It also provides an example of a Prism application, complete with MVVM paradigm, command binding, dependency injection using Unity, etc.

Please feel free to try it out and add any requests and/or issues, bearing in mind that the purpose of the framework is not to replace White. For instance, I have no plans at this time to support drag-and-drop or mouse and keyboard input, nor am I going to respond to bugs with WiPFlash not working on WinForms, SWT, etc.

If you’re looking for something similar for Java and Swing, check out my other automation framework, Tyburn.

Posted in csharp, open source | 3 Comments

Who are your Users?

I’ve wanted to write this post for a while, and reading “Metaphors we live by” has given me some language and ideas to express it in. So here goes.

Requirements come from above

In a straw-man Waterfall project, requirements are delivered to senior developers to design. Senior developers deliver the designs to junior developers to implement. Managers instruct teams in how to progress. We have, in our language and hierarchical organisation, a metaphor which maps “up” to the origin of the project, and “down” to the implementing details. We also think in terms of seniority and power, with the originators of the vision having that seniority and power, and the more junior developers and testers being at the bottom of the pile. We even talk about the team members “on the ground”.

Think of every organisational chart with the managers at the top, or the V-model in which the requirements are split into increasing detail towards the bottom.

In life, things naturally flow downwards.

Orders come from above

The other hierarchy with which we’re familiar is the military. We can map our employment and communication hierarchies to those of the military. We even talk about companies fighting for market share, defending their reputation, a hostile trading environment, captains of industry, command-and-control management, etc. It’s hardly surprising that we have, in our subconsciousness, another pattern: that the more junior members of a company should obey orders. (This isn’t necessarily true even in the military, but it fits our perception of it.)

Turning the world upside-down

I once heard of a business analyst who got tired of explaining the requirements to the developers. “I’ve told you three times already!” she snapped. “Everything’s clear. Just do it.” The BA sees the developers as working to fulfil her requirements. They serve her needs, rather than the other way around.

When we write and deliver software to a user on an Agile project, we ask them for their feedback.

  • Is this useful to you?
  • Is this easy to use?
  • Is anything difficult to use?
  • Does it help you to do your job more effectively?
  • Can you think of any ways we could make this more intuitive?
  • What would you like next?

Because we think of communication in terms of orders, we also think of junior staff delivering value to senior staff. We don’t necessarily think in terms of the communication itself being a form of delivery. If we did, we might ask for feedback from the users of our communication.

  • Is this communication useful to you?
  • How easy was our communication to use?
  • Was anything difficult to understand?
  • Did it help you to do your job more effectively?
  • Can you think of any format you’d find more intuitive than this?
  • Any questions?

If the BA above was a piece of software, her users would be filing bug reports, working around her, and using her competitors instead. I imagine instead that she’ll get a poor review and teams will prefer to work with her colleagues. If they only have the one BA to work with, the project will probably fail – the developers won’t be able to use her to get their job done.

Stakeholders aren’t users

I’ve written about this before, and it takes on a new importance in the context of users, and stakeholders, of communication. When we get a management report, we often think, “So what?” We hit the delete key. Instead, we could try to think, “Who is it that cares about us understanding this? Why does he care?” It’s often the case that a user is meant to do something, as part of his job, which is for the benefit of someone else. Similarly, we may be asked to understand or act on something for someone else’s benefit – and it won’t be the person delivering the message either.

The stakeholders of communication on a project are often stakeholders of the project itself – the security expert, the chief architect, the facilities manager, etc.

Project experience

Eric gave me the concept of a “Project experience”. In the same way that we can think of communication as a form of delivery, we can think of the experience that our stakeholders and customers have when they ask us, as a project team, to deliver their code. We can ask usability questions about the team.

  • How easy is it to use the team?
  • Is it easy to see what’s going on and get information about the progress of the team?
  • Is it easy to undo a mistake?
  • Is it easy to input a new idea?

We often hold retrospectives amongst ourselves to work out how to change our processes. I’d also like to see us actively getting feedback from the people who use the project. And next time someone gives you some instructions which are unclear or don’t help you to do your job, perhaps this metaphor will help.

Posted in feedback, stakeholders | 3 Comments

Calling UK residents

Rob Bowley has set up a petition to ask the government to review the way in which IT projects are done.

I don’t know about you, but I’m fed up of hearing tales of Government IT failure. I even heard one story of a company asked to triple its bid so that a council department could spend, and therefore retain, its budget.

Go sign it already.

Posted in life | 2 Comments

They’re not User Stories

Reading Simon Baker’s post on metrics made me smile. I rant about similar misuse of metrics quite a lot. A common reason that I see targets and metrics fail is because they’re aimed at a perceived circle of responsibility – for instance, developers who are measured on how few bugs they produce. This ignores the possibility that something outside of the development team might be causing the bugs – poor analysis, a difficult technical environment, lack of a decent production-like staging platform, etc.

Simon’s post calls out another common local optimisation. He says, “…the true purpose of the people doing the work, which is to improve service and quality and satisfy users.”

One of the ways in which we can satisfy users is through usability and user experience. At one of the Agile 2009 keynotes, Jared M. Spool gave a beautiful example of why this could be a bad idea. He talked about a company that had reduced a 5-stage process to 2. The users loved it. “Unfortunately, they forgot that the company was paid per page impression,” he said. The company went bankrupt shortly after putting the beautiful new website in place.

In Feature Injection, Chris Matts calls out the people with the original idea, or the people who are investing in the idea, as the core stakeholders. These are the people who need to be satisfied. Everyone else is incidental, and the vision is usually one that either makes money, saves money or protects money (stops another company spoiling your idea, or stops them from stealing your market share). Everyone else whose input is needed to make the vision a success is an incidental stakeholder. This can include the users.

Here’s an example of how focusing on the true stakeholder can help. I was talking to a friend at XtC about a user-centric story.

As a user
I want register to be emailed when the game is released
So that I can buy it as quickly as possible.

I was discussing alternative ways of implementing this story which didn’t involve email. “Who really wants the users to be notified? Who’s actually paying to notify them?”

“Marketing, I guess.”

“Why do Marketing want the user to be emailed?”

“So that they can make a big hype about the game when it’s released.”

So, rephrase this from Marketing’s point of view.

In order to make a big hype about the game when it's released
As Fred, the Marketing guy
I want users to register for an email about the release.

Now we can see that perhaps, users may not want to register for the game. We might have to entice them with something else. We also see that our goal – the big hype – could be met by other methods; with advertising, for instance, or by getting favourable reviews in magazines.

By allowing the developers to focus on the goal, we may come up with different or better solutions. We also come up with different tests. Will the user actually want to navigate through the 5 screens we make them fill in to register? Will we get the big hype we’re looking for?

I find when using the Feature Injection template that I frequently put the real name of the stakeholder on the card. This means that if we run into trouble, we can go and talk to the stakeholder about alternate ways of achieving their goal.

They’re not user stories. They’re stakeholder stories.

Posted in bdd, stories | 28 Comments

Lean Software and Systems Conference, Atlanta

I’ve been invited to speak at the Lean Software and Systems Conference in Atlanta, April 21st to 23rd 2010.


BDD, often described as “TDD done well”, is strongly aligned with Lean
principles. It’s a pull-based approach to delivering software that
matters through the whole software lifecycle, from vision to code. It
minimises rework and over-delivery, bakes quality in, and is founded
on respect for people in their various roles and the language that we
use to collaborate and communicate. BDD has its origins in NLP and the
Sapir-Whorf hypothesis: the idea that the words we use affect the
cognitive model of our work. It decouples the learning associated with
TDD and Acceptance Testing from the word “test”, using the more
natural vocabulary of examples and behaviour to elicit requirements
and create a shared understanding of the domain.

In this talk Liz will introduce BDD, show how to model it using PDCA,
and talk about how its practices can provide quicker feedback and help
us to turn a vision into reality faster.


I’ve been working on this talk for a few months, and hope you enjoy it.

This has been a very special year for me. I’ve been fascinated by Lean principles for a while, but only recently had the opportunity to do some serious study into them and try out the related practices and tools. It’s also taken me some time to work out how strongly aligned Lean Thinking and BDD are. The community around the Lean and Kanban movement has been very welcoming and respectful this year, and I’d urge anyone who is interested to make their way over to the Limited WIP Society, where some excellent blogs, articles and examples of Kanban boards etc. have been collected for your accelerated learning.

We held a bag-stuffing event at Agile 2009, and used it as an exercise in applying Lean techniques. (Hugo Corbucci and Hamlet D’Arcy both posted excellent write-ups of this). One of my proudest moments this year was when some of the Limited WIP and Kanban community asked me to stand up afterwards as someone who could be approached with questions about Lean and Kanban. I’m an effective Agile coach, but my knowledge of Lean still felt new to me at that point. To have this kind of validation meant a lot to me.

I appreciate those of you who have helped me in this journey for your extraordinary patience in teaching me and providing feedback on my understanding. You know who you are.

Posted in bdd, conference, kanban, lean | Leave a comment

The Evil Hat

You’ve got a problem.

You want to measure, and improve, something about your project or people. You’ve got a good idea about how to do this. Perhaps the metric you want to use is already widely measured. Perhaps it’s been in the industry for a while. It might be a KPI, related to a management incentive or perhaps you simply want to replace your existing metrics with something better.

Before you put that measurement in place, borrow my Evil Hat.

The Seventh Hat

Edward de Bono identified six different ways in which people prefer to think, and created the six famous thinking hats.

Unfortunately for humanity, there’s a seventh way in which we think. It comes unconsciously from our innate desire for an easy life, our craving for approval, and mechanisms of feedback which tell us whether we’re doing the right or the wrong thing. It comes more consciously from our desire to be paid more, keep or improve our jobs, and make our bosses happy. If we’re determined to be evil, we can think of it as a way of manipulating the system for our personal gain.

The problem is, even if we aren’t evil, we do start responding subconsciously to the feedback provided by our measurements and responses to them. Like an electrical current, we tend to take the path of least resistance. If we’re seeing problems as a result of the metrics, we’ll address the problems – and if we’re doing it subconsciously, we may not actually analyze the cause of those problems, or the effect of our changes outside of the system. We’ll respond to praise for achieving the targets, and to criticism for missing them – even if the targets and the praise are implicit.

By putting on the Evil Hat, we can move those subconscious reactions into the conscious realm. Pretend, for a moment, that you have no care whatsoever for the success of your project, your team or the bigger picture. You are merely interested in your own personal gain. You are not interested in making life better for anyone else but yourself. This is what your brain is already doing, before the altruism in your conscious mind or subconscious habit kicks in (and there are plenty of arguments to suggest that altruism itself is merely done for psychologically selfish reasons).

Congratulations. The Evil Hat has just turned you into a sociopath.

Sociopaths can destroy your company or project

When a sociopath wants something, they can resort to any means necessary to get it. This article, Sociopaths in High Places, illustrates some of the behaviour we can expect from sociopaths, including bullying, cruelty, manipulation and outright fraud.

This only happens because sociopaths don’t care about other people. Of course, most of us are born with empathy. We feel other people’s pain. Don’t we?

When we’re stressed, our adrenaline levels rise. We are primed for fight or flight. Our instincts are turned inwards, to our own survival. We are more likely to act in our own interests, and less likely to worry about those around us. This rather lovely article talks about the circular nature of stress and concentration, relating the feeling of compassion to the state of relaxation. The opposite is also true.

So, let’s imagine that we’ve been set some targets, and we’re not meeting them. Our boss (who has targets of his own) is putting the pressure on us. Now we’re starting to feel stressed, which makes us less empathic. Even if we’re not sociopaths ourselves, we’re capable of selfishness, and it’s starting to show.

Sociopaths are in charge

The targets in any company tend to filter down from the top. The shareholders want a profit. The CEOs, board members and upper management are in charge of delivering that profit. Their targets and metrics are clear. As Chris Matts has said when talking about Feature Injection, they need to “make money, save money or protect money”.

Two psychologists, Paul Babiak and Robert Hare, started applying a checklist for psychopaths to the boardroom members of corporations, and published some of their findings in a book, “Snakes in suits”. This transcript of a radio interview with the authors and other experts illustrates some of the behaviours they found.

It’s often easier for a psychopath to achieve their goals by destroying others. Certainly, they have no empathic reason to want to help others, and they will protect themselves and the power they amass quite jealously. There are some phrases that we can look for to see if we or our colleagues are becoming less empathic with stress:

“It’s not my fault.”

X did it.”

This is us, protecting our power and our jobs at the expense of someone else. We’re not thinking about the impact on others when we say these things. We’re doing it to protect ourselves.

Of course, true sociopaths and psychopaths (Wikipedia defines the difference nicely) will protect themselves in advance, so rarely have to resort to passing the blame – it will already be obvious to all powerful onlookers that they are blameless. Or, worse, the powerful onlookers will themselves have sociopathic tendencies, and be in cahoots with their sociopathic comrades.

As the stress mounts, the more clever amongst us will start protecting ourselves. We keep those emails, do everything in writing, and insist that processes are followed, making sure that we cannot be blamed for anything more than being cogs in a giant machine. The more creative amongst us find ways of becoming more influential and indispensable – hoarding knowledge, hiding our lack of skill, making friends in high places, setting others up to take the fall. As the habits develop, we become more and more sociopathic ourselves. Anyone who finds themselves unable to dispense with morality leaves, and the company culture is now fully riddled with blame.

Sociopaths can save your company or project

As Robert Hare says in the radio interview:

Enlightened self-interest is not a bad idea for psychopaths, and try to indicate or convince them that there are ways in which they can get what they want and need without having to actually harm other people. “Enlightened self-interest is not a bad idea for psychopaths…” Now it’s easier said than done, because their behavioural patterns are fairly entrenched. But these are not stupid people, I mean the range of intelligence amongst psychopathic populations is the same as it is in the general population. These are people who know what’s going on.

So, what’s going on?

The word is spreading. Self-organising teams, in which the members are not merely cogs, are more performant. Employee empowerment and learning improves company morale, reduces expensive employee turnover and can help make money. Transparency in the workplace fosters productivity. Incremental delivery reduces risk, resulting in more successful projects and more fulfilled staff; even governments are listening.

It turns out that in most cases, doing the empathic thing – creating positive cultures and professional experiences for employees – is also the most profitable thing, helping those sociopathic CEOs. It’s the most productive thing, helping their cahooting managers. If it involves transparency, it’s hard for anyone else to manipulate, and because an enabled, positive, productive workforce creates options it reduces risk and provides the greatest possible control in the event of uncertainty.

The sociopaths of the world – CEOs, managers, and democratic governments – are also starting to listen. If you know yourself to be a sociopath or a psychopath, you’re in a position of power, and you’re not paying attention, then you’re losing this race.

If, however, you are already cynically manipulating your company culture to be better, faster, more productive, empowered, self-organising, transparent, learning, improving, Lean, Agile, incremental, feedback-driven, forward-thinking, creative, optimistic and prepared, then congratulations. You are about to rule your slice of the world. Just what you always wanted.

Put on the Evil Hat

By pretending to a certain amount of sociopathy before we start introducing metrics and targets, we can ask ourselves, “How will we respond to these targets?” Will we game the system, manipulating these in a way which serves our purposes, but not the whole? Are they perverse incentives in disguise? Will we see anti-patterns emerge as a result?

We can also use the Evil Hat to turn this around. What metrics and targets could we put in place that would lead to even more productive behaviours? That would lead to success, and therefore maximise our personal gain? How can we make sure that the things we’re measuring are the things we most want?

It’s Good to be Evil

I was in a meeting when someone suggested introducing a KPI for measuring team leaders. “One of their jobs is to remove obstacles from the path of the team,” a manager suggested. “We should measure how many obstacles they remove.”

“Excuse me a moment,” I grinned. “That sounds like fun. Just let me put on my Evil Hat, and I’ll tell you what I’m going to do in response…”

Posted in breaking models, evil hat | 7 Comments

Kanban thinking: hungry vs. peckish

I just read Michael Dubakov’s excellent post on Kanban psychology, and the shift in thinking from the habits we’re taught to a more rational behaviour.

This post made me remember what it was like, being a developer who’s discouraged from sitting and reading blog posts, or books, or learning more about the job, but who can’t find much meaningful work to do, so starts on the next most valuable non-valuable thing. The feeling was very similar to the way I feel when I can’t work out what to do, but it’s lunchtime soon, I know I’m not completely stuffed, there’s a snack machine down the corridor, and I’ve got into the habit of kinesthetically nibbling on things when I have nothing else occupying my attention.

I can say “no”. Here’s to better dietary habits, for both me and my projects. Long may they last.

Posted in kanban, lean | Leave a comment

A Community of Thinkers

I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

  • reflect and honor the practitioners who make its existence possible;
  • provide an excellent experience for its members;
  • support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
  • exemplify, as a body, the professional and humane behavior of its members;
  • engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
  • embrace newcomers to the community openly and to celebrate ongoing journeys; and
  • thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

Creative Commons License

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.


Jean, Eric and I got together in Denver last week. We didn’t start with any particular goal in mind – I was excited to be there because I knew I’d learn something, regardless of what we did. Jean has strong skills in facilitation and collaboration, and Eric’s heavily involved in Lean and Kanban, both of which are currently areas in which I’m focused and learning.

I’ve already seen a small slice of Rally’s culture at their Chiswick offices in London. Jean was kind enough to show us around the Boulder headquarters, where we were warmly welcomed. The layout of the Rally offices is the most effective I’ve seen – large, partitioned project areas with sliding doors, allowing collaboration while avoiding the problem of noise common to open-plan spaces. Jean managed to book us an entire room for the day, complete with a huge jug of coffee.

We started with the idea that we’d produce something for the Lean and Kanban community. Particularly, we expressed a desire to see the LSSC learn from some of the trials that other communities and community-leading organisations have undergone. Ryan Martens, the CTO and a founder of Rally, also provided extensive input. We talked about what communities meant to us, how leaders and leadership manifest within them, and the influence of factors like money, certification, vendor sponsorship, etc. on the community landscape. At the same time I learnt more about facilitation, appreciative enquiry, group psychology, constructive language, the power of well-formed outcomes and the history of the Lean and Kanban movements in and outside of software.

As we talked, we became less convinced that the LSSC actually needed to be challenged, and more concerned with software communities generally. We started writing phrases that we felt represented our views on post-its, and constructed the above challenge by piecing them together. For me, this is a personal statement and commitment – if it’s exactly the same as the copies on Eric or Jean’s sites, it’s only because their arguments were sound and convincing. We were heavily influenced by conversations with Chris Matts and his call for “fewer leaders, more leadership”.

Because of that personal nature, we wanted to avoid putting this up as some kind of centralised manifesto that people can sign. If you feel strongly enough about it that you want to sign up, copy it. Post it on your own site. Attribute it to wherever you got your copy from – the act of sharing is more important to us than the act of creation – and feel free to change it so that it reflects your own values. I don’t think that any statement like this can ever be perfect, nor will we perfectly live up to it.

I am a member of a community of thinkers. So are you.

Posted in values | 13 Comments

This blog is now under Creative Commons

I hereby release these blog posts under Creative Commons Attribution-Share Alike 3.0. If you want to do anything different to this, please ask.

Posted in life | Leave a comment

Estimation anti-patterns

Dan North’s talk on “the Fallacy of Effectiveness” prompts me to put down the many estimation anti-patterns I’ve encountered. It also reminds me of his blog post on the Perils of Estimation.

Here they are, in alphabetical order, because none is any better than any other:

Budget-driven Estimation

Whatever estimate you come up with will be enlarged by the customer so that he can spend the rest of this year’s budget, otherwise he won’t get it again next year.

Catch-up Estimation

Scrum Master: We have 30 points of work still to do, and only 2 more sprints to do it in. How many points can we manage in a sprint?
Team: 15!
Scrum Master: But we only managed 5 last week! How many do you really think we can manage?
Team: 15!
Scrum Master: (facepalm)

Comedy-driven Estimation

As told to me by Dan from a talk he saw – if you know who it was please let me know so I can credit:

Presenter: How tall am I?
Crowd:5’8″! 5’9″! 2 metres!
Presenter: Go on, you can manage more than that. How tall am I?
Crowd: 6’2″?
Presenter: Come on! You can do better than that! HOW TALL AM I?
Crowd: (Giggles nervously.)
Presenter: Just because a project manager tells you you can do more, it doesn’t make it true.

Done-driven Estimation

A symptom of a pressured team, this method of estimating allows a pair of developers to get the story out of their stream as quickly as possible by eliminating time spent on tedious things like refactoring to make the code maintainable, deployment, manual testing, etc. Symptoms include the oft-quoted “Works on my machine.”

Done-done-driven Estimation

A good team knows, of course, that the code counts for nothing until it’s out there in production, doing the thing it was built to do. Estimates are given with this in mind, but without the help of anyone involved in production deployment, systems integration, performance testing, UAT, etc., because they’re in different teams.

Fractal Estimation

After the scope of the project has been constructed, some stories may be considered too large to fit into an iteration, so the team decide to split them into the smallest possible deliverable slices, re-estimating each slice. Of course, this is a bit like measuring the coast of Britain. The epic which was 13 points at project inception becomes 16 points of features, and 23 points of stories by the time it’s done in the sprints. Analysts wonder where this extra scope came from, while advocates of burn-down charts tuck the growing scope away somewhere where it won’t be noticed.

Goat Estimation

Asking a goat can help when you know it doesn’t really matter what you say, you’ll probably end up doing target-driven estimation anyway.

Job-driven Estimation

As practiced by residential consultancies on Time and Expenses, contract Project Managers and anyone else with an interest in seeing the project go on as long as possible.

M25 driven Estimation

“Yes, I know it took me 3 hours to get around London yesterday, but that was because there was a traffic jam on the M25. Today will be much quicker.

Pareto Estimation

Often used by teams which have work still left over at the end of an iteration and desperately want to include the incomplete work in their velocity. Unfortunately the Pareto principle, applied to tasks, suggests that 20% of any task will take 80% of the time. Let’s hope the 20%’s not the bit that got left till last.

Post-mortem Estimation

The team chooses estimates that will allow them to avoid the post-mortem inflicted by the project manager when they missed the deadlines last time.

Promise-driven Estimation

Developer: “These estimates… they’re just estimates, right?”
PM: “Don’t let the business hear you say that!”

Like Scrum’s sprint commitments, but used for release or project planning, this estimation method often leads to three-week long project planning meetings before the project starts. Frequently occurs as a result of fixed-price contracts with first-time suppliers. Also the second time. And the third.

Star-Trek Estimation

Geordi La Forge: I told the captain I’d have this analysis done in an hour.
Scotty: How long would it really take?
Geordi La Forge: An hour!
Scotty: Oh. You didn’t tell him how long it would REALLY take, did you?
Geordi La Forge: Of course I did.
Scotty: Oh, laddie. You’ve got a lot to learn if you want people to think of you as a miracle worker.

Student Estimation

If an estimate is chosen wisely, 50% of measurements will fall under the estimate, and 50% will fall over the estimates. Strangely, nothing ever gets handed in early, no matter how inflated the estimate is.

Target Estimation

PM: How many story points can you manage this week?
Team: 10.
PM: That’s not good enough. I need you to do 12. How many can you manage this week?
Team: 12.

Velocity-driven Estimation

Once a target velocity has been established – sometimes by the team itself – the team members will find a reason as to why the work they’re capable of doing does actually add up to 12 story points. Often applied in conjunction with Fractal Estimation.

Zero-outlier Estimation

If being wrong is uncomfortable, a team will wait for the most experienced developer to “throw” their estimate first before following suit. Planning poker fixes the symptoms, but not the problem.

Posted in humour | 17 Comments