Tuesday 16 February 2010

Ménage à trois in kinky teams

My fellow Thoughtworker Greg recently posted about our revolutionary experiences and experiments with team formation and delivery at our current client.

I wanted to expand a little more on a subtle and incredibly important point that has lead to the success we have been having. Our wall, as described by Greg, has only a single central delivery column "in progress". It is what happens here that makes our new team formation a kinky success.

Traditionally in perhaps an XP style team, you would have dev pairs assigned to a story, which is then handed off to a QA, who writes defects against the story, which the dev pair fix, and is retested and so on. We decided this doesn't work... well at least for very long anyway!! Before long (usually towards the end of a release) cards and defects get piled up into one big traffic accident of a story wall. Any "Individuals and Interactions" goes out the window, whilst we cling to the ceremony of raising defects, reading defects, closing defects, explaining defects, re-opening defects, explain what those changes to the acceptance criteria were you missed whilst at lunch. What is all this craziness? It shouldn't be this hard? Delivering software, should be sexy!

Sexy?

In our new team, we have Threesomes, some times several at once, and I'm not sure what that is even called (never was that adventurous)? No longer are there dev pairs, now there are only delivery threesomes, two developers and a QA. This is the subtle and overlooked part. It is only as this combined unit that a story is delivered.. together as one intertwined collaborative ball of sexiness.

So what are the logistics of this? Surely people will be sitting idle?

Firstly there is the story huddle, which I won't go into great detail as this deserves its own blog post. The acceptance criteria are read together as one team, we get the breaking news on the story and a shared idea of what will be done and expected.

Next the dev pair formulate a plan on how they will deliver the story to the QA. This is a valuable pairing technique, known as micro-tasking and usually involves a bunch of stickies. The stickies break the story up into more vertically sliced, micro end-to-end business functionality (not technical functionality), which can be individually showcased.

The dev pair continually share, showcase and communicate with the QA, who continually explores and probes the virgin behaviour that is just delivered. This continues until the the development work is complete.

Now the crux. If development has finished and QA has not, then the dev pair then submit to the QA, who instructs them at their will to do all that they desire and more. When and only when the QA's appetite is fully satisfied and final climatic showcase has ensued, can the dev pair return to the awaiting pile of stories.

Although, our new threesomes are not faithful within their new found relationships. If when a story is finally complete, there are no more stories to pick up, then attention is shift to new meat in the BA. The developers or QA, remove their current hats and get stuck in with the juicy task of analysis. (There's probably a metaphor in there somewhere, but I won't go there.)

Finally, if we find our dev pair has finished entirely too prematurely, and there is nothing more that can be done with our QA. Then we still do not pick up new stories, but go off to satisfy ourselves, with trusty old tech-debt cards.

Has this Ménage à Trois been successful?

As Greg pointed out, we have only yet raised one solitary defect since October. This was caught and fixed within the Sprint the story was played.

