When faced with the challenges of managing a growing email marketing software and 40-person development team, AWeber turned to the project management system Kanban. In this presentation with Ethan McCreadie and Philip Cristiano, they shared AWeber's journey into Kanban, how it functions within AWeber's team structure, and the advantages and disadvantages other companies should take into consideration before implementing the system.
This talk was given on April 24 as part of the 2012 Philly Tech Week (www.phillytechweek.com).
26. Wish List: No Data
Entry
• Manually entering data into Google docs
• Integrate Kanban with issue tracking
software
27. Issue: Project Count
• No limit to the number of projects in
progress
• Each person focuses on their own project
28. Retrospective
• 40 people is too much for a single card wall
Looking into sub-boards by:
• project
• stakeholder (devs, CEO, education)
• code domain
29. Before We Used Kanban
• Poor visibility into projects
• Repeated missed deadlines
• Incorrect feature implementation
31. Join Us
1516 Sansom St.
Philadelphia, PA 19102
Notes de l'éditeur
AWeber provides web-based email marketing and social media software to:\nentrepreneurs, businesses and nonprofits\n\npoll: who is a developer / project manager / designer / other\n\nPlease interrupt us with questions at any time\n
we’re just a couple of devs\n\nintroducing philip cristiano, previous kanban experience\n\nintroducing ethan mick-cred-eeee, project-lead experience\n\nstarted Kanban in September 2010\n\n1.5 years doing this\n
Kanban - sign, billboard, signal\n\nBreak projects down into tasks\n
\n
about as simple of a board as you can get\n\nuse a physical board\n
describe Kanban\n\nkaizen - “improvement”, continuous process improvement\n\n\n\n
TOYOTA! First applied in 1953 after watching supermarkets - toyota production system\n\nPull cards through the board / focus on prioritization over deadlines\n\nDon’t need all project cards to be done before shipping\n\n\n
Visualize productivity\n
Visualization becomes the expectation\n\nIncreased productivity\n\nHigher quality product because each task is a first-class citizen\n
Benefits happen naturally\n
Agile is a set of goals or ideals\n\nIndividuals and interactions over processes and tools\nWorking software over comprehensive documentation\nCustomer collaboration over contract negotiation\nResponding to change over following a plan\n\n
project was due but no where near ready\n\nmanagement didn't know\n\nturns our there was no visibility or accurate estimates\n\n
our initial approach - first attempt Small projects - 4/5 people wordpress plugin\n\nNEXT SLIDE: Kanban for small groups\n
Very useful easy to get small groups on the same page\n\nCameron story: He didn't have a choice.\n\nFeeling of completion\n
4 days for cards\n\nscaling up Kanban doesn’t mean larger work items\n
Couldn’t force 20+ people the way we strong-armed Cameron\n\nmention standup\n\neventually ~25 developers, (plus management, designers, education)\n
ladies and gentlemen, this image is not an affiliate link\n\nhad weekly meetings to work through the book \n
mapping our workflow (chapter 6) \n\nlots of OH SHIT / CEO peeking in\n\nlots of firefighting - coming from ops\n
webops creates cards for any significant (20 min+) item\n\navoid firefighting\n
columns - ANALYSIS / elaboration & acceptance\n\ntrash\n\nwip limits\n\n3rd-party rail\n
We need to limit what a single person can work on. \n\nprimary/secondary per card as mentioned in continuous delivery\n\nneed project limits (~25 developers, 8 projects)\n
started measuring work item delivery\n\nadd new cards / re-adjust queue everyday\n\ninput queue replenishment meetings\n\nmost queues are currently working through a backlog\n
record CFD daily with Google docs\n\ndrop of TODO items is a result from pruning\n
noticed that 60% of our work items were maintenance\n\ndevelopers would become distracted from feature development\n\nwebops team, significant developer work becomes a card\n\nless shit hitting the fan (although still a lot of maintenance items)\n
Etrik has to count a lot, we don't have a single electronic ticketing system in use (trac/github per project) * Column limits hinder people who are making progress by people who are not even though they could do nothing to help (swimlanes)\n
We don't know how many projects are in progress by looking at the board * We don't set priorities for cards, lack of stackholders\n
\n
poor visibility: much better visibility\n\nmissed deadlines: visibility helps a lot\n\nincorrect implementation: \nexplicit analysis of done state\nless WIP -> less inventory (features going stale before release)\n\n