1. 14 July 2014

    Comments

    Buffer

    What can Agile teams learn from the German World Cup champions?

    (Cross posted from Medium)

    After a month of binge-watching football let the hangover begin.

    The runners-up match the day before — between Holland and Brazil to determine who finishes in 3rd place — can only serve to separate the truly addicted from the merely interested. I devoured that game like I had the previous 62.. but ask me today who came third in 2010. I can’t tell you and I’ll probably forget at some point that Holland came third this year

    I was happy to see Germany win against Argentina in the final — I have some German friends, a European team has never triumphed in South America and this is the first win as a unified country. When the Germans last won in 1990 it was as West Germany in a divided nation.

    So Glückwünsche Germany… you deserve to be world champions.

    During the week the Evening Standard in London published an article examining the German squad and the ingredients to their success.

    I’ve linked to the article here in full resolution. I found the newspaper on an Underground train and took it home to scan the article. Immediately I could see lessons to learn for my teams at work.

    What can Agile teams learn from the World Cup champions?

    Organise, organise, organise

    Perhaps the over-riding Germanic characteristic — the football squad was fantastically organised.

    Agile teams can learn from this — Agile is not a byword for anarchy and Agile is not an excuse not to plan or not to organise. There are many opportunities to do this in an Agile squad, from the cadence of regular ceremonies to the hygiene of the product backlog and the presentation of the team board. Be organised.

    Always prepare

    I believe the German team won because of their formation, discipline and routine. They didn’t have a single standout player like a Messi or Neymar or *cough* Rooney.

    The German team were well prepared as should your Agile team be.

    Teams reach a level of high performance once routines that add value become ingrained into the team — like a muscle memory.

    Pair programming, writing testable code and accompanying automated tests. Good communication. These things don’t happen, they are practices that need to be taught, honed and integrated until they are routine.

    Be direct

    My favourite! I’ve bought copies of Patrick M. Lencioni’s book The 5 dysfunctions of a teamfor the teams that I work with and I encourage everyone to read it.

    It describes high performance teams and the absence of traits that could kill high performance. For example — if a team has Absence of trust that leads to Invulnerability. The presence of Invulnerability leads to Fear of conflict.

    You can see the model below but please run… don’t walk… and buy that book for your team.

    The German team certainly had no absence of trust or fear of conflict from what I saw throughout the tournament. When a team has a clear focus and purpose it’s easier to pull together and call out behaviour that is detrimental to achieving the objective.

    Work as a team

    For me this is the most telling attribute of the German team. I’d heard of only a few German players before but they won because the sum of their power and skill was greater than the 11 component parts.

    Does your team perform as a whole better than the sum of the individual efforts?

    Act clinically

    The Evening Standard introduced the German word for ruthlessness (Unbarmherzigkeit) which I’d use more often if enunciation wasn’t such an issue! :-)

    This unbarmherzigkeit is what lead to a 7-1 demolition of hosts Brazil in the semi-finals and I’d like to see my team be more ruthless… in the right way.

    The reason that my team switched from abstract story points to cycle time (elapsed time from starting a feature until it’s acceptance) is that we can be more ruthless in the elimination of wasteful activity.

    Moving from “We complete 20 points in a sprint” with the associated opportunities to fluff and pad and alter estimates to our current system of “Our cycle time for features is 6 days” exposes wasteful activity. It gives the team a chance to be predictable, have a target to aim for and to be ruthless in its execution.

    Be disciplined

    To keep this article short.. lets roll up all of the above under the heading “Be disciplined.” I think it works anyway.

    Teams should be organised in their artefacts (stories, backlogs, team boards) and in their practices (design, build, test, deploy).

    Teams should discover which practices work for them and incorporate them into their working agreements and daily routine. By regularly practicing good practice simply becomes muscle memory.

    Teams should have a shared purpose and objective and should be comfortable enough with each other to highlight negative behaviour without it becoming personal or vindictive.

    Teams should be ruthless in their execution. Train hard and execute well now when the pressure is off and you’ll execute well when it’s a week from the end of the release and you need to make late changes.

    All of the above takes discipline from the team, from the ScrumMaster, Agile Coach and management team.

    And lastly…

    BE HUMBLE

    Doing well in the previous sprint is no guarantee that you’ll do well this time around.

    Team performance suffers hugely through atrophy and you have to actively keep improving through introspection.. even to keep performance level.

    Be humble and always on the lookout for ways to improve. Retrospectives help.

    In summary…

    So the World Cup is over and so are my hopes that England can put together a decent team for 2018.

    During the next 4 years I’ll be concentrating on applying the learnings from this years World Champions to the Agile teams that I work with.

    I hope you do too!

  2. 5 June 2014

    Comments

    Buffer

    Wireframes on the teams board

    How do you know you have team that embraces self improvement?

    I spent the last few days in our Amsterdam office with some others, including one of my ScrumMasters. Naturally we kept in contact with the team by attending the morning standup over Google+ Hangouts and via email and IM.

    During that time the team finished one story and picked up the next. Whilst planning the story in detail a mini-retrospective was held, although they weren’t scheduled to have one until Friday.

    And the team - in our absence - fundamentally improved how they visualised their work.

    image

    We’ve used wireframes in the past - Balsamiq is our preferred tool - and as much as possible we make them visually available to the team.

    Wireframing is great. It provokes conversations and debates about the approach we are taking to solving a problem. Having a standup conversation around a whiteboard with a wireframe pinned to it leads to an open, engaged, physically active discussion.

    The same people huddled around a computer screen leads to a closed off, quiet conversation, often without a well understood outcome.

    So what did the team do whilst their manager and ScrumMaster were away? They agreed that in the previous story not everyone was engaged with the solution and were working away on their small piece of technology. 

    Writing technical tasks on cards and progressing them through the “TO-DO”, “DOING” and “DONE” columns wasn’t giving everyone all the answers to the questions they had. It was an abstract way of describing the work that needed to be done.

    For this story the team stuck all of their tasks to the wireframe itself. "Configure this field to constrain it’s choices". Previously an abstract task and now it is cognitively associated to a place on the wireframe.

    You can see tasks that have faces stuck on them - they’ve been assigned and work being removed from the wireframe and placed in the Done column.

    As one team member said this morning “For the first time I don’t have any questions about this feature”

    What was my role in this improvement? Getting the hell out of the way and providing a working environment where the team feel safe in experimenting and implementing their own improvements.

    I genuinely wish that this was my idea to suggest. But of course the guys and girls that are closest to the work have the answers to the problem: Genchi Genbutsu

  3. 22 May 2014

    Comments

    Buffer

    How to read cumulative flow diagrams

    Love the concept of wall skills - one page printable graphics on technology subjects.

    Here is how to read a cumulative flow chart

    image

  4. 21 May 2014

    Comments

    Buffer

    The ingredients of Kanban

    I enjoyed this infographic on the ingredients of Kanban

  5. 20 May 2014

    1 note

    Comments

    Buffer

    Regular Agile team surveys to gauge morale

    A short while ago we took the opportunity to change the structure of our little corner of the development organisation.

    We based our new structure on the Scaling Agile @ Spotify whitepaper which I still believe is one of the most promising and exciting examples of making Agile work across a large organisation.

    So far - we’ve had moderate success. Cross-functional team members are organised into squads and we have 2 tribes in different locations. The formation and curation of guilds is harder and we are still working on that.

    One interesting example from Spotify is the use of surveys to find out which kind of organisational support is needed from the teams either in terms of additional coaching, tools or process support.

    This week we’ll send out our first developer survey. I think this will be helpful - although squads hold retrospectives each iteration it’s hard to get a broad view of how people feel. The retrospective - quite rightly - should go deep into some subjects to uncover issues experienced in that iteration. There isn’t always time to ask questions over a broad section of topics.

    Here are the questions that we’ll send to developers - I would love some feedback from other organisations that have done similar exercises.

    The questions are grouped into the following sections

    • My vision and purpose
    • Product Ownership
    • Process that fits the squad
    • Quality and testing
    • Morale
    • Organisational Support
    • Summary questions

    Each question will be presented with a sliding scale of answers

    • Never
    • Rarely
    • Occasionally
    • Often
    • Very Often
    • Always

    (Cleverly avoiding an odd number of questions - otherwise people hit the middle option without thinking)

    My vision and purpose

         1. I know both the short term goal that my squad is working towards and the overall release objectives for the AppDev organization.

         2. I know how to view the Product Backlog and which backlog items are most important

         3. I start work each day knowing what is expected of me

    Product Ownership

         4. The decisions I make relating to product development are aided by feedback from real customers

         5. The stories I work on are well defined and have clear acceptance criteria

         6. The team (including my line manager and product managers) have the right balance between speed and quality


    Process that fits the squad

    7. The SDLC process is effective in getting the work done rather than simply being a process that must be followed

         8. I am an active participant in my teams process and growth and my voice is heard during retrospectives

         9. My team has a learning culture and we are making active, regular improvements both to our technical competence and our process


    Quality and testing

    10. Our automated test suites allow me to make changes to the product quickly and safely

         11. The team is passionate about quality and our actions result in a high quality product

         12. The amount of time invested in maintaining quality is proportionate

    Morale

    13. I work at a sustainable pace - not so fast that I make mistakes or so slow that I feel underutilized.

         14. I am a member of team that is working towards a common goal and with individual agendas

         15. I enjoy being a member of my squad


    Organisational support

         16. My physical office environment allows me to be productive and work closely with my team

         17. Managers outside my Agile squad are available to help resolve technical or organizational issues that we cannot control ourselves

         18. My team is generally well supported in terms of tooling and process.

    Summary questions

    19. The team is effective and productive as it could be

         20. Being a member of this squad gives me an opportunity to progress and grow in my role

         21. I see the value in this survey in order to understand how the team sees their work


    I’ll be sure to write about the outcome of our first developer survey.

  6. 20 May 2014

    1 note

    Comments

    Buffer

    As a leader, which mode are you in today?

    Recently I’ve been thinking a lot about leadership. Reading Turn the ship around by L. David Marquet has been transformational for me. There are also some great thoughts in Notes to a Software Team Leader by Roy Osherove.

    When it comes to leading people there are fundamentally two choices of style with a distant third.

    • The Command and Control “dictator” model…. “Do it my way”
    • Empowerment style…. “Do it your way”
    • Lean Management…. “Follow me and we’ll figure it out together”

    John Shook defines these styles well in a conference keynote a few years ago

    "Empowerment" isn’t a viable option IMO

    I would disregard “Empowerment style” as a choice of leadership strategy despite the Agile methodology being seemingly aligned to this model.

    I don’t think it’s feasible to bring people together, provide a vision and just walk away expecting great results. Teams need a more active style of leadership than that.

    As much as I want to believe that every software development team will be completely self-organising, self-determining and autonomous I’m yet to see it in action.

    For me self-organising teams have a specific meaning around the habitual identification and solving of problems and implementing improvements via systematic learning rather than operating autonomously without leadership

    So we are left with “Command and Control” and “Lean” as two viable options for leaders to adopt.  

    Every Agile and Lean book you’ll read will tell you that “Command and Control” is a bad style of leadership. It stifles real engagement from participants, encourages a hierarchy where information flows into a bottleneck and removes the workers from the responsibility for their work.

    However - I suggest that there is a place for this technique in a leaderships skillset. In fact I’m encouraging my two squad leaders to constantly evaluate whether the time is right for this style of leadership to be engaged.

    Which mode is your team in today?

    The job of a leader is to constantly evaluate the situation that the team is in and to select a mode of leadership.

    image

    On any normal day the team should be in Learning mode meaning that they have enough slack in the system to learn from their work.

    That should involve implementing ideas from previous retrospectives or experimenting around TDD or pairing. In this mode the team should self-organise around their work and remove the need for the team leader to actively lead.

    In this mode the team leader is a true servant-leader, coaching, removing impediments and facilitating the team.

    A practical example of a team in Learning mode would be the morning standup. Too often standups are all about the ScrumMaster being front and center. Ever seen that happen? The ceremony turns into a reporting exercise with information flowing from the team member to the ScrumMaster. 

    In learning mode I’d go as far to say that the ScrumMaster should be physically 6 feet behind the rest of the team listening in to coach where necessary.

    And when the s**t hits the fan…

    The idea of “slack time” is important to this concept. The team leader should be aware when the team has no slack time in which to run in “learning mode”.

    Slack time can evaporate for a number of reasons - urgent customer issues, outages, unexpected critical work, the team slipping against a deadline.

    Lean management requires slack time as a critical component in order to learn and implement kaizen improvements.

    When slack time evaporates the dynamic of the team should change into Survival mode. The team leader needs to take a more active leadership approach and demonstrate more command-and-control characteristics. Perhaps being the dispatch controller, tracking work centrally and guiding team members from task to task.

    I still believe that true self-organising teams are a wonderful aspiration and should be worked towards.

    But pragmatically the idea of leaders that can deploy an effective leadership style when it’s necessary is a great balance between Lean management and command-and-control.

  7. 10 April 2014

    Comments

    Buffer

    Agile estimating in a Scrumban context

    Last night I went to the London Kanban Coaching Exchange to listen to a talk by Nader Talai titled “Does size matter”. In his talk Nader told us a story of a team that gained trust with its stakeholders through improved estimation.

    Our journey with Agile estimation…

    Personally I have been through an Agile estimation journey with my team over the last year. In our work before last August my team ran a fairly vanilla Scrum routine, meeting three times a sprint for an hour to discuss and size the top of the backlog.

    For us, at that time, estimation was a useful practice and we felt we were accurate enough. Taking work that we’d recently completed and comparing upcoming work against it; asking “is upcoming feature X bigger or smaller than completed feature Y" gave us a good sense of what we could take on.

    At that time, during sprint planning we’d take our targeted stories and plan in detail assigning an estimate of hours against each task. To be fair - we were often wildly inaccurate at estimating the hourly tasks but it all held together and we enjoyed good trust with our stakeholders.

    Moving from Scrum to Kanban…

    In August we made a few changes. Firstly we started working on new projects for new stakeholders. Secondly I had read a lot of debate about #NoEstimates and wanted to remove a lot of the overhead associated with estimating - especially estimating tasks in hours where we were failing to improve. Lastly - for business reasons - it made sense for us to become very familiar with the mechanics of Kanban rather than Scrum.

    So between August and January we shifted our routine to Kanban. I blogged a fair amount about our experiences if you missed it and we felt fairly successful in that transition. Certainly we felt predictable in our delivery even though we’d stopped estimating work in either story points or hours.

    Additionally, by tracking the cycle time of each user story we had a good basis for Kaizen - identifying the elapsed time from accepting the work to it being completed and where work had stopped in the process.

    We were able to point to our cumulative flow chart and say with confidence "By the end of the release we’ll be here" or "Based on our previous data the next feature will be delivered in 12 days (with 80% certainty)". Those probabilistic predictions felt a lot more stable than using abstract points to project into the future.

    image

    But we lost something by not estimating work…

    At the moment we are planning our next release which will run over a number of months. The business drivers for using a strict Kanban methodology have changed so we have some free reign to adopt our process.

    In our release retrospective recently we agreed that striving for continuous flow and moving away from iteration goals meant we lost some valuable interactions in the team.

    Some members missed the focus that a sprint goal and commitment and the two week timebox gave them.

    Others missed the planning and estimating meetings where they had the opportunity to discuss and get a shared understanding of the work. For them the practice of estimating was more valuable than the outcome of the estimating session. 

    The evils of estimation

    Last nights talk by Nader crystallised some thoughts for me. When we moved away from Agile estimates in our last release we realised the value of cycle time and the Lean method of identifying waste in our process.

    Holding up a “13 point estimate” as the only measurement of size abstracts a lot of evils that might lurk in the teams work.

    Firstly if teams feel under pressure to meet a certain velocity (lets say 26 points a sprint) it’s too easy to buckle and start to play with the numbers.

    "OK, lets take this feature and call it 13 points even though last time we called it an 8. We need to keep our velocity up"

    Or

    "We’re 2 days away from the end of the sprint, lets make sure we get this feature done quickly to keep our velocity up"

    Neither of these patterns are helpful. By making the work bigger you mask a lot of inefficiencies that will follow. If the developer can actually complete the work faster because he over-estimated to make the velocity report look good will he gold-plate the feature to use up the remaining time? If the team finish early and bring in more work does that make the velocity chart more accurate? Of course not.

    By rushing to complete work before the end of the sprint, normally an arbitrary date anyway, only quality can suffer. Why rush to complete a feature in order to satisfy the velocity chart if you have to then rework it later or ship it with low quality.

    How about this one from the Product Owner

    "You can do 26 points in a sprint right? So I can trade these two 13 point features for twenty-six 1 point features??"

    Of course not.

    How we are going to use estimates

    Despite the above I believe estimates to be helpful. They only go bad when the output is used as a management tool and especially when that management exists outside of the team.

    Here is how we are going to use estimates in the next release.

    1. Use story points as a planning guide but use cycle time for predictability, reporting and kaizen

      Estimating in T-Shirt size or story points is a useful activity because it encourages conversations about features and promotes shared understanding of what is complex (big).

      It also identifies features which are candidates for decomposition so they can flow easily through the process.

      To track predictability cycle time (how long a feature takes to complete) is a much more powerful metric. It provides a guarantee to stakeholders with an accompanying range (“We can provide a feature in 12 days (with 80% predictability)” and that is backed up with concrete data.

    2. Always remember that the value in estimating is the activity, not the output

      Taking time to estimate throughout the release promotes discussion and highlights where team members have different interpretations of the requirements.

      If one member estimates a feature at 1 point and another member at 13 points… you’ve just realised the value of estimates. That misunderstanding needs to be straightened out before development starts.

    3. Don’t drive the team to get better at estimating

      Mike Cohn has the following model in his book “Agile Estimating and Planning”

      image
      I like it - it shows that the accuracy of estimates increases dramatically with some low amount of effort but will never reach 100% accuracy.

      And actually trying to improve the accuracy of estimates requires significantly more effort and actually ends up reducing accuracy as you gather more and more data.

    Teams will continue to be inaccurate in their estimates - thats fine and expected. Your predictability and trust with stakeholders should be built using probabilistic data (cycle time and cumulative flow) leaving estimates to be a team activity and metric.

    Thanks Nader for a thought provoking talk

  8. 31 March 2014

    Comments

    Buffer

    What CustDev is and is not

    Last week I wrote about a Customer Development methodology that we are codifying in my organisation.

    We are a group of product development teams in a larger, established company. Although we don’t have the problem that “The Lean Startup” and “The 4 steps to the Epiphany” aim to solve (who are our customers, which market are we entering?) we do have a need to validate our product vision amongst our existing known customers.

    That word “vision” is important. 

    Customer Development is not a methodology for interviewing customers, discovering their biggest wishes, complaints or issues and building a product roadmap. It is also not a process for holding focus groups and getting feedback on completed features.

    From our companies inception we’ve been led by visionaries and a product vision that is simply the sum of a list of customer wishes would not have taken us to our market position today. We feel that we have to lead our customers to innovative solutions at a rate that is slightly faster than comfortable for them.

    The “Technology Adoption Lifecycle” model is useful. 

    We feel that our job is to satisfy our existing customers across the market but to innovate and predict which products will appeal to the Early Adopters and Early Majority, keeping everyone moving to the left across this diagram.

  9. 27 March 2014

    Comments

    Buffer

    A new Lean Customer Development methodology

    Currently my teams are in the period between product releases, tidying up on the one just gone and planning for the one ahead. It’s a great time to think about Customer Development and how to apply it to our next product iteration.

    I’m a huge fan of books like “The Lean Startup" by Eric Ries and "Running Lean" by Ash Mauyra and "The 4 steps to the epiphany" by Steve Blank.

    These books hold a wealth of generally applicable techniques and guidance but solve an adjacent problem.

    They all deal with the problem of “We have a vision for a product.. is there a market fit and what should the product actually be”. They deal with the uncertainty of customer discovery (do they exist, will they pay for a product) and product validation (is this idea for the product the right one).

    Fundamentally they deal with business model planning and validation.

    In my line of work I have to solve a slightly different problem. I work for a  Platform-as-a-Service company. My customers are known to me (I’ve been talking to them today!) and my motivation isn’t to discover if a market exists or which pricing plan would appeal to which market segment.

    PaaS and SaaS economics

    The PaaS and SaaS economy is driven by a few key metrics:

    • New customers: Bringing people into the system that weren’t using the product previously
    • Renewals: Keeping those customers happy and using the product
    • Upsells: Expanding the product further into the customers organisation to increase the numbers of users

    The aim of Customer Development for me is to build a product that will drive one (or all three) of those metrics for my company.

    I’m struggling with what to call this methodology - it isn’t the same as Customer Development as codified by Steve Blank, or Lean Startup as codified by Eric Ries.

    This is a methodology in need of a name!

    What is Customer Development

    In my organisation Customer Development exists as a methodology in parallel with Product Development (Agile, Scrum).

    As a methodology it complements and reinforces Product Development by eliminating risk, uncertainty and the causes of rework and waste.

    image

    What are the aims of Customer Development

    The aims of Customer Development, in order, are:

    1. Systematically prepare the Product Development teams to build a product that will drive new customers to our product (new logos) and will drive customer loyalty (renewals).
    2. To reduce waste in our Product Development process by building the “right thing” first time.
    3. To shorten the feedback loop between developers and customers.

    What are the principles of Customer Development

    1. There are no facts inside our building, only opinions. Facts come from validated research with customers.
    2. We aren’t interested in building what we think is “the right product”. We are interested in building a product our customers will use driving new logos and renewals
    3. The biggest source of waste in Product Development is feedback delay. Customer Development provides feedback on assumptions, ideas and features as quickly as possible to eliminate waste.

    Lots more to come on #CustDev and our work to build a product that will drive logos, renewals and upsells!

  10. 14 February 2014

    Comments

    Buffer

    Finding the 1%: The danger of atrophy in Agile teams

    According to Wikipedia…..

    Atrophy is the partial or complete wasting away of a part of the body. Causes of atrophy include mutations, poor nourishment, poor circulation, loss of hormonal support, loss of nerve supply to the target organ

    "Agile team atrophy" is something that I’ve experienced with teams before. Left over time there is a potential for good habits to drop off and bad habits creep in.

    Standups might be skipped if we’re all too busy today. We don’t have time to write an automated test for that feature. We don’t need a retrospective for this sprint.

    My team seems to march over rolling terrain - walking up steep inclines towards great agile practices but sometimes wandering through long valleys where things start to slip and require attention.

    I read a great post by James Clear on BufferApps blog - by the way, one of my favourite internet companies at the moment after hearing Joel speak at the London LeanStartup group.

    James wrote about the science of marginal gains. What happens if you improve everything by 1%

    image

    From James’ post:

    It’s so easy to overestimate the importance of one defining moment and underestimate the value of making better decisions on a daily basis.

    Almost every habit that you have — good or bad — is the result of many small decisions over time.

    And yet, how easily we forget this when we want to make a change.

    So often we convince ourselves that change is only meaningful if there is some large, visible outcome associated with it. Whether it is losing weight, building a business, traveling the world or any other goal, we often put pressure on ourselves to make some earth-shattering improvement that everyone will talk about.

    Meanwhile, improving by just 1 percent isn’t notable (and sometimes it isn’t evennoticeable). But it can be just as meaningful, especially in the long run.

    And from what I can tell, this pattern works the same way in reverse. (An aggregation of marginal losses, in other words.) If you find yourself stuck with bad habits or poor results, it’s usually not because something happened overnight. It’s the sum of many small choices — a 1 percent decline here and there — that eventually leads to a problem.

    I believe in this model. In fact I’d go further in the application of the model to Agile teams and say that if you aren’t continually improving by 1% you are probably regressing somewhere. Teams need to keep improving.. most of all to keep the idea of Kaizen alive.

    If you have a learning culture built into the team and the ability to experiment it’s possible (but not easy) to regularly find that 1% improvement and make it stick.

    Without that culture of improvement (Kaizen) even if you think you are standing still you are very likely to be regressing by 1% week over week.

    What improvements have you made today? Answers in the comments please!