rose.pruyne

I just published this article at plone.org on Andreas Mantke, a deputy member of the Board of Directors of the Document Foundation for LibreOffice . Mantke led a workshop for new Plone site administrators in the LibreOffice community during its annual conference last week. See the full article at plone.org/news/andreas-mantke-to-lead-site-administration-workshop .

I recently wrote this article for plone.org about the University of California, Los Angeles Diazo Work Group that collaborated with other members of the Plone community to improve Plone’s Diazo UI. Read the full article at  plone.org/news/ui-project-leads-to-significant-improvements-in-plone-4.3-theme-editor .

About 30 members of the Plone community participated in a 3-day sprint at WebLion , following Plone Symposium East 2012 . We worked on PloneEdu, Plone Installation on Windows, ZopeSkel Documentation, Plone Accessibility, a promising new product called plone.app.toolbar, and a follow-up dose of Code Cleanup and Removal. Thanks to Steve McMahon for leading our sprint; to team captains Kim Nguyen, Ross Patterson, Cris Ewing, Matt Barkau, Nathan Van Gheem, and Eric Steele; and finally, to Mark Corum and Rob Porter for...um...naming this the Hot! Hot! Hot! Sprint. Here are the teams and what we accomplished: PloneEdu Plans include fresh content, a site facelift, and new hosting for PloneEdu , a resource for educational institutions using Plone. Team: Kim Nguyen, Mark Corum, Rob Porter, Chris Thomas, Brian Davis, William Fennie,  Prathmesh Mengane, Greg O'Toole Accomplishments: Defined the PloneEdu audience Made plans to migrate the site's hosting to Osh

We adopted Agile in WebLion in January 2011, using Agile Software Development with Scrum as our first guide. before agile Before making this change, we were highly collaborative in our own way. But we lacked the structured cohesiveness that Agile brings. We had no systematic process for vetting one another's work, no way of identifying when a task was truly done . And — I don't like admitting this — we worked alone or in pairs way too much. agile resources in the webLion wiki: http://socuteurl.com/freshykissymidgypiggy Add to this all of our projects. These varied enough in nature and complexity to make it difficult to distinguish priorities, dependencies, and monsters that might bite. Our self-taught foray into Agile served us pretty well. We were getting better at requirements collecting, time estimation, sorting out dependencies... But the big change came in August 2011, when we took a NetObjectives course on Lean-Agile with Scrum . Today, we are more L

Capturing requirements in Agile stories is finicky business. Stories need to be just the right size and shape, have the right bits of detail, point to a clear outcome. They must capture the who, what, and why in a way that speaks unequivocally to the user and to the team. Badly written user stories will slow down your team in any number of ways. A few recommendations... Get the right people writing the story. Even if you've done lots of requirements gathering, or the functionality seems like a no-brainer, don't assume that you have sufficient information to compose stories without stakeholder participation. In fact if at all possible, the stakeholders should do the writing. You are there to ask questions and help clarify. Without this collaboration, you will end up going into iteration planning with hobgoblins, not real stories. The team then must devote time to figuring out what's actually needed, returning to the stakeholder with lots of questions, rewriting and

transparency is undeniably more efficient. Developing products on your own with inadequate checks and balances for long stretches of time might seem acceptable, or even cool, for a while -- if you're inexperienced or a cowboy. But in reality, it's a burdensome and buggy process. It's rife with questionable decisions, bad habits, and shortcuts. Egos get tied too closely with methods and products. Change causes pain. Troubleshooting and maintenance becomes a real killer. And pity those who inherit the lone wolf's pile of work later on. Lean-Agile's systematic approach helps ensure that the entire team is aware of what is being worked on and how the work is progressing. Tracking tools (we use FogBugz to good effect), Kanban boards, incremental unit- and acceptance-testing, daily standups, iteration planning sessions, retrospectives, and vigilant facilitation at each point in the process help to keep team members from straying off course or going underground.