8. We NEED
Project
Management
for Successful
Outcomes.
b4b2 on Flickr
9. • 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.
10. 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...
11. make for nightmares for
us, our partners (internal
and external), They bring
us to an Open Sourced
“Arkham”... and we feel...
19. 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
29. 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
30. Product
Owns Backlog
Personas, Epics, and Stories
Answers questions that Clarify Business Needs
Demos Software at the End of Sprint
31. Developers
Self Organizes Selected Stories
Decides What Can/Can’t be Completed in
the Timebox
DEFINES the Implementation of
Business Needs
Executes
32. This Next Model Works Well
For Projects with a Long
Timeline
33. A Sample Timebox Timeline
60 days - Business Requirements
40 days - User Stories, Wireframes,
Comps
20 days - Beginning of Current
Development cycle
MS:\nTweet questions or anything else you might want to share.\n
MS:\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\n
MS:-- 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
MS:\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
MS:\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
\n\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\n\n\n
MS:\nOur job is to communicate, to translate, to mediate\nOur job is to unblock\nOur job is to bring calm from chaos\nOur job is to make everyone else’s jobs easier. \nTo simplify the complex. \nIf we are being successful, there will be times when things appear to be running smoothly entirely their own. “Why do we need project managers?” Don’t be fooled...\n\n
MS:\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
MS:\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-- How often have you heard the five lethal words, “How hard can it be?”\n
MS:\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 us to use clear communication to prevent ourselves, our clients, our colleagues from falling down dangerous holes.\n-- 90% of project management is communication. Not just us communicating out, it’s setting up the space and framework that allows the team to most effectively communicate with each other. And it’s LISTENING. Listening for the underlying message. Listening for the unspoken message.\n
MS:-- There are three main project management methodologies I’m going to talk about\n-- I have used them all in my career with varying degrees of success \n-- Learned from each one and how they can inform our own method of managing projects\n\n
MS:\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\n\n\n
EXAMPLE\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--Cowboy, for projects like this - if there is trust, can be quite effective.\n\n\n
MS:\n-- Waterfall sacrifices speed for predictability. 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-- Waterfall often has requirements dictated. Can make for a not very inclusive experience with the Dev team. Order takers rather than active participants. Scope can often shif in the middle of working on a set of features. \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
\nIn waterfall, there can be a tendency for a client to become impatient - this can lead to the mis-step of developing before you are ready. This ends up creating a munged methodology feel something like this. PLAN BUT HURRY UP.\n
\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
MS:\nSo what is an agile process?\n
MS:\n-- Phase I 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
\nYou can imagine that after months of the stress of these two conflicting approaches, the teams can fracture and cease to work as a cohesive unit: \n\n--no traction\n--lack of trust\n--frustration among the departments. \n\nThis was not a high-functioning team. \n\n
\nAnd when I say “us” I mean the whole team was involved in setting up the new process. Everyone was REQUIRED to give input and bring their expertise to the table from the get go. \n\nAny team-based methodology really only works when it has contribution, buy-in and ownership for the new process. \n\nAs project managers, our job was to set a framework, and then allow the team to help organically build upon that framework to support its own unique needs. \n\nNo two teams or companies are exactly alike, nor do they have the same needs, which is why every “hybrid-agile” methodology tends to be unique.\n\n
\nIn the book Outliers, Malcolm Gladwell \n-- A number of commercial flight crashes back in the nineties attributed:\n-- not to equipment malfunctions or severe environmental conditions \n>>> to communications constrained by the rules of social hierarchy \n- First Officers and engineers were not at ease to speak directly to the Captain about their concerns. \n\n--Planes were going down because people with expertise who could advise weren’t speaking up or being heard.\n\n--A strength of the Agile Methodology: \n--Yes, we all have our areas of expertise\n-- This is NOT a hierarchical system. \n\nOur job was to set up a methodology whereby the team would feel comfortable offering suggestions. It would be much easier to identify risks/unblock problems when feedback was built into:\n\n1) The system - VIA scrums, war room, retrospectives\n2) The culture\n--eliminating blame\n--owning mistakes\n--asking for feedback\n-- LISTENING\n\n
\n
-- communication conduit between business and development group\n-- Stories are developed well in advance of the sprint\n
\n
This assumes a 20 day (4 week sprint). It can just as easily be broken into two for a two week sprint. I’ve done both, each has different advantages and different shortcomings.\n
This assumes a 20 day (4 week sprint). It can just as easily be broken into two for a two week sprint. I’ve done both, each has different advantages and different shortcomings.\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\n\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 briefly about rapid deploy.\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 is 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
On the last day of the timebox:\nCompany-wide DEMONSTRATION on what team has built. \nWhy: \n1) The entire company knows development status\n2) it build respect\n3) Everyone knows how to use the products, or who to ask\nDirectly afterwards:\nThe production team holds a RETROSPECTIVE meeting. \n1) Team members have their feedback and suggestions heard\n2) PjMs are accountable that problems are being addressed from timebox to timebox.\n\n\n
-- Scrums are broken into feature teams. Currently we have 3 feature teams.\n-- Have Bug Triage Scrums once a week or so\n
-- What if you have many small projects?\n-- What if your timelines get disrupted because of immediate needs?\n-- You shouldn’t just throw the baby out with the bath water.\n-- Your planning cycles will be shorter.\n
\n
The 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, Google Hangouts, Join Me, 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\nWhat have we built using this methodology?  Among MANY other projects, A successful site redesign, the largest Drupal Mobile site in existence, a complex behaviorally-based rewards program for our 70,000 examiners.  \n\nOur team: High-performing, etc.\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