After conducting two sprints with a consecutive testperiod, where everything did not end up the way we wanted it to be, we found it to be a good time to do some retrospective. Of course, this should be done after each sprint, and to a certain extent it has. However, we had much to talk about after this delivery. Here’s an example of our retrospective
(more…)
After attending a Certified Scrum Master Training session, the discussion about the difference between the Scrum Master and a “traditional” project manager raged long with many good arguments. The part that most people from the “old school” had problems with was the fact that the Scrum Master is without authority! The only way a Scrum Master can force a project result is through good coaching and to make sure all impediments are removed so the team has nowhere to hide. The rest is up to the team (and some praying maybe?). But what kind of project managers fit into the Scrum Master role?
One of the least mentioned roles, but an important support character, can and should in fact be the leading actor in an agile project. After all, the product owner is calling the shots. And a simple decision from a product owner can mean hundreds of working hours avoided, or added, to a project. A product owner can be a teams best friend of fiercest foe. Here’s a mock-up on successful product ownership:
I just came across this video that just made sense. Like all agile evangelist I buy into the test driven development. And like most people I find myself trading between the amount of extra work of writing tests to the actual code and implementation of the task at hand. Other issues are where to put the tests and how to organize these tests. But behavior driven development gave me some answers:
Two practices from two different methodologies: user stories are an emphasis in extreme programming, while features is the mainstay in feature driven development. They both present strength and weaknesses. But aren’t they really related?
I just came over a pretty good boundle of links, which serves as an introduction to agile. It has a Microsoft.Net aura to it (coming from theserverside.net) but should still apply to all agile fans out there: http://www.theserverside.net/tt/articles/showarticle.tss?id=AgileResources
Instead of putting them up against each other, why don’t we think of them combined? In fact, combining the two words I like the best within software, Agile and Architecture, (oh, the phrase “it works!” is still my favourite though), an Agile Architect seems like a pretty good role to have on board! But what are the characteristics of an Agile Architect?
I came over a blog talking about being a software architect in an agile world (codebetter.com/…). Agile missionaries weren’t very fond of the term “architect” as it too many times ment a person drawing up som schemes for the developers to implement, a part of the waterfall-dinosaur development process, soon to be extinct. Still, is there a place for architects in todays software development?
So, there you are, the iteration is on and you get assigned / choose a task for you to do. Some project manager has decided what tasks should fill this iteration and it’s up to you, the developer, to come through with a solution. As a developer you have to relate to several parameters:
To answer these questions, agile development introduce the DOMAIN WALKTHROUGH