Flow to READY, Iterate to DONE
Posted by Serge Beaumont at around evening time: July 4th, 2009
In a previous blog post I introduced the definition of READY, and I wanted to do another "context" blog post before starting on this one: on the difference between flowing ("kanban") and iterating. However, I had much more to say on the subject than I expected, so the thing kept expanding... I'll gather my thoughts and publish that one later. So for the purpose of this blog post just bear with me: I find that a Product Owner's job is best done in a flow style. And since my dear ex-colleague Lars Vonk told me he was waiting for this post, I'll just explain the how here. Lars, here you go... 
Not all backlog items are equal. A backlog item starts out as a rough sketch - usually just the As a.. I want... So That... stanza - and needs to be fleshed out to the extent that it can be picked up by the team in a Sprint. Just like a team has a basic workflow getting stuff to Done, the same applies for the Product Owner role. Scrum does not have any specific support for a Product Owner: somehow the Product Backlog just "happens". In this post I'll try to fill that gap with respect to the process that a Product Owner can follow.
I'll explain a partitioning of the backlog that maps onto a flow, the nature of those partitions and how you proceed through them to get enough stuff Ready for the team to pick up in the next Sprint.
Jeff Sutherland @ nlscrum
Posted by Marco Mulder at around evening time: June 29th, 2009
Last week I co-organized an nlscrum event with a very special guest: Jeff Sutherland. After rushing with him from the airport to our Xebia office, Jeff gave a very inspiring presentation.
The Definition of READY
Posted by Serge Beaumont around lunchtime: June 19th, 2009
Yesterday I gave a presentation on the Integrating Agile conference on the answers I have found in what I consider to be the Big Black Hole of Scrum: the Product Owner role. Based on the feedback I want to blog about this subject, and unblacken the hole a bit...
The Definition of Ready
I give CSM trainings with Jeff Sutherland, and about half a year ago he had put something in his material called "the dynamic model of Scrum". The essential feature was the addition of a READY state opposite the DONE state. The idea here is that a team needs to be in a stable, known situation to be able to perform well. It immediately struck a chord with me: I had seen so many teams thrash because the Product Owner could not give them a clear objective, the READY state was exactly the goal to work to. But what was it really, and how do you get there? By now I think I've got some good answers to these questions.
Knowledge Sharing Between Distributed Teams
Posted by ShriKant Vashishtha mid-morning: June 2nd, 2009
One of the key USPs of pair-programming is - it provides value which is more than simple typing. That includes ACTIVE participation in code-review, knowledge sharing on continual basis, frequent design discussions with minimal distractions etc. If you primarily focus on knowledge sharing, pair-programming essentially provides true form of knowledge sharing as instead of looking at some bulky heartless documents you sit together with a person who has already worked on the subject and can have conversations and design discussions.
Feature Flow - Increasing velocity using Kanban
Posted by Machiel Groeneveld around lunchtime: May 28th, 2009
A few months ago I was joined a software development team that had some problems getting their process right. The team was doing Scrum by the book, apart from regular production releases they were doing it all: sprints, planning, retrospectives, Scrum board etc. This team didn't need too much explanation of Scrum so I could dive into development straight away, or so I thought. They struggled with getting the sprints right, their velocity was decreasing and spirits were low. Luckily we managed to change our process by changing some basic Scrum practices and replacing some of them with Lean practices, inspired by the new Kanban articles and presentations. Productivity is now higher than ever and we can now focus on what really matters: product quality and customer satisfaction.
(more...)
Augmented Distributed Agile Teams - The Need of Local Retrospective
Posted by ShriKant Vashishtha around lunchtime: May 21st, 2009
World is becoming a global village especially in form of communication and the dissemination of information. In context of current economic turmoil and lack of enough trained software professionals locally, distributed Agile is becoming a norm for software project execution.
Earlier, most of the times, entire distributed software project used to be executed completely at offshore because of time-zone differences and communication issues. Now because of communication revolution, you see a new trend where software companies like to extend their teams (augmented Agile teams) with different vendors. Recently while working in such a project from a distributed location, we realized the need of local retrospective.
Life on Tour: JAX 2009 Conference Review
Posted by Andrew Phillips in the wee hours: April 30th, 2009
Do you worry about crappy code? Then face reality and grow up.
Posted by Serge Beaumont around lunchtime: April 24th, 2009
My colleague Age pointed me at a blog post by Uncle Bob about a presentation where a Mr. Josuttis presented the inevitability of crappy code because "businesses will do whatever it takes to cut costs and increase revenue, and therefore businesses will drive software quality inexorably downward". Uncle Bob proceeds to go against that argument, but I find it to be a technocratic (DSLs and produce better code) and ultimately unsatisfying answer. My answer to the problem?
Face reality, grow up.
Multimedia Communication: When to use screencasts/movies in demos.
Posted by Robert van Loghem in the early morning: April 24th, 2009
For the last 9 months I've been working as a team member of Xebialabs on a product called Deployit. The product automates deployments of applications. As any Xebia team we use SCRUM for our development. Now at the end of our two week sprint we give a demo to the product owner and stakeholders of what we've been building.
We demo deploying applications onto a variety of Application Servers and other Middleware, like for instance WebSphere/Oracle-Bea Application Server/Portal, MQSeries, HTTP Servers and so on... Sometimes demo-ing a story, like deploy application A to application server B can take 10 to 15 minutes. That means, for an hour of demo time we can not show every user story that we finished in our sprint. So we only show the important ones. But what happens when demoing a story can take up to 45 minutes? How can can we cram multiple finished stories into the hour?
(more...)
Fitnesse - Selenium integration struggles
Posted by Cirilo Wortel around lunchtime: April 23rd, 2009
Recently I was challenged by a client to test a new web application in an Agile project. The team was new at working Agile and even more with working together with a functional tester, altogether this resulted in me getting very little development support from the team.
Because the lack of tooling and support I focussed my efforts on just recording test-scripts using Selenium IDE, hoping I would be able to reuse them once I got the development support I had been requesting. The plan was to integrate the pre-recorded scripts in a more extended test environment in a later stage of the project.
Archives
Xebia Sites
Categories
- Java (235)
- Agile (101)
- General (50)
- Performance (37)
- Hibernate (35)
- Podcast (31)
- Testing (30)
- Scrum (28)
- Spring (24)
- Project Management (22)
- Architecture (22)
- SOA (19)
- Flex (17)
- Maven (15)
- Eclipse (14)
- JPA (13)
- Quality Assurance (12)
- Groovy (12)
- Articles (11)
- Grails (11)