Sunday 19 April 2015

Why are Multi-Functional Teams Desirable?

In the past I've talked about multi-functional teams being the unicorn at the heart of scrum, i.e. very desirable but essentially mythical.  I've also written a post explaining my take on the reason why multi-functional teams are so hard to find, but an article from Darren Wilmshurst has made me realise that I've never talked about why multi-functional teams are desirable in an agile environment (actually, required, if you don't want to do Water-Scrum-Fall).  But before I go into this, I need to share a little bit about the writing process behind this blog, for reasons that will hopefully become clear.

Some of the posts on this blog are articulations of good practice, some of them are based on years of experience, and some of them - like this one - spring from a thought that occurs to me whilst I'm reading/writing/doing something in relation to agile.  If you've ever spent a lot of time immersed in a conceptual framework, you'll hopefully understand how everything you see and hear that has any relation to what you're immersed in has the potential to send your mind off in a direction you'd never thought of before.  This is the case with this blog; so much of what I write is the result of seeing everything professionally through the lens of trying to understand and then explain how and why agile things work the way they do, and that constantly sparks off ideas for blog posts.

Right then, that's all well and good, but what does it have to do with why multi-functional teams are desirable? Well, it's this: When I realised that I'd never written about this topic, I initially thought that it would already have been well covered in the blogosphere by other writers, so maybe I was just mentally riffing on something that has been fully documented elsewhere. This has happened before, and I didn't feel I had anything to add to the conversation, so I didn't write a post.  But in this case, maybe someone has posted extensively on this topic, but I can't find those posts.  There are posts that explain some of the practical benefits of a multi-functional team within an agile process, such as greater efficiency, less waste, cross-fertilisation of skills and ideas, and so on, and for a lot of people, maybe most people, these benefits are an acceptable end in themselves.  No more explanation is required.  But I'm more interested in articulating why those benefits are indeed benefits.  What is the conceptual paradigm behind those benefits?  What is the ground for the article of faith that says multi-functional teams are good? 

Perhaps "article of faith" is wrong, but it captures the essence of my point.  A more accurate statement might be to say that the concept of multi-functional teams has become one of the boundary conditions for what defines an agile team as agile, and, therefore, if you think agile is good, you must by default think that multi-functional teams are good.  And that makes sense, because nothing is more closely associated with agile than the concept of the multi-functional team.  Multi-functional teams are the hinge on which the agile process turns; without that team, you can't describe yourself as agile.  And yet, this boundary condition is so universally accepted without question that I can't find much written about it, which seems like an oversight to me.  I'll try to address that here.


In a previous post I talked about how agile methodologies like scrum and Kanban might be more suited to startups than mature companies.  The heart of the piece was as follows:

"As a company grows though, employees become more specialised to increase efficiency and quality.  This is an economy of scale that basically turns any suitably large company into a form of production line.  Processes, procedures and standards provide not only the structure of the company which analysts can constantly study for new ways to increase efficiency (read: profits), but also the conceptual conveyor belt along which the product passes from conception through delivery and implementation to maintenance and support.

But scrum is the antithesis of this production line ethos with its proscriptive standards and linear flow.  Scrum suggests, nay, demands a multi-functional approach to production within the scrum team, and that cannot happen if the scrum team is made up of specialists. "

Individual specialisation is the opposite side of the coin to multi-functional teams.  It is the difference between the Henry Ford production line and the farming collective.  There is an inherent tension here between the command-and-control, profit-driven efficiency of the production line, and the self-organising arrangement of a series of individual strengths and weaknesses for mutual benefit in the farming collective.  The production line values efficiency over everything, and this is why it makes sense for a startup to move towards increasing specialisation.  The key to a successful business, in the short to medium term, is to leverage a good idea such that enough revenue is generated to sustain that business as a going concern and provide enough profit for the owner to make it worth their while to continue.  The best way to leverage a good idea which you've had initial success with is to hire specialists who can design, build, support, market, sell, and so on, while you focus on the good idea you had.

