Personas are imaginary users that fulfils a specific role in the use of a software product, and they are used by usability and user experience designers to infer what a real person might need. For example, for a Financial application there may be personas for Accounts Payable clerks, Accounts Receivable clerks, Financial Controllers, Finance Directors, and so on. The personas will include key information about levels of knowledge (of both the product and the domain) and common tasks that are undertaken by the persona at regular intervals (e.g. entering invoices, scheduling batch payments, producing reports, etc) to allow the designers to produce designs which are more user-centric, rather than being driven by the designer's own understanding of the requirements which might be inaccurate or incomplete.
As a secondary benefit, these personas can be used during grooming and planning to help the scrum team understand why the requirements are what they are, e.g. it's important that certain fields are grouped together because the persona that most often uses this form will always have to fill those fields in and grouping the fields together will make them more efficient. Using personas to help the scrum members stand in the shoes of a real (statistically-averaged) user means that the scrum members are more likely to immediately "see" why certain design aspects will make things easier for the users, and thus they are more likely to produce an increment that meets those needs.
This brings us to the role of personas in targeting documentation. Writers are no more immune from the fallacy of "me-centred design" than designers or developers are: making decisions based on what we would want or we think our users would want. Documentation is often created and maintained by a smaller team, proportionally, than the team that creates and maintains the product; it is (unfortunately) not unusual for there to be software designers and UX/usability specialists working on the artifacts for a sprint, but for there to be no corresponding documentation designers or UX specialists. Writers themselves are often expected to fulfil these roles, either singularly or as a team. Just think about that for a moment. On a large piece of software the help file is likely to be amongst the most accessed pieces of the functionality, and yet a lot of companies do the equivalent of expecting the developers to make all of the software design decisions. That's both worrying and depressing!
If this situation is familiar to you and you are not a documentation UX specialist, the personas that are used by the software UX/usability experts in your company can help you avoid making the basic mistakes that prevent your readers from easily accessing the information they need from your documentation. If you don't have access to UX/usability personas, or you want to learn more about creating and using them specifically for documentation, I recommend Communicating the User Experience: A Practical Guide for Creating Useful UX Documentation by Richard Caddick. As well as personas this book covers other useful tools and practises for designing user-centric documentation and will help you when you are maximising documentation ROI.
Saturday, 28 February 2015
< /LeonardNimoy >
This is a blog about agile documentation, and as such not the appropriate or preferred forum for sharing my personal feelings about events in my life or events in the world at large. However, occasionally something happens which intersects the personal and professional, and the passing of Leonard Nimoy is one such event.
Star Trek in general, and Spock in particular, was a significant inspiration to my love of philosophy and science, loves which continue to this day. I would not have have been half as interested in computer science and technology without my weekly doses of Star Trek, TNG, Voyager and DS9. Spock's rational viewpoint was a role model for how I tried to view the world and tackle the problems I faced, and I know I'm not alone in that. My life would probably have taken a different course without that role model, and this blog, modest though it is, wouldn't have happened.
Thank you Leonard. Live long and prosper, wherever you are.
Normal service will be resumed in the next post.
Star Trek in general, and Spock in particular, was a significant inspiration to my love of philosophy and science, loves which continue to this day. I would not have have been half as interested in computer science and technology without my weekly doses of Star Trek, TNG, Voyager and DS9. Spock's rational viewpoint was a role model for how I tried to view the world and tackle the problems I faced, and I know I'm not alone in that. My life would probably have taken a different course without that role model, and this blog, modest though it is, wouldn't have happened.
Thank you Leonard. Live long and prosper, wherever you are.
Normal service will be resumed in the next post.
Scrum Works Better in Startups
Inspired by this article, I've been thinking about how agile works better in startups than in mature companies. The article in question argues that Kanban is often more appropriate for startups due to the time-to-market imperative and the rapid pace of change, and I'm not disagreeing with that because a) she makes a great point, and b) I'm not going to argue with an agile maven like Abby Fichtner.
Rather, it occurs to me that the posts I've written previously suggest that scrum is difficult to implement in practise because of the unicorn at the heart of scrum, which tends to lead towards an inevitable Water-Scrum-Fall situation. This could imply that I think scrum doesn't work. This is not true. Scrum is a great methodology and although its application is hindered by the lack of multi-functional teams, that doesn't mean that it can't still be implemented well and have many benefits.
However, my experience comes mainly from working with mature products and teams, or new products and teams within mature companies. The larger and more mature a company gets, the more specialists they employ. No tech startup hires an agile coach as one of their first employees; it's normally 2 or 3 coders with an idea and easy access to deliverable fast food. Agile coaches come after another developer, an accountant, a saleswoman, a marketing guy, a tester, another couple of developers, and about 50 other people, because that's the point when the company stops being naturally agile and starts needing help to understand and proceduralise the things that make them good at what they do.
In a more mature company that's got hundreds or thousands of staff you'll find increasing levels of specialisation. In the technical writing team you might have editors, sub-editors, API specialists, tools experts, learning and education experts, and so on, on top of a pool of staff writers who actually document the output from development. And then there's the non-technical writers who provide marketing copy, sales brochures, company reports, blog posts, social media content, and all other manner of written communications. In a startup, the founders will do all of that as and when necessary, and as they hire staff the marketing guy will produce the marketing copy, the saleswoman will put together the sales brochure and the developers will provide some release notes or instructions on installing the product. After that, as the company grows further, someone in development will gradually start to take responsibility for documentation and eventually become the technical writer, or the company will hire someone specifically to write it. At that point, scrum starts to become more difficult.
In a startup, generalists are highly valued because there are many jobs to do and not many people to do them. The founders and early employees have to do everything from development to sales to documentation to marketing to testing to paying the wages and they normally lack proscriptive standards for these things. Therefore, an agile development methodology like scrum or Kanban is ideal: it allows them maximum agility and they are already a fully multi-functional team where the emphasis is on quick, iterative delivery. 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.
The more specialised the roles in your company are, the less effective scrum will be
This highlights an inherent tension that might help explain why so many companies end up implementing some version of Water-Scrum-Fall and not getting the results they expected. Specialism - division of labour - is a clearly defined economic tool to help companies scale up their production to make it more efficient and, ultimately, increase profits. This is one of the reasons why Waterfall is considered to be an efficient model. Scrum is a methodology that demands generalists. Therefore, whilst scrum can be more efficient and produce higher-quality deliverables in a small team, the staff needed for it are at odds with the staff needed for the traditional division-of-labour, process-driven methodologies. So large companies have specialists who work in a (conceptually) linear process, but if the company tries to implement scrum they need to employ generalists that don't fit with the perceived conception of efficiency.
In a startup though, specialisms are an anathema, and the entire company - which might be as small as 1 person - is composed of generalists who are agile by default. Agile is not so much the right methodology for a startup to use, it's the only methodology that can be used. Really, agile development as a methodology is the re-creation and formalisation of a tech startup mentality for larger companies, and larger companies have moved away from the generalised skill set needed to fuel that mentality in favour of a division-of-labour efficiency. Is agile trying to recapture a mentality that's inevitably lost in the paradigm shift to being a "proper" company? Is it possible for a large company to be agile in this way? I'm not sure it is.
I'd be interested in hearing from anyone that seen a startup move from being a small agile operation to a larger company with increasing specialisation. Did your company keep itself agile? How did it do it? Were generalists still valued as highly? Thoughts and experiences are welcome in the comments.....
Rather, it occurs to me that the posts I've written previously suggest that scrum is difficult to implement in practise because of the unicorn at the heart of scrum, which tends to lead towards an inevitable Water-Scrum-Fall situation. This could imply that I think scrum doesn't work. This is not true. Scrum is a great methodology and although its application is hindered by the lack of multi-functional teams, that doesn't mean that it can't still be implemented well and have many benefits.
However, my experience comes mainly from working with mature products and teams, or new products and teams within mature companies. The larger and more mature a company gets, the more specialists they employ. No tech startup hires an agile coach as one of their first employees; it's normally 2 or 3 coders with an idea and easy access to deliverable fast food. Agile coaches come after another developer, an accountant, a saleswoman, a marketing guy, a tester, another couple of developers, and about 50 other people, because that's the point when the company stops being naturally agile and starts needing help to understand and proceduralise the things that make them good at what they do.
In a more mature company that's got hundreds or thousands of staff you'll find increasing levels of specialisation. In the technical writing team you might have editors, sub-editors, API specialists, tools experts, learning and education experts, and so on, on top of a pool of staff writers who actually document the output from development. And then there's the non-technical writers who provide marketing copy, sales brochures, company reports, blog posts, social media content, and all other manner of written communications. In a startup, the founders will do all of that as and when necessary, and as they hire staff the marketing guy will produce the marketing copy, the saleswoman will put together the sales brochure and the developers will provide some release notes or instructions on installing the product. After that, as the company grows further, someone in development will gradually start to take responsibility for documentation and eventually become the technical writer, or the company will hire someone specifically to write it. At that point, scrum starts to become more difficult.
In a startup, generalists are highly valued because there are many jobs to do and not many people to do them. The founders and early employees have to do everything from development to sales to documentation to marketing to testing to paying the wages and they normally lack proscriptive standards for these things. Therefore, an agile development methodology like scrum or Kanban is ideal: it allows them maximum agility and they are already a fully multi-functional team where the emphasis is on quick, iterative delivery. 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.
The more specialised the roles in your company are, the less effective scrum will be
This highlights an inherent tension that might help explain why so many companies end up implementing some version of Water-Scrum-Fall and not getting the results they expected. Specialism - division of labour - is a clearly defined economic tool to help companies scale up their production to make it more efficient and, ultimately, increase profits. This is one of the reasons why Waterfall is considered to be an efficient model. Scrum is a methodology that demands generalists. Therefore, whilst scrum can be more efficient and produce higher-quality deliverables in a small team, the staff needed for it are at odds with the staff needed for the traditional division-of-labour, process-driven methodologies. So large companies have specialists who work in a (conceptually) linear process, but if the company tries to implement scrum they need to employ generalists that don't fit with the perceived conception of efficiency.
In a startup though, specialisms are an anathema, and the entire company - which might be as small as 1 person - is composed of generalists who are agile by default. Agile is not so much the right methodology for a startup to use, it's the only methodology that can be used. Really, agile development as a methodology is the re-creation and formalisation of a tech startup mentality for larger companies, and larger companies have moved away from the generalised skill set needed to fuel that mentality in favour of a division-of-labour efficiency. Is agile trying to recapture a mentality that's inevitably lost in the paradigm shift to being a "proper" company? Is it possible for a large company to be agile in this way? I'm not sure it is.
I'd be interested in hearing from anyone that seen a startup move from being a small agile operation to a larger company with increasing specialisation. Did your company keep itself agile? How did it do it? Were generalists still valued as highly? Thoughts and experiences are welcome in the comments.....
Subscribe to:
Posts (Atom)