Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Managing a Project the Drupal Way - Drupal Open Days Ireland

1,391 views

Published on

You're organised, you love spreadsheets, you're a great cheerleader, you handle a backlog with superhero skills, and now you're faced with managing a Drupal project and everything just feels foreign. It's not you, it's Drupal. The mix of site building, front end development, backend development, and over 20,000 contributed modules makes project management for Drupal exceptionally frustrating for people who've not worked with Drupal before.

This session will cover:

- the basic Drupal development workflow (from a developer's perspective, but without using developer jargon)
writing useful tickets which developers can accomplish
- estimation tips for multi-discipline tickets (design / back end / front end)
- ideal team structures -- and what to do if you can't get them

Updated from DrupalCamp London to include the truisms I've learned about being a first-time project manager.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Managing a Project the Drupal Way - Drupal Open Days Ireland

  1. 1. Managing a Project The Drupal Way @emmajanehw drupal.org/user/1773 You're organised, you love spreadsheets, you're a great cheerleader, you handle a backlog with superhero skills, and now you're faced with managing a Drupal project and everything just feels foreign. It's not you, it's Drupal. The mix of site building, front end development, backend development, and over 20,000 contributed modules makes project management for Drupal exceptionally frustrating for people who've not worked with Drupal before. This session will cover: • the basic Drupal development workflow (from a developer's perspective, but without using developer jargon) • writing useful tickets which developers can accomplish • estimation tips for multi-discipline tickets (design / back end / front end) • ideal team structures -- and what to do if you can't get them • Bring your questions, and bring your experience -- plenty of time will be left for discussion at the end of the session. Time: 30 minutes
  2. 2. The best place to learn software development is in the Drupal community. Disclaimer. I have never met a more supportive group of people who genuinely wanted to help others to succeed in learning how to contribute to a software project. We / they are an open, welcoming group of people. No previous experience needed. - testing - peer review - writing good bug reports - collaborative patch writing
  3. 3. The worst place to learn how to build a site with Drupal is the issue queue. (Another) Disclaimer But learning how to build Drupal is not the same as learning how to make a client website with Drupal. Too often developers forget to bring the best practices from Drupal into their workplace. This talk is a reminder of some of those lessons, mixed with the lessons I’ve learned about building Drupal sites, mixed with some of the psychology I’ve picked up as a Project Manager on Drupal and other software projects.
  4. 4. Avoiding project managers is iterative.
 It’s something we developers get better at every time. @adamculp First a little background for this talk. I’ve been working with Drupal for over a decade. First as a developer who was building her own CMS (I used the database structure for multi-lingual content); then as a site builder, and a themer; then as an educator (I’ve written two books on Drupal and delivered sessions at a lot of Drupal events); and finally as a project manager. Having played all of these roles, I know where all the snake pits are when delivering Drupal sites. I also know where there are easy wins for teams.
  5. 5. Every project is a unique snowflake. The trick is to understand what those snowflakes mean in aggregate. This is pretty snow because it’s in a field.
  6. 6. This means: danger due to drifts.
  7. 7. This means a lot of shovelling.
  8. 8. Drupal PM Survival Guide 1. Foster collaborative, cross-functional teams
 who stay with you for the entire project. 2. Find your gremlins sooner by deploying features
 from start to finish. 3. Build re-usable components, 
 and all their variants, from content “out”. 4. Emulate the drupal.org issue queue. 1. Build your team. 2. With very small chunks, walk through all the steps from start to finish. 3. Build re-usable components where possible. 4. push all communications + artefacts of conversation to the issue queue; collaborate and hold each other to the highest possible standard.
  9. 9. 1. Foster collaborative, cross-functional teams who stay with you for the entire project. Managing Projects the Drupal Way (this is a header slide; don’t dwell!)
  10. 10. Teams are immutable. 
 Every time someone leaves, or joins, 
 you have a new team, 
 not a changed team. @richardadalton
  11. 11. Be aware of job titles. Ideal team structures -- and what to do if you can't get them Be aware in the sense of “these are the tasks you’ll probably have to complete”. But also be aware in the sense of not letting people roll up their sleeves because they have the wrong title. And finally be aware if you’re asking someone to accomplish something outside of their normal comfort zone. Having someone stretch can take more time away from other tasks.
  12. 12. Web Projects • UX • Designer • Content Strategist • Backend Developer • Front End Developer Supportive Roles • Business Analyst • Project Manager • Quality Assurance • DevOps / Sysadmin Client-Side • Product Owner • Content Manager Drupal-Specific • Site Builder • Themer
  13. 13. Foster strong teams. I’ve watched teams of weaker individuals raleigh together and become an incredibly strong team. Communication Peer review Knowledge sharing Collaborative research (LMGTFY) Brainstorming Rubber ducking Accountability Morale boosting (Acknowledge effort) (Protect dev time)
  14. 14. Moods are infectious. Project management truism. Every day everyone brings themselves to work and in a distributed team you rely on voice and typed words. Sales folks train themselves to smile when talking on the phone. They say it changes the tone of the voice. If you feel the team is trending towards frustration take the time to check your own attitude. Smile. You might be able to pull the team into your good mood.
  15. 15. Acknowledgement
 kindles effort. Project management truism. In software, a job well done is often invisible. If I no longer see error messages, it's as if the solution had always been there. Ensure the effort of your teammates is visible. The more you acknowledge their work, the more they will want to work for you. Even if you are not grateful, or wanting to give thanks, you can still acknowledge the effort someone has invested in their tasks.
  16. 16. Language matters. Project management truism. We had been referring to our launchable site as a "Minimum Viable Product". It didn't resonate with the team, who wanted to create something better than something which was just barely good enough. We changed our language to remove the loaded phrase. In our ticketing system, we updated the backlog title to be "Launch Blocker Backlog" instead of "MVP Backlog" and pride emerged from the team for the product they were working on.
  17. 17. Minor choice makes a major difference. Project management truism. When I was first given the job of "loading sprints", I assumed I was supposed to pick tasks for people. No one told me otherwise. I'd load up the sprints and send out assignments and would be met with the abyss. When we changed to everyone choosing their own tickets from a prioritized list, sprint loading became more dynamic and people had only themselves to blame if they didn't enjoy their tasks. It still takes me about 1.5 days to close a sprint and prepare the next one, but people seem to enjoy their work more during the sprint.
  18. 18. 2. Find your gremlins sooner
 by deploying features
 from start to finish. Managing Projects the Drupal Way (this is a header slide; don’t dwell!) Deploy Features from start to finish with cross-functional teams. In other words: be agile.
  19. 19. Prototype Component Design Component Build Custom Development Content Migration Theming Deployment Infra-
 structure Let me show you what I mean by this. I’ve got a typical assembly line that we’d use for a website project. This is displayed in a linear fashion, but it really isn’t a linear process. - Infrastructure may include setting up your local environment, dev server, and prod server. - Prototyping: if you can, prototype in Drupal (plan to throw it all away), but figure out where the snake pits are. Prototyping in HTML can be misleading because it can be very difficult to bring that HTML / CSS back into Drupal if it wasn’t created by someone who thinks like Drupal. - Component design: work in the smaller widgets and think about how they may work as interchangeable elements throughout the site. e.g. style tile; KSS style guide. You can get the theme and the designer working together quite early on. - Component build: site building. The point-and-click of views. Display formatters. Contrib modules are probably introduced at this point. - Custom development. Only now and finally are we starting on custom development. If your developer starts by saying that it’s all custom: question them. There are 30,000 modules. It’s highly unlikely there isn’t a starting point *somewhere*. Note: I include front end dev and back end dev here. - Content migration. This is where things start to fall down, because really you want to have been working on content migration for ages by the time you get here. Getting the content into the site sooner helps you confirm your data model and interactions throughout the site. - Theming: the custom theme / templates needed to display your content. At this point you need to finalise how all of the components are built into the site. You might end up using Panels or Context at this point. - Deployment: we’re back to infrastructure again. But now we need to also be thinking about our Git branches and tagged releases and how we separate the code into “in progress” and “fully tested” and “deployed on production”. GitFlow is quite common. Ask your developers early to write down their process for deploying code. Figure out how you’re going to track the deployment information in your ticket tracker. Document, document, document. You never want someone to be attempting a system restore without careful step-by-step instructions.
  20. 20. How long? • Developers know best. 
 But multiply it by 2 (and by 2 again). • On-boarding takes a week longer 
 than you think it should. • Sprints of 1-2 weeks are generally “about right”. • Half way through your project; 
 local environments will mysteriously break. • The “last mile” takes three weeks longer 
 than it should because of regressions and Features. - Why not multiple by four? Because on most projects you’d 2x an estimate. But the Drupal factor gives it a 2x again. Not because it’s harder to build things in Drupal, but because sometimes things are fragile in unexpected ways. - On-boarding includes the beginning of the project, and also if you bring anyone in mid-stream. Getting everyone on-boarded at the very beginning (instead of on boarding a themer towards the end will help with velocity because they’re all losing the same week). - Most software nerds like to run the latest and greatest. Often these software updates are happening automatically in the background. It’s inevitable that something will mysteriously break. This can also be due to upgrading Drupal modules because of security releases. - The more you pile into Features the more it seems to drop things on export. This is extremely frustrating and developers can lose whole days to a Feature export which has failed (you ticked all the boxes but it still didn’t export all of the elements). And yet: it’s the best thing we have for Drupal 7. Drupal 8 will be better.
  21. 21. Adrenaline is finite. Project management truism. When I first started on the project, we kept making optimistic, arbitrary launch dates. Being our own client, we could make whatever deadlines we wanted. "In time for DrupalCon." "At the end of July." We had no empirical data to suggest these deadlines were possible. Shifting deadlines are exhausting and we were burning ourselves out. As soon as we removed the arbitrary dates, people were able to enjoy their tasks a little more instead of constantly feeling a time pressure. This made people happier.
  22. 22. Closure is important. Project management truism. Originally we worked on two week sprints. At the end of a sprint, any ticket that wasn't completed lingered in an old sprint. Based on a comment from James Sansbury about one of his projects we changed how sprints were loaded and completed. Each sprint is now only a week long. At the end of the week, the old sprint is closed. Outstanding tickets are moved to the current sprint. Anyone is allowed to put an unfinished ticket into the backlog. No shame; no blame. We begin fresh today and move constantly forward.
  23. 23. 3. Build re-usable components, and all their variants, from content “out”. Managing Projects the Drupal Way (this is a header slide; don’t dwell!)
  24. 24. Layout Functionality Component Content The basic Drupal development workflow (from a developer's perspective, but without using developer jargon). Content: what are you going to store in the site; and where does that content come from.
 In Drupal terms: what are your content types (entities); and what are the taxonomies used to categorise that content? Component: when content appears, how is it listed? Does more/less of it appear when in different contexts?
 In Drupal terms: what are your Views? What are the Display formatters for the fields? Functionality: can I interact with the context around that content? Can I add comments? Bookmark? Buy? What else can I *do* in addition to reading / scrolling? In Drupal terms: What are the additional contributed / custom modules you need to install to make the site “behave” / “work” appropriately for site visitors? Layout: How do the components fit together on the page? Are different layouts available for different screen widths? Are there different context for different user permissions?
 In Drupal terms: Base themes, Context, Panels, and conditional rendering of objects on the page. When we see the cluster like this, you can understand why functionality is sometimes separated from theming. But I think that’s a mistake to build it in isolation. Working on smaller, components--with all their variations--will make the individual components more robust, and better able to adapt to different view port sizes.
  25. 25. 4. Emulate (some parts)
 of the drupal.org
 issue queue. Managing Projects the Drupal Way (this is a header slide; don’t dwell!) • Allow the description to be updated, so that it includes a summary of comments. • Use a template for the summary description. • Push all conversation into the issue itself. • Attach relevant assets (wireframes, diagrams, visuals). • Use keyword tagging from a controlled vocabulary. • Standardised your format; but also allow room for one-offs. The 3Cs from Agile work well. Except when they don’t. Drupalize.Me had a QA “test” as the required first line of every ticket. These lines were copied and pasted in the deployment checklist for the week (and sometimes automated). • Groom the backlog frequently. No matter what tickets you write, you will miss some things, and duplicate others. • Push conversations, and their artefacts, into tickets. Diagrams, testing notes, conclusions from discussions.
  26. 26. Card: 
 Define testable outcomes.
 Demonstrate business value.
  27. 27. As a ___ I want to ___ so that I ___. For example: 
 As a user, I want to filter the search results
 so that I can more easily find people with the verified role assignment.
  28. 28. Conversation:
 Centralise, and be flexible. - drupal.org does this really, really well. - Be descriptive; not prescriptive. - Provide annotated screen shots; and screen casts of the problem. - Allow for alternate interpretations of the conversation so long as it accomplishes the user story. - Get the conversation out of email. Issues are tracked in the queue, not in email. - Being descriptive is REALLY damn hard as a recovering developer. - Be as detailed as you can in the description of the problem. Including screen shots can help the dev to replicate the problem and then figure out how to “recover” things. If they can’t replicate it, they may be able to come back to you and see if it’s problem on *your* local environment. - Not just “it doesn’t work” but *how* it doesn’t work.
  29. 29. Confirmation: Test, test, and test again. - Provide step-by-step testing instructions
 in support of the user story as soon as the story is written. - Require testing notes and screen shots (of what it should look like) from the developers. - Peer review the code; user test the functionality. - The testing steps help set the developer up for success: they know exactly the sequence you’re expecting to take to accomplish the task, so they can make sure the workflow / sequence works before asking for a code review (and then QA). - Step-by-step instructions help non-SMEs work efficiently on testing. You don’t need to know the system inside to just click through the test. - The steps may be helpful in the development of automated tests as well. - The screen shots help you to immediately see if there has been a problem with the Features export. If it doesn’t look right, the QA person can immediately stop and go back to the developer to see if they need to re-export the Feature.
  30. 30. Sort for yourself;
 format for others. Project management truism. I love spreadsheets. I assumed everyone else did too. They don't. Who knew? Instead of creating spreadsheets to share with others, I now create summaries with markdown within our ticketing system. Now that the team receives the content in their preferred format, I find them more likely to engage in conversation about it.
  31. 31. Moderate what you change; including your moderation. Project management truism. At first I found the lack of feedback on my processes really difficult. I didn't know how to evaluate if I was implementing good changes or bad changes. So I'd change my approach. Frequently. This made it very difficult for people to track what a week's process was supposed to be. Finally we threw it all out and started again. Consciously. Any changes we make are now immediately documented in a centralized guide. The guide is a trusted document, but also not so holy that it cannot be changed if the documented procedures are not helping the team accomplish their tasks.
  32. 32. Drupal PM Survival Guide 1. Foster collaborative, cross-functional teams
 who stay with you for the entire project. 2. Find your gremlins sooner by deploying features
 from start to finish. 3. Build re-usable components, 
 and all their variants, from content “out”. 4. Emulate the drupal.org issue queue.
  33. 33. Resources • A Developer’s Primer To Managing Developers
 https://austin2014.drupal.org/session/developers-primer-managing-developers.html • Things I Learned From Managing my First Project
 https://drupalize.me/blog/201312/things-i-learned-managing-my-first-project • Avoiding the Git of Despair
 https://events.drupal.org/losangeles2015/sessions/avoiding-git- despair • Git for Teams
 http://www.gitforteams.com
  34. 34. Books • User Story Mapping -- Jeff Patton • Agile Product Management with Scrum -- Roman Pichler • Essential Scrum -- Kenneth Rubin • Scrum Shortcuts -- Ilan Goldstein • Fifty Quick Ideas to Improve Your User Stories -- Gojko Adzic • User Stories Applied -- Mike Cohn
  35. 35. Managing a Project The Drupal Way @emmajanehw www.gitforteams.com

×