But in the long term, the key to a successful business - especially in an industry as fast-moving and competitive as software - is innovation, not efficiency.  That's not to say that efficiency becomes unimportant, because it doesn't.  It's just that efficiency is only useful so far as your products are delivering what the market wants.  Even Ford, the company that made the production line famous, has the 2nd highest R&D budget of any company in the world.  Why?  Because without innovation their profits will wither and die.  Not many people want a 1980's Ford, no matter how efficiently Ford can make them, when they can have a 2015 Toyota, so Ford spends billions every year to make sure that they have a competitive range of products for people to buy, and thus ensure their long term success. 

And here's something important: innovation does not have to be mutually exclusive from efficiency.  Nor does innovation have to flout a company strategy, or a divisional goal, or have no command-and-control directing it. As long as the team that is innovating knows what their boundaries are, you can let them get on with it, like a black box.  Innovation might not be something that can be made more efficient in the way that piece work on a conveyor belt can be, but you can most definitely give a team of people the right conditions to innovate and improve their chances of coming up with the next big idea.  If you do some research on the topic, the same recommendations for creating an environment that fosters innovation come up time and again:

 - A culture of trust where people know that their ideas are valued;
 - A culture of empowerment where people won't get in trouble for trying something new;
 - A culture where the leadership actively encourages and rewards innovation.

In other words.....an Agile culture. Agile has all of these things, and although many people have to put up with working in Dirty Agile, anyone lucky enough to work in a company that has properly bought into Agile should have experienced these 3 things.  So despite initial impressions, it is the collective that values the contribution of the individual more than the production line does, and this speaks directly to why multi-functional teams are desirable:
 

The collective allows the individual the space to innovate as part of a team.  The production line just allows the individual to do the same thing they've always done, only a bit quicker.

Agile is firmly in the collective camp, and the self-organising multi-functional team is the tool that is used to drive innovation by building trust, providing empowerment, emphasising communication and fostering a culture of collective problem solving.

That's why multi-functional teams are desirable. 

This also explains why so many companies who engage in Dirty Agile don't value multi-functional teams - they are the companies without the foresight or leadership to plan for the long term, so a multi-functional team that can innovate is never as important to them as a group of specialists who can do the same thing again and again, very efficiently.  That also saves on training budgets and career development, which reduces short-term costs, although the staff turnover rate is strangely high..... I suspect that I don't need to gild this lily any further!

Perhaps you should ask yourself the question: Are you working for a company with a 1920's Ford production line, or a company with a 21st century Ford R&D department? And which one would you rather work for?


Wednesday 15 April 2015

Working Remotely with Developers and Testers

From the Agile Manifesto: 

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

There are times when you can't be in the same room as some or all of the rest of your team to have that face-to-face conversation, so how can a writer work as part of a team remotely?

Let's get one thing clear: Agile can and does work with remote team members. This applies to writers as much as developers, testers, designers, etc. In theory even a scrum master could be remote (although that might be one of those times when theory and practise diverge).  I'll explain how this can work, but nothing beats practical experience and as a manager of writers I've managed all 4 of the possible scenarios:
  

  • Local writers working with local teams; 
  • Local writers working with remote teams;
  • Remote writers working with local teams; 
  • Remote writers working with remote teams (i.e. a worker who is not working in the same geographical location as me and nor are they working in the same location as their scrum team, who were based in a different geographical location to mine).
I know that all of these scenarios can work for writers, because I've managed writers who have been successful and productive members of scrum teams in all of these scenarios.  There's no doubt in my mind that the simplest and most effective situation is for all team members to be in the same location, and preferably the same office space***.  But there are often good reasons why one or more members of a team will be working remotely, and, if you are the remote worker, it is your responsibility to find ways to be an effective member of the team.  It is the responsibility of the rest of the team to help you be effective. 

The following lays out the most important things for being an effective remote worker in a scrum team over a period of time:

1 - Communication
2 - Trust
3 - Availability
4 - Clarity of goals

