Sheep herding versus shepherding
Kimball Fisher's comparison between sheep herding and shepherding presents an interesting metaphor for a traditional Project Manager versus a
ScrumMaster.
The purpose of the sheep dog is to move sheep from A to B. Focusing on the flock itself, it achieves this by directing the flock from behind using barking and heel-nipping. Through this behaviour the sheep become dependent on the sheep dog. A sheep herder drives a subordinate flock. Sound familiar?
In contrast, a shepherd develops a relationship of trust with the sheep. From out in front of the flock, the shepherd focuses on the surroundings and clears a path for the sheep to get safely from A to B. A shepherd leads as an example and is constantly on the look-out for dangers in the environment.
Tags:
scrum,
self-organising
Links to this post
X != Y
Back in the 60s
Douglas McGregor developed two theories about human motivation in the workplace:
Theory X and Theory Y.
I'm not interested in supervising
X-people who need to be motivated and encouraged to do good work. I want to work with
Y-people, who are self-disciplined, demonstrate self-control and contextual judgement, and who motivate themselves to do good work. I'm lucky enough to be working in a team full of
Y-people.
Thinking about some
X-people I've worked with previously, I wonder if they were always
X or whether they started out as
Y but were turned into
X by prolonged subjection to command and control management? Is this a chicken and egg scenario? I'm speculating but I would guess a transformation from
Y to
X is most prevalent in institutionalised organisations that do everything by command and control. That said, what worries me is the prevalence of command and control in the industry and that it seems to be the norm.
Links to this post
Satisfy today's needs today. And worry about tomorrow's needs tomorrow
It's not cost-effective to maintain tomorrow's code today, when it's surplus to today's requirements. So, implement functionality only when you actually need it. Don't implement code just to accommodate something you (might) need in the future, nomatter how sure you are it will be needed. Focus on satisfying today's needs and forget about tomorrow's needs. This can feel counter-intuitive but remind yourself "you aren't gonna need it" [
YAGNI]. Have courage and push your fears about tomorrow to the side. And have confidence in your ability to deal with tomorrow when it comes.
By focusing on only today's needs you write less code and that can only be a good thing in my mind. It's quicker to write less code, and coupled with a simple design and merciless refactoring, it keeps the implementation small and testable while reducing the opportunities for defects. Also, less code that is clean, self-documenting and communicates the intentions of the developer is easier to understand.
Focusing on today's needs also applies to the architecture. I favour evolving an architecture over Big Design Up Front [
BDUF]. For the last 6 years I've worked on high-performance, high transaction rate enterprise systems and it took me a while to get comfortable with this approach. You need to understand the non-functional system characteristics you're aiming for and regularly assess the system against these criteria, evolving the architecture and optimising as you go. There's no doubt that this is seat-of-the-pants stuff and to pull it off you need courage, discipline and expert application of the
Extreme Programming practices.
Tags:
yagni,
bduf
Links to this post
Iteration zero
We recently completed iteration zero to setup our project ready for development. Here's what we completed in the iteration:
- Installation of RedHat Fedora Core on the Continuous Integration, DEV and UAT servers.
- Installation of Subversion, Maven2, and Cruisecontrol on the Continuous Integration server. We created our own Maven2 repository to contain artifacts not available in the central repository at ibiblio. Cruisecontrol was configured with a continuous integration project that builds the whole application and runs all the tests on a check-in to Subversion. We used Maven2 profiles to provide targeted deployment to the DEV and UAT servers. The DEV profile was configured as a separate Cruisecontrol project scheduled to deploy a nightly build to the DEV server to enable our customer to 'play' with functionality as it is developed in each iteration.
- Installed and configured the following tools, frameworks and applications on the DEV and UAT servers and the developer workstations:
- The developer workstations also had Eclipse installed with the following plugins:
- Conducted spikes for FIT, FIT Library, and Selenium.
- Customised Maven2's site.xml to publish the FIT tests on the Maven2 reports page on the project Web site.
- Completed some introductory training on collaboration and Agile teams, Extreme Programming and Scrum. More will follow on-the-job through coaching.
- Completed a chartering session (more about this in a later post) where the team, including our customer, created a guiding vision statement for the project, defined futurespective success criteria, noted assumptions and constraints, identified the project community and agreed working practices.
- Produced an initial product backlog with our customer. This product backlog comprises a goal roadmap identifying the high-level goals for the next 6 months (corresponding to 6 releases, 1 every 4 weeks). Each high-level goal was broken down into 4 sub-goals corresponding to potential iteration goals (we're using 1-week iterations).
- Completed a release planning game for the first release. We took the high-level goal for the first release and broke the 4 sub-goals into user stories, grouping the story cards according to the sub-goals. Our customer prioritised each grouping by business value. Using planning poker [pdf], the team provided coarse estimates in ideal pair days. Since the team had not worked together before we did not have an empirical velocity. To use only as a starting point, the team decided on a calculated velocity of half the number of pair days in the release (based on the assumption that one ideal pair day equalled one elapsed day). Using these estimates and the velocity, our customer and the team agreed on a final set of user stories for the release that would deliver the release goal.
- Set up our planning boards to show the goal roadmap, and the current release and iteration plans. (I'll describe our planning boards in more detail in a later post)
- Wrote enough code to help us set up the automated build, configure Cruisecontrol, and play around with FIT, FIT Library, and Selenium.
We still have to complete the following tasks so we'll do them as slack over the next few iterations:
We haven't got our bullpen yet but I've obtained permission to reogranise the workspace subject to cost. We're in a rented office space and something as simple as constructing a bullpen costs silly money, so we're waiting on the quote from the landlord. If we get the go-ahead we'll need rectangular desks (the office is furbished with those curvy desks) to make the layout easier and more efficient, and to make pair programming more comfortable.
Tags:
iteration zero,
extreme programming
Links to this post
Take a look at
InfoQ. It's in preview mode until June 8th but already it looks like there's going to be some good content there. Go and
register now.
Deb Hartmann, the Agile Editor of
InfoQ emailed me last night to inform me that my blog post about the
Daily Stand-up / Scrum meeting has been referenced in
Keeping those stand up meetings short and sweet. Groovy! Hopefully more of my blog posts will make it onto
InfoQ in the future.
Links to this post
