If you are given a problem to solve, how much does the presentation of that problem matter to your ability to solve it? Imagine that it’s a simple problem… imagine that it is presented in two different ways, both of them simple. It turns out that presentation differences can still make a huge difference. In fact, there is a way to present problems that makes them substantially easiers to solve: make them people problems.
Jeff Sutherland has announced a paper describing the use of the Scrum methodology in a large distributed project. One of the very interesting unique features of this project is that members of each Scrum team were distributed geographically across several locations., rather than having everyone on a single team all co-located at a location. The paper also talks about lean practices and software engineering practices used on the project.
Once in a while I run across a blog that I really like. This one, BrainScrum, doesn’t have frequent postings, but I _really_ like what’s there!
Take a peek at our new cheat sheet for Agile Work process facilitators (large PDF). This cheat sheet features a complete set of basic reference information for process facilitators including a great list of questions to ask oneself. There are also a number of colorful diagrams that quickly convey important tools for the process facilitator including methods of dealing with obstacles. We also have a poster-size version available for sale at the Agile Work shop.
The Agile Work Cheat Sheet has been updated. It can be found on the Berteig Consulting Inc. Agile Work Resources page. There are layout and formatting changes designed to make it easier to understand. There is also the addition of the seventh core Agile Work practice “Clear the Path”. If you are interested in poster-size color printed copies, please check out the Agile Advice store.
Sorry for the short notice: Tuesday May 16th I will be giving a short presentation (in Toronto) on the use of Agile methods in non-software environments. For more details see http://www.xptoronto.com/.
Due to personal reasons, I have lately been unable to keep up with Agile Advice. I’m looking forward to re-starting in a few days. Some things to look forward to include publication of a Cheat Sheet for process facilitators, and some announcements about two new sites with lots of great agile-related content. I’m also queuing up some interviews that I hope will be interesting to readers.
For over 40 years I have been developing, delivering and managing technical training for others. Finally, I’ve done this one for me. And I expect many others to follow. This course is both intensively conceptual and intensively hands-on workshop. The course is being delivered in Boston on May 18 and 19. See www.jconne.com for details. And read on here for more about this course.
In the Agile Dragon, Scott Sehlhorst, a software guy with a mechanical engineering background, has written a very interesting take on the agile approach vs. an approach called “Interaction Design“. While I love many of the ideas and even the results that come from good interaction design (check out The Inmates Are Running the Asylum for more info), I am very sceptical of Scott’s weak arguments about the weaknesses of agile.
Today I had a very interesting and unique opportunity. I went through my agile project management training materials with a single individual instead of a class. Was it training, or was it coaching?
I was recently asked: “where does Agile come from?” It’s easy to answer this on the surface: from software development. But digging a little deeper, there’s a lot more going on. This paper by Craig Larman and Victor Basili details a brief history of Iterative and Incremental Development [pdf] (focused a great deal on US military software history). The Agile Alliance is one of the better sources for articles, papers and other resources relating to the history of agile software development.