13 comments:

  1. The biggest problem with having QA engineers separate from "real" engineers is that the "real" engineers depend too greatly on the QA engineers for testing. Why not ditch QA completely and test drive your code, follow it up with some code review time in front of the team, and do a little regression testing before your release?

    ReplyDelete
  2. I have been thinking about this a lot lately and want to try it out on the next project. My concern is mainly with QA sitting idle and possible drifting off into random automation tasks unrelated to the current story in play.

    Also taking some inspiration from the Feature Injection stuff, I was thinking of BA / QA paring as well.

    Maybe a combination of those two techniques will help.

    ReplyDelete
  3. @David I think you are correct and I have similar thoughts. Indeed I know of companies that have actually done this with success (uSwitch being one of them).

    Although I think it must be said that I don't think that the "role" dies, just that a new breed of developer is born who performs this role. Quality is built in from the start.

    @Akshay Ironically idleness is actually necessary in a system with constraints. Many a manager focus on keeping the workers busy and not the work. You should read the book The Goal: A Process of Ongoing Improvement by Eliyahu Goldratt for more on this.

    ReplyDelete
  4. I had received a few great comments on Buzz and thought I would repost them here to share. Warning some of these are are from past colleagues and contain a little banter.

    ReplyDelete
  5. Gordon said: Question: In the event of a project with a fixed deadline how does this approach affect sprint planning? Are you able to estimate the amount of testing required in the sprint in the same way? Does the approach lead to a consistent but slower delivery of high quality code - what impact does it have on the amount you deliver?

    Very interested to know your learnings as to overall project delivery to deadline, and sprint planning.

    ReplyDelete
  6. My reply: Yes the ultimate goal of this exercise is to recognize that the delivery process is a system. You can only work as fast as your constrained resource, so whilst it may seem that development is going slower it might be that it is only going as quick as it needs to, in order to match the input/output of upstream and downstream processes.

    You mention what is the impact on the amount that you deliver. This is actually a bad delivery measurement, as I can ask what is amount? Story points? Stories? Projects? These are all relative, I can easily break a project into many small stories and call them all large. This would appear like I am delivering a lot.
    What is better is to ask is, how quickly can we get a feature to the customer from the moment they request it? Ahh, but I hear you say.. your threesome method is slower and more methodical so how can this be better in the new system?

    This process certainly leads to much higher quality code and actually improves end-to-end delivery time as there is no/less re-work. Rework is further waste, and actually costs more than getting it "right" the first time, due to the fact that it introduces communication costs (raising bugs, remembering the code etc). In this method, you could potentially do away with long "UAT" stages of delivery as there is little need if the quality has already been completed thoroughly.

    In our new process sprint planning is waste, as it is based on forecasts and estimates. So there is no "slower", there is only "actual" if that makes sense? You can only go "slower" against a plan. Plans are based on estimates and therefore not reality.
    We generally just transition from sprint to the next (mid week), with no boundary in between. Our sprint planning is done at the morning stand up in 5-10 minutes, and is generally just enough for the threesomes to just get started. Work is pulled in as needed from the business analyst, that way the acceptance criteria are as fresh as they can get.

    Warning rant approaching: In all my project years, I have only ever worked on a handful of true "fixed deadline" projects, meaning that there was an external market force driving the deadline (ie: Christmas promo, sporting event etc). The majority of fixed deadlines have been set by project managers working to plans based on finger in the air high level estimates. When developers complain that it will be tight and need more time, "the deadlines are set in stone", yet if there is a clerical error in a spreadsheet or failure to organize a project dependency by a project manager "deadlines are moved with a stroke of the pen". Highlighting just how farcical most deadlines are. rant over :)

    ReplyDelete
  7. Gordon's reply: Jeez Christian I had enjoyed your blog but I didn't realise you had found religion.

    Yes 'amount' would be stories and I would hope you wouldn't simply call them all large to make your output appear more impressive. Such pendantry does your argument no favours.

    The context of my question was concerning fixed deadline projects so there is no need for your rant. You seem to forget that, on top of external market forces, deadlines are also there because a business has a need to know when it can expect a product to begin delivering value. Being able to do that has lots of benefits - it means the business can forecast correctly (or more correctly at least) from the point of delivery - in turn helping owners or shareholders to understand potential profit, loss or cashflow for the coming year. Having said that a delivery date should always be agreed with the developers not arbitrarily by a product owner. Take a certain redesign we worked on - the late August deadline had been set for August by the CEO whereas we had communicated it would take until at least January to deliver. That was a delivery always doomed to failure as a result. Additionally PMs rarely set deadlines - they simply enforce them (rightly or wrongly) because delivery to time and budget is what PMing is all about. A good PM will seek to make sure an agreed deadline is agreed between business and developers - take CAM for instance. Initially there was an arbitrary deadline of late Jan for its delivery but once we had all sat down and planned our delivery it was clear that we'd come in a couple of months later than that. Wasn't popular with senior stakeholders but meant we could actually deliver something and we actually came in dead on time.

    I take your point about deadlines changing - it's true. Often stakeholders will set a deadline in the mistaken belief it will drive the developers harder. For some developers that's true. For others it isn't. Dependencies failing to deliver too can mean a deadline has to shift but my experience is that this is an unpleasant decision for a stakeholder to make and it is not taken lightly.

    By simply railing against deadlines you sound like an errant schoolboy who hasn't done his homework on time. They are, for the most part, a necessary part of the process in the wider context of a succesful business. If my builder told me my new kitchen would be ready in November but wasn't delivered until January I'd be really pissed off because, even though I got a really high quality kitchen in January I hadn't been able to use it to make my family's Christmas Dinner. I'd have preferred something slightly of less quality in November that could then be revisited and enhanced later.

    Was hoping your post could have shed some light on delivering quality to a timescale is all.

    ReplyDelete
  8. David's reply: Interesting, the original article certainly holds good food for thought. Generally I find with these methodology discussions that the concepts are good, and the incrementally better methodologies do provide a increase in value because they better express the best way for people to work. I can see how the "threesome" approach would add value without undue cost, my main concern would be the risk of following the methodology too rigidly and forgetting it's purpose, which would be a noticeable issue in teams with weaker members in some of the positions.

    To comment on the comments...

    "You mention what is the impact on the amount that you deliver. This is actually a bad delivery measurement"
    This makes absolutely no sense to me at all until I read on far enough. The ONLY thing you can usefully measure is delivery, this initial statement just creates unnecessary argument, because what follows is a brief discussion on what you would use to measure "delivery" which is a somewhat useful discussion. At the end of the day, the only delivery that matters is working code delivered to customer, but it is critical to the success of a project to be able to measure progress prior to final customer delivery (so you can identify bad projects or unrealistic time-scales).

    So with that in mind, you have to pick some measurable item that is at least somewhat representative of what you will eventually deliver to a customer, and that item will probably be stories functionally complete and tested or some such.

    As to the next discussion point re "sprint planning, estimation and "fixed" deadlines are counter productive" [paraphrased]. In most real world scenarios Gordon is right, although organisation can get too attached to the fixedness of a deadline, they need to be able to at least roughly plan for the future and time-scales for delivery of systems, resource cost for implementation etc are critical items for a business to do effective planning.

    Like most agile questions, the most important concept in agile is enough methodology to be successful and no more. So depending on the project and the organisation, there is a level of estimation and projection that will need to be done for a project.

    Equally, there are probably projects where just do it and don't over plan is fine, I can imagine for a project which is about fixing or turning around a significantly broken environment, then deadlines and estimation are almost irrelevant, you just need to get the team stuck in and moving forwards making the world better. On the flip side, there are projects to implement a new system that needs at minimum say 5 major feature paths, even though additional features and scope can be done very agile later, the initial build has to be fairly planned out and some clear expectations set in terms of time-scales. This allows the organisation to plan when it can ramp up marketing effort or other activities associated with the delivered product. This also means that when 1 month in we realise that it'll be delivered in 12 months rather than the planned 6, the organisation can adjust scope or client expectations to resolve the issue.

    ReplyDelete
  9. Julian's reply: I remember the famous dictum that a country can have two of free capital movements, fixed interest rates and fixed exchange rates, but not all three.* I think development is much the same: you can have a two of a fixed deadline, a fixed feature set and a successful project.**

    The thing is, fixed deadlines do have a measureable benefit, but one of the principal observations of the agile manifesto is that, in development, it's all design work. You often run into tasks you thought would take a week that take hours, and vice versa. Unfortunately, our standard response to this seems to be bank the former and treat the latter as a disaster.

    Anyway, The difficulty with Christian's approach isn't one of delivery. I doubt people would be paying for him if he didn't deliver. The difficulty is one of trust. A lot of old school agile seems to be about establishing this trust. New school seems to be about taking it out for a spin once you've got it. And yeah, a fair amount of your upfront planning probably is muda, then... :)***

    *In practice, in the modern world you nearly always have the first, even if you try to prevent it. Black markets are quiet efficient these days.
    **Apparently a joke in the Netherlands in the early forties was that the Dutch had three great virtues: bravery, intelligence and allegiance to the Nazi cause. You guessed it: any given Dutchman only had two of these virtues.
    ***This isn't my idea, it's a summary of half of Liz Keogh's posts for the last year...

    ReplyDelete
  10. My reply: Yes Gordon, I am becoming very religious about this :) And yes I have been referred to a schoolboy on many occasions..

    There is a LOT of ground here that I can cover and will possible write another blog post off the back of all your comments thanks (my 3rd one ever). ... Just to throw more fuel on to the fire so we have plenty to talk about here's even more of my religious views.

    Ahhh yes forecasting.. the partner in crime of estimation.. Alone they are fraught with danger. Together (or by their alias "ROI"), they form a big ball of business excrement!! A very well respected report, the Standish Group's Chaos report last year claimed that only 32% of software projects were successful (ie: on time and budget). What we are doing now, is not working!! Radical thinking is required to solve this problem.

    Many companies have moved away from traditional budget driven centrally controlled cost-based accounting with great success. As you and Dave point out, this is a requirement in standard operating procedure for a traditional company. This doesn't make it right! There are alternatives..

    Estimation feeds the budget driven animal and keep the "management factory" busy. Getting it "right" is an impossibility, in fact the more effort you spend on getting estimates right, the more it costs you.

    I'm not sure if you have heard the difference between accuracy and precision? As an example, If I ask you to give me an accurate estimate of pi. You can give me a very quick 3.1. This is a correct representation of pi. if I ask you to write down pi, being precise to 7 decimal places. you might arrive at 3.1414999. But it is a wrong representation of pi and it and took you more effort to get there.

    Most companies favour precision in their software estimates and in doing so waste effort and cost getting there.

    I have seen projects take up to 18 months to get off the ground through business-case development and detailed requirements gathering process in order to determine detailed estimates for ROI project prioritization. Centrally controlled organisations that rely on budgets, are SO focused on meeting budget that actual business strategy has died or has been lost in amongst the need to know the detailed cost of something to meet those budgets.

    Unfortunately, even though I didn't mention Agile once in my initial post or reply, it has far too limited a scope to make a dramatic impact on end to end software delivery, as we are coupled to far greater reaching powers. What needs to change management thinking! At the end of the day, I would say I can only eliminate around 10% of overall waste in the process by introducing good agile software delivery practices. However there is another 30-40% (real numbers gathered from one of our clients) of waste that is purely swept up in management practices.

    ReplyDelete
  11. Gordon's reply: Whilst this wasn't where we started out (and I do hope you appreciate that my original questions were put in good faith and a genuine desire to learn more in the context of typical software development) I am very glad to have this back on track and really getting to the heart of where this debate has gotten to. Right now I'm in the throes of an agile process bookended by waterfall for testing - causing huge release delays - and I want to bring testing into the dev process - hence my original questions. I do have fixed deadlines too - brought about by the World Cup.

    I think what really interests me in your first post is the assertion of quality in an environment untroubled by deadlines but if there are learnings to be gotten from that I want you to spell them out more clearly so that we can see how they can be applied to other situations. It would be really easy for me to say 'of course it would be succesful to stick two devs and a tester on a story and have it come out bug free', especially in a world free of deadline constraints - you don't need to find religion to see that what you're telling us is obvious. But it's the way you did it, the small things that make the project work seamlessly and the wider context of the development you're doing that I want you to tell me about. What learnings can I take out of your post?

    You're right too about not mentioning agile and I'm really sorry to have jumped to that conclusion.

    The topic of structured project delivery is a far meatier subject and well worth the debate

    ReplyDelete
  12. David's reply: 2 followups then.

    Estimation,
    In the detail I completely agree, and your pi example is it. There is no benefit in super detailed estimation, because it's never true, however you need some level of broad estimation to set useful expectations. In your example pi=3.1, in reality you can probably survive with pi is beteen 2 and 5 ;-)

    So if I tell my boss that we are going to work on something for the next 3 months, and we establish a list of 50 odd stories, with some loose prioritisation, I can estimate to him that in 3 months I think we can get between 20 and 40 of them done, that's all he needs to approve the work.

    Onto the other point, about organisational change, I agree a big part of the problem is management structure within an organisation and we lose 30-40% of our time due to traditional management. In an ideal world we'd just change the management methodology for the organisation and it would all be lovely. In the real world, this is hard to do unless you allready have a huge amount of sway and goodwill with the organisation, and often the best you can do is aim to slowly erode the traditional processes by proving success working differently, but it's a slow change as inertia at that level of an organisational is often quite high.

    Additionally, some of this organisational management cost can be even harder to change. If the project is for internal consumption, or if it's a consulting engagement where there is sufficient trust to make it like an internal project, then you can take this a long way to everyone's benefit. However sometimes you are in a situation where you are selling a solution to a third party, and the third party has no interest in how the solution is developed, all they want to know is that they will pay X for a system and that solution will be available to them by Y date. While you can then get them into a mindset of being flexible on features and delivering sufficient value by Y date, you do need at least a reasonable level of planning and estimation to ensure that you are not going to have an insufficient quantity of functionality by the target date, otherwise you can very rapidly end up in a lawyers at dawn scenario.

    ReplyDelete
  13. Christian, this is a great post and very insightful.

    I think you and Gordon have enough meat in the comments to put together at least a few more posts.

    There is another important value to estimation that you didn't touch on above, although I think that Gordon might have alluded to it indirectly.

    Even if you have the customer's trust and the project isn't a fixed budget, estimations are important to help the customer prioritize which stories get done and in what order.

    If a story costs too much it might not be worth implementing because it might not have a sufficient ROI. Also, customers may want to prioritize the stories that provide a bigger "bang for the buck" earlier so that they can optimise their ROI.

    I think that there is value with your threesomes (trios?) continuing to do do estimation with the customer during a planning phase and checking in frequently to ensure that the customer's priorities haven't changed. Maybe you do this already?

    ReplyDelete