17. Marcus Vitruvius Pollio
• 1st Century BC Architect
Christopher Wren
• 17th and 18th Century AD Architect
Thomas Telford
• 18th and 19th Century AD Architect
22. Modern
Project CPM and PERT
Management
Really began in the 1950s
Defense and Civil Engineering
Critical Path Method, Program Evaluation and Review
Technique evolved
26. Cowboy or Extreme
• Highly informal
• Focuses on Stakeholders
• Can be used in very unpredictable projects
Roy Montgomery
• Can be excellent for rapid prototyping on flickr
30. Agile
• Defined Timeboxes
• Iterative Development Methods
• Incremental
• Collaborative Requirements and Solutions
• Rapid and Flexible Responsive to Change
• Self Organizing Teams
31. We NEED
Project
Management
for Successful
Outcomes.
b4b2 on Flickr
32. • I had a client a couple of months ago call me at 6:30 in the morning yelling and
screaming because his site had been down for over an hour.. I drag myself out of
bed, get to the computer and his site comes right up... I told him to try to get on
Google. Guess what? According to him Google was down too. I politely told him to
call his internet provider because that was down and once his internet came back
up to use it to search for a new developer.
• I had a project that had multiple decision makers. They wouldn't move forward
unless they all agreed on any one point. And they couldn't agree on anything.
• Drunk guy I met one time: "Oh, you make sites? Let's make something like
Facebook and earn alot of money! I'll come up with ideas and you make it. Got any
suggestions? Yeah, we need something like Facebook so we'll be rich! You go make
it!"
• The client doesn't know what they want, so they spend endless hours in meetings
with you "throwing ideas around". Then, despite the warnings that they were
consuming their contracted hours in this fashion, insist that they shouldn't have to
pay for the time because the site still hasn't been built.
33. Lack of Planning
Lack of Communication
Lack of Process
make for nightmares for
Lack of Focus (internal
us, our partners
Differences in CULTURE
and external), They bring
us to an Open Sourced
“Arkham”... and we feel...
34. make for nightmares for
us, our partners (internal
and external), They bring
us to an Open Sourced
“Arkham”... and we feel...
42. Product
Owns Backlog
Personas, Epics, and Stories
Answers questions that Clarify Business Needs
Demos Software at the End of Sprint
43. Project Management
Acts as Scrum Master
Leads Pointing Stories
Protects Dev Team from Distractions During Coding
Ensures that the Team Doesn’t Make Mistakes
Manages the Schedule
44. Developers
Self Organizes Selected Stories
Decides What Can/Can’t be Completed in the Timebox
DEFINES the Implementation of Business Needs
Executes
45. Examiner’s Timebox
Timeline
• 60 days - Business Requirements
• 40 days - User Stories, Wireframes, Comps
• 20 days - Beginning of Current
Development cycle
-- Thanks for inviting me to come to speak today\n-- Thanks to Examiner.com for supporting my travel\n-- My remarks today are going to focus on Process and Project Management but I must admit that after conversations last night, I have made some last minute adjustments to this presentation. Bear with me.\n
-- Examiner is a giant drupal site - somewhere in the neighborhood of 9 million nodes at this point. ~2000-3000 new articles produced per day and ~6000-7000 media nodes (photos and videos) per day.\n-- Use a hybrid approach of MySQL and MongoDB across multiple Web heads with a load balancer and redundant failover slave databases. \n-- Cat Herder\n-- Bridge Between Product and Development\n\n
-- introduce different areas\n-- indicate it is fine to contact me\n-- slides will be posted to dogstar.org for sure, believe they will be on camp website too\n-- feel free to follow me on G+ and Twitter. I tweet, mostly, about Drupal stuff - but you may occasionally hear about great food or drink and travel.\n\n\n
Tweet questions or anything else you might want to share.\n
-- On organizing committee for Drupalcon Denver as Customer Service Manager\n-- Engaged in Volunteer coordination with my partner in crime Vordude. Matt - you want to stand up?\n-- Starting to line up the volunteers we will need for conference - find me or Matt if interested\n-- signup sheet on groups.drupal.org denver meetup page\n\n
-- Worked in Technical Theatre - Stage Management and Lighting\n-- Nonprofit Management - Technology and Grantmaking\n-- Marketing, Books, Web, Worked in a Wine Store, Taught University\n-- Have a bunch of letters after my name like BA, Cert AA and MFA\n
-- Several of sites with Western States Arts Federation - little history of custom PHP MySQL apps there -- distributed team of developers. ArtJob online, Culturegrants Online, artist adjudication\n-- Ton of sites with pingVision before the company closed\n-- Several sites with Vintage Digital LLC\n-- One GIANT migration of a site from Cold Fusion to Drupal 7 before Drupal 7 was much more than a twinkle in our eyes\n\n
-- From 1999 - 2007 I worked in the nonprofit industry building custom PHP MySQL applications. I’m not a programmer - I managed the builds and directed others.\n-- A happenstance encounter had me learning about Drupal while at a meeting in Vancouver in 2006 and that began a transformation\n-- In 2007 - I was a little Cuckoo egg that had been dropped into the nest of a bunch of Drupal birds - that nest was the community. When I popped out of the egg - it was immediately clear to all that I was something different. But that was embraced and I was mentored in the culture of the community. And it is an odd culture of self starting, but supporting, and we criticize one another but hopefully in a collegial way.\n - To the outside world, we communicate in funny ways and that can lead to conflict. I challenge you to embrace new people when they join our tribe. Welcome them and celebrate the differences they bring.\n
-- All my experiences have informed how I approach project management and process\n-- For example, retail taught me patience with difficult clients\n-- Stage Management taught me extreme organization and planning\n
-- Break presentation into three parts. 1) Some moments and people in Project Management 2) 3 PM Methodologies used at Examiner over the two years. 3) Examiner.com’s Process Today.\n--Examiner has had large shifts in its methodologies before settling on its current path.\n-- The moments in time will be arbitrary and I’m sure extraordinarily inaccurate. But they will serve as an illustration.\n
-- My #1 goal is to build cool things that people can use.\n-- #2 is that these things bring happiness to our clients and/or employers\n-- #3 I want to have fun - after all, that is one of the main reasons we are engaged here, right?\n-- Frankly it is really cool that we can make a living this way.\n
So, lets start from the very beginning.\n
--Cold and hungry and needed protection\n--To catch food, make fires, build shelters, and protect each other they had to build tools and work together. \n-- Needed, at worst, loose organization and cooperation. \n-- No planning, organization, cooperation, and goals to meet would have equaled the extinction of mankind. We are, in a very real sense, products of prehistoric project management.\n-- The ability to work together provided man with an advantage which has made us the dominant creature on the planet.\n
-- People built small structures, larger buildings, started organizing farms\n-- Built relationships improving interactions with with each other. \n-- candlestick makers, farmers, blacksmiths, artists, bakers\n-- This cooperation led to larger and more complex structures and we ended up with towering structures like...\n
Chichen Itza and...\n
The Great Pyramid of Giza -- It was estimated as needing between 20,000 and 30,000 labourers. -- Evidence of manifests for materials - but still not highly organized in the sense of modern day project management. -- It is likely that as materials were needed, orders were put forth for dressed stone, pack animals, slaves, timber etc. -- Seems unlikely that there would have been a constant supply that met the specific needs of the builder which implies there would have been periods of inactivity and periods of tremendous productivity\n\n
-- The concept of project management was spearheaded by architectural engineers. Folks like Pollio (in the 1st century - De Architectura - a treatise on architecture) beginning of PM. Often thought of as the world’s first engineer.\n--Wren - incredibly acclaimed architect responsible for rebuilding many churches after the great London fire in the 1600s. He became the nation’s Surveyor General. \n-- Telford - scottish architect and civil engineer. Known for Bridges and raised canals. \nThese gents helped drive the idea of organization around an end goal of baths, villas, churches, bridges and raised canals. All these required a great deal of coordination of fine details. \n-- Still, we hadn’t reached the point of accurately estimating the resources needed for a project. Much of the process was ad hoc.\n
We were able to produce some magnificent structures that survive until today. This is a testament to our ingenuity. We are a clever creature.\n
--These weaknesses were recognized by Henry Gantt. He moved us closer to our concept of modern project management through invention of the Gantt chart in 1917. To this day, software development makes use of Gantt charting. \n-- How many folks here have used Gantt charts in your planning? \n--This methodology was used in major infrastructure projects to identify dependencies and track estimated time. They were used in giant projects like...\n
Hoover Dam\n
--Interstate Highway System\n--Which leads us to modern project management.\n--It may not surprise you that the defense industry is largely responsible for many of the PM methodologies used today.\n
--Defense and Civil Engineer made use of information/intelligence from the second world war to develop ways to path projects to provide highly accurate resource and time estimate.\n--This saw the development of a large number of projects related to planes, rockets, and complex technology required by the US Air Force and Navy\nnuts bolts\nfiddly bits\n
-- PERT chart - milestones, time, and transition states.\n-- Illustrates alternate paths and dependencies\n-- Facilitates decision making\n-- Arrows are activities and time.\n-- First used in the 50’s by the Navy working on the Polaris missile project\n\n\n
-- There are three main project management methodologies I’m going to talk about\n-- Main reason, they all have been used in one way or another in my time with Examiner\n-- Learned from each one and how they can inform our own method of managing projects\n\n
--First Phase of our development methodologies was cowboy\n--can be extremely unpredictable\n--very fast\n--A great deal of trust needs to exist between developers and stakeholders. Can lead to miscommunication of expectations.\n--Drupal management tools out of the box, very different than the custom tools build for the company in Cold Fusion\n\n\n\n
-- Examiner’s Big Giant Project involved migration to D7 - not just a redesign, but a migration of what would become 7 million nodes across multiple media types, 200K users\n-- Requirements - Very detailed and not really Drupally. Gantt charting the project as it stood indicated an 18 month project. Needed to complete for public launch in 7-9 months. So we had to cut corners and work incredibly fast.\n\n\n
-- The pendulum swung after we launched from being cowboy with the high unpredictability and speed to the predictability that waterfall brings. Much slower. Not great for a company with a fair bit of risk tolerance who wanted to see things happen.\n
-- Who has worked in Waterfall?\n-- Have any of you ever had a project that was fixed scope and the scope truly didn’t change?\n-- Waterfall, in its purist state is a pipe dream\n-- Some may disagree with me, but I think waterfall tends to not work extremely well with Drupal projects - new community code always popping up\n-- At Examiner, requirements dictated weren’t very inclusive with the Dev team. Order takers rather than active participants. Scope often shifted in the middle of working on a set of features. All of these factors made Waterfall not appealing.\n
--So we went from embracing rapid development with an enormous tolerance for risk and change to not having much choice with rigid requirements with slow progress. Neither was particularly desirable.\n--Agile requires that we weave, that we move, that we be flexible - but there be predictability in a single timebox as to the deliverables.\n
So what is an agile process?\n
-- In any of these methodologies we need PM for successful outcomes. \n-- To illustrate this, I put out a call for stories on my blog. It was tweeted, and facebooked, and G+ed\n-- got about 30 responses on dogstar.org, twitter, G+, and private email messages.\n-- ranged from complaints on support for modules, to concern about undocumented code, to client stories.\n-- 4 stood out as GEMS - and underlined needs we have as development teams\n\n
1) Sadly pretty common. Need trust and empathy between development team and the client (internal or external). Both dev and client need to be active listeners. \n2) Again, common. Indecision is crippling.\n3) I think it is important to note that there are BAD clients. This happens quite a bit in agency land - the client that really thinks you should “make him rich”\n4) How many have had a similar situation?\nAll this comes back to process - schedules - expectations for both the client and the vendor.\n\n
\n
like we’re being drawn into a HP Lovecraft novel. We look into that darkness and see...\n
You might find this familiar. This is the emotional state your find yourself in when the client is throwing around different contrib modules that you know won’t work. The place where the client assumes that something is easy or won’t take much time - but that is just never true. The place where you wonder if you ever will have the chance to actually build something. When you realise the project state is constantly in flux. Change is the norm. Predictability has evaporated.\n
Our job is to communicate, to translate, to mediate\nOur job is to unblock\nOur job is to bring calm from chaos\n
--WE ARE THE cat herder - but not just of developers and themers, but also of product owners, business owners and clients\n--Keep the communication running\n--Keep the ducks in a row\n--And above all...\n\n
--You must help your team avoid shiny pretty things that distract during your sprints.\n--How many of you, in the middle of a coding sprint, have been asked to add just this one little bauble - “really, it will make the site SO much better and surely it can’t take THAT long.”\n
-- All this requires STRONG communication across your working unit. Across your company. With the client.\n-- Who knows why manhole covers are really heavy and round?\n-- To prevent folks from falling down them. It behooves use to use clear communication to prevent ourselves, our clients, our colleagues from falling down dangerous holes.\n
-- Phase I in my tenure, cowboy. Fast, but caused problems with expectation gaps between the business and the team. Volatile. Not much predictability.\n-- Phase II - Attempt at waterfall. Slow, change was inevitable - often in the middle of a project. Requirements often fought what Drupal does naturally. Lots of dictating to the dev team what should be done. Developers became order takers and not active participants.\n-- Phase III - Hybrid Agile Approach - this is the focus of the rest of this talk. This is high level, not going to get into all the details.\n
-- Our unit is comprised of product, creative, qa, and development. The team is mixed of local and distributed. Colorado, British Columbia, Hungary, Slovenia, Virginia, Texas\n-- Distributed teams have their own challenges and advantages.\n\n
-- communication conduit between business and development group\n
\n
\n
The timeline is broken into three distinct overlapping parts. Business requirements, Story Development, Development\n
Includes everything for the NEXT timebox. Days 3 through 12 are Story Creation and Wireframes. Days 13 - 18 Meetings, Comps, final delivery of Epics, and Stories. Day 19 is the next Timebox LOCKDOWN.\n
Development Cycle - 2 days of technical planning, 10 days of intense coding, 6 days of testing and reworking, Deployment and Drupal Day (as we can manage), Demo and Retrospective. Talk about the two deployments.\n
60 - 40 - 20 overlap. There are activities going on across all these different phases in a single timebox. The backlog continues to be developed, the stories and supporting artifacts are being constructed, code is being written.\n
The deliverables are added to the team’s Google Calendars.\nEVERYTHING in future timeboxes are negotiable. Until day 19, when the next timebox’s development tasks are locked down, it can change. Once we hit day 19, we try to have no further change.\n
-- Scrums are broken into feature teams. Currently we have 3 feature teams.\n-- Have Bug Triage Scrums once a week or so\n
The Examiner Toolbox\n
logged channels\n\n
Tracking tools\n--green, yellow, white, pink\n-- Story ID, Priority, Where it lives, its story, notes, feedback, comp?, timing, ticket number, LOE, Lead Dev, themer, QA, product\n
Ticketing through Trac (moving to Jira with Greenhopper now), Version control using Git, Deployments using Jenkins, Jing, Skitch, Screenflow for screen captures, Google for managing user stories, Drupal for logging our IRC channel(s).\n
-- By adopting a more agile process, we have found ourselves able to deliver working code more quickly. We aren’t overburdened by specific requirements, but focus on the business needs trusting that the Scrum teams will deliver product that fits the needs of the business.\n-- It has taken 2 years to get to this point. We continue to shape the process each timebox by focusing on lessons learned.\n
If folks would like to continue this conversation and talk about specific tools and strategy, I’d be happy to meet informally this afternoon and find a room or a corner. Just nab me.\n