Something our team has wrestled with over the course of our agile adoption is how architecture and framework development fit into our Scrum process.  We strive to deliver an increment of functionality to our client at the conclusion of each sprint.  However, in many of our early sprints, we have to do architecture and framework development.  The things we develop on these types of architecture/functionality tasks are not really useable by our clients and we really can’t demo them either.  Brian Noyle recently wrote a post on his blog asking a similar question.  Read the rest of this post

Over the past two months, our development team has gone through a lot of changes…from joining a new company and setting up a new work environment to learning new technologies to serve our new clients.  In general, we were a desktop-based shop that focused on the ESRI desktop stack.  However, many of our new clients require web-based mapping applications.  As such, our team is currently climbing a very steep learning curve to work with a new set of technologies in a new environment.  More to the point, there are way more unknowns in what we’re currently doing than we’ve ever dealt with in the past.  Read the rest of this post

I was recently reading a short story by Jorge Luis Borges called “Funes the Memorius“. It’s a story about a man with the strange inability to forget.  He remembers every detail in his life, but he can’t distinguish between the trivial and the important.  He can’t prioritize and he can’t generalize. This made me think about product owners I’ve worked with in the past. They could not distinguish between the trivial and the important. They could not (or would not) prioritize or generalize.  Read the rest of this post

I was giving some thought to how to close out agile projects today and realized that because agile projects are managed in an iterative manner, closing a project should be a simple affair with no surprises. During the lifespan of the project, agile teams should be conducting product review sessions at the end of every two week iteration with their product owners. At the review sessions, the development team should present the functionality they developed in the previous iteration. During the review the product owner and other stakeholders should have the ability to comment on the functionality developed. These reviews allow the product owner to provide iterative acceptance of developed functionality.  Read the rest of this post