Before we look at these in more detail, it's worth emphasising that if you haven't worked with all of the remote team members before, then face-to-face meeting at the start of the process can be very helpful.  Putting a face to an email signature and having an idea of them as a living, breathing person can make faceless communication much less fraught. It’s very easy to read the wrong intentions into written communication, especially if you don’t share a common native language and/or culture. Meeting people can prevent a lot of that kind of problem by giving you a sense of who they are as people - remember that most communication is non-verbal, so you'll get far more out of a 30 minute meet-and-greet than you will out of a month's worth of dialling in to conference calls. 

If meeting the team in person isn't possible for whatever reason, try doing virtual face-to-face meetings using video conferencing.  Introduce yourself, ask questions about what each team member does, what they need from you and what you need from them.  This will at least give you some kind of baseline to work from, because you don't want your first person-to-person contact with a team member to be at a moment of stress or pressure.

Assuming you've met your team either in person or by video, lets look at the 4 key areas in more detail.



Communication
 

Clear, agreed lines of communication are key when working in an scrum team. By working remotely you're giving up one of the biggest assets that a scrum team has - regular face-to-face communication within the team - and as such you must agree on methods and systems for replicating this as much as possible.  The obvious tool is video conferencing, and it should be a matter of course that you attend all ceremonies using this tool. But over and above these set-piece meetings, use instant messenger, email, Slack, Hangouts, or whatever combination of tools that works for you and your fellow team members, and use them a lot.  Part of being a remote worker is making sure that your team remembers and includes you, and if you've never worked remotely before you might be surprised by how easy it can be to feel, or be, forgotten.  Regular (at least daily) contact with your team outside of the set-piece ceremonies will help you keep in the loop, and help your team mates keep you in the loop, and nothing is more important for an agile team than everyone knowing what is going on.


Trust

My experience of managing writers is that a good member of staff is good regardless of whether they are working remotely. I appreciate staff who are pro-active, good at gathering information, independent and who know when they need to involve me and when they don't, and that is the same for both local and remote workers.  Unsurprisingly, these skills are also key to being an effective member of a scrum team, especially if you work remotely and you don't have a long history with your team.  You can't assume that your new team will have an immediate level of trust in you and your work, because until you've proven it - and they've proven the same to you - you're all still finding your way. 

It's only once the team's velocity has stabilised that the team as a whole will have a good feeling for which team members have what strengths and weaknesses. The developer who's not the quickest at getting their task done, but who is the social glue that holds the team together, provides a value over and above just their output; as a remote worker, you don't have this kind of opportunity to provide additional value because you're not in the office with the rest of the team.  Therefore your team mates need to trust the quality and quantity of your output, and your contributions to meetings - those are your core competencies and you will be judged on them.  That can feel a bit harsh sometimes, but one of the downsides of remote working is that your lack of physical presence gives the rest of the team less day-to-day evidence on which to evaluate your contribution, so make your contributions regular and high-quality!


Availability

If there is a particularly annoying problem when dealing with remote workers, it's that they aren't working when you are, so you can't get hold of them. This is really, really irritating because they have become an impediment to your work, and as they are part of the same scrum team that should not be happening, even if they are part-time or working in a different time zone.

To be clear, I'm not saying that people who work part-time or in a different time zone are a impediment to the team.  What I am saying is that the team should know when someone will be available so they can plan accordingly.  If I need something from a part-timer who works 10am - 2pm 5 days a week, then I can just ask them on any given day during that time slot. That's not an impediment because I know when they will be available.  Similarly, if I work 9am - 5pm and a remote worker in a  different time zone works the equivalent of 11am - 7pm, that's also not an impediment because I know I can contact them between 11am and 5pm.  The impediment is the uncertainty of when I can and can't get hold of a team member.

To remove this impediment, try instigating a block of core hours – e.g. 11am – 2pm  - when people will always be available for ceremonies, conference calls, IM/email exchanges, etc. This gives everyone the flexibility at the beginning and end of the day when you aren’t expected to answer immediately, whilst still providing a standard block of time each day to ask questions, get answers, have meetings, etc. This will help with planning and time management, and remove the impediment of uncertainty.

An additional remedy is making sure all calendars are shared, either by sharing individual calendars or, preferably, having a team calendar where everyone adds in their holidays, booked meetings, and so on.  This provides a central location for remote and local workers to easily find out when a person they need will next be available.


Clarity of goals

There are short term and long term goals that the whole team should be working towards.  The short term goals will normally be sprint and release based, so it is important to clarify up front what deliverables are included in the Definition of Done for both the sprints and the release. This is even more important if you're working remotely because the assumption for a remote worker is that they tend to be slightly more autonomous, especially if they are a contractor and/or non-developer.

For the long term, try to build a common goal and sense of direction between both teams. Meeting face-to-face helps build the required trust to work as a team; having a shared, agreed goal helps that team have a focus. In general terms, it’s about developing strong relationships quickly and making sure you’re all pointing in the same direction. Again, as a remote worker this is particularly important.



What else do you think is important when you're providing documentation remotely for a scrum team? Sound off in the comments!



Update: Content curator, blogger, entrepreneur and all-round high-achiever Belle Beth Cooper has put together a stupidly good guide to remote working which I can't recommend highly enough.  If you want more articles, Belle has kindly added a section at the end of the guide with her recommendations.


*** -
The caveat is that some people prefer to be on their own for periods of time, and suitable allowances such as private offices (where available) should be made for that, but they should still be easily reachable.

Thursday 9 April 2015

Documentation Shouldn't Be Used to Cover Technical Debt

In my previous post, I talked about documentation having technical debt.  Normally this debt is a burden on the users, and therefore the customer support team (this is one of the reasons why documentation has value, rather than just a cost, but I'll expand on the benefits of documentation in a future post).  But technical debt in the software, whilst potentially being a burden on customer support - and indeed customers - can become a big burden on documentation, and lead to more technical debt in the documentation itself.  Allow me to clarify. 

If your software:
  • Does something when it shouldn't do;
  • Doesn't do something when it should do;
  • Does something in an unexpected way;
  • Does something in an incorrect way;
  • Is unnecessarily complicated;
  • Is not designed with ease-of-use in mind;
  • Causes an unnecessary manual intervention;
  • Causes an unnecessary manual correction;
  • Causes the user any problem that requires them to contact Customer Support;
Then your software has technical debt that should be explained in the documentation.  That's a whole bunch of known issues that have to be documented in at least one place, and maybe more (for example, on a dynamic customer-facing website and also in the release notes), as well as additional documentation effort required to talk the users through bad design or bad implementation.  This is a burden on the documentation team.  In a very real sense, development's debt is therefore documentation's debt, because we (are one of the teams that) have to pay the interest on that debt until it is paid in full by development.

On top of this, the additional documentation that has to be done has to be recorded and monitored, so that as the development team pay back their debt in code, we can amend our documentation to match.  As soon as this happens, there is a technical debt in the documentation, because it no longer matches the software.  This debt may only last until the writer has completed the documentation task that go with the development task, or, as happens more than it should, a developer might see and fix something whilst they are working on the code line but not mention it because they didn't realise it was documented anywhere, and the documentation debt never gets paid.

A simple example might be that the documentation states that a process may take some time if there is >= 10000 records.  A developer is working on fixing an unrelated issue in this process, and whilst she's in the code she realises that a minor change to a While loop will speed up the process significantly, especially for larger record sets.  She makes this change, as well as fixing the unrelated bug, documents the bug fix (but not the speed change), and moves on to the next task in the backlog.  Bang, your documentation is now incorrect, and there is no way you'll ever know about it.  Meanwhile, your customers "know" that this process is not as fast as it should be, and this decreases their satisfaction with your product.  This is a small error in your documentation, and the customer's satisfaction decrease is equally small, but if you multiply this by 10, or 20, or 50 small errors then their cumulative weight can make your documentation seem inaccurate and your product quality seem poor.


The other large burden that technical debt can place on documentation is when the software is unnecessarily complex.  A friend of mine once described a product he worked on as suffering "death by a thousand parameters", as every piece of additional functionality that a customer wanted was parameterised so that the other customers could continue using the product in their own way.  This led, as you can imagine, to a ridiculously complicated system, and was caused entirely by an unwillingness to say no to shouty customers, and an equal unwillingness to make long-term strategic decisions that would benefit the majority of customers instead of just the most obnoxious complainers.  The fate of this product was entirely obvious to all but those who's unwillingness led it to its inglorious endpoint.  This situation is a somewhat extreme example, and I suspect it's particularly prevalent in a Dirty Agile situation where the Product Owner is not the hawkish gatekeeper they should be, but it casts a light on a problem that writers face in many companies - the expectation that technical debt has been "dealt with" as long as someone has documented it.

I don't know how to say strongly enough that this is wrong, but maybe Scott Adams can help:


'Nuff said....


 








That kinda sums it up right there.  The scary thing is that some people need that explained to them, or they see the superficial humour but don't see it as a genuine problem that needs solving.  If as a writer you find yourself spending any significant time writing documentation to cover the technical debt of your software, then that software will be unlikely to provide you with a long term career.  No company with any pretensions to success will have that level of debt in their products, because they won't get the confidence of their customer base, and without that confidence they won't make the sales that will sustain the company in the long term.  On top of that, the cost of maintaining a product with significant technical debt is much higher than the cost of maintaining a product with low levels of technical debt, so you get the double whammy of low customer confidence leading to low sales income on the one hand, and high maintenance cost on the other.  Hopefully you don't need to be a business guru to work out the consequences of this....


Documentation has Technical Debt Too

"Technical debt" is a concept in programming that describes all of the work that has to be done later because it wasn't done (or done right) at the time.  Wikipedia sums it up nicely:

"The debt can be thought of as work that needs to be done before a particular job can be considered complete. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy [software complexity]."

A solid overview of technical debt in software projects can be found here.  That link details the technical debt experienced within the code line, which is the common understanding of where such debt accumulates.

However, the following issues are also a form of technical debt for your documentation:

  • A backlog of documentation tasks (where documentation is not in your definition of done).
  • Known errors in your documentation.
  • Known omissions in your documentation.
  • Known ambiguities in your documentation.
  • An out-of-date Table of Contents or index.
  • A lack of consistent terminology and/or use of standards within a document.
  • A lack of consistent terminology and/or use of standards within a documentation suite.
  • A lack of consistent terminology and/or use of standards across different documentation suites.
  • Documentation that is out of sync with the most recent release.
  • Missing documentation (e.g. you have installation notes but no configuration guide).
  • Multiple documents that could (and therefore should) be single sourced.

There are other types of technical debt for documentation; these points should be thought of as examples, rather than as an exhaustive list. As all technical debt is shared by the whole team, our debt is their debt and vice versa. I'm sure you can imagine that there is some contention about whether documentation is included in the "official" definition of technical debt, but that
largely boils down to whether or not documentation is included in the Definition of Done, which I've discussed elsewhere.

The important point is that, like a software application, a large piece of documentation can be very complex, and the more errors or omissions there are, and the earlier these occur, the more you pay for them when trying to fix the errors or include the omissions at a later date.  There is no magic bullet for fixing technical debt, so I won't try to provide one here, but at a later date I will be posting about the value of documentation, and hopefully that will give you some ideas about how to persuade people of the importance of getting your documentation correct, consistent and complete.


That aside, don't be afraid to talk in terms of technical debt if you need to persuade your Product Owner to prioritise tasks that will fix these problems.  The more that your documentation issues are seen as being similar in scope and type to the software issues, the more likely you are to be supported when you ask for a higher priority to fix your technical debt.  It's important to frame requests in language that your development-oriented team mates can understand, and most developers understand both the importance of minimising technical debt, and the frustration that having it